『AWS で実現するモダンアプリケーション入門 〜サーバーレス、コンテナ、マイクロサービスで何ができるのか』を読んでみた

はじめに

現在、仕事で AWS のさまざま機能を使ってアプリケーション開発しています。
主に、ECS や EC2・S3 を使ってアプリケーション開発をしているのですが、それ以外のサービスについてはあまり詳しくありません。

そのため、モダンアプリケーションに興味があったのと、AWSの様々な機能を知ることができるのではと思い、今回はこの本を読んでみました。

書籍情報

今回読んだ本はこちらです。

概要と感想

「はじめに」に記載されているのですが、この本はモダンアプリケーション化を検討するための「考え方」を伝えることに比重を置いているため、AWSの具体的なプログラミングの実装や、AWSサービスの操作方法は書かれていません。

「なんとなく流行っているから、という理由でテクノロジーやアーキテクチャを選択するのではなく、実現したいことから逆算をして、自信を持ってテクノロジーやアーキテクチャを選択できるようになることを目的としている」とのことで、モダンアプリケーションに興味がある人や、モダンアプリケーション化を検討しているが、どこから始めれば良いのかわからないという方はおすすめです。しかし、具体的な実装方法を知りたい人には物足りない内容かもしれません。

この本では、架空の企業とその企業が開発・運用する架空のシステムを、AWSサービスを使用するとどのように構築できるかの一例が書かれています。

本の最初の方はある程度システム開発をしていたり AWS サービスを使っている人には知っている内容かもしれません。
私は、本の中盤あたりからとても参考になりました。

まず、私が参考になったのは AmazonSQS と AWS Lambda を使用した非同期処理のシナリオです。
AmazonSQS と AWS Lambda は親和性が高く簡単に構築できるメリットがあります。
また、以下のような仕組みや機能を知ることができました。

• 基本的には AWS Lambda の処理が正常終了したときに AmazonSQS キューから該当するメッセージが消える仕組みとなっていること
• もし、AWS Lambda の処理が異常終了した場合は、そのメッセージは「他のクライアントから取得できない状態」となり AmazonSQS キューから消えず残ること
• AmazonSQSには可視性タイムアウトという設定があるため、その秒数が経過した場合はメッセージの処理に何かしらの異常が発生したと判断し、自動的に「他のクライアントから取得できない状態」が解除されること
  （「他のクライアントから取得できない状態」と可視性タイムアウトの経過による解除を繰り返すことになるので、開発者は AmazonSQS 特有の障害対応をする必要はなく、なるべく早くプログラム修正し、AWS Lambda 関数をデプロイするだけですむこと）
• プログラムのエラーではなくメッセージそのものの誤りがあった場合、AmazonSQS の DLQ(Dead Letter Queue)機能を使い、別の AmazonSQS キューにメッセージを移行できること
• AmazonSQS の DLQ(Dead Letter Queue)機能に移行することで、開発チームとしては「なぜ誤っているのか」分析しプログラムの修正を進めることができること
• 誤ったメッセージの理由を突き止め、正常に直したメッセージを AmazonSQS キューに戻したり、DLQ に溜まったメッセージをソースキューに戻して処理することができること

上記の処理ができるため、実行時間が 15 分以内で完了する処理の場合、プログラムにリトライなどの機能を作らなくても AmazonSQS と AWS Lambda で実現できるのでとても良いなと思いました。

上記の他には、サービスにまたがったデータ整合性を維持するための分散トランザクションの仕組み「Saga」パターンを知りました。

Saga は結果整合性をベースに分散トランザクションを実現できる仕組みで、その方法には大きく以下の 2 種類があります。

• Saga(コレオグラフィ)
  • それぞれのサービスが自律的に他のサービスと強調しながら処理を進めていく形で、整合性を取りたいサービスでエラーが発生した場合のことを考慮しリトライの機能やリカバリするためのイベントを送信したりして整合性を取る方法です。
• Saga(オーケストレーション)
  • オーケストラに例えると、指揮者の役割をするオーケストレーターがそれぞれのサービスの実行結果を判断しながら処理を進めていく形です。
    AWS で Saga(オーケストレーション)を実現する場合の代表的な機能は AWS Step Functions です。AWS Step Functions はステートマシンとしてそれぞれのサービスの実行ワークフローを管理できるマネージド型サービスです。AWS Step Functions ステートマシンではエラーに対する設定もできます。

マイクロサービス間のデータ整合性を担保するための方法の一つとしてとても参考になりました。

そのほかにもサービスメッシュを構築する AWS App Mesh についてや、フィーチャーフラグの管理やモニタリングを実現できる Amazon CloudWatch Evidently も初めて知りました。

フィーチャーフラグとは、リリース時にコードを書き換えることなく、動的にアプリケーションの振る舞いを切り替える仕組みです。
たとえば、新機能をリリースしたい場合、フィーチャーフラグといわれる「スイッチ」をOFFからONに切り替えることでリリースされます。
外部システムとの連携がある場合、フィーチャーフラグがあればそのリリースを待つことなく先にリリースできるので、別の開発とのコンフリクトを避けることができるので有用だなと思いました。

おわりに

この本を読むことでモダンアプリケーションとはどんなものか、それを AWS で実現するにはどういう方法があるかを知ることができました。
知らない AWS のサービスも紹介されていて、とても参考になりました。
どういうことができるかについて理解できたので、今後は実際に AWS を操作しながら使ってみたいと思います。