Your SlideShare is downloading. ×
0
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
How eXcale Built a PaaS on AWS
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

How eXcale Built a PaaS on AWS

3,143

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,143
On Slideshare
0
From Embeds
0
Number of Embeds
14
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. How eXcale built a PaaS on AWS 2014年4月5日 西谷圭介
  • 2. 自己紹介 西谷圭介 TIS株式会社 eXcaleというPaaSの企画開発やってます 開発チーム(6名)のマネージャ兼デベロッパ兼マーケティング 当然コードも書きます 好きなAWSサービス:ELB, Route53 好きなCDP: Direct Hostingパターン @Keisuke69 https://www.facebook.com/keisuke69 https://github.com/Keisuke69
  • 3. TIS株式会社 金融・カード系を得意とするSIer 事業内容 ITコンサルティング システム構築サービス アウトソーシングサービス ソリューション/クラウドコンピューティングサービス アドバンスドコンサルティングパートナー AWSのインテグレーションサービスとかもやってます
  • 4. ?What's
  • 5. 2012年10月15日betaサービス開始 Webアプリケーション向け Node.js, PHP, Ruby, Javaに対応 オートスケール メールアドレスだけでサインアップ可能 2013年11月15日よりサービスの一部を有料化 初期費用なし、利用機能・スケール量に応じた完全従量 課金
 有料タイプ・・・0.66円/1時間
 1プロセス・・・2.85円/1時間 詳しくはWebで
 https://www.excale.net/
  • 6. 現時点ではいわゆるPaaS 2012年10月15日betaサービス開始 メールアドレスだけでサインアップ可能 2013年11月15日よりサービスの一部を有料化 初期費用なし、スケール量に応じた完全従量課金
 有料タイプ・・・0.7円/1時間
 1プロセス・・・3円/1時間 詳しくはWebで
 https://www.excale.net/ ! サインアップ! キャンペーン実施中!
  • 7. eXcale is built on AWS
  • 8. eXcale is built on AWS Route53 Web Git for user Request Router API MQ DB Backend DB ユーザインスタンス ユーザDB Job EMR AMI S3 Glacier DB S3 SES
  • 9. Why AWS
  • 10. なぜAWSか 自前でインフラを持ちたくなかったため 人数も予算も少ないので見積もり、調達、センターへの搬入 といった行為にリソースを割きたくなかった コストコントローラブル 使い方次第でコストのかけ方を変動させられる スモールスタート可能 プログラマブル 人数の少ないチームでは人手の定形運用作業は厳しい コスト効果を最大限に得るためにもプログラムからの制御は 必須
  • 11. AWSの利用状況 使っているサービス/機能 EC2, ELB, EBS, ElasticIP VPC S3 Glacier Route53 SES EMR IAM AWS Support 全てVPC上で稼働、RI購入 ただし、当たり前だが無尽蔵ではない AMC/APIの向こうにある物理の壁は確実に存在する キャパ不足によって苦しんだこともあり(今は解決) Auto Scaling、CloudWatchは使っていない 独自のmetric、計算でスケールアウトさせたかったため 開発環境として同一構成の小規模なセットを用意 定時で強制停止 開発環境を日次で起動停止してたらSpikyと見なされて起動に制限がかかってしまった 早くCloudTrailの東京リージョン対応を!
  • 12. Philosophy
  • 13. 目指したこと 今まで通りのアプリケーション開発でPaaSならではのメ リットを得られるようにする 容易なデプロイ オートスケール アプリケーション開発における「手間」の排除 以下の4項目を同時に実現した上でPaaSのメリットを実 現する機能を加える 自由度 分離性 ポータビリティ オープン
  • 14. 目指したこと 自由度 言語が持つAPIに対する利用制限を設けない ユーザが利用するフレームワークに対し制限を設けない ポータビリティ ローカルで開発したものや標準的なWebアプリケーションであれば限りなく無 修正で稼働可能とする サービス固有の実装、設定ファイル等を要求しない 分離性 他テナントへのOSレベルでのアクセスを防ぐ 他テナントのアプリケーションクラッシュやリソース高騰等による影響を防ぐ オープン性 利用できる言語は世間一般的に利用される言語とし、独自言語は定義しない 標準SQLを利用可能とする アプリケーションが利用できるテクノロジーは標準的なものとし、プロプライ エタリなプロトコル、手続きを必要としない
  • 15. 実現する上での課題 言語が持つAPIを自由に利用できるようにするというこ とはアプリケーション内部からOSレイヤへのアクセスが 可能になるということ ネットワーク/ファイルシステムIO OSコマンドの実行 OSレイヤにアクセス可能ということは同一ホストの他ア プリケーションへもアクセス可能になってしまう いかにテナントを分離した上でリソース効率を高めるか 一番簡単なのは1アプリ=1ゲストOS(VM)だがリソース効率は 悪い 実行時のユーザを分けることでも一部は制御可能だが現実的 ではない
  • 16. 課題に対するアプローチ 1プロセス = 1アプリ 1アプリに1プロセスを占有させることで他テナント起因のメモリ 不足やGC、クラッシュによる影響を防ぐ アプリケーション内部からOSレイヤへのアクセスはLXCで プロセスが稼動するOS空間をコンテナ化することで対応 自テナントでのファイルIO等は許可しつつ、同一ホスト上の他テ ナントへのアクセスを制限 他のユーザ権限で稼動するプロセスも見えない 実行プロセスのみをコンテナ化 OSが稼動するわけではないためコンテナごとにOSをインストー ルする必要なし 各コンテナは使えるOSのコマンドや共有ライブラリを必要最低限 に絞ることでコマンドインジェクションを防ぐと同時に小容量化
  • 17. Instance アーキテクチャ Request Router Computing Resource  DB Server for App a Instance Instance InstanceInstance Application Runtime System Library …… DB Server for App b a.excale.net b.excale.net ・インスタンス毎の空間は論理的に独立 ・別インスタンスの空間へアクセス不可 ・インスタンスからOSコマンド実行不可 ・DBはアプリごとに独立 Random Internet App a App b
  • 18. AWSで実現するにあたり LXCがAmazon Linuxでは使えなかった(当時) カーネルのリビルドしてゴニョゴニョしてみたが厳しい 最初から使えるUbuntuを利用 アプリケーションインスタンスに割り当てるIPの問題 ホストとなるEC2インスタンスごとに小さなサブネットを割 り当て ブリッジインターフェースを定義し、それを介して外部と通 信 ユーザのリクエストのルーティング 後述
  • 19. Infrastracture
  • 20. Infrastructure Route53 Web Git for user Request Router API MQ Backend ユーザインスタンス ユーザDB Job EMR AMI S3 Glacier S3 SES DB DB DB
  • 21. DB DB DB アプリケーション Route53 Git for user Request Router MQ ユーザインスタンス ユーザDB EMR AMI S3 Glacier S3 SES Web API Backend Job RubyとJava Webはビューのみ提供 バックエンドは制御系とプロビジョニング系の2種類 Nginx Thin Rails Web Jetty Spring API
  • 22. データベース Route53 Web Git for user Request Router API MQ Backend ユーザインスタンス ユーザDB Job EMR AMI S3 Glacier S3 SES DB DB DB MongoDB 目的に応じたレプリカセットが3つ ログ用を除いてデータ量はそれほどでもない ログ用も期限データなのである一定以上は増えない チューニングはほとんどしていない 運用面倒なのでDynamoDBとRDSに移行したい が、アプリの書き換えが発生するので悩ましい
  • 23. DB DB DB MQ Route53 Web Request Router Job EMR AMI S3 Glacier S3 SES Git for user API MQ Backend ユーザインスタンス ユーザDB RabbitMQ (Mirrored) コンポーネントをまたいだ処理は全てキュー経由 基本的には各コンポーネントはメッセージを発行するだけ バックエンド系はメッセージの発行だけでなく取得も行う 性能不足の際は各ロールのサーバを何も考えずに追加すればよい
  • 24. 開発言語とアプリ名、アプリのタイプを入力する アプリケーションの作成 ユーザ インスタンス DBサーバ gitリポジトリ公開用URL 作成 http://~ ただし、アプリ名はeXcale上で稼働する全てのアプリで一意である必要あり 公開用URL: http://<アプリ名>.excale.net
  • 25. DB アプリケーションの作成 Request Router Job EMR AMI S3 Glacier S3 SES API MQ Backend DB ユーザインスタンス ユーザDB Web DB Route53 リクエストを受ける 空きホストを探す gitリポジトリ作成、コンテナイメージの展開と起動、DBの作成 インスタンスの起動チェック後、DNSへ登録 Git for user
  • 26. アプリケーションのデプロイ 用意されたGitリポジトリにgit push
  • 27. APIWeb DB DB アプリケーションのデプロイ Request Router Job EMR AMI S3 Glacier S3 SES MQ Backend DB ユーザインスタンス ユーザDB Route53 Git for user gitサーバ上で、依存性チェックの後、ビルドおよびパッケージング パッケージングされたアプリケーションをmongoのGridFSに保存 コンテナイメージの展開と起動、DBの作成 インスタンスの起動チェック後、DNSへ登録
  • 28. リクエストルーティング Web Git for user API MQ Backend ユーザDB Job EMR AMI S3 Glacier S3 SES DB DB DB Route53 Request Router ユーザインスタンス Customized Nginx TwistedNames Based DNS Memcached MongoDB ユーザのアプリケーションへのリクエス トをルーティング Nginxをベースとしてほんの少しだけ手 が加えられている インスタンスごとにDNSとMemcached を配置 DNSはTwistedNamesをMongoDBに対応 させた上で独自のアルゴリズムで名前解 決
  • 29. リクエストルーティング Route53 Nginx+ Twisted! Names+ Memcached LXC Processes Nginx+ Twisted! Names+ Memcached MongoDB ReplicaSet LXC Processes
  • 30. リクエストルーティング Route53 Nginx+ Twisted! Names+ Memcached LXC Processes Nginx+ Twisted! Names+ Memcached MongoDB ReplicaSet LXC Processes ワイルドカードでリクエストルータ用 ELB
  • 31. リクエストルーティング Route53 Nginx+ Twisted! Names+ Memcached LXC Processes Nginx+ Twisted! Names+ Memcached MongoDB ReplicaSet LXC Processes ①リクエストされた ②、③ルーティング先の ※キャッシュを確認、なければ ④リクエストを転送 ① ② ③ ④
  • 32. DB Route53 Web Git for user Request Router API MQ Backend AMI S3 SES DB アカウンティング(課金) Glacier Ruby JobScheduler fluentd EMR 大きく分けて記録、集計、計算の 3プロセス ユーザのアプリケーションの状況 を分単位で記録 記録したデータをEMRで集計 集計結果に対して課金額を算出 将来的にはKinesis使ってよりリ アルタイムに近い形にしたい 現在は1時間に1回バッチ更新 ユーザインスタンス ユーザDB Job EMR DB S3
  • 33. Route53 Web Git for user Request Router API MQ Backend ユーザインスタンス ユーザDB Job EMR AMI S3 SES DB DB ロギング S3 Glacier DB fluentd、MongoDB、elasticsearch、Kibana、Nginx fluentdで全サーバのログをアグリゲータへフォワード アグリゲータはMongoDB / elasticsearch / S3に書き込み MongoDBとelasticsearchはほぼリアルタイム MongoDB・・・障害時等の横断的な検索用途 elasticsearch・・・リアルタイムログ解析用途 S3・・・ログの長期保管用途、即日Glacierへと移動
  • 34. Route53 S3 Web Git for user Request Router API MQ Backend ユーザインスタンス ユーザDB Job EMR AMI S3 Glacier DB DB DB その他 SES Zabbixで監視 Cloudwatchは使っていない アラートはSESを使ったメール通知とHipChatへの通知 GithubのIssueを自動で起票 インスタンス数の増減が激しい環境では厳しい Sensuに置き換えることを検討中
  • 35. SES Web Git for user Request Router API MQ Backend ユーザインスタンス ユーザDB Job EMR AMI S3 Glacier DB DB DB その他 Route53 S3 静的コンテンツはS3上から直接配信 ダイレクトホスティングパターン ドキュメントサイトやブログの画像等 Route53でドキュメントサイトのサブドメイ ンをバケット名に紐付け
  • 36. スケールアウト Auto Scalingは利用していない 独自のメトリックで制御したかったため スケールアウトのトリガ ユーザのアプリケーション数 ユーザのアプリケーションインスタンスの負荷 ホストサーバの負荷 モニタリング用の仕組みはRuby製のオリジナル Zabbix等の既存監視ツールでは計算処理を伴うモニタリング は難しかったため モニタ状況に応じてMQにイベント発行 イベントを拾ったら内部的にサーバの増減の要否を判断した 上でEC2インスタンスを追加 不要になったら同じく計算した上でterminateを実施
  • 37. 運用
  • 38. 運用 サーバを1台ずつ管理することはしていない 各サーバのシステムにおける役割をロールとして定義 ロール単位の管理のみ スケールアウト時も対象ロールのサーバをAMIから起動するだけ。不要に なったらterminate 作業は基本的にRubyスクリプトかCapistranoを使って実装 作業手順のレビュー = コードレビュー サーバログインしてコマンド叩くような処理はCapistrano、それ以外 は全て普通のRubyプログラム Chefの導入は検討中 プロジェクト初期に一度導入したがCapistranoでいいじゃんってこと になった Capistranoで書くのは冗長、台数も増えてきたので最近また導入を検 討中
  • 39. 課題
  • 40. 課題 サーバ管理に時間を取られる オンプレで構築するよりははるかにマシだがそれでも・・・ 障害時など後手を踏みがち ネットワーク構成、セキュリティグループが複雑化 とある一時点の構成が把握しづらくなっている Capistranoで自動処理をしているがこれだと「今」の状態が分かり づらい Capistranoのコードが散らかっている オペレーション単位で用意されがちで再発明を繰り返しがち その場しのぎのアドホックなコードが多く再利用性に乏しい 為替の変動 古く小さいインスタンスタイプに縛られている
  • 41. 2nd generation of Infrastructure 現在第2世代のインフラを検討・構築中 Cloudformationを使ったAWSサービスのテンプレート化 OpsWorks(Chef)を使った構成管理 内部DNSによる、より動的な構成 PowerDNS + RDS + Dnsmasq +独自API マネージドサービスの積極利用 RabbitMQ → SQS MongoDB → DynamoDB + RDS MongoDB → ElasticCache Memcached → ElasticCache いつでも再構成可能なインフラに 現行のインフラから全面移行予定 VPC Peering Connectionが大活躍中 大幅にアプリケーションの書き換えが発生することが障壁
  • 42. 公式資料など eXcale https://www.excale.net/ ドキュメント http://doc.excale.net/ ブログ http://blog.excale.net/ サポート https://github.com/eXcale-support/eXcale/issues twitter @eXcale_official Facebook https://www.facebook.com/excale.net
 ※「いいね!」をお願いします!

×