「AWSで実現するモダンアプリケーション入門」を読んだのでその読書ログの続きです。今回は第5章〜第7章です。

前回までの記事

• AWSで実現するモダンアプリケーション入門 #1
• AWSで実現するモダンアプリケーション入門 #2

第5章 サーバーレスやコンテナテクノロジーによる運用改善

この章では、運用改善のためにサーバーを意識しない構成にすることの重要性について書かれていました。

サーバーレステクノロジーを使う価値

サーバーレスにすることで得られるメリット

• サーバー管理なし（運用作業の削減）
• 柔軟なスケーリング
• 価値に見合った支払い
• 自動化された高可用性（耐障害性の設計をする必要がない）

サーバーレスとコンテナはどちらを使うべきか

コンテナとは、アプリケーションの実行環境をパッケージ化し、それをデプロイ、実行するためのテクノロジーのこと。パッケージ化されているので、開発環境から本番環境まで一貫性のある形でアプリケーション開発ができる。

サーバーレスとコンテナを選択する場合、「アプリケーション開発により多くの時間や人を投資できる選択肢はどれか」で考えると良い。

AWSでは、LambdaとEKSを比較した場合、Lambdaの方がAWSに多くの作業を任せられる。しかし、Lambdaにはタイムアウト上限時間があり、その制約がネックならEKSの方が良い、となる。

実際のアプリケーションで考慮する観点

• 大規模リクエストに対応できるか
• アプリケーションのエラーに対応できるか
  • Lambdaの異常終了の時どうする
• 冪等性の考慮ができるか
  • 一意でないといけないのに重複したデータが作られる、などを避ける
• モニタリングできるか
• 拡張性はあるか

第6章　CI/CDパイプラインによるデリバリーの自動化

この章では、継続的インテグレーションと継続的デリバリーについて説明されていました。

継続的インテグレーション（CI）と継続的デリバリー（CD）

• 継続的インテグレーション（CI）
  • アプリケーションの品質向上やリリースにかかる時間の短縮のため、小さな変更をメインブランチへ取り込むことに焦点を当てた開発手法。メインブランチとは別のブランチが長く存在すると、レビューやテストが長期化したり、マージする際にコンフリクトが発生する可能性が高まる。
  • 頻繁に変更点をメインブランチに取り込むため、自動的なテストやビルドの実行環境を構築するケースがほとんど。

• 継続的デリバリー（CD）
  • アプリケーションソースコードの変更をトリガーにして、自動的にテストやビルド、リリースの準備を実施する開発手法。デプロイの作業負荷が軽減されるため、開発者はアプリケーションの機能追加や改善に集中できる。

パイプライン・ファースト

開発の初期段階でCI/CDパイプラインを構築すること（パイプライン・ファースト）が望ましい。

理由1

• 自動化の恩恵を初めから享受できる。初めから構築した方が、手動での作業コストを容易に回収できる。

理由2

• 組織やビジネスの成熟に伴ってCI/CDパイプラインに機能が追加される際に、修正が容易になる。

CI/CDツールに求める機能と要件

• CIに必要な機能
  • ソースコードを取得する
  • ユニットテストを実行するためのCIサーバ
  • ビルドを実行し、ビルドアーティファクトを作成

• CDに必要な機能
  • 稼働中のサービスに影響を与えることなく新しいビルドアーティファクトに置き換えること
  • ローリングデプロイやBlue/Greenデプロイがある

具体的なAWSサービス+α

• AWS CloudFormation
  • サービスの構築を自動化
• AWS SAM
  • CloudFormationテンプレートの拡張構文
• Github Actions
  • Github上でデプロイを自動化できる
• AWS CodeBuild
  • テストやビルドを実行するための環境を利用できる
• AWS CodePipeline
  • AWS CodeBuildと組み合わせて、CI/CDパイプラインを構築できる

第7章 要件にあったデータベースの選択

この章では、要件にあったデータベースを選択するための考え方が紹介されていました。

データベースに求める機能と要件

• データ量
• データ増減パターン
• 保持期間
• アクセスパターン
  • Read Heavy? Write Heavy?
• 形式
  • リレーショナル
  • キーバリュー
  • インメモリ
  • ドキュメント
  • ワイドカラム
  • グラフ
  • 時系列
  • 台帳

Purpose-built database

「データベースXは過去に使ったことがあるから」や「データベースXのライセンスが残っているから」という理由ではなく、「データベースXはアプリケーションで実現したい要件に最適だから」という理由で選択すべき。

具体的なAWSサービス例

• Amazon ElastiCache
  • キャッシュがある場合は、キャッシュからデータを取得できるようにする
• Amazon DynamoDB
  • スケーラビリティに強みがある

以上です。