|
非常に影響力のある12要素認証方式は、最近の技術革新の多くをカバーしていません。Herokuは、コミュニティ主導の取り組みを通じて、この方式を最新の状態に保ち続けています。
12ファクター・メソドロジーは、企業がエンタープライズSaaS（Software-as-a-Service）アプリケーションを統一された管理しやすい方法で開発、運用、保守することを可能にする12の原則です。12ファクター・メソドロジーは、特定の製品、テクノロジー、ツールセットに依存するものではありません。むしろ、移植性、回復力、安定性、そして費用対効果を重視したソフトウェア開発哲学です。 12ファクターアプリケーションは、Herokuの共同創設者であるAdam Wigginsによって2011年に作成されたため、長年にわたり活用されてきました。長年にわたり、12ファクター原則は、開発者がクラウド上で実行される、より回復力、拡張性、管理性、保守性に優れたアプリケーションを開発するのに役立ってきました。 12ファクター方式が初めて登場した当時、WebベースのアプリケーションとAmazon Web Servicesはまだ初期段階にありました。それ以来、多くのことが変化しましたが、12ファクター方式自体はほとんど変わっていません。今こそ、これを近代化し、現代のテクノロジーの利用方法に合わせる時です。そのため、12ファクター方式はオープンソース化されました。 オープンソース化された 12 要素方法論の目的と影響について詳しく説明する前に、まずその背後にある原則を紹介します。 12の要因以下は、12 の要素を推進する原則について、各原則の意味とその使用方法を含めて簡単に説明したものです。 要因1: コードベース意味：各アプリケーションは単一のコードベースを使用し、バージョン管理によって追跡され、複数回デプロイされます。これにより、アプリケーションに関連するすべての資産が単一のリポジトリで管理されます。 アプリケーションアプローチ：通常、単一のコードベースをサポートするということは、プロジェクトのすべてのソースコードと補助的な成果物を、GitHub、BitBucket、AWS CodeCommit、Google CloudSourceリポジトリなどの単一のソースコードリポジトリに保存することを意味します。コードベースは複数のリポジトリに分散してはなりません。 要因2：依存意味：システムツールやライブラリへの暗黙的な依存を回避するため、すべての依存関係を明示的に宣言し、分離します。これにより、アプリケーションの予測可能性と管理性が向上します。 アプリケーション方法：依存関係の原則をサポートする上で重要な点は、独立したライブラリとパッケージを制御された方法で保存するリポジトリを使用することです。アプリケーションは、カスタムコードと独立して開発されたライブラリを分離し、これらのライブラリを構成ファイルにリストする必要があります。アプリケーションの実行時に、ビルド時と実行時に、独立したライブラリがプロジェクトに追加されます。ライブラリはソースコードと一緒に保存されるのではなく、ライブラリ開発者が管理する別のリポジトリに保存されます。 このようなリポジトリの例としては、npm (Node.js プロジェクト用)、PyPI (Python 用)、MVN リポジトリ (Java 用)、Chocolatey (.NET 用)、RubyGems (Ruby プログラミング言語用) などがあります。 要因3: 構成意味：異なるデプロイメント間の設定変更をコードとは別に保存します。これにより、コードベースを変更することなく、より簡単に変更を加えることができます。 アプリケーション：構成とコードを分離することは、エンタープライズシステムアーキテクチャにおける基本的なプラクティスとなっています。構成情報はマニフェストファイルに保存される場合もあります。Kubernetesなどのフレームワークは、マニフェストで宣言された情報を自動的に環境に注入します。さらに、構成の更新はマニフェストファイルの情報を変更することで実行されます。フレームワークは変更を検知し、環境を自動的に更新します。 構成要素の更新提案がオープンになっています (問題 #4)。 要因4: バックエンドサービス意味：バックエンドサービス（データベース、キュー、メモリキャッシュなど）は、設定に保存されたURLやその他のロケータを介してアクセスできる補助リソースとして扱われます。これにより、サービス間の互換性が容易になります。 適用：この原則では、リソースへのアクセスは標準プロトコル（HTTP/HTTPS接続など）を介して行う必要があります。ライブラリやコマンドラインインターフェース（CLI）ツールの使い方を理解する鍵は、これらの技術が実際のリソースを抽象化したものであるということです。これらの技術はリソースに厳密に結びついているわけではありません。プログラマーはリソースへのアクセス資格情報と実行する操作を宣言します。ツールはリソースとのやり取りの詳細を処理します。 理論上、プログラマーは最小限の影響でリソースプロバイダーを切り替えることができるはずです。しかし、他のテクノロジーと同様に、細部にこそ落とし穴があります。そのため、プログラマーはTCP/IPベースのリソースを使用するべきです。そうすることで、汎用的な方法でリソースにアクセスするためのコードが構築されます。 要素5: ビルド、公開、実行意味：デプロイメントプロセスのビルド、リリース、ランタイムの各フェーズを厳密に分離します。ビルドフェーズではコードをコンパイルし、リリースフェーズでは環境固有の設定を追加し、ランタイムフェーズではアプリケーションを実行します。 適用方法：JenkinsやTeamCityなどの包括的なCI/CDアプリケーションは、ビルド、リリース、実行の原則をサポートするために使用できます。これらのツールは通常、プログラマーがアプリケーションの構成設定とソースコードリポジトリを定義できるようにします。これらのツールには、指定されたリポジトリからソースコードを自動的に取得するスクリプトが含まれています。これらのスクリプトはアプリケーションをビルドし、構成設定をテストコードに適用します。（これらのテストスクリプトは、ソースコードと共にリポジトリに保存されます。）ビルドされたコードがテストに合格すると、スクリプトはビルドされたアプリケーションを指定されたランタイム環境にデプロイします。ビルド、リリース、実行の原則と組み合わせて使用されるCI/CDツールは、継続的、迅速、正確、かつ監視可能なアプリケーションデプロイを可能にします。 要因6：プロセス意味：アプリケーションを1つ以上のステートレスプロセスとして実行します。永続データはステートフルなバックエンドサービスに保存する必要があります。これにより、スケーリングが容易になり、予期しない副作用を防ぐことができます。 適用方法：ステートレスコードは、Webベースアプリケーションの基本原則です。プロセスの唯一のタスクは、処理ロジックを実行することです。プロセス間の副作用は避けるべきです。プロセスは、アプリケーション全体の状態やアプリケーション内の他のプロセスの状態に影響を与えてはなりません。プロセスの状態を判断するには、すべてのプロセス間のアクティビティを調整する、別の信頼できる情報源を調べてください。 要因7: ポートバインディング意味: ポート バインディングを使用してサービスをエクスポートし、自己完結型にして、指定されたポート経由でアクセスできるようにします。 適用方法：特定のポート番号は、特定のサービスと同義になっています。例えば、安全でないWebアプリケーションのデフォルトポートはポート80です。安全なWebサイトへはポート443でHTTPS経由でアクセスします。Kafkaメッセージングサービスはポート9092でクライアントトラフィックをリッスンします。MySQLデータベースのデフォルトポートは3306です。一部の企業は、自社製品のブランドをポート番号と関連付けるために多大な努力を払っています。DockerとKubernetesは、ポート宣言を使用してドメイン内のサービスへのアクセスポイントを定義します。開発レベルでは、プログラマーは通常、ローカルホストURLに基づいてマシン上のリソースまたはサービスを使用し、関連付けられたポート番号を介して特定のリソースまたはサービスにバインドします。 要因8: 同時実行性意味: アプリケーションをスケーリングする場合は、単一のプロセスを垂直方向にスケーリングするのではなく、プロセスを追加して水平方向にスケーリングする必要があります。 応募方法：オンデマンドの水平スケーリングのサポートは、現代のウェブスケールのエンタープライズアプリケーションにとって不可欠な機能となっています。AWS Elastic Container Service (ECS)、Docker Swarm、Google Cloud Run、Heroku、HashiCorpNomad、Kubernetes など、多くのテクノロジーが自動スケーリングをサポートしています。同時実行の原則を理解する上で重要なのは、アプリケーションは冗長かつ同時実行可能な、個別に独立した実行ロジックユニットで構成されている必要があるということです。実行ユニットの数は、現在のトラフィック需要に基づいてスケールアップまたはスケールダウンできます。 要因9：使い捨て意味: 起動とシャットダウンの時間を短縮して、回復力を最大限に高め、システムの堅牢性を高めます。 適用方法：12要素原則の廃棄可能性原則は、現代の分散アプリケーションの短命な性質を反映しています。同時実行原則が示すように、アプリケーションは現在のニーズを満たすためにリソースを冗長的に起動します。そのため、コンポーネントはトラフィック需要を満たすために常に「生成と終了」を繰り返します。リソースが終了する際は、迅速かつ適切に処理する必要があります。これは、操作が不定形で終了しないようにすることを意味します。操作は完了し、外部リソースへの接続は閉じられ、リソースはメモリから安全に削除される必要があります。コンポーネントが終了した後も、アプリケーション全体の状態は一貫性を保つ必要があります。 要因10: 開発/本番環境の一貫性意味: 継続的なデプロイメントを容易にし、開発と運用の間のギャップを減らすために、開発、デプロイメント、運用環境を可能な限り同じに保ちます。 適用方法：開発／本番環境の一貫性の原則は、ビルド、リリース、実行の原則に似ており、アプリケーション開発プロセスを個別の部分に分割します。ただし、ビルド、リリース、実行がコードのリリースに重点を置いているのに対し、開発／本番環境の一貫性は、アップグレード後の開発環境全体にわたるコードの一貫性に重点を置いています。 通常、ソフトウェア開発では、段階ごとに異なる操作が実行されます。開発段階では、開発者がコードを提出します。このコードは、コード分析とユニットテスト（場合によってはパフォーマンステスト）を受けます。すべてが順調に進んだ場合、ステージング環境に移行されます。ステージング段階では、コードはより広範なテスト体制にかけられ、セキュリティリスクを特定するための統合テストや侵入テストなどが含まれる場合があります。アプリケーションが人間によって使用される場合、ステージング環境では、コードが人間のニーズを満たしていることを確認するためのユーザビリティテストも行われます。最終的に、問題がなければ、コードは本番環境に移行されます。 開発環境と本番環境の一貫性に関する重要なポイントは、各環境（開発環境、ステージング環境、本番環境）が同一であること、そして各環境で自動化タスクを実行する際に同じツールを使用することです。さらに、緊急アップデートでない限り、アップグレードプロセスは一方向でなければなりません。つまり、コードは開発環境からステージング環境へ、そして本番環境へと移動する必要があります。開発環境とステージング環境の間を移動させることはできません。また、パッチ適用などの緊急事態では、コードが開発環境を経由せず、開発者のマシンからステージング環境へ直接移動されます。そのため、パッチコードが本番環境にリリースされたら、ステージング環境の変更に合わせて開発環境を更新する必要があります。 円滑に機能しているIT部門では、開発者がローカルマシンでコーディングセッションを開始する前に、開発環境のアップデートを毎日確認するのが慣例となっています。これにより、緊急の「後方」アップデート（ステージングから開発へのパッチ適用など）が開発者のマシンに確実に反映されます。 開発/運用環境の一貫性を保つための重要な要素は、各環境にわたるインフラストラクチャの均一性と、環境間のアップグレード プロセスの予測可能な制御です。 因子11: ログ意味：ログをイベントのストリームとして扱い、実行環境で集約します。これにより、ログ管理とデバッグが簡素化されます。 適用方法：ログ記録は、ログイベントを特定のテクノロジーに依存しない独立したデータストリームとして扱う必要があります。一般的な実装では、ログイベントをKafkaなどのデータストリーミングテクノロジーで使用されるメッセージとして扱います。ログ出力とログストレージを分離することで、アプリケーションの移植性が向上します。 データストリームにデータを記録すると、保存とデータ管理の責任はストリーム管理技術に委ねられます。そのトレードオフとして、ログデータを出力するマシンとアプリケーションに関する情報が不透明になります。したがって、標準化されたメッセージ形式を使用することは、効率性の向上に不可欠です。メッセージ形式には、イベント、マシン、アプリケーションに関する情報、そしてアプリケーションの動作に関連するその他のコンテキスト情報を含める必要があります。 イベント ストリームにログを記録することには多くの利点がありますが、ログに正確で包括的かつ有用な情報が記録されるようにするためには、追加の計画を立てる必要があります。 この要素を拡張して、テレメトリを含む現在の観測可能性の実践を反映するというオープンな提案があります (問題 #3)。 要因12: 管理プロセス意味：このアプローチでは、管理タスクを一回限りのプロセスとして扱い、アプリケーションと同じコードベースとバージョン管理システム内で管理します。これにより、一貫性と実行の容易さが確保されます。 応募方法：アプリケーションには、ダッシュボードなどの独自の管理機能が付属している必要があります。例えば、作家、ジャーナリスト、その他のコンテンツクリエイター向けのオンライン出版プラットフォームであるSubstackには、コンテンツクリエイターが出版業務や読者アクセスを制御できるダッシュボード機能が含まれています。このプラットフォームでは、コンテンツクリエイターが特定のコンテンツを有料アクセス用にセグメント化し、支払い方法を設定することもできます。この管理機能はSubstackの一部です。これは独立したアプリケーションではなく、ソースコードは別のリポジトリにホストされていません。一般的なアプリケーションと管理プロセスはどちらも統一されたコードベースの一部です。Substackは、管理プロセスの原則の一例です。管理機能はアプリケーションとは別のものとしてではなく、アプリケーションの一部として管理されることを理解することが重要です。 オープンソースをより高いレベルへ各要素の説明から気付くことの 1 つは、12 要素法は、その原則をサポートするために使用されるテクノロジに依存しないということです。 12ファクターアプローチが2011年に導入された当時、この手法はテクノロジー業界において斬新な考え方でした。この原則は特定の要件に依存しないため、特にHerokuのような、多様なツールやテクノロジーをサポートするプラットフォームを提供する企業にとって導入が容易でした。しかしその後数年間で、様々なクラウドプロバイダーが12ファクターアプローチを採用し、Herokuはオープンソース化することで、コミュニティによる近代化への貢献を促しています。 Heroku の最高マーケティング責任者はインタビューで次のように説明しています。
Junod氏が指摘するように、12要素原則は当時としては理にかなっていましたが、テクノロジー環境は劇的に変化しました。テレメトリ、認証、サービス間（S2S）通信といった現代の開発者やアーキテクトが日々取り組んでいる問題に対処するために、12要素原則は近代化する必要がありました。しかし、これらの問題は当初の方法論には含まれていませんでした。 Herokuは、12 factorialのモダナイゼーションへの幅広い参加を促すため、11月にCC-BY-4.0ライセンスの下でプロジェクトをオープンソース化しました。同社は、12 factorialのソースコードを元のウェブサイトから新しいオープンソースリポジトリに移行しました。 新しいリポジトリは、12 Factorialフレームワークへの貢献のための中心的なハブとなります。ウェブサイトのコードとドキュメントの更新版が含まれており、これらの要素に関するより詳細な説明も含まれています。また、O'Reilly、Nginx、IBMといった様々な組織からの新しいアイデアや追加ドキュメントへのリンクも含まれています。これらの企業は12 Factorialフレームワークの精神を受け入れており、彼らの洞察は、今日のフレームワークをより適切なものにする上で非常に貴重です。 オープンソースの最も重要な利点は、透明性とコミュニティベースの技術革新を促進するメカニズムの2つです。Herokuの12ファクターリポジトリのチーフアーキテクト兼メンテナーは、12ファクターDiscordサーバーでの最近の議論で、このイノベーションは12ファクターの範囲を広げるだけでなく、この方法論に基づいたアプリケーションを作成するためのツールにも刺激を与えるだろうと述べました。 鍵となるのは、12要素ベースのアプリケーション開発を統一された包括的なエクスペリエンスにすることです。このプロジェクトをオープンソース化し、12要素の理念を推進することは、ネットワーク規模で稼働する、回復力、拡張性、保守性に優れたアプリケーションを構築するための重要な一歩となります。 参加する12ファクターソフトウェア開発方法論は、10年以上にわたりソフトウェア開発とアーキテクチャに影響を与えてきました。その原則は、エンタープライズシステムの導入をより安全にし、保守を容易にする、統一された予測可能なアプローチを定義します。 しかし、過去10年間に起きた驚異的な技術変化を考えると、12 factorialは時代に合わせて継続的に進化していく必要があります。12 factorialをオープンソースプロジェクトにすることで、より幅広い貢献者が多様な視点を持ち込み、2011年のリリース当時と同様に、今日でも12 factorialが有用なものとなることを期待しています。 |
