Building Scalable Application on the Cloud

3,829 views

Published on

2016年3月19日に開催されたInnovation Eggでお話した際の資料です

Published in: Software
0 Comments
11 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,829
On SlideShare
0
From Embeds
0
Number of Embeds
2,158
Actions
Shares
0
Downloads
18
Comments
0
Likes
11
Embeds 0
No embeds

No notes for slide

Building Scalable Application on the Cloud

  1. 1. Building Scalable Application on the Cloud Keisuke Nishitani (@Keisuke69) Amazon Web Services Japan K.K.
  2. 2. Profile Keisuke Nishitani Solutions Architect, Amazon Web Service Japan K.K @Keisuke69 Keisuke69 ✤ AWSのソリューションアーキテクト ✤ Webサービス系 ✤ モバイル系 ✤ クラウドを使ったアプリ開発とかモバイル開発の話しをよくしてい ます ✤ モバイルニンジャ1号機 ✤ RESTおじさん ✤ Lambda Wizards ✤ 餃⼦の王将エヴァンジェリスト(⾃称) ✤ ブログ: http://keisuke69.hatenablog.jp/ Keisuke69 Keisuke69Keisuke69
  3. 3. Every day is still Day One 「我々はこの先の⻑い道のりから⾒るとStill Day One(まだ1⽇⽬)です。 まだ朝⾷も⾷べていません。」
  4. 4. 今⽇のお話
  5. 5. スケーラブルな アプリケーション
  6. 6. クラウドネイティブ
  7. 7. クラウドネイティブ = スケーラブル but スケーラブル ≠ クラウドネイティブ
  8. 8. クラウドネイティブ? Photo credit: Samer AlQaisi via VisualHunt / CC BY-SA
  9. 9. クラウドネイティブ ✤クラウドの特性を踏まえ、利点を最⼤限に活かす形で構築されたアプ リケーション ✤クラウドで提供されるサービスを利⽤して効率的にアプリケーション を実装
  10. 10. クラウドネイティブ ✤クラウドの特性を踏まえ、利点を最⼤限に活かす形で構築されたアプ リケーション ✤クラウドで提供されるサービスを利⽤して効率的にアプリケーション を実装
  11. 11. クラウドネイティブ ✤クラウドの特性を踏まえ、利点を最⼤限に活かす形で構築されたアプ リケーション ✤クラウドで提供されるサービスを利⽤して効率的にアプリケーション を実装 ⼤事なのはこっち
  12. 12. クラウドの特性 ✤障害を前提としたデザイン(Design for failure) ✤疎結合 ✤弾⼒性の実装 ✤全てのレイヤでセキュリティを担保 ✤制約を恐れない ✤並列処理 ✤複数あるストレージのオプション
  13. 13. The 12 Factor App
  14. 14. The 12 Factor App ✤モダンなWebアプリケーション開発のための⽅法論 ✤直接的にクラウドと関連する話しではないが⼀読しておくべき ✤URL http://12factor.net/ http://12factor.net/ja/(⽇本語訳)
  15. 15. The 12 Factor App ✤Codebase - コードベース - ✤バージョン管理されている1つのコードベースと複数のデプロイ ✤Dependencies - 依存関係 - ✤依存関係を明⽰的に宣⾔し分離する ✤環境に依存しないこと ✤Config - 設定 - ✤設定を環境変数に格納する ✤設定などの環境によって異なる可能性があるものはOSレベルの環境変数によって注⼊ されるべきである ✤Backing services - バックエンドサービス - ✤バックエンドサービスをアタッチされたリソースとして扱う ✤データベースやメッセージブローカーといったものはアタッチされたリソースとして 扱う
  16. 16. The 12 Factor App ✤Build, release, run - ビルド、リリース、実⾏ - ✤ビルド、リリース、実⾏の3つのステージを厳密に分離する ✤Process - プロセス - ✤アプリケーションを1つもしくは複数のステートレスなプロセスとして実⾏す る ✤プロセス間で何も共有はしない ✤Port binding - ポートバインディング - ✤ポートバインディングを通してサービスを公開する ✤Concurrency - 並⾏性 - ✤プロセスモデルによってスケールアウトする ✤⽔平⽅向へのプロセスのスケールアウトによって並⾏性を担保する
  17. 17. The 12 Factor App ✤Disposability - 廃棄容易性 - ✤⾼速な起動とグレースフルシャットダウンで堅牢性を最⼤化する ✤Dev/prod parity - 開発/本番⼀致 - ✤開発、ステージング、本番環境をできるだけ⼀致させた状態を保つ ✤CI/CDは各環境が揃っていることで実現される ✤Log - ログ - ✤ログをイベントストリームとして扱う ✤中央集権的なサービスによってイベントを集約、インデックス化し分析する環 境が実現される ✤Admin processes - 管理プロセス - ✤管理タスクを1回限りのプロセスとして実⾏する
  18. 18. Microservices Photo credit: wildxplorer via Visual hunt / CC BY
  19. 19. Microservices Architecture The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies. -- James Lewis and Martin Fowler
  20. 20. 9つのポイント ✤Componentization via Services ✤Organized around Business Capabilities ✤Products not Projects ✤Smart endpoints and dumb pipes ✤Decentralized Governance ✤Decentralized Data Management ✤Infrastructure Automation ✤Design for failure ✤Evolutionary Design
  21. 21. Microservicesとは ✤サービスを単⼀のアプリケーションではなく⼩さなサービスの組み合 わせで構築する ✤各サービスは独⽴したサービスであり、単⼀でデプロイと実⾏が可能 なものである ✤技術的な境界で分割するのではなくビジネスの遂⾏能⼒で分割する ✤サービスをデプロイするのに必要な能⼒を持てるように分割する ✤組織構造と密接に関連 ✤機能だけ別チーム・別サービスでDBは共通で持つというようなことはしない ✤サービス間のコミュニケーションは軽量な⼿段を利⽤する ✤単⼀アプリにおけるインメモリのメソッド呼び出しではなくなる ✤HTTPは最良の選択肢の1つであり、RESTful APIによる呼び出しがよく利⽤さ れる
  22. 22. Microservicesの利点 ✤「モノリシック」なシステムからの解放 ✤単独でデプロイ・実⾏可能であるため、個々のサービスで⾃由にス ケールすることが可能 ✤各サービスで独⽴性の⾼い実装が可能 ✤⾔語、DBなど全てのサービスで同じものを使う必要がない ✤各サービスごとに最適と思われるものを選択可能 ✤サービス間は独⽴しているため、個々の可⽤性の問題が全体に影響し ない ✤ビジネス上の境界とより密接にアラインされる ✤パラレルな開発とデプロイ ✤迅速なデプロイ
  23. 23. The Amazon Way Photo credit: jurvetson via Visual Hunt / CC BY
  24. 24. Monolithicな開発サイクル developers releasetestbuild delivery pipelineapp
  25. 25. 2 Pizza Rule AMAZON CONFIDENTIAL
  26. 26. Two Pizza Team ✤作るものに対する全てを負う ✤プロダクト計画(ロードマップ) ✤開発 ✤運⽤ ✤サポート ✤You build it, you run it ✤DevOps 27
  27. 27. Microservicesな開発サイクル developers delivery pipelinesservices releasetestbuild releasetestbuild releasetestbuild releasetestbuild releasetestbuild releasetestbuild
  28. 28. アプリケーションの実装パターン
  29. 29. アプリケーションの実装パターン ✤いくつかの典型的なパターンがある ✤シンプルなものから複雑なものまで ✤どのやり⽅が許容できるかはチームで決めること ✤短期的にはシンプルなアプローチを取ったほうがいい ✤最初に選んだやり⽅を最後まで貫く必要はない ✤柔軟に変更する
  30. 30. Graceful Degradation ✤500エラーは返さない ✤⼀部に障害やエラーがあっても全体の停⽌を引き起こさず、その他の 機能は有効に機能させる ✤最悪な例:
  31. 31. Throttling ✤内部サービスによる偶発的なDoSが引き起こされることはよくある問 題 ✤リクエストに対するスロットリングが基本的な防御⽅法 ✤スロットリングにはユーザ単位であったり、ソースアドレス単位で あったり、あるいはその組み合わせも ✤計測は常に⼤事 ✤API Gatewayを使えば簡単にできます
  32. 32. Fail Fast ✤エラーを検知したらなるべく早く返す ✤メモリ不⾜などの問題出会った場合、素早い回復が可能になることが 多い ✤エラーの原因が軽減されれば、サービスは再び正常に動作する
  33. 33. Fail Silently ✤エラーを内部的に処理した上で、ユーザには成功を⽰すレスポンスを 返す ✤Webサービスであれば内容がない200 OKを返す ✤正常終了のコードを返す ✤当然、内部的にはエラーとなっているため、それを検知するためのロ ギングは⾏うこと
  34. 34. Static Fallback ✤エラー時には何らかの静的なコンテンツもしくは値を返す ✤返すコンテンツにはリクエストのコンテキストがわかるものを含める こと ✤ハードコーディングせずに変更可能にすること
  35. 35. Retry ✤失敗は⼀時的なものが多いのでシンプルにリトライすることで成功す ることが多い ✤スロットリングに対する対応も同様 ✤エラーが起きたら、少し待った上でリトライする ✤Exponential back offもしくはフィボナッチ数列を利⽤したリトライ間 隔の調整を⾏う ✤Exponential back off ••• リトライ間隔を指数関数的に⻑くしていくアルゴリズ ム ✤無制限にリトライするのではなくどこかでエラーとして判断すること が必要
  36. 36. Caching ✤サービス呼び出しに対するレスポンスをキャッシュする ✤リクエストを受け取ったら、最初にキャッシュをチェックし、キャッ シュがない場合や期限切れの場合にだけバックエンドへとコールする ✤レスポンス時にはキャッシュにも書き込みを⾏う ✤キャッシュがあった場合はキャッシュを⽤いてレスポンスする
  37. 37. Circuit Breaker ✤発⽣したエラー数を記録し、閾値を越えたときにフォールバックプラ ンを実⾏する ✤⼀般的にはFail fastと同じくエラーを素早く返す ✤故障箇所を部分的にかつ迅速に切り離すことでサービス全体への影響 を防ぐ ✤機能を回復させるために定期的にヘルスチェックする
  38. 38. Think Parallel ✤処理を並列化することでレイテンシを⼩さくする
  39. 39. Smooth Internal Traffic ✤キューの利⽤ ✤コンポーネント間にキューを置いて、内部トラフィックをなだらかにするバッ ファとして利⽤ ✤スパイク的な負荷をハンドリング
  40. 40. Microservicesの考慮点 ✤分散した複数のコンポーネントを扱うことの難しさ ✤サービス単位で独⽴して実⾏可能な状態にするということはそれだけ⼩さいシ ステムが増えるということ ✤複数のコンポーネントを協調動作させることの難しさ ✤コンポーネント間のコミュニケーションメッセージの増加によるレイ テンシ増 ✤トランザクションの取り扱いと結果整合性の検討 ✤サービスディスカバリ ✤分散するシステムのテストにおける複雑さ ✤分散するシステムの運⽤とデプロイの複雑さ
  41. 41. AWS上で構築する場合のパターン ✤API Gateway + Lambda ✤EC2 + ECS ✤EC2 + Elastic Beanstalk ✤EC2 + ELB + ASG + Runtime
  42. 42. AWS上で構築する場合のパターン ✤API Gateway + Lambda ✤EC2 + ECS ✤EC2 + Elastic BeanStalk ✤EC2 + ELB + ASG + Runtime
  43. 43. API Gateway + Lambda ✤サーバレスアーキテクチャ ✤ELB/EC2を使わずAPI Gatewayと Lambdaで応答 ✤Lambdaファンクションから各AWSサー ビスを利⽤ ✤EC2を利⽤した別システムへのアクセス も当然可能 ✤運⽤/構築/開発からの解放 ✤コスト効率が⾼く、多くの場合コス ト減に Lambda API Gateway AWSサービス S3 CloudFront
  44. 44. Amazon API Gateway 複数バージョンや複数環境 へのデプロイを管理 APIの定義とホスティング クラウド上のリソースへのアクセ ス認証におけるAWS IAMの活⽤ AWSのAuthを活⽤ バックエンド保護のため のDDoS対策やリクエス トのスロットリング ネットワークトラフィックの管理 開発者がAPIの運⽤を気にせずに作成、公開することを可能にするサービス
  45. 45. Amazon API Gateway 複数バージョンとステージ APIキーの作成と配布 リクエスト時におけるAWS SigV4の利⽤ リクエストのスロットリングとモニタリング バックエンドとしてAWS Lambdaが利⽤可能
  46. 46. Amazon API Gateway レスポンスをキャッシュ可能 CloudFrontを利⽤したレイテンシの軽減とDDoS対策 iOS、AndroidとJavaScript向けSDKの⾃動⽣成 Swaggerのサポート Request / Responseにおけるデータ変換
  47. 47. Amazon API Gateway レスポンスをキャッシュ可能 CloudFrontを利⽤したレイテンシの軽減とDDoS対策 iOS、AndroidとJavaScript向けSDKの⾃動⽣成 Swaggerのサポート Request / Responseにおけるデータ変換
  48. 48. Lambdaファンクション: ステートレス、トリガーベースのコード実⾏ AWS Lambda あらゆるスケールで⾼性能 費⽤対効果が⾼く効率的 インフラ管理不要 使った分だけの⽀払い リクエスト量に応じて⾃動的に キャパシティ調整 100ms単位のコンピュート課⾦ ⾃⾝のコードを持ち込み 標準的な⾔語でコードを実⾏ スレッド、プロセス、ファイル やシェルスクリプトも利⽤可能 インフラではなくビジネスロジック に集中可能 コードをアップロードするだけで、 Lambdaが全てをハンドリング
  49. 49. AWS Lambda ✤インフラを⼀切気にすることなくアプリケーションコードを実⾏でき るコンピュートサービス ✤実⾏基盤は全てAWSが管理 ✤AWSサービスと連携させることで簡単にイベントドリブンなアプリケーション を実装可能 ✤コード実⾏時間に対しての課⾦でありコスト効率が⾮常に⾼い ✤VPC内のリソースへのアクセスも可能 ✤Lambda function ✤JavaScript(Node.js)およびJava、Pythonで記述 ✤サードパーティライブラリも利⽤可能
  50. 50. AWSのサービスと連携可能 ✤Amazon S3 ✤Amazon Kinesis ✤Amazon DynamoDB ✤Amazon Cognito ✤Amazon SNS ✤Alexa AppKit ✤Amazon SWF ✤Amazon SES inbound mail ✤Amazon CloudWatch Events ✤Amazon CloudWatch Logs ✤Amazon Connected Home ✤AWS IoT ✤AWS CodePipeline ✤AWS CodeDeploy ✤AWS CloudFormation
  51. 51. サーバレスアーキテクチャのメリット ✤アプリの開発に多くのメリット ✤バックエンド側のコードが減るため開発コストを最⼩化 ✤バックエンド側のサーバが減るため運⽤コストを最⼩化 ✤AWSによってマネージされるため、スケーラビリティやキャパシティ、セキュ リティの⼼配不要 ✤⾮常にコスト効率が⾼く、多くの場合コスト減が⾒込める ✤必要に応じてEC2も導⼊できる安⼼感 ✤汎⽤的なサービスでは実現の難しい、ビジネス固有の要件に関してはEC2を利 ⽤して実装 ✤EC2を利⽤する部分についてもCodeDeployやElastic Beanstalk、OpsWorks等 で⾃動化
  52. 52. よくある課題 ✤インフラ構築 → 不要 ✤インフラの運⽤管理 ✤キャパシティ ✤スケール ✤デプロイ ✤耐障害性 ✤モニタリング ✤ロギング ✤セキュリティパッチの適⽤ ✤ビジネスの差別化には直接繋がらない機能のアプリ実装 ✤認証 ✤スロットリング ✤スケーラビリティの確保
  53. 53. よくある課題 ✤インフラ構築 → 不要 ✤インフラの運⽤管理 ✤キャパシティ ✤スケール ✤デプロイ ✤耐障害性 ✤モニタリング ✤ロギング ✤セキュリティパッチの適⽤ ✤ビジネスの差別化には直接繋がらない機能のアプリ実装 ✤認証 ✤スロットリング ✤スケーラビリティの確保 不要(各サービスが適切にハンドリング) 不要
  54. 54. 付加価値を⽣まない 重労働からの解放
  55. 55. 「何をするか」 を書くだけでいい
  56. 56. 「何をするか」 を書くだけでいいAll you need is code.
  57. 57. However
  58. 58. You need more flexibility?
  59. 59. Use container.
  60. 60. You need longer timeout?
  61. 61. Use container.
  62. 62. AWS上で構築する場合のパターン ✤API Gateway + Lambda ✤EC2 + ECS ✤EC2 + Elastic BeanStalk ✤EC2 + ELB + ASG + Runtime
  63. 63. What are containers? ✤プロセスの隔離 ✤イメージ ✤⾃動化 Server Guest OS Bins/Libs Bins/Libs App2App1
  64. 64. Containerのメリット ✤Portable ✤Flexible ✤Fast ✤EfficientServer Guest OS Bins/Libs Bins/Libs App2App1
  65. 65. Containerのメリット ⼀貫性のある環境 ⾼い⽣産性 バージョン管理 効率的な オペレーション
  66. 66. FROM ubuntu:14.04 MAINTAINER John Doe <jdoe@example.com> RUN apt-get update && apt-get install -y curl wget default-jre git RUN adduser --home /home/sinatra --disabled- password --gecos '' sinatra RUN adduser sinatra sudo RUN echo '%sudo ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers USER sinatra RUN curl -sSL https://get.rvm.io | bash -s stable RUN /bin/bash -l -c "source /home/sinatra/.rvm/scripts/rvm" RUN /bin/bash -l -c "rvm install 2.1.2" RUN /bin/bash -l -c "gem install sinatra" RUN /bin/bash -l -c "gem install thin" Package
  67. 67. docker push docker pullShip
  68. 68. docker runRun
  69. 69. Cluster Management
  70. 70. $ docker run myimage Server Guest OS Bins/Libs Bins/Libs App2App1
  71. 71. Amazon EC2 Container Service (ECS) ✤Dockerコンテナを複数のEC2インスタンスに分散配置できる ✤⼀時的な計算処理にも、ロングランニングな処理にも対応 ✤ELB連携など各種AWSサービスとの親和性 ✤Amazon ECS⾃体の利⽤は無料 複数のコンテナをEC2のクラスタ上で⼀元管理できるサービス
  72. 72. Cluster Management Engine Agent Communication Service API Key/Value Store Amazon ECS AZ ECS Agent Container Instance Task Container Task Container Docker AZ ECS Agent Container Instance Task Container Task Container Docker ECS Agent Container Instance Task Container Task Container Docker ELB ELB User/Scheduler
  73. 73. Cluster管理を簡単に ✤クラスタ管理ソフトの導⼊不要 ✤クラスタの状態管理 ✤コンテナの管理 ✤コントロールとモニタリング ✤1コンテナから数万コンテナまで スケール
  74. 74. フレキシブルなコンテナ配置 ✤アプリケーション ✤バッチジョブ ✤複数のスケジューラ
  75. 75. AWSサービスとの連携 ✤Elastic Load Balancing ✤Amazon Elastic Block Store ✤Amazon Virtual Private Cloud ✤AWS Identity and Access Management ✤AWS CloudTrail
  76. 76. Service Discovery/Registry? Hashicorp Consul ✤DNSもしくはHTTP経由でのエンドポイン トの登録と探索 ✤エンドポイントへのヘルスチェック ✤動的コンフィグレーションなどのための Key/Valueストア
  77. 77. AWS上で構築する場合のパターン ✤API Gateway + Lambda ✤EC2 + ECS ✤EC2 + Elastic BeanStalk ✤EC2 + ELB + ASG + Runtime
  78. 78. 普通の話なんで割愛
  79. 79. おまけ Photo credit: marcopako via VisualHunt.com / CCBY-SA
  80. 80. 忘れちゃいけないDevOps Photo credit: www.pierrelognoul.be via Visualhunt.com / CC BY-ND
  81. 81. 11.6秒 1,079 10,000 30,000 Amazon.comにおけるデプロイ
  82. 82. Amazon.comにおけるデプロイ 1時間あたりの最 ⾼デプロイ回数 1回のデプロイで 同時に変更をうけ る平均ホスト数 1回のデプロイで 同時に変更をうけ る最⾼ホスト数 平⽇の デプロイ間隔 11.6秒 1,079 10,000 30,000
  83. 83. MonitorProvisionDeployTestBuildCode Elastic Beanstalk OpsWorks Cloud Watch Cloud Formation Code Deploy Code Commit Code Pipeline AWS DevOps Services
  84. 84. AWS Code services CodeCommit ソースコード管理 CodePipeline 継続的デリバリ CodeDeploy ⾃動化されたデプロイ
  85. 85. AWS CodePipeline ✤リリースプロセスの定義 ✤⾃社システムとのインテグレーション ✤パイプラインステータスの可視化 ✤各リリースの⼀貫した検証 Amazonと同様の継続的デリバリとリリース⾃動化 Build 1) Build 2) Unit test 1) Deploy 2) UI test Source Beta Production 1) Deploy 2) Perf test Gamma 1) Deploy canary 2) Deploy region 1 3) Deploy region 2 1) Pull
  86. 86. AWS CodeDeploy ✤簡単で信頼性の⾼いデプロイを実現 ✤簡単にスケール ✤あらゆるサーバにデプロイ可能 Test CodeDeployv1, v2, v3 Production Dev リビジョン deployment groups
  87. 87. AWS CodeCommit ✤S3上に⽤意されたGitプライベートリポジトリ ✤⼀般的なGitのツールを利⽤可能 ✤Amazon S3とDynamoDBを利⽤したスケーラビリティ、可⽤性と信頼性 ✤ユーザ固有のキーで全リポジトリを⾃動的に暗号化 git pull/push CodeCommit Git objects in Amazon S3 Git index in Amazon DynamoDB Encryption key in AWS KMS SSH or HTTPS
  88. 88. 参考資料 ✤ Martin Fowlerのブログ ✤ Microservices http://martinfowler.com/articles/microservices.html ✤ Microservices Premium http://martinfowler.com/bliki/MicroservicePremium.html ✤ THE TWELVE-FACTOR APP http://12factor.net/ http://12factor.net/jp/ (⽇本語) ✤ AWS関連 ✤ Amazon API Gateway http://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/welcome.html ✤ AWS Lambda http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/welcome.html ✤ Amazon ECS http://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html ✤ AWS CodePipeline http://docs.aws.amazon.com/en_us/codepipeline/latest/userguide/welcome.html ✤ AWS CodeDeploy http://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html ✤ AWS CodeCommit http://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html ✤ AWSクラウドサービス活⽤資料集 https://aws.amazon.com/jp/aws-jp-introduction/ ✤ AWS re:Invent 2015 スライド http://www.slideshare.net/AmazonWebServices/tag/reinvent2015 ✤ Exponential Backoff and Jitter https://www.awsarchitectureblog.com/2015/03/backoff.html

×