「AWSで実現するモダンアプリケーション入門」はクラウドを扱うエンジニアとして最高の本

時間があったので「AWSで実現するモダンアプリケーション入門」を読んでいます。一言で「神書籍」

現代の開発で起こりうるあらゆる問題や課題を解決するための手立てが解説されています。

この書籍内で、自身がこれまでに知らなかったawsでの手法についてブログ記事としてピックアップして、随時追加します。

1.awsを使ってアプリケーション外で設定を一括管理する

awsのサービスとして設定情報管理を行えるサービスが展開されている

これにより、アプリケーション内部で環境変数を定義して設定情報を管理するなどのアプリケーションに蜜結合した状態を回避できる

→つまるところ同時にこれは設定変更によるアプリケーションの再デプロイを避けられる

gitignoire忘れで設定（特にアクセスキー関連）をgit pushしてしまうリスク対策にもなる様子なことと、awsで構築されたサービスであればスムーズに利用できる

リクエスト数による課金が存在するので使い分けなど注意

使い分けに関しては詳しく書かれているこちらの記事を参照

EC2上にコンテナを設置すると、コンテナランタイム等のEC2インスタンス管理が発生するのは必須だが、 Fargateを利用した方がアプリケーション開発に注力できる。

以下は自身で調べた疑問点

Fargateのコストは高めなので、ECS on EC2も検討できる模様

また、EC2が向いているケースもある様子

CI/CDは開発初期に用意することで、開発が進むことで開発フローが変化したとしても少ない労力でパイプラインの変更が行える。

これは既存のデプロイプロセス（本番環境）などへの影響といったリスクの削減に繋がる。

追加で調べてこのほかにもデプロイ手法はいくつかある

マイクロサービスとしてAPIファーストの設計をすることで、APIを呼び出して結果を画面描画することが可能になる。

このことで、Ruby on Railsのようなフルスタックフレームワークを用いた描画画面構築処理が削減できる場合がある。

このあたりはきっとマイクロサービスにするかどうかやコストや現場によって状況が違うんだろうなあという所感。

これもAPIのデザインパターンとして、クライアント単位でAPIのエンドポイントを分割する手法。

クライアントの種類が多い場合など複雑化する場合においてAPI自体がモノリシックな構造となることを回避できる。

マイクロサービスでは、決済・購入履歴・ポイントなどサービス単位で独立しているが、購入イベントが発生した際にどこかで問題が生じるとデータの整合性が取れなくなる。

event bridgeを使用することで、いずれかのサービスでエラーが生じた場合のリトライや取り消し処理を行って整合性を保つことができる。

マイクロサービスを作る際のクラウド技術選定のポイントが凝縮されており、業務でモノリシックアプリケーションの現場しか経験がない身としてマイクロサービスを体系的に知ることができた。

今後マイクロサービスの現場へ入る機会も考えられるので、構築例を知っておくことで役に立てられたら良いな。