Rのつく財団入り口

ITエンジニア関連の様々な話題を書いているはずのブログです。

【感想】『AWSで実現するモダンアプリケーション入門』:モダンなアプリの考え方が学べる本

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

 2023年1月に出たばかりの新刊です。著者の落水 恭介さん(@otty246)は現AWSのコンテナソリューションアーキテクト。もう一人の吉田 慶章(@kakakakakku)さんは同じくテクニカルトレーナー。カカカカックじゃなくてカックさんといえばめっさ毎週更新されててよく話題に上がる【kakakakakku blog】の方としてブログ界隈ではお馴染みでしょう。

 開発戦略として注目されているモダンアプリケーションについて、最初はRailsのバックエンド主体で作られている設定の架空のアプリをモダン化していくストーリーで諸々解説していく本となっています。ちょうどAWSアーキテクチャを考える仕事にジョインしたところだったので、これで頭をモダンに切り替えていくぜ! そういやワイもふんいきで使ってるけどモダンってなんだ? というお気持ちで拝読スタートしました。

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

第1章 モダンアプリケーションとは何か

  • 「アプリケーションの設計、構築、管理を継続的に見直し、常に変化を受け入れ続ける開発戦略」のこと。
  • ユーザの声の傾聴→アイデア→実験→傾聴の繰り返しの「イノベーションフライホイール」の考え方をAmazonは重視。Minumum Viable Product, MVPの考え方。
  • 市場投入を加速できる、イノベーションを促進する、従量課金モデルのサービス採用で総所有コスト(TCO)を下げられる、自動化やモニタリングで信頼性が上がる、ワークロードに適した技術やツールを適材適所で採用しやすくなる...というメリットあり。
  • ベストプラクティスとしては:モニタリング、サーバーレステクノロジーの使用、リリースパイプラインの構築、モジュラーアーキテクチャの使用がある。
  • 1個のアプリ(≒サービス)の中に機能が混在するモノリシック→機能がモジュール単位で綺麗に分かれてDBはまだ共用のモジュラモノリス→モジュールもDBもサービスごとに別々のマイクロサービスへ

 まずはなんぞやという基本の章で明快に解説しています。コラムにモダンアプリケーションは目的でなく手段であり、文化によって最適方法は違う...という話も載っていて、やはり永続的な唯一絶対の正解はない世界なのだなあと分かります。

第2章 サンプルアプリケーションの紹介

  • 電子書籍サービスを展開するスタートアップ企業Sample CompanyのSample Book Storeがお題。
  • アプリはバックエンドがRuby on Railsで、Auto ScaleするEC2インスタンス上で後ろにRDS、PDFデータなど静的ファイルはS3上...という標準的な構成。
  • ユーザー数増加、システム規模増加、組織も拡大によって現実でもありそうなよくある問題がいろいろ起こっており、モダン化して解決していきたい...という段階。

 名前がSampleで直球そのまんまや!という感じですが、このSample Book Storeが本章全体でのモダン化のお題のシナリオとなっています。アーキテクチャは解説されていますが具体的な実装の細かいところまでは出てこずに、抽象化された段階で留められています。
 この塩梅がちょうど本書の立ち位置とうまく合っているんですね。一般的なWeb開発の経験のある方ならこのSample Book Store、なんとなく機能や画面が想像できて問題なく読み進められるかと思います。

第3章 アプリケーション開発におけるベストプラクティスを適用

  • いきなり抜本的なアーキテクチャ変更ではなく、小さくできるところから徐々にモダン化していく。
  • 2012年頃にHeroku社から提唱されたThe Twelve-Factpr Appの話。
  • 2016年頃に今度はPivotal社から提唱されたBeyond the Twelve-Factor Appの話。3個増えて15個に。
  • コードベースとアプリは1対1(モノレポ)がよい、依存関係は厳密に制御しパッケージ管理ツールを使う、設定とコードは分割して外出し、環境変数を活用...など。
  • アプリケーションの後ろにあるバックエンドサービスは切り替え可能に、そしてやりとりはAPI経由にする「APIファースト」など、各種プラクティスを適用していく。

 Sample Book Storeへの適用例含め解説してくれます。〜FactorはBeyond含めると15個になるんですねえ。

第4章 データの取得による状況の可視化

  • Sampleではユーザー数や買った本の数が「ビジネスデータ」になる。これらもログとして集約、Quick Sightのようなサービスで可視化するのが望ましい。
  • 運用作業のチケット数や時間、デプロイ数など割と決まってるのが「運用データ」。これらもダッシュボードで可視化するのが望ましい。
  • リクエスト数やエラー回数などの「REDメソッド」、キュー系サービスではタスク処理件数やキューイングされている件数などの「USEメソッド」が「システムデータ」。このへんもCloudWatchで可視化できる。
  • 可観測性のオブザーバビリティの3本柱にメトリクス、ログ、トレース。
  • モニタリングとオブザーバビリティの明確な違いは実はないが、全社は問題把握、後者は問題発見に繋がる。

 REDメソッドとUSEメソッド、こういう用語があるとは初めて知りました。こうした監視周りはAWSの資料や本にはよく出てきますが、本書ではSample Book Storeを題材に改めて整理されていて明快です。

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

  • サーバーを意識しないサーバーレスでのメリットを改めてまとめると:サーバー管理が不要、スケーリングが柔軟、従量課金、高可用性が自動化されている
  • サーバーレスの解釈は多少違いがある。正しい定義は実はCloud Native Computing Foundation, CNCFで「コードをホストして実行するためにサーバーを使わないのではなく、サーバーのプロビジョニング/スケーリング/キャパシティプランニングに時間とリソースを割かなくてよいという考え方」だと説明されている。
  • AWSでもサーバーレスとコンテナの使い分けは難しいが、アプリ開発自体に時間と人をより投資できるる選択肢はどれか、という観点がある。Lambdaなどサーバーレスの方が抽象度が高く、開発以外の作業が少ない。要件を満たせない時にECS or EKSへとなる。
  • またコンテナを動かすデータプレーンはEC2Fargateがある。要件を満たすなら管理不要のFargateのほうがアプリケーション開発に集中できる、となる。
  • なお「モダンアプリケーション」であるためには技術の縛りがある訳ではないので、サーバーレスやコンテナ必須というわけでもない。EC2周辺に各種サービスを配置したアーキテクチャがフィットする場合もある。
  • Sample Book Storeへの適用例。本を買った後の領収書発行機能は購入と同時実行必須ではなく、なるべく早くでよい。そこで切り離して、SQSにメッセージ格納→Lambdaが非同期に処理→領収書をS3に保存というサーバーレス導入例。
    • 大規模リクエストでは...Lambdaは自動でスケールしてくれる
    • エラー時は...SQSDead Letter Queueがある
    • 冪等性の考慮...ファイル名を固定にすると、2回目以降は上書きになってOK
    • モニタリングは...CloudWatch Logsへ渡せる
    • 今後の拡張性... EventBridgeSNSをイベントバスとして、別の処理に繋げられる
  • 同様に、本を買うと貯まっていくポイントの機能をサーバーレスコンテナに切り出す例。ELBの後ろでECS/Fargate上のコンテナ内のタスクが処理し、RDSに保存する
    • 大規模リクエストでは... ELBが負荷分散。各サービスで使えるAWS Application Auto Scalingを使うとECS上のコンテナ数増減も対応
    • エラー時は...APIなので、APIのレスポンスに入れて伝える
    • 冪等性の考慮...最新のポイント残高参照は都度変わるので保証できない。パラメーターで渡して特定の日の値を返す工夫がある。更新はIDで冪等性保証
    • モニタリングは...こちらもコンテナ上のアプリからCloudWatch Logsへ、あるいはさらにX-Ray
    • 今後の拡張性...境界がAPIなので、その後ろをサーバーレスに切り替えるなども可能で拡張しやすい

www.cncf.io

 割とお馴染みなサーバーレス周り。対応サービスが幅広く紹介されています。そして後半で2例、Sample Book Storeにおいて運用要件を元にしっかり検討し、だからLambdaにするよ、だからECS/Fargateにするよという明確な理由とともに技術選定している例が秀悦で、シュッと理解できます。
 なおコンテナを選んでさらにECSEKSのどちらかを選ぶべきかの話は、本書ではアクティビティで問いかけられる形になっていました。このへんの話は本書とオレンジの色合いが似ている『AWSコンテナ設計・構築[本格]入門』にも載っていますが、最適なモダンなプリケーションは1択ではないわけですね。

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

  • 機能ごとのフィーチャーブランチがずーっと続いてメインブランチになかなかマージされないと品質向上やリリースに時間が掛かる。定期的にメインブランチにマージしていく。
  • ブランチ戦略にもGit Flowなど有名なものがあるが、長命ブランチを最小限に抑えるように注意。
  • 自動化の恩恵を受けやすく、リリース後の機能追加の修正もしやすくなるので一番最初に構築した方がいいよ、という「パイプライン・ファースト」の考え方。
  • CI/CDに必要な機能の改めての整理
  • Sample Book Storeへの適用例。今はEC2上のJenkinsでやっているところを...
    • サーバーレスな機能ではSAMCloudFormationGitHub Actionsを使って実現
    • サーバーレスコンテナな機能ではCodeBuild, Code Pipelineを使って実現
    • さらに脆弱性検査も組み込んだり拡張できる! 本書ではTrivyを紹介。

 パイプラインの活用方法が幅広く解説されています。

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

  • 検討すべき要件を整理すると:データ量、増減パターン、保持期間、アクセスパターン、データ形式がある。
  • このアプリケーションで実現したい要件に最適だからという理由で選ぶ「Purpose-built database」という考え方が重要。
  • Sample Book Storeでの適用例として...
    • 書籍データは穏やかに増えて様々な条件で検索、参照が多い(Read Heavy)→RDSを使い、前面にElastiCache
    • ユーザーごとのお気に入りデータは登録/参照/削除が同じぐらい→DynamoDBで、キーやインデックスをしっかり設計

 なんとなくで選択してしまいそうなDBの選択を深掘った章。何を観点にどう選択していくべきかがしっかり解説されています。ここでもSample Book Storeでの適用例が秀悦で、ああ確かにこのケースはRDS、このケースならDynamoDBだなあとスッと納得できます。

aws.amazon.com

第8章 モダンアプリケーションパターンの適用によるアーキテクチャの最適化

 8章では様々なパターンを適用してSample Book Storeをさらにモダン化していきます。クラスメソッドさんの書評記事に写真が載っていますが、7章まで、そして8章ぶんまで適用したアーキテクチャ図が最初に載っており、かなりビルディングブロックの数も増えて細かくなっています。最初の頃に比べるとすごい進化を遂げています! これが...モダンアプリケーションなんや...

  • 特定の状況下で課題を解決する際に直面する目的や制約に対する解決策を「パターン」と呼んで、各種当てはめていく。
  • Sample Book Storeでは非同期なイベント駆動のサービスはLambda、同期的なAPI提供のサービスにはECS、を基準にしている。
  • 画面へのSPAの導入:デプロイはCloudFront+S3で。
    • なおGitリポジトリにフロントエンド部分をコミット→S3静的Webサイトにデプロイ+内部でCloudFrontを持つという、上記を内包したAWS Amplify Hostingというサービスがある(!)
  • API Gatewayパターンで複雑性を集約:
    • AWSでは同名サービスのAPI Gatewayをバックエンド側の前面に置き、通信回数を抑える。
  • BFF(Backends for Frontends)パターン:ブラウザやモバイル、クライアントそれぞれにAPIを集約。
    • これもそれぞれにAPI Gatewayを用意。
  • サービス間で非同期に通信するメッセージングパターン:動的な通信の連鎖ではレイテンシー/信頼性/サービス結合度/負荷 の問題がある。どこかが落ちたら全部に影響してしまう。そこで...
    • キューモデル:キューに貯めることでスパイクをバッファリングできる。SQSを活用。
    • パブサブモデル:publisherがsubscriberに一斉に投げる。1対多を特に「ファンアウト」という。AWSではEventBridgeSNSを活用。そこからLambda関数やSQS、他のAPIに飛ばせる。
    • この2つを組み合わせた構成もある。
  • 分散トランザクションでデータ整合性を維持するSagaパターン
    • Saga(コレオグラフィ):ダンスの振り付けの意。まとめ役不在で各サービスが協調してやっていく。EventBridgeから各サービスをコール、エラーが起こったらそのサービスから補償イベントを送信。
    • Saga(オーケストレーション):指揮者の役割をするまとめ役の人がいる。AWSではStep Functionsがエラー時の処理も指定できるので実現可能。
  • データの登録と参照を分離するCQRS(Command and Query Responsibility Seregation)パターン:
    • DynamoDBに登録→DynamoDB Streamsを使って変更をトリガー→RDSにコピーしてこちらは参照専用に。
  • イベントソーシング:
    • RDSに記録して更新し続けるのでなく、すべてのイベントをログとして保存し他のサービスに伝搬。変更をすべてDynamoDBに記録する。EventBridgeでも実はできる。
  • サーキットブレイカー:非同期でなく同期通信が必須の要件で、どこかのサービスが落ちたときに影響を食い止める。あるサービスが正常レスポンスを返せなくなったら、手前の「サーキットブレイカー」がすぐエラー応答を返したり一部のリクエストだけ許可したり。「サービスメッシュ」の一部として実現。
  • サービスディスカバリ:あるサービス→別サービス→別サービス..と伝わっていくとき、スケール対応でインスタンス数が増減するなら見つける必要がある。
    • AWSなら手前のELBに聞けばよいがELBを使わない場合。「サービスレジストリ」というのがインスタンス情報を管理しており、これに次のサービスを聞きに行くとクライアント側で負荷分散できる。AWSならCloud Mapがある。ただし接続先をどう分散して使うかなどのロジック実装が呼び出し側に必要。
  • サービスメッシュ:サービス同士で通信する場合ネットワークは信頼できないのでロギングなど共通ライブラリが各サービスに重複して必要、統一して監視が必要。通信にプロキシを配置、さらに「コントロールプレーン」で一元管理する。
    • OSSIstioを使う方法
    • AWSならApp Meshがある。App Mesh はプロキシ部分はOSSEnvoyを使っている。AWS Cloud Mapと連携。サーキットブレイカーの機能がある。ひとつのECS内のコンテナ全体をこのApp Meshでくるむイメージ。
    • なお、現時点ではLambdaからはこのApp Meshがまだ使えないため、本書のSample Book StoreではECSベースの戦略にしている。
  • フィーチャーフラグ:新機能を積極的にリリース。新機能用のフィーチャーブランチは短期間でメインのブランチにマージ。別のリリースブランチを用意するかメインのブランチからどんどんリリース。
    • 特定日時から使う新機能などはコードでなく設定ファイルで切り替えられるようにし、コードの中ではif文やユーザの1/xにだけ新機能を適用...などの分岐を埋め込む。
    • AWS Systems Manager Parameter Storeでやる時は、開発/本番など同じ項目にX個づつパラメーターがいるのに注意。
    • 最近はCloudWatch Evidentlyという機能でもフィーチャーフラグ管理やモニタリングができる。
    • AWS AppConfig(AWSのSystems Managerの1機能の扱い、2019〜)にもフィーチャーフラグ機能がある。
  • 分散トレーシング:たくさんのサービスを横断して流れていくリクエストの追跡が必要。
    • AWSならX-Rayがある。CNCFのプロジェクトであるOpenTelemtryというのもあり、これのディストリビューションAWS Distro for OpenTelemetry(ADOT)として提供されている。

 最終章といいつつ本書の後半約1/3を占める圧倒的なボリューム! 既にAWSの主要サービスが分かっている方、日々バリバリ運用している方ならこの8章はお役立ち知識の宝庫ではないでしょうか。
 各節のタイトルは『マイクロサービスパターン』という本などに載っているパターンとだいたい通じているのですが、この抽象化されたパターン群をAWSではどう具象化して実現するのか、その間の空白がだいぶ繋がってクリアになります。
 自分は同書でも詳しく載っている分散トランザクションのSagaパターン、すごく難しくて面倒くさそうで読んでて「えっここまでして分散トランザクション実現しなきゃいけないの...苦行なんですけど...」と感じたのですが(笑)、本書を読んでおお!となりました。そうか...AWSだとStep Functionsをうまく使うと実現できるんですね...!

 他にもAWS認定だけは持ってるマンとしては知らないサービスがけっこう出てきました。Amplify HostingCloud MapApp MeshAppConfigADOT、このへんは僕が獲った時点の認定試験ではまだ見かけなかったですね。いやはやどんどん進化していきますね...。
本書で扱っている「モダンアプリケーション」は必ずしも「マイクロサービス」とイコールではないかと思いますが、AWS上でマイクロサービスを現実化する手段もけっこう整ってきたのだなあと思ったり。

 フィーチャーフラグは幾つかの実例をともに詳しく述べられています。似たような考え方を本番稼働中のシステムで既に使っている方もおられるのではないでしょうか。オライリー本の『ユニコーン企業のひみつ』にもちょこっと出てきてSpotify社でも使っているパターンですね。

 ちなみにフィーチャーフラグのRubyコード例では変数名がふつうに flag になっています。読みやすいコードを書いたり設計を追求する本の観点ですとこれは紛らわしい変数名としてリーダブルコード警察に通報案件ですが(笑)、本書はより抽象度の高い領域を扱っている本なのでヨシ!であります。(現場猫のポーズで)

まとめ:モダンアプリの考え方がよく学べる本

 冒頭の本書で特に大切にした点のひとつとして分かりやすさを追求したとあるのですが、確かにその通りでした。それほど分厚い本ではないのですが、自分はあっけないぐらいにスラスラ読めてスッと大枠が頭に入ってきました。ある程度AWSの前提知識がある方ならすーっと読めるであろうというのは、それだけ中身の工夫を凝らしたのだろうなあと思います。
 具体シナリオのSample Book StoreはRuby on Railsで作られている設定なのでたまにコード片でRubyのコードも登場しますが、だいたいAWS SDKを呼んでいるだけの簡単コードなのでRuby畑でない方でもまったく問題ないかと思います。
 AWS知識については、AWS自体に入門中ぐらいの方は主要サービス概要は先に理解したほうが良いかと思いますが、その先の段階にいる方なら問題なく読めるでしょう。

 そしてこの手の最新技術の話になると、ベストプラクティスとかその筋の偉い人によるこれを使うといいんです!という唯一絶対の答えをつい求めたくなってしまうのですが、本書は必ずしもそうではありません。
各章で技術要素をバランス良く紹介しながらも、章の最後のアクティビティで「皆さんはどう考えますか。」と逆に本から問いかけを受けて「ウッ唯一の正解を求めてしまってスイマセン...」というキモチになります。(笑)

 20世紀からのエンジニア界の金言『銀の弾丸はない』はここでも成り立ち、永続的な唯一の答えはない。目の前の要件や課題を分析してなぜその技術を選んだかを明確にしながら選択し、そして未来においてはその選択がまた変わってもよいように継続的に選択を見直し、変化を受け入れて対応し拡張していく。これがモダンアプリケーションの考え方なのだなあと改めて理解しました。
 このエントリを書いている時点でめでたく増刷(3刷)も決定とのことで、かなり注目されているようです。クラスメソッドさんの書評に「5年間は生き続ける考え方が凝縮された〜」とありますがその通り、考え方がよく分かる本でした!

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

はてブでも話題になったお馴染みクラスメソッドさんの書評。

dev.classmethod.jp

id:beatdjam さんのブログにも感想が上がっています。

blog.beatdjam.com

おまけ:関連書籍

 本書のテーマ群と関連する本を集めてみました。AWSの本は最近色々揃ってきた感がありますね。

AWS概観

 本書の内容を理解できるように至る前に、まずは沢山あるサービスを体系的に概観せねば...という方なら、『AWSの基本・仕組み・重要用語が全部わかる教科書 (見るだけ図解)』が最新で2022/8。『AWSの知識地図 〜現場必修の基礎から構築・セキュリティまで』が2022/4。『図解 Amazon Web Servicesの仕組みとサービスがたった1日でよくわかる』が2022/2。いま入門するならこの3冊のうちのどれかから、が鉄板でしょうか。

『図解まるわかり AWSのしくみ』という本も2022/5に出ていますが、エンジニアより一般の人寄りの初心者向けのようです。

このテーマでは『図解即戦力 Amazon Web Servicesのしくみと技術がこれ1冊でしっかりわかる教科書』もベストセラーですが、2019/11なのでやや古くなっているかもしれません。

コンテナ

 本書でも登場するECS or EKS+EC2 or Fargateのコンテナ周りといえば、『AWSコンテナ設計・構築[本格]入門』が2021/10、この本でしっかりと深堀りされています。

サーバーレス

サーバーレスの中核をなすLambda関数にフォーカスした本としては、『AWS Lambda実践ガイド 第2版 impress top gearシリーズ』が2022/3に第2版となって最新化されています。

『動かして学ぶ!Pythonサーバレスアプリ開発入門』が2021/6、Pythonでサーバーレスという不思議な組み合わせの本。

『基礎から学ぶ サーバーレス開発』が2020/7でCIerとしておなじみアイレットさんの本。こちらも一通りまとまっています。現時点でサーバーレス全体で1冊選ぶなら最新はこの本でしょうか。

Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド』が2018/3、当時AWSJ所属だった西谷 圭介さんの本。

AWSによるサーバーレスアーキテクチャ』が同時期の2018/3、こちらは翻訳本でがっつりと扱っています。

 一番古いのがオライリー本の『サーバーレスシングルページアプリケーション ―S3、AWS Lambda、API Gateway、DynamoDB、Cognitoで構築するスケーラブルなWebサービス』で2017/6、さすがに古いので他の本がよいでしょう。

マイクロサービス

初版は2016年だったオライリー本の『マイクロサービスアーキテクチャ』はだいぶ分厚くなって『マイクロサービスアーキテクチャ 第2版』が2022/12、最新化されています。表紙の蜂の巣もカラーになっています。

同じくオライリー本の『モノリスからマイクロサービスへ ―モノリスを進化させる実践移行ガイド』が2020/12、こちらも新しめですね。

国産の『絵で見てわかるマイクロサービスの仕組み』が2021/7、だいたい他の本と同じようなことが書いてあるので他の翻訳本でもいいかもという感じでした。この本だけは日本産なので、DXというワードが連発されています。

『マイクロサービスパターン[実践的システムデザインのためのコード解説] (impress top gear)』が2020/3、翻訳本で本書の8章にも登場する様々なパターンを詳細に述べています。分厚いけどためになる本です。

オライリー本の『プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化』は2017/9でちょっと古め。こちらも表紙は『マイクロサービスアーキテクチャ』と一緒で蜂になっています。