今回はawsのパフォーマンス・コスト構成についてみていきます。いわゆる、スケーリングの話になっていくかと思います。教材はこれまで同様、「ガバメントクラウド利用における推奨構成（AWS編）.pdf」です。
パフォーマンス・コスト構成
パット見た感じ、前回のセキュリティ構成②
とほぼ同じようで、バッチ処理などの周辺機能が増えているようです。
引用元：ガバメントクラウド利用における推奨構成（AWS編）.pdf（デジタル庁）P.27
| アイコン | 名称 | 機能 |
|---|---|---|
 |
CodeCommit | フルマネージドのGitリポジトリ |
 |
CodeBuild | ビルド・テストを自動化するエンジン |
 |
Elastic-Container-Service | いわゆるコンテナオーケストレーションサービス。Dockerコンテナの実行、スケーリングなどを管理する |
 |
Elastic-Container-Registry | コンテナレジストリサービス。Dockerイメージを保存している |
 |
Fargate | サーバーレスコンテナエンジン。ECS+EC2ではEC2のOS管理を自ら実施する必要があるが、ECS+Fargateでは不要 |
 |
Managed-Workflows-for-Apache-Airflow | フルマネージドのApache Airflowサービス（データパイプライン等を管理するオーケストレーションツール）。複数のバッチを順次実行したりするイメージ |
 |
Step-Functions | サーバーレスのバッチ実行ツール。いわゆるバッチ一個分で、Lambdaなどをまとめて一つの機能を作るイメージ |
 |
Lambda | イベント駆動型のプログラム。関数１個分のイメージ |
 |
Transfer-Family | ファイル転送サービス。SFTP、FTPS、FTP、AS2プロトコル等 |
 |
Systems-Manager_Parameter-Store | 設定情報を管理する機能。クラウド上のINIファイルに該当 |
サーバーレス
パフォーマンス・コストの観点からは、サーバーはコンテナ化、バッチはマネージドサービスの利用にすることでサーバーレスにしましょうという方針かと思います。
サーバーレス化の注意点としては、EBSなど「サーバー固定のストレージ」は利用せず、RDBやS3などの独立したストレージに格納する必要がある点です。基本サーバープログラムであればRDBにデータを格納する事が多いのであまり問題にはなりそうにありませんが、セッション情報については高速・頻繁にアクセスすることになることからElastiCache(マイクロ秒単位の超低遅延)や、Amazon DynamoDB(ミリ秒単位の低遅延)に保存するのがベストプラクティスとなっているようです。
参考資料
ページ中で利用しているAWSアイコンは、以下のページからダウンロードしたものを利用しています。
