The Twelve-Factor App の対応状況を可視化するアンケートを作成してみた

アーキテクチャー エンジニアリング マイクロサービス

こんにちは。アーキテクトの小林です。

最近ブログの書き手が増えましたので、久しぶりに出番が回ってきました。 今回は、自分も最近まで知らなかった「The Twelve-Factor App 」を紹介いたします。 「The Twelve-Factor App 」は昨今の当社のプロダクト開発にとても役に立つ内容でしたので、これをブログ記事にすることで社内外のエンジニアに影響を与えられればと考え、少しでも役に立つ形になるようにアンケート化してみたというものです。

The Twelve-Factor Appとは

「The Twelve-Factor App」とは、Herokuプラットフォーム上での何百何千ものアプリケーションの開発・運用・スケールに間接的に立ち会った寄稿者が取りまとめたベストプラクティスの方法論です。

「The Twelve-Factor App」は、どのプログラミング言語でも当てはまるように抽象的な書き方になっていて、具体的な対処方法を書いてくれているわけではないため、ちょっとわかりにくいところもあるのですが、このキーワードでGoogle検索していただくと様々な方の解説ページが見つかります。

今流行の ChatGPTも知っていると思いますので「The Twelve-Factor Appについて教えてください」と入力してみました！ 以下は、ChatGPTが返してくれた文章です。

The Twelve-Factor App（12要素アプリ）は、クラウドネイティブアプリケーションの設計原則をまとめた方法論であり、Herokuの創設者であるAdam Wigginsによって提唱されました。これは、スケーラブルで持続可能なアプリケーションの開発と運用を簡素化するために、アプリケーションの設計や構築に関するベストプラクティスを定義したものです。

以下がThe Twelve-Factor Appの12の原則です。

  1. コードベース: すべてのアプリケーションは、1つのコードベースに格納され、バージョン管理されるべきです。
  2. 依存関係: 依存関係は明示的に宣言され、厳密に管理されるべきです。
  3. 設定: アプリケーションの設定は環境変数を使用して管理されるべきです。
  4. バックエンドサービス: すべてのリソースはバックエンドサービスとして扱われ、接続情報は環境変数を使用して設定されるべきです。
  5. ビルド、リリース、実行: アプリケーションのビルド、リリース、実行は明確に分離されるべきです。
  6. プロセス: アプリケーションは状態を持たず、シリアル化されたデータを介して状態を共有するべきです。
  7. ポートバインディング: アプリケーションは、ポート番号を環境変数から取得するべきです。
  8. 実行環境: アプリケーションは、実行環境に依存しないように設計されるべきです。
  9. ステートレスプロセス: ステートはローカルディスクに保存されず、外部のデータストレージに保存されるべきです。
  10. 開発/プロダクションパラダイム: 開発環境と本番環境はできるだけ一貫性を持つべきです。
  11. ログ: アプリケーションは標準出力にログを出力し、ログはイベントストリームとして扱われるべきです。
  12. 管理タスク: 管理タスクは、1回限りのプロセスとして実行されるべきであり、アプリケーションのランタイムプロセスとは分離されるべきです。また、管理タスクは明示的に実行されるべきであり、自動的に実行されるべきではありません。

これらの12の原則に従うことで、アプリケーションはスケーラブルで持続可能な形で開発・運用されることが期待されます。また、これらの原則はクラウドネイティブアプリケーションの設計や運用に適用されるだけでなく、モダンなアプリケーション開発において一般的に適用されるベストプラクティスとしても広く認められています。

ChatGPTのこの要約力！すばらしいですね。

実は「The Twelve-Factor App」が提唱されたのは2012年とやや古く、曖昧さや抽象的な部分をより明快に解説し、15項目に拡張して進化させた「Beyond the Twelve-Factor App」が書籍化されています。

「Beyond the Twelve-Factor App」は電子ブックバージョンとして無料でダウンロードできますので興味のある方はこちらからどうぞ。（英語です）

ついでにChatGPTに「Beyond the Twelve-Factor Appとの違いを教えてください」と聞いてみました。

Beyond the Twelve-Factor App（12要素アプリを超えて）は、The Twelve-Factor Appの発展版であり、より進んだトピックについて掘り下げた内容を含んでいます。The Twelve-Factor Appは、クラウドネイティブアプリケーションの基本的な設計原則をカバーしていますが、Beyond the Twelve-Factor Appはそれを補完し、より高度なトピックを扱っています。

以下はBeyond the Twelve-Factor Appのいくつかのトピック例です。

  1. マイクロサービスアーキテクチャ: マイクロサービスアーキテクチャの設計原則、モノリシックアプリケーションからマイクロサービスアーキテクチャへの移行方法についての詳細なガイダンスが含まれています。
  2. イベント駆動アーキテクチャ: イベント駆動アーキテクチャの原則、イベントドリブンなアプリケーションの設計と実装に関する情報が含まれています。
  3. セキュリティ: クラウドネイティブアプリケーションにおけるセキュリティの考慮事項、セキュリティベストプラクティスについての詳細な情報が含まれています。
  4. インフラストラクチャオーケストレーション: コンテナオーケストレーションツール（例: Kubernetes）を使用したアプリケーションのデプロイ、スケーリング、管理に関する情報が含まれています。
  5. サーバーレスコンピューティング: サーバーレスコンピューティングにおけるアプリケーションの設計と実装に関する情報が含まれています。
  6. DevOpsプラクティス: DevOps文化とプラクティス、CI/CD（Continuous Integration/Continuous Deployment）の導入に関する情報が含まれています。

これらのトピックを含め、Beyond the Twelve-Factor Appは、The Twelve-Factor Appの設計原則を拡張し、より深化した情報を提供しています。これにより、より複雑なクラウドネイティブアプリケーションの開発と運用に関する情報を得ることができます。

とまぁ、こんな感じになるわけです。

「Beyond the Twelve-Factor App」は発展版であり、根本的には「The Twelve-Factor App」をベースにしています。より複雑なクラウドネイティブアプリケーションに適応するものですので、まだまだクラウドネイティブアプリケーション開発者として「よちよち歩き」な我々としては、ひとまずは「The Twelve-Factor App」にきちんと対応させていく必要があると思っています。

そして、この知識が頭の中にある人がたくさんいるだけではまったく意味がありませんので、この知識をプロジェクトに適用できているのかを定期的に確認し、組織として「The Twelve-Factor App」対応についてPDCAを回せるようにしたいわけです。

そこで「The Twelve-Factor App」への対応状況をアンケートで可視化し、改善すべき点を見直せるようにしてみたいと考えました。なぜアンケートで可視化するのかというと、昨今のシステム開発ではマイクロサービスアーキテクチャの採用が進んでいますので、組織では多様なアプリケーションをマイクロサービスとして多数抱えることになります。それぞれのアプリケーションがきちんと「The Twelve-Factor App」に対応できているのかを管理するのが大変になるためです。

だいぶ前置きが長くなりました。ここからは「The Twelve-Factor App」の対応状況を確認するアンケート項目です。 アンケート項目の内容を検討するにあたっては「Beyond the Twelve-Factor App」で紹介されている発展的な内容も少し含めてあります。

The Twelve-Factor App対応状況確認アンケート

1. コードベース（15点満点）

  • アプリケーションのソースコードをGitリポジトリで管理していますか？

    • はい【5点】
    • いいえ【0点】

  • 別のアプリケーションと共有するソースコードは別リポジトリに切り出して外部ライブラリとして参照するようにしていますか？

    • はい【5点】
    • いいえ【0点】

  • 本番・ステージング・QAなどの複数の環境にデプロイされたアプリケーションは、リポジトリのタグ、ブランチ、コミットIDなどを指定して、それぞれの環境と完全に一致するデプロイをいつでも構築可能ですか？

    • はい【5点】
    • いいえ【0点】

2. 依存関係（10点満点）

  • アプリケーションが依存している言語ランタイムと外部ライブラリやツール類はすべて把握できる状態になっていますか？

    • はい【5点】
    • いいえ【0点】

  • アプリケーションが依存している言語ランタイムとすべての外部ライブラリやツール類は、パッケージマネージャーや環境構築手順書などでバージョンを明示的に宣言して管理されていますか？

    • はい【5点】
    • 最新版などのあいまいなバージョン指定を含む【3点】
    • いいえ【0点】

3. 設定（10点満点）

  • 本番・ステージング・QAなどの環境によって異なる設定の定数をどのように管理していますか？

    • 環境変数やデータベースなどのバックエンドサービスに保存している【5点】
    • テキスト形式の設定ファイルに記述している【2点】
    • ソースコードに記述している【0点】

  • 外部サービスのクレデンシャル情報をテキスト形式の設定ファイルに記述しないようにしていますか？

    • はい【5点】
    • いいえ【0点】

4. バックエンドサービス（5点満点）

  • データベースや電子メール、キャッシュなどのすべてバックエンドサービスを接続文字列等の設定変更によって再デプロイすることなくローカルサービスからマネージドサービス等のように切り替え可能にしていますか？
    • はい【5点】
    • いいえ【0点】

5. ビルド、リリース、実行（20点満点）

  • アプリケーションの実行環境で直接ソースコードを変更しないようにしていますか？

    • はい【5点】
    • いいえ【0点】

  • ビルドしたアプリケーションのパッケージをリリースとして一意のリリースIDを持たせて履歴管理していますか？

    • はい【5点】
    • いいえ【0点】

  • リリースに対応するソースコードのリポジトリのコミットIDを追跡できますか？

    • はい【5点】
    • いいえ【0点】

  • ビルドしたアプリケーションのパッケージは各環境固有の設定情報以外は完全に同一のものを本番・ステージング・QAなどの環境にデプロイしていますか？

    • はい【5点】
    • いいえ【0点】

6. プロセス（10点満点）

  • アプリケーションの実行サーバーのローカルに情報を永続化しないようにしていますか？（キャッシュとしての一時ファイルの利用を除く）

    • はい【5点】
    • いいえ【0点】

  • アプリケーションの実行サーバーのメモリ内にセッション情報を格納するスティッキーセッションを使わないようにしていますか？

    • はい【5点】
    • いいえ【0点】

7. ポートバインディング（10点満点）

  • アプリケーションはミドルウェアに依存することなく完全に自己完結していますか？（実行環境にWebサーバーやアプリケーションサーバー等をインストールしたりする必要はありませんか？）

    • はい【5点】
    • いいえ【0点】

  • アプリケーションはポートバインディングによって公開していますか？

    • はい【5点】
    • いいえ【0点】

8. 並行性（10点満点）

  • アプリケーションは複数のプロセスによって並行実行可能にしていますか？

    • はい【5点】
    • いいえ【0点】

  • アプリケーションは複数のサーバー上のプロセスとして水平方向にスケールアウト可能にしていますか？

    • はい【5点】
    • いいえ【0点】

9. 廃棄容易性（10点満点）

  • アプリケーションを強制的に終了した場合でも後続のリクエストやバッチ処理によって自動的に復旧できますか？

    • はい【5点】
    • いいえ【0点】

  • サーバーが起動している状態からアプリケーションを起動したときアプリケーションの起動時間にどのくらいかかりますか？

    • 10秒以内【5点】
    • 30秒以内【4点】
    • 60秒以内【3点】
    • 60秒を超える【0点】

10. 開発/本番一致（20点満点）

  • QA環境へのデプロイは数分以内に可能ですか？

    • はい【5点】
    • いいえ【0点】

  • 本番環境へのデプロイは１時間以内に可能ですか？

    • はい【5点】
    • いいえ【0点】

  • 本番環境へのデプロイではダウンタイムが起きないようになっていますか？

    • はい【5点】
    • いいえ【0点】

  • QA環境でテストされたリリースが本番環境で確実に動作することを期待できますか？

    • ネットワーク構成やバックエンドサービスの種類およびバージョンが高い互換性を持つ環境を維持している【5点】
    • リスクの低い許容可能な違いを持つ環境を維持している【3点】
    • 非互換のリスクがあるため本番環境での動作確認を欠かせない【0点】

11. ログ（10点満点）

  • アプリケーションはログの出力先を設定によって標準出力（標準エラー出力を含む）に容易に切り替えできるようにしていますか？

    • はい【5点】
    • いいえ【0点】

  • アプリケーションのログはログフォワーダーによって集約され可視化したりアラートを出す外部システムにつながっていますか？

    • はい【5点】
    • いいえ【0点】

12. 管理プロセス（5点満点）

  • アプリケーションのデータマイグレーション機能や管理用のコマンド等のツールはアプリケーションと一緒にデプロイしていますか？
    • はい【5点】
    • いいえ【0点】

最後に

「The Twelve-Factor App」の12項目について、アンケート項目をつくって紹介してみました。 点数はかなり大雑把に決めている部分がありますので、組織によって優先度の高い項目の配点を高くしたり、別のアンケート項目を追加するなど、いろいろ工夫してみてください。

アンケートが出来上がったら、実際にアンケートをとって可視化してみてください。現在地を知ることができなければ、目標を立てて進むべき方向を見つけることはできません。

この記事が皆様のクラウドネイティブアプリケーション開発のお役に立てれば幸いです。

ecbeingではクラウドネイティブな開発がしたい人を募集しています！

careers.ecbeing.tech