【ITニュース解説】What serverless developers need to know about the 12 Factors

分散システムやスケーラブルなシステムの構築は、ますます複雑な課題となっている。特に、サーバーを意識せずにアプリケーションを構築できるサーバーレスアーキテクチャを選択した場合でも、その難しさは変わらない。このような現代的なアプリケーション開発において、指針となる考え方が存在する。それが2011年に提唱された「The 12-Factor App」というモデルである。これは、時間とともにメンテナンスが容易で、異なる環境への移植がしやすく、需要に応じて規模を拡大できる、堅牢なアプリケーションを構築するための12のベストプラクティスをまとめたものである。サーバーレスの考え方と非常に相性が良い一方で、サーバーレス特有の視点で理解し直す必要がある点も存在する。

最初の原則は、バージョン管理システムで追跡される単一のコードベースから、開発環境や本番環境など複数の環境へデプロイを行うというものだ。サーバーレスでは多数の小さな関数（Lambda関数など）を作成することが多いが、それらが無秩序に散らばるべきではない。関連する機能やビジネスの文脈で関数をグループ化し、システム全体として一貫性のある単一のコードベースで管理することが理想とされる。

次に、アプリケーションが必要とするライブラリなどの依存関係は、明示的に宣言し、隔離されなければならない。これにより、どの環境でも同じようにアプリケーションを再現できる。サーバーレスでは、各関数が独自の実行環境を持つため、この原則はさらに重要になる。依存関係の管理が不十分だと、関数の起動時間（コールドスタート）が長くなったり、メンテナンスが困難になったり、最終的には不要なコスト増加につながる。

データベースの接続情報や外部APIのキーといった設定情報は、コードの中に直接書き込むのではなく、環境変数などを通じて外部から与えられるべきである。これにより、コードを変更・再デプロイすることなく、設定だけを安全に変更できる。分散システムであるサーバーレスでは、関数ごとや環境ごとに設定を変える必要があり、この原則の遵守は不可欠となる。AWS Systems Manager Parameter StoreやSecrets Managerといったサービスを利用して、設定情報を安全に一元管理することが推奨される。

データベース、メッセージキュー、キャッシュなどの外部サービスは、いつでも交換可能な「アタッチされたリソース」として扱うべきである。コード側では、特定の実装に強く依存せず、抽象的なインターフェースを通じて接続する。サーバーレスの世界では、データベースのDynamoDBやストレージのS3など、利用するサービスのほとんどがこのバックエンドサービスに該当する。この原則に従うことで、例えばキャッシュ機構をあるサービスから別のサービスへ、コードの大きな変更なしに切り替えることが可能になる。

アプリケーションのライフサイクルは、ソースコードをデプロイ可能な単位に変換する「ビルド」、ビルドされた成果物を実行環境に展開する「リリース」、そして実際にアプリケーションを動かす「実行」という3つのステージに厳密に分離されるべきである。サーバーレスではこの分離が自然に行われる。コードをパッケージ化し（ビルド）、CI/CDパイプラインを通じてクラウドにアップロードし（リリース）、イベントをトリガーに関数が実行される（実行）という流れがこれに該当する。

アプリケーションは、状態を持たない「ステートレス」なプロセスとして実行されるべきである。セッション情報のような、保持し続ける必要のあるデータは、データベースなどの外部の永続的なデータストアに保存する。これはサーバーレス、特にAWS Lambdaの基本思想そのものである。Lambda関数は呼び出されるたびに起動し、処理が終わると終了する一時的な存在であり、ローカルに状態を保持しない前提で設計する必要がある。

アプリケーションは、それ自体が自己完結型のサービスとして、特定のポートでリクエストを待ち受けることで外部に機能を公開する。サーバーレスでは、この役割をAPI GatewayやAppSync、EventBridgeといったサービスが担う。物理的なポートではなく、HTTPエンドポイントや特定のイベントを「待ち受け」、それに応じて関数が実行されるという形でこの原則が実現される。

システムの処理能力を向上させるには、単一の巨大なプロセスを高性能化するのではなく、独立した多数のプロセスを並行して実行することで対応すべきである。サーバーレスは、この原則を最も体現しているアーキテクチャの一つだ。リクエストが増加すると、クラウドプラットフォームが自動的に関数のインスタンスを増やして並行処理するため、開発者はスケーラビリティを意識することなく、個々のリクエストを処理するロジックに集中できる。

プロセスは迅速に起動でき、またいつでも安全に停止できる「使い捨て可能」なものであるべきだ。これにより、システムの耐障害性が高まり、迅速なデプロイやスケーリングが可能になる。Lambda関数はまさに「生まれては死ぬ」を繰り返す存在であり、この原則に合致している。ただし、起動が遅くなる「コールドスタート」という課題も存在する。これを最小限に抑えるため、軽量なプログラミング言語を選んだり、依存関係を小さく保つといった工夫が求められる。

開発環境、ステージング環境、本番環境は、可能な限り同一の状態に保つべきである。環境間の差異が原因で、本番環境でのみ発生する予期せぬエラーを防ぐためだ。従来、本番環境と同じ構成の開発環境を維持するのはコストがかかったが、サーバーレスでは使用した分だけ課金されるため、低コストで本番に近い環境を複数用意することが容易になった。Infrastructure as Code（IaC）という手法で環境構成をコード化し、自動で構築することがこの原則を実現する鍵となる。

ログは、アプリケーションの動作を記録したイベントの連続的なストリームとして扱うべきである。ログをファイルに書き出すのではなく、標準出力に流し、実行環境がそれを収集して外部のログ集約・分析システムへ転送する。サーバーレスでは、Lambdaのログは自動的にAmazon CloudWatchに送られる。開発者の仕事は、これらのログをただ眺めるのではなく、構造化された形式（JSONなど）で出力し、分析ツールを使ってシステムの状態を効果的に監視することである。

データベースのデータ移行や一時的なメンテナンス作業といった管理タスクは、アプリケーション本体のプロセスとは切り離された、一回限りの使い捨てプロセスとして実行するべきだ。サーバーレスでは、このようなタスクを実行するために専用のLambda関数を用意し、スケジュール実行したり、手動でトリガーしたりすることができる。これにより、本番のアプリケーションフローに影響を与えることなく、安全に管理作業を行える。

結論として、12-Factor Appの原則は、サーバーレスという現代的なアーキテクチャにおいても非常に有効なガイドラインである。サーバーレスの多くの機能は、これらの原則を自然に満たすように設計されているが、各原則の背景にある思想を深く理解することで、結合度の高いシステムや、監視が困難なシステムといった落とし穴を避けることができる。これらの指針に従うことで、変化に強く、長期的に価値を提供し続けられる、高品質なソフトウェアを構築することが可能になる。