Serverless DeepDive #00：なぜServerlessを選ぶのか
管理する実行基盤を減らし、担当者が変わっても運用を続けるために、Serverlessを選ぶ理由を考えます。AWSと利用者の管理範囲をもとに、サービスの条件を引き受ける設計と、Lambdaを選ぶ条件を説明します。
Series: Serverless DeepDive (13 articles)
- 1Serverless DeepDive #00：なぜServerlessを選ぶのか This article
業務を動かし続けるために
僕は、管理する実行基盤をできるだけ減らしたいと思っています。担当者が変わっても運用を続けられるようにしたいからです。
コードが完成したあとも、サーバーの更新や監視、台数の調整は続きます。どこを変更すると何に影響するかを、次の担当者も把握する必要があります。自分たちで管理する範囲が広いほど、引き継ぐ知識も増えます。
Serverlessを選ぶとき、僕はその管理をどこまでサービス側へ移せるかを考えます。
Lambdaで変わる管理の範囲
通常のon-demand Lambda関数では、AWSがサーバーやOSを保守し、呼び出しに応じて実行環境を用意します。Lambdaの動作説明 には、AWSが管理する範囲と、利用者が設定する権限やコードの関係が示されています。
runtimeは、コードを動かす言語の実行環境です。AWSが提供する対応runtimeをAuto設定で使う場合、AWSがそのruntimeの更新を適用します。runtime管理の責任分担 では、設定やデプロイ方法によって、更新を適用する担当が変わります。
自分で追加したlibraryの更新と、アプリの互換性確認は利用者の仕事です。言語のメジャーversionを変えるときも、利用者が関数を更新します。この範囲はLambda runtimes に説明があります。
図は、管理責任の分担を示す概念図です。通常のon-demand Lambda関数を対象に、AWS提供runtimeのAuto更新を例にしています。
サーバーやOSの保守をAWSの管理範囲へ移すと、その手順を自分たちで持ち続ける仕事を減らせます。アプリの更新時には、業務のコードや依存library、設定を中心に確認します。どこまで管理するかを決めて、チームが引き継ぐ範囲を絞ります。僕がServerlessに期待しているのは、この変化です。
Capital Oneの「How serverless reduces the cost of collaboration」 では、Kelsey Hightower氏が、Serverlessの価値を、チーム間で決める仕事が減るという視点で説明しています。デプロイやログ、通信の標準をサービス側が持つことで、基盤を作るための合意を毎回積み重ねる負担を減らせる、という議論です。
僕の目的に照らすと、採用時には、担当するサーバーの台数に加えて、自分たちで決め続けることにも目を向けたいと思います。保守するコードや、障害時に調べる対象まで含めて、管理する範囲を考えます。
サービスの条件に合わせて設計する
通常のon-demand Lambda関数は、呼び出しごとにコードを実行します。必要な状態の保存先や、失敗した処理をやり直す方法を、その実行モデルに合わせて決めます。Serverless Applications Lensの設計原則 も、短命な実行環境、重複するイベント、失敗が起こりうることを前提にしています。
たとえば、CSVを受け取り、在庫を更新する処理を考えます。途中で止まった仕事を再開するには、どこまで反映したかを保存します。同じ処理をやり直せるように、在庫を二重に加算しない方法も決めます。受け付けたCSVと、反映が終わったCSVを区別する記録も必要です。
こうした設計ができれば、実行環境が作り直されたときも、保存した記録から処理を続けられます。代わりに、進捗の保存や再処理の仕組みを作り、その状態を監視する仕事が増えます。減らす基盤管理と、業務側で持つ仕事を比べて選びます。
僕は、このようにサービスの条件を引き受ける姿勢を「誓約」として捉えています。利用者が受け入れる設計条件、という意味です。仕様を読み、必要な条件を記録し、実際の挙動を確かめながら使います。
業務に合わせて実行方法を選ぶ
Serverlessで構成を考えるときも、コードを置く場所は業務から決めます。
API GatewayのHTTP APIには、SQSというメッセージキューへ直接送信するサービス統合 があります。リクエストをキューへ渡すだけなら、その統合でコードの管理も減らせます。
サービスの設定だけでは表せない照合やデータ変換が必要なら、独自のコードを持つ理由が生まれます。その仕事を呼び出し単位で実行したいとき、Lambdaを選びます。データの保存先や完了の記録も、その業務に合わせて組み立てます。
常駐するprocessや、複数の処理にまたがって維持する接続が要件なら、Fargateでコンテナを動かす方法を考えます。Fargateでも基盤のサーバー管理はAWSが行い、利用者はコンテナの起動や停止、必要なCPUやmemoryなどを決めます。LambdaとFargateのDecision Guide は、こうした実行モデルの違いから選択条件を説明しています。
業務ルールを書く必要があるか、どの単位で実行を終えられるか、何を保存して次の処理へ渡すか。ここを決めてからサービスを選ぶと、Lambdaを使う理由も、別の方法を選ぶ理由も説明できます。
選んだ理由を次の担当者へ渡す
LEGO GroupのNicole Yip氏への2021年のインタビュー では、LambdaとFargateを併用する構成に加え、チームがサービスを引き継ぐための取り組みが語られています。サービスの役割、起動方法、制約、構成図を文書にし、運用の基準を共有していました。
その取り組みでも、監査で作った修正ticketを配るだけでは、しばらく作業が進みませんでした。監視と追跡の導入へ目標を絞り、利点と手順を伝えることで、利用が広がったと説明しています。基盤をServerlessへ移したあとにも、チームが運用できるようにする仕事があります。
僕も、採用したサービス名に加えて、その構成を選んだ理由を残したいと思っています。たとえば、CSVの反映を翌朝までに終えればよい業務と、画面操作へすぐに結果を返す業務では、受け入れられる待ち時間が違います。その前提と、失敗時の対応を記録すれば、次の担当者が続けるか変えるかを判断できます。
この連載では、要件を決め、設定や実装を変えてAWS上で確かめ、その結果を設計の判断へつなげます。差が出なかった場合も、判断した条件と一緒に残します。次の#01では、Lambdaの呼び出しに成功したとき、業務も成功したと判断してよいかを検証します。
Series: Serverless DeepDive (13 articles)
- 1Serverless DeepDive #00：なぜServerlessを選ぶのか This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article