AWSでアプリ開発するなら 知っておくべこと
- 1. AWSでアプリ開発するなら 知っておくべこと Keisuke Nishitani (@Keisuke69) Amazon Web Services Japan K.K. Mar 11, 2017
- 2. Profile Keisuke Nishitani Specialist Solutions Architect, Serverless Amazon Web Service Japan K.K @Keisuke69 Keisuke69 ✤ ソーシャルで⾚ドクロの⼈です ✤ RESTおじさん ✤ 餃⼦の王将エヴァンジェリスト（⾃称） ✤ ⾳楽が好きです、フジロッカーです、今年も⾏きます ✤ ブログ: http://keisuke69.hatenablog.jp/ Keisuke69 Keisuke69Keisuke69x
- 5. スケーラビリティ
- 6. スケーラビリティ ✤ 運⽤中のシステムを拡張/縮⼩させる能⼒ ✤ スケーラビリティを⽣かすことで可能になること ⎻ 柔軟性の向上(事業の必要性に応じたリソース確保) ⎻ コスト削減(必要な時に必要な分だけのリソース確保) ✤ スケールの種類 ⎻ ⽔平スケーリング(スケールアウト/スケールイン) ⎻ 垂直スケーリング(スケールアップ/スケールダウン)
- 7. ⽔平・垂直のスケーリングの⽐較 ✤垂直スケーリング (スケールアップ/スケールダウン) ⎻ 個々のリソースのスペックを増減 ⎻ リソースの限界が存在 ⎻ インスタンスの停⽌が伴う ✤⽔平スケーリング (スケールアウト/スケールイン) ⎻ リソースの台数を増減 ⎻ 論理的には限界が存在しない ⎻ インスタンスの停⽌が伴わない small large small small small small small small small small small small
- 10. アーキテクチャのベストプラクティス ✤ Design for failure: 障害を前提としたデザイン
- 11. アーキテクチャのベストプラクティス ✤ Design for failure: 障害を前提としたデザイン ✤ Build Security in Every Layer: すべてのレイヤでセキュリティを担保
- 12. アーキテクチャのベストプラクティス ✤ Design for failure: 障害を前提としたデザイン ✤ Build Security in Every Layer: すべてのレイヤでセキュリティを担保 ✤ Leverage Many Storage Options: 複数のストレージオプションを活⽤
- 13. アーキテクチャのベストプラクティス ✤ Design for failure: 障害を前提としたデザイン ✤ Build Security in Every Layer: すべてのレイヤでセキュリティを担保 ✤ Leverage Many Storage Options: 複数のストレージオプションを活⽤ ✤ Implement Elasticity: 弾⼒性の実装
- 14. アーキテクチャのベストプラクティス ✤ Design for failure: 障害を前提としたデザイン ✤ Build Security in Every Layer: すべてのレイヤでセキュリティを担保 ✤ Leverage Many Storage Options: 複数のストレージオプションを活⽤ ✤ Implement Elasticity: 弾⼒性の実装 ✤ Think Parallel: 並列化
- 15. アーキテクチャのベストプラクティス ✤ Design for failure: 障害を前提としたデザイン ✤ Build Security in Every Layer: すべてのレイヤでセキュリティを担保 ✤ Leverage Many Storage Options: 複数のストレージオプションを活⽤ ✤ Implement Elasticity: 弾⼒性の実装 ✤ Think Parallel: 並列化 ✤ Loose Coupling: 疎結合
- 16. アーキテクチャのベストプラクティス ✤ Design for failure: 障害を前提としたデザイン ✤ Build Security in Every Layer: すべてのレイヤでセキュリティを担保 ✤ Leverage Many Storage Options: 複数のストレージオプションを活⽤ ✤ Implement Elasticity: 弾⼒性の実装 ✤ Think Parallel: 並列化 ✤ Loose Coupling: 疎結合 ✤ Don’t Fear Constraints: 制約を恐れない
- 18. Everything fails, all the time.
- 19. Design for Failure ✤ 単⼀障害点をなくす ✤ すべてが失敗し得るという前提で考える ⎻ 仮に物理的なハードウェアが故障したり、削除したりリプレースされてもアプ リケーションが機能し続けることがゴール ⎻ 個々のコンポーネントが失敗してもアプリケーション全体の停⽌を招かないよ うにする
- 20. Design for Failure: 具体的には ✤最初に、1ホストを複数に分割する ⎻ Webとデータベース ✤データベース ⎻ Amazon RDSを利⽤するとより簡単 Web instance Elastic IP RDS DB instance User Amazon Route 53
- 21. Design for Failure: 具体的には ✤次に、フェイルオーバや冗⻑性 の問題を解決 ✤複数のWebインスタンスを異な るAZで ✤RDSはMulti-AZで ✤Elastic Load Balancing (ELB)を 利⽤して負荷分散 Web Instance RDS DB Instance Active (Multi-AZ) Availability Zone Availability Zone Web Instance RDS DB Instance Standby (Multi-AZ) ELB Balancer User Amazon Route 53
- 22. Build Security in Every Layer
- 23. Build Security in Every Layer ✤ すべてのレイヤーでセキュリティを確保 ⎻ ⼀箇所でもセキュリティホールがあれば、そこを突かれてしまう ✤ 通信経路および保存されたデータの暗号化 ✤ IAMを⽤いた最⼩権限の原則 ✤ アプリケーションのロールごとに個別に制限されたSecurity Groupを ⽤意する ⎻ 外部へのアクセスはこれらで制限 ✤ サブネットレベルでのトラフィック制限にNetworkACLを使う ✤ MFAを使⽤する
- 24. Build Security in Every Layer Web Web Web Web Private Segment (Web) Public Segment Lo g Private Segment (DB) Public Subnet (DMZ) Public Subnet (DMZ) Private Subnet Private Subnet Private Subnet Private Subnet NAT NAT 操作ログ リソース監視 通知 データ暗号化 権限管理 【サブネット】 外部からアクセスできるサブ ネットと、外部からはアクセ スできないサブネットの作成 【ネットワークアクセス制御】 SecurityGroup及びNetwork ACLを使ってアクセス制御を実 施 【保管するデータの暗号化】 S3やEBS、RDSといったスト レージサービス上のデータを暗 号化 【アクセス管理】 AWSアカウント・IAMユー ザーの管理。AWSリソース へのアクセス制御(最⼩権限 の原則を順守可能) 【AWS操作ログ】 AWS操作ログの取得（管理コン ソールやCLI含む） 【AWSサービス監視】 各種AWSサービス（ELB、RDS、 EC2等）のリソース監視 Availability Zone Availability Zone 詳細： http://www.slideshare.net/AmazonWebServicesJapan/awswebinar-aws-56260969
- 25. 提供されている機能の活⽤ ✤ 提供されている便利なセキュリティ機能を活⽤することでよりシンプ ルにセキュリティ確保が可能に ✤ AWS が提供するセキュリティ機能活⽤の例 ⎻ AWS IAM による権限制御 ⎻ セキュリティグループによるアクセスコントロール ⎻ AWS WAF による DDoS 緩和 ⎻ AWS CloudTrail による監査ログ取得 ⎻ AWS KMS による暗号化鍵管理 ⎻ etc
- 26. リアルタイム監査 ✤ 継続的にコンプライアンスのための監視を実施 ⎻ AWS Config ⎻ Amazon Inspector ⎻ AWS Trusted Advisor ✤ AWS環境の操作ログの取得 ⎻ AWS CloudTrail ✤ アプリケーションログの収集 ⎻ Amazon CloudWatch Logs
- 27. Leverage Many Storage Options
- 28. Leverage Many Storage Options ✤ 万能なデータストアは存在しない ✤ データストアの特性(得意不得意)に応じて使い分ける
- 29. Leverage Many Storage Options ✤ ストレージの使い分け File/Block Storage Object Storage • ⾼可⽤ • ⼤容量 • 静的コンテン ツ配信 • 低価格 • アーカイブ • NFS • 共有ディスク • ⾼IOPS • 低レイテンシ • 永続化 • 任意のファイルシ ステム Amazon S3 Amazon Glacier Amazon EFS Amazon EBS
- 30. Leverage Many Storage Options ✤ データベースの使い分け Amazon DynamoDB Amazon RDS Amazon ElastiCache Amazon Redshift SQL NoSQL• 低レイテンシ • インメモリ • 3拠点間での レプリケーション • SSDに永続化 • トランザク ション処理 • 汎⽤⽤途 • 集計・分析処理 • ⼤容量データ • DWH
- 31. Leverage Many Storage Options ✤静的コンテンツはS3に ✤セッションやステートはAmazon DynamoDBに ✤DBのキャッシュはAmazon ElastiCacheに RDS DB Instance Active (Multi-AZ) Availability Zone ELB Amazon S3 Amazon CloudFrontUser ElastiCache DynamoDB Web Instances Amazon Route 53
- 33. Implement Elasticity ✤ コンポーネントの正常性、可⽤性、固定されたロケーションを前提と しない ⎻ IPアドレスで参照しない、分散させるなど ✤ リブートや機能停⽌に対して弾⼒性のあるデザインを⾏う ✤ インスタンスのブートストラップ ⎻ インスタンスが起動する時に、⾃分⾃⾝が誰で役割が何かを問い合わせる ✤ 動的な構成を優先する
- 34. Think Parallel
- 35. Think Parallel ✤ 様々な並列アーキテクチャを試す ✤ クラウドサービスに対するマルチスレッドや並列リクエストの利⽤ ⎻ EMRを⽤いて並列のMapReduceジョブを実⾏ ⎻ ロードバランサ（ELB）を⽤いた負荷分散 ⎻ 1つのKinesis Streamと複数のKCLアプリケーション ⎻ バックエンドとしてのLambdaの利⽤
- 36. Think Parallel: バッチ処理の例 ✤ 1インスタンスでN時間かけるのもN台を使って1時間で処理するのも コストとしては同じ
- 37. Loose Coupling
- 38. Loose Coupling ✤ 独⽴したコンポーネントを⽤いたアーキテクチャデザイン ⎻ コンポーネント間の結合度が緩やかになるほど、スケーラビリティは⾼まる ✤ すべてのコンポーネントをブラックボックスとしてデザイン ⎻ 個々のリソースに固有の情報に依存しない ⎻ 必要な情報だけをわたし、API でアクセス ⎻ IP アドレスではなく DNS 名でアクセス ⎻ 処理を実施するインスタンスへの直接アクセスを避け、 ELB, SQS へアクセスさせるよう設計 ✤ 負荷分散のためのクラスタ
- 39. Loose Coupling ✤ キューを利⽤して疎結合なコンポーネント間でメッセージを受け渡し 密結合 キューを⽤いた疎結合 Component1 Component2 Component3 Component1 Component2 Component3 Q QQ
- 40. Loose Coupling ✤ 結合度が緩やかになるほど、スケーラビリティは⾼まる ⎻ 独⽴したコンポーネント ⎻ すべてのコンポーネントをブラックボックスとしてデザイン ⎻ インタラクションの切り離し ⎻ 独⾃で構築するよりも、冗⻑性とスケーラビリティが組み込まれているサービ スを活⽤する S3 Bucket Lambda Push: Event Notification DynamoDB Pull: DynamoDB Stream Amazon Kinesis Pull: DynamoDB Stream SQS messages Get Message Instance Put Message Instance Amazon SNS Topic Publish Notification Queue Is Subscribed to Topic
- 42. Service Discovery ✤ 個々のサービスがブラックボックスとしてお互いにやり取りをするには、 各サービスで増えたリソース、減ったリソースに対して透過的にアクセス できる必要がある ✤ Service Discovery の例 ⎻ Auto Scaling を使ったインスタンスの ELB への⾃動登録 ⎻ EC2 ユーザーデータ × Amazon Route 53 ⎻ Auto Scaling Life Cycle Hook × Amazon Route 53 ⎻ 3rd party solutions ⎻ Netflix Eureka ⎻ Airbnb Synapse ⎻ HashiCorp Consul ⎻ etc
- 44. Asynchronous Integration ✤ 同期処理である必要がなければ⾮同期にする ⎻ その処理、本当にレスポンス必要ですか？ ✤ ⾮同期処理の利点 ⎻ ユーザ側の利点 ⎻ アプリケーションがブロックされない ⎻ サーバ側の利点 ⎻ スケーラブルかつ⾼可⽤なバックエンド ⎻ Frontend を停⽌させることなく Backend を容易にメンテナンス可能 ⎻ 少ないFrontend のキャパシティで多くのリクエストを受付可能 ⎻ リクエストの処理順序やリトライ等の制御が容易に
- 46. Don’t Fear Constraints ✤ より多くのメモリが必要？ ⎻ 負荷を分散させる、キャッシュの利⽤を検討
- 47. Don’t Fear Constraints ✤ より多くのメモリが必要？ ⎻ 負荷を分散させる、キャッシュの利⽤を検討 ✤ データベースにさらなるIOPSが必要？ ⎻ 複数のリードレプリカ、シャーディング、DBクラスタを検討 ⎻ PIOPS、SSDベースのインスタンスストレージ ⎻ ElastiCacheを使ったデータベースのキャッシング
- 48. Don’t Fear Constraints ✤ より多くのメモリが必要？ ⎻ 負荷を分散させる、キャッシュの利⽤を検討 ✤ データベースにさらなるIOPSが必要？ ⎻ 複数のリードレプリカ、シャーディング、DBクラスタを検討 ⎻ PIOPS、SSDベースのインスタンスストレージ ⎻ ElastiCacheを使ったデータベースのキャッシング ✤ ハードウェア障害や設定が壊れてしまった ⎻ シンプルに問題のあるインスタンスを破棄し、置き換える
- 50. The Twelve-Factor App ✤ 元はHerokuのエンジニアが公開したモダンなWebアプリケーション 開発のための⽅法論 ⎻ 直接的にクラウドと関連する話しではないが、少なくともWebエンジニアは⼀ 読しておくべき ✤ Dockerによるアプリケーション開発やLambdaのようなサーバレスコ ンピュートの普及に伴い、改めて重要性が増しつつある ✤ URL http://12factor.net/ http://12factor.net/ja/（⽇本語訳）
- 51. The Twelve-Factor App ✤ Codebase - コードベース - ⎻ バージョン管理されている1つのコードベースと複数のデプロイ ⎻ デプロイされているアプリとコードベースは常に1:1であるべき ✤ Dependencies - 依存関係 - ⎻ 依存関係を明⽰的に宣⾔し分離する ⎻ 特定の環境に暗黙的にインストールされているパッケージやツールに依存しな いこと ⎻ アプリケーションが必要とするツール、ライブラリはアプリケーションに同梱 されるべき
- 52. The Twelve-Factor App ✤ Config - 設定 - ⎻ 環境によって異なる設定はOSレベルの環境変数によって注⼊されるべきである ✤ Backing services - バックエンドサービス - ⎻ アプリケーションがネットワーク越しに利⽤するようなサービスはすべてリ ソースとして扱う ⎻ データベースやメッセージブローカーといったものはアタッチされたリソース として扱う ⎻ ローカル環境も本番もサードパーティもどれもリソースとして扱い、それらの 切り替えはリソースハンドルの切り替えとする
- 53. The Twelve-Factor App ✤ Build, release, run - ビルド、リリース、実⾏ - ⎻ ビルド、リリース、実⾏の3つのステージを厳密に分離する ⎻ それぞれのリリースは⼀意のIDを持つべき ✤ Process - プロセス - ⎻ アプリケーションを1つもしくは複数のステートレスなプロセスとして実⾏す る ⎻ プロセス間で何も共有はしない ⎻ 永続化する必要のあるデータはDBなどのステートフルな外部サービスを⽤いる ⎻ ローカルディスクのファイル、メモリ上のデータはあくまでもキャッシュとし て扱い、永続化されることを期待しない
- 54. The Twelve-Factor App ✤ Port binding - ポートバインディング - ⎻ ポートバインディングを通してサービスを公開する ⎻ Webアプリケーション⾃体がサービスとなってリクエストを待ち受けること ⎻ リクエストを受け付ける何かを⽤意するのではなく、アプリに組み込まれるべき ✤ Concurrency - 並⾏性 - ⎻ プロセスモデルによってスケールアウトする ⎻ ⽔平⽅向へのプロセスのスケールアウトによって並⾏性を担保する
- 55. The Twelve-Factor App ✤ Disposability - 廃棄容易性 - ⎻ ⾼速な起動と簡単な廃棄 ⎻ グレースフルシャットダウン ✤ Dev/prod parity - 開発/本番⼀致 - ⎻ 開発、ステージング、本番環境をできるだけ⼀致させた状態を保つ ⎻ CI/CDは各環境が揃っていることで実現される ✤ Log - ログ - ⎻ 出⼒ストリームの保存先やルーティングには関与しない ⎻ ログファイルへの書き出しや管理などをアプリ側ですべきではない ⎻ シンプルに標準出⼒に吐き出すだけ ⎻ 本番環境などではそれを集めて、保存し、インデックス化し分析する環境をアプリの外に⽤意 する ✤ Admin processes - 管理プロセス - ⎻ 管理タスクを1回限りのプロセスとして実⾏する
- 56. ⽔平スケーリングを⾏うために⼼がけること ✤ ステートレスアプリケーション/コンポーネント ⎻ ステートフルになる要素を⽔平スケールするリソースの外部に配置 ⎻ セッション情報は、DynamoDB/ElastiCache へ ⎻ バイナリファイル, ログなどは、 Amazon S3 へ ✤ ステートフルになるコンポーネントをどう扱うか ⎻ ⽔平スケールするマネージドサービスの利⽤ ⎻ ⽔平スケールができない場合に注意すべき制約を洗い出す ✤ 分散処理（今までのやり⽅を⾒直す） ⎻ ⻑時間かかっていた単⼀のタスクを分割できないか検討 ⎻ 1台のサーバで4時間かかるタスクを、4台のサーバで1時間でこなす ✤ 商⽤ライセンスの扱い ⎻ ライセンスの提供元に確認
- 58. ステートレスにするためのセッション情報の扱い ✤ スケールさせやすくするためにセッション情報は外だし Web/ App Auto Scaling ELB Client Web/ App DynamoDB セッション情報 ElastiCache or 書き換えられても問 題ない情報、肥⼤化 の恐れがない情報は Client-Side で保持す ることも可能 Client-Side で書き換え られると困る情報は Server-Side で保持 各リソースに固有の情報がないの で、いつでも増減しやすい
- 59. DevOps
- 60. Why DevOps? ✤ ビジネスのスピードと多様性はより⼀層増している ⎻ 何が当たるかわからない ⎻ 事業環境の変化 ⎻ 事前に予測しきるのは難しい ⎻ 本当に求められているのは何なのか ✤ ビジネスを成功に導くためのITの重要性の⾼まり
- 61. Why DevOps? ✤ ビジネスのスピードと多様性はより⼀層増している ⎻ 何が当たるかわからない ⎻ 事業環境の変化 ⎻ 事前に予測しきるのは難しい ⎻ 本当に求められているのは何なのか ✤ ビジネスを成功に導くためのITの重要性の⾼まり 素早い変化への対応が必要
- 62. What is DevOps?
- 65. What is DevOps? ⽂化 Culture ✤ コラボレーション ✤ 壁をなくす ⎻ チーム間 ⎻ 中間プロセス ✤ End to EndでOne teamであること ✤ 直接的に関係する個⼈に対する責任は減らす ✤ ⾏われた作業の結果に対する可視性を⾼める
- 66. What is DevOps? 実践 Practice ✤ Automate Everything ✤ Test Everything ✤ 継続的インテグレーション ⎻ アプリケーションのテスト/QAは開発中ずっ と⾏う ✤ 継続的デリバリ ⎻ 環境をまたいだコードの⾃動デプロイ ✤ Infrastructure as Code ✤ Canary, Blue-Green and Red-Black デプロイメ ント ✤ セルフサービスな環境 ⎻ 調達ブロッカーをなくす ✤ Microservices ⎻ 複雑なモノリシックアプリケーションを⼩さ なものへブレイクダウン
- 67. Elastic Beanstalk CloudFormationOpsWorks ⾃動化と構成管理 ✤ 宣⾔的なアプローチ ⎻ プロビジョニング ⎻ 設定 ⎻ オーケストレーション ⎻ レポーティング CodeDeploy
- 68. 継続的インテグレーション（CI）と継続的デリバリ（CD） ✤ 結果を事前定義し、コードの品質と機能を繰り返し検証する ✤ 多様なツール群: ⾃社開発、オープンソース、プロプライエタリ製品、 SaaS ✤ モニタリング、テスト、検証 AWS CodeDeploy AWS CodePipeline
- 69. 継続的インテグレーション（CI）と継続的デリバリ（CD） ✤ アプリケーションとインフラストラクチャの両⽅ ✤ 可能な限り⾃動化する ✤ 宣⾔的にインフラを定義 ✤ セキュリティを含め注意深くインフラを設計 ✤ 定義や設定をアプリケーションコードのごとく扱う ✤ バージョンコントロール ✤ アプリケーションの⼀部としてのインフラ ✤ ロールバックのためのプラン ✤ モニタリング、ロギングと監査 Introduction to Microservices DevOps and AWS
- 71. What is DevOps? ツール Tool ✤ ⾃動化とCI/CDのためのツール ⎻ Pipeline管理ツール ⎻ ソースコード管理ツール ⎻ テストフレームワーク/テストツール ⎻ コードレビュー/フィードバックツール ⎻ コードの静的解析ツール ⎻ デプロイツール ✤ ⼀貫性のある、予測可能なアプリケーション管理 と設定管理 ✤ インフラストラクチャの計測 ⎻ メトリクス ⎻ ロギング ⎻ モニタリング ⎻ APM(Application Performance Monitoring) ✤ セキュリティの分析と管理ツール
- 72. What is DevOps? DevOps = 開発者 顧客 releasetestbuild plan monitor デリバリのパイプライン フィードバックループ ソフトウェア開発のライフサイクル 無駄やボトルネックを取り除くことで、 ライフサイクルを効率化し、⾼速化すること
- 73. DevOps Tools on AWS
- 74. Networking AnalyticsCompute Storage & Content Delivery Developer Tools Management Tools Security & Identity Mobile Services Database Business Productivity, Desktop & App Streaming S3 CloudFront EFS Glacier Storage Gateway AppStream CloudSearch SESSQS Mobile A nalytics Cognito Device Farm SNS RDS DynamoDB ElastiCache RedShift WorkSpaces WorkDocs WorkMail Lambda ECSEC2 VPC Direct Connect Route 53 EMR Data Pipeline KinesisELB QuickSight Elasticsearch Service CodeCommit CloudWatch Cloud Formation CloudTrail Config OpsWorks Service C atalog IAM Directory Service Trusted A dvisor WAFSnowball DMS IoT IoT Game Dev Mobile Hub ElasticBeanstalk ACM Inspector GameLift CodePipeline CodeDeploy ほとんどのサービスに⽤意されたAPI Lightsail AWS Batch Application Discovery Service SMS Pinpoint Application Services API Gateway Elastic Transcoder SWF Step Functions Messaging Migration X-Ray CodeBuild Amazon Lex Amazon Polly AI LexPolly Rekognition Machine Learning KMS ShieldOrganizations
- 75. SDK Ruby iOS Python (boto) Android Node.js AWS Toolkit for Visual Studio .NET AWS Toolkit for Eclipse PHP AWS Tools for Windows PowerShell AWS CLI JavaScriptJava Xamarin
- 76. クラウドならではのメリット 76 オンプレミス 新しいインフラの構築は 複雑かつ遅くなりがち クラウド ワンクリックで新しい インフラを⽤意 新しいデプロイ環境を構築 新しいテスト環境を構築 新しい環境を海外に構築 1,000 サーバ追加 1,000 サーバ削除 必要 調査 評価 計画 設計 エンジニア 調達 契約 コミッション デプロイ
- 77. MonitorProvisionDeployTestBuildCode Elastic Beanstalk OpsWorks Cloud Watch Cloud Formation Code Deploy Code Commit Code Build AWS DevOps Services Code Pipeline Third Party Tools
- 78. Jenkinsを使ったデプロイ ✤ 多くのプラグインが利⽤可能 ✤ CIとCDに使われている ✤ CodePipelineからの呼び出しが可能 ✤ GitHubのWebHookによるイベント受信 ✤ Dockerイメージをデプロイするプラグインも利⽤可能
- 79. JenkinsとDockerを使った継続的デリバリ Introduction to Microservices DevOps and AWS Bucket Amazon ECS AWS CloudFormation ECS Cluster
- 83. $ docker run myimage Server Guest OS Bins/Libs Bins/Libs App2App1
- 85. Amazon EC2 Container Service (ECS) ✤ 管理ノード不要の、安定かつ⾼パフォーマンスなクラスタ管理サービス ✤ Dockerコンテナを複数のEC2インスタンスに分散配置 ✤ ⼀時的な計算処理にも、ロングランニングな処理にも対応 ✤ ELB連携など各種AWSサービスとの親和性 ✤ Amazon ECS⾃体の利⽤は無料 複数のコンテナをEC2のクラスタ上で⼀元管理できるサービス
- 86. その他のベストプラクティス ✤ CI/CDは必須 ⎻ 頻繁なコミットとコミットごとのビルド ⎻ 実際に稼働する環境を⽤いたテスト ✤ コードのすべてをコードリポジトリに保管 ⎻ アプリ、インフラ、ドキュメント ⎻ リポジトリ上にないものはプロダクションに持っていってはいけない ✤ コードレビューは良いコードのためのベストな⽅法 ⎻ クリーンで誰もが理解できるコードか？ ⎻ 設計がニーズを満たせているか？ ⎻ 同じことをするのにより良い⽅法、簡単な⽅法はないか？
- 87. その他のベストプラクティス ✤ ⾃動ロールバック ⎻ 失敗時における最も速いリカバリのメカニズムと⾔える ⎻ まずはロールバックし、その後ログ/グラフなどを⽤いてデバッグする ✤ ダッシュボードを通じて状況を把握する ⎻ 今何がおきているか？ ⎻ 通常時はどのように⾒えているのか？ ⎻ グラフがおかしかったり、アラームが発⽣した場合に何をするのか？ ⎻ グラフ内の動きはどのようなイベントと紐付けられるのか？
- 88. Conclusion ✤ クラウドを最⼤限に活かすには、アプリケーションをスケーラブルに 作ること ✤ スケーラブルなアプリケーションを作るための⽅法論はいくつかあり、 適宜⾃分たちにあわせて選択をしていくこと ✤ 忘れちゃいけないDevOps ⎻ というかCIとCD ⎻ すべてを頻度⾼くテストする