AWSによるサーバーレスアーキテクチャ読了後感想

サーバーレスアーキテクチャのまとまった書籍ないかなと探して見つけた一冊を読んでみたので、感想を含めてメモ書きです。

AWSによるサーバーレスアーキテクチャ

作者: Peter Sbarski,吉田真吾,長尾高弘
出版社/メーカー: 翔泳社
発売日: 2018/03/14
メディア: 単行本（ソフトカバー）
この商品を含むブログ (1件) を見る

TL;DR

Youtubeクローンのサービス作成を通して、サーバーレスアーキテクチャでサービスを作るためのアーキテクチャ、考え方、コンポーネントの使い方と実装・テストといった設計からサービスの公開までの一連の要素を学べます。

特にアーキテクチャの原則や各章で説明されているコンポーネントの組み合わせ・実装はAWSに限らず汎用的に適用できるものだと手を動かしながら感じました。それと個人的にはちゃんとテストを書こうって書いてあったのは好印象。

また、サーバーレスのコンポーネントとしてAWSのサービスを多用していますが、類似したサービスは他のクラウドベンダーやOSSにも存在するので置き換えて作ることもできそうです。

以下、この書籍からピックアップして所感を書き連ねます。

サーバーレスアーキテクチャの原則

この書籍で一貫して適用される原則です。具体的には以下の5つになります。

オンデマンドでコードを実行するために、サーバーを自分で立てるのではなくコンピューティングサービスを使う
目的が1つでステートレスな関数を作る
プッシュベースのイベント駆動パイプラインを設計する
より厚く強力なフロントエンドを作る
サードパーティサービスの活用する

1つのアプリケーションサーバーで実現していたことをサーバーレスアーキテクチャで実装するにはどれも重要な原則です。

(2)を突き詰めると(4)や(5)も自然と実施するようになるので、それぞれ独立した原則ではなく相互関係があるように思えます。

(3)のイベント駆動パイプラインはAPI Gatewayから接続されるようなサービスではなく、非同期サービス側だけで使うアーキテクチャ・実装に見えます。ですが、背後にこのようなアーキテクチャのパイプラインがあることを意識すると、同期的に処理するAPIのインターフェイスや、APIとパイプラインの接続部分の実装が変わります。

サーバーレスのコンポーネント

この書籍で使用したコンポーネントは以下の通りです。

AWS Lambda ... Computing Service
Amazon S3 ... Storage and Event
Auth0 ... OAuth style authentication
Amazon SNS ... Notification
Amazon SES ... Email
Amazon CloudWatch ... Monitoring
Amazon CloudTrail ... Auditing
Amazon API Gateway ... Relate API with Lambda
Firebase Realtime Database ... Realtime datastore
AWS Step Functions ... State machine

こうやって使ったコンポーネントを見ると、サービスをたくさん使いました。下の参考記事みたいにサーバーレスのサービスのアーキテクチャをServiceful Serverlessと表現するのは的を得ていますね。

--> サーバーレスによる大変革

標準的だったり汎用的な機能はクラウドベンダーもしくはサードパーティーのサービスを使い、カスタムコードは単一の目的に特化した最低限だけ書く。そしてそのカスタムコードはサービスを繋ぐ(=グルーコードにする)。カスタムコードをいかに書かずに実現させるかを考えるのはゴリゴリコードを書くのとはまた違った楽しさがあって良いです。

Good Point

実際にコードを書きながら学べる
- これは言わずもがなですが、ただ読んでいるだけではなく手を動かしながらの方が理解できますね。
自然とクラウドネイティブなサービスを作れる
- まるでCNCFの定義のようなクラウドネイティブなアーキテクチャに結果的になっています。「管理しやすい」については疑問が残りますが、他の要素については概ね満たしていますね。
- スケーラブルなサービスである
  - Lambdaやイベント駆動パイプラインを使用することで、特定部分がボトルネックにならない！
- コンポーネントが互いに疎結合となっている
  - コンポーネント同士を同期的に呼び出さずにS3イベントやSNSを使うことで、他のコンポーネントを意識しなくて良い。
- 耐障害性がある
  - 特定の部分が失敗したり応答不能になっても、他のサービスには影響しない。
- 可観測性が高い
  - CloudWatch Metrics/LogsやCloudTrailを使うことでそれぞれのコンポーネントの状態を把握できるようになっている。
上記の原則に沿って、サーバーを意識しない/自分で管理せずサービスをどのように作るのか明確であった。
- 自分でEC2やベアメタルサーバーを立てずにLambdaを使う、フロントエンドを厚くする、サードパーティーサービスを活用して自分でコードを書かずに機能を実現できるといった具合です。
エラーハンドリングについてアーキテクチャ的解答があった。
- 単純に実装としてDLQを使いましょうで済ませてないです。なんでDLQを使わないといけないんだっけ?の理由が自分の中ではフワッとした理解に留まっていたので、この解答には膝を打った。
  - (Why) マイクロサービスになるにつれて全てのサービスのトランザクションをまとめ上げるプロセスが存在しなくなるため、一連の処理の一部が失敗した場合のデータの整合性担保が難しくなる。
  - (What) アーキテクチャとしては、エラー通知のトピックとエラー処理サービスを立ててロールバックを実行する。
  - (How) 通知の具体的なコンポーネントとして、SNS/SQSを使ったDLQを使用する。

Bad Point

上記のように良書ではあるものの、残念 or ここは改善できそうというポイントもありました。

CI/CDパイプラインを作らず全てコマンド手動実行
- package.jsonにパッケージングやデプロイ用のコマンドを書いてまとめてはいるものの、いちいち自分で実行しないといけないのは効率が悪いです。
- 画像処理のためにffmpegを入れるLambdaのデプロイパッケージのZIPファイルは40MB近くあるため、ネットワークによってはupdate-function-codeが失敗します。これがすごいストレスです。S3にアップロードしてからコマンドを叩けばデプロイ可能ですが、AWS SAMやServerless Frameworkを使ったCI/CDパイプラインを作ればストレスフリーかつ時短になったはず。
- 折角クラウドサービスを使ってるんだから、手作業でボトルネックができちゃうのは勿体無い点です。
使用するサービスが古い
- 面白みに欠けるという意味ではなく、すでにdeprecatedになっている機能や代替サービスの使用を前提としていたことがあって何度か心が折れそうでした笑
- Auth0は認証用のウィジェットとして組み込みのUIではなく、Auth0がホストするUI(Universal UI)の使用が推奨されていました。こっちの方がライブラリ管理が少なくてベターに感じます。
- Firebase Realtime Databaseの代わりに(beta版ではありますが)Firestoreを利用が最近は多いようです。
- 認証は委譲トークン(Delegation Token)を使用する前提で記載されていましたが、この手法による認証方法は廃止されていました。
長時間処理するバッチコンピューティングの利用や、既存のサーバーを使ったレガシーアプリケーションとの共存・マイグレーションについて言及がなかった。
- 実際には一からサーバーレスで作ることは(特にエンタープライズ系のサービスだと)少ない訳ですし、サーバーありのサービスとの共存や割り切り方については何かしら意見が欲しかったところです。
- 例えばAWS BatchやEMRを使うケース、ECRを併用するケースってどう切り分けているのかしら...??とか。

まとめ

上記のようにGood/Badポイントは双方あるもののが、総じてサーバーレスアーキテクチャと実装を理解し、イメージするには良書でした。単にAWS Lambdaを使おうに止まらず、サービスを作るために必要なコンポーネントやそれぞれの役割、原則について非常によくまとまっていたので、これからサーバーレスに挑む人には是非おすすめしたい書籍です。

せっかくなので、IBM Cloudや最近認定を取ろうと目論んでいるGCP、もしくはOSSをふんだんに使ったケースでも同じ or さらに発展させられないか試してみようと思います。

以上。

Ponz Dev Log

ゆるくてマイペースな開発日記