初めてのJAWS DAYS参加です。
1発目のセッションは事前申し込みした「管理者に送る処方箋」ではなく、
「AWSでアプリ開発するなら知っておくべきこと」に出ました。
- スケーラビリティ
- 水平・垂直
- アーキテクチャのベストプラクティス
-
Design for failure
Build Security in Every Layer
Leverage Many Storage Options
Implement Elasticity
Think Parallel
Loose Coupling
Don't Fear Constraints - Everything fails, all the time.
- by Wanner Vegl???
- Design for failure
-
WebサーバとDBを分ける。
EC2とRDS
次にフェールオーバーや冗長性を考える
冗長構成にするなど。 - Build Security in Every Layer
- 全てのレイヤーでセキュリティを確保
- Leverage Many Storage Options
-
4種類のストレージを使い分けろ
- S3
- Glacier
- EFS
- EBS
- RDS
- Redshift
- DynamoDB
- ElastiCache
- Implement Elasticity
- 動的な構成を前提とすること
- Think Parallel
- 並列アーキテクチャを試すこと
- Loose Coupling
-
疎結合
コンポーネントの中身を参照しないようにする
コンポーネントを結合した処理の場合、
キューにすることで一から再処理する必要はなくなる。 - Asynchronous Integration
-
本当に即座にレスポンスが必要かを考える。
非同期処理のメリット
・アプリケーションがブロックされない(ユーザ体感の向上) ・よりスケーラブルになる - Don't Fear Constraints
- スケールアップの他に、負荷分散やキャッシュも検討できる
- The Twelve-Factor App
- Herokuのエンジニアが公開したWebアプリ開発の方法論
- Codebase
- アプリトコードベースは1:1にしろ
- Dependencies
-
特定の環境に依存しないようにする。
アプリと必要なモジュールを同梱してリリースする。 - Config
- 環境によって異なる設定はOSレベルの環境変数によって注入されるべき
- Backing Services
- ?
- Build, Release, Run
-
上記3つのステージを厳密に区分すべき
各リリースに一意のIDを振るべき - Process
-
プロセス間共有をなくすべき
永続化するデータは外部領域にだす(DBなど)
ファイルやメモリはあくまでキャッシュとして扱い、永続化には用いないこと - Port binding
- ???
- Dev/prod parity
-
本番環境と開発環境は一致させるべき
CI/CDは環境が同じであることが前提 - ステートレスにするためのセッション情報の扱い
-
セッション情報はec2インスタンスで持たずに、
DynamoDBに外だしなどをする - DevOps
-
背景は、不確実性とスピード性が加速していること
Culture + Practice + Tool
Build → Test → Release Feadback ← ??? - AWSのDocker管理サービス
- ECS
- 自動ロールバック
- 失敗時の最も早いリカバリ