初めての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種類のストレージを使い分けろ
4種類のDBを使い分けろ
- 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
-
自動ロールバック
-
失敗時の最も早いリカバリ