こんにちは、エンジニアマネージャーの堀越です。
ちょっと前、TLで割と盛り上がっていたこちらの書籍をポチり読んでみました。いいですよこの本！！ gihyo.jp
こちらの書籍の第3章に Beyond the Twelve-Factor App なるものの紹介があり、色々調べて考察した結果を社内勉強会で発表したのでブログにも書き起こしておきます。
Beyond the Twelve-Factor App とは？
Pivotalという会社が提唱したアプリケーション開発のためのベストプラクティス集です。 実は元ネタに Heroku が考案したThe Twelve-Factor App があるのですがこちらは内容も考え方も古く、Beyond の方はクラウドを使う点での考慮点が含まれているのがポイントです。
以下のリンクからE-Mailを登録するとPDFがダウンロードできます。 tanzu.vmware.com
Beyond the Twelve-Factor App のプラクティス紹介
Beyond the Twelve-Factor App は以下、15個のプラクティスから構成されています。 個人的に共感したり、自分が関わっているサービスで課題に感じている項目を抜粋（色付きの項目）して紹介していきます。
- One codebase, one application （1コードベース、1アプリケーション）
- API first（APIファースト）
- Dependency management（依存関係管理）
- Design, build, release, and run（デザイン、ビルド、リリース、実行）
- Configuration, credentials, and code（設定、機密情報、コード）
- Logs（ログ）
- Disposability（廃棄容易性）
- APIBacking services（バックエンドサービス）
- Environment parity（環境一致）
- Administrative processes（管理プロセス）
- Port binding（ポートバインディング）
- Stateless processes（ステートレスプロセス）
- Concurrency（並行性）
- Teremetry（テレメトリ）
- Authentication and authorization（認証、認可）
プラクティス紹介（抜粋）
One codebase, one application （1コードベース、1アプリケーション）
コードベース（リポジトリ）とアプリケーションは1:1、アプリケーションとデプロイする先の環境は1:Nの関係であるべきという考え方です。
一方で、N個のアプリケーションが1つのコードベースに依存している、またはアプリケーションがN個のコードベースから構成されているような状態は規約に違反しているということになります。
冒頭で紹介した書籍には複数のアプリケーションからの参照を持つコードベースはライブラリ化を検討、N個のコードベースで構成されたアプリケーションの開発戦略としてモノレポについて紹介がありました。
ただ、ここで重要なのは再現性の高いデプロイを実現できているかどうかというところなので必ずしも前述のアプローチが最適解ではなく、目的を達成するための最善策をプロジェクトの中で見出すべきです。
API first
前段のコードベースの考え方と関連しますが、Beyond the Twelve-Factor App ではサービス間でコードベースを共有するとそれぞれのサービス間で干渉し合って統合失敗のリスクがあるとしています。そこで公開されたインターフェイスとなるAPIを第一に考え、サービスの統合もAPIを通じて行いましょうというのが API first という考え方です。
内部開発のプロセスに干渉することなくチーム同士がコラボレーションできるようになる、また関係者間との議論が円滑に進むようになるといったメリットがあります。
API first を推進するのに有効なツールとして Swagger や API Blueprint を用いたAPIの仕様を公開するためツールの紹介がありました。個人的には gRPC や GraphQL と行ったスキーマ定義に重きをおいたスタックの活用も有効かと考えています。
Design, build, release, and run（デザイン、ビルド、リリース、実行）
アプリケーションのデリバリーのサイクルをデザイン、ビルド、リリース、実行と厳密に分離しましょうという考え方です。自動化によって信頼性を維持しながらデリバリー速度を最大化することが最終的な目標とします。
Beyond the Twelve-Factor App にある各ステップの詳細は以下のような内容となっています。
Configuration, credentials, and code（設定、機密情報、コード）
APIのトークンやデータベースのアクセス情報といった設定、認証情報などはハードコーディングしないようにしましょう、ソースコードはオープンソースのように扱いましょうという考え方です。基本的に環境変数から読み込めるようにしておけば問題ないと認識しています。
ただ、アプリケーションをクラウドで動かす前提なのであれば機密情報を保管するのに特化したサービスがあるのでローテーションサイクルなども踏まえつつアーキテクチャを考える段階で選定しておくと良いのかなと考えています。
AWSなら System Manager や Secret Manager が候補に上がってきそうです。
以前、Secret Manager を活用してRDSのアクセス情報の自動ローテーションを検証した際のブログポストがあるので参考までに貼り付けておきます。
Backing services（バックエンドサービス）
RDSやS3といった外部のサービスをアプリケーションにアタッチされた状態としましょうという考え方です。つまるところRDSが壊れてしまった場合にコードの変更なしに切り替えできる状態を目指します。
昨今のクラウドネイティブアプリケーションであれば、必然的に上記のような構成になりそうではあります。ただ、いざ何か障害が発生したときに円滑にリソースの差し替えができるのかというと自信がないなというのが正直なところ。SREの文脈ですがディザスタリカバリの訓練を行うなど事前準備を行っておくことが重要な気がしています。
Telemetry（テレメトリー）
監査と監視はクラウドで動作するアプリケーションを適切に運用するうえで最も重要な項目の一つであるとしています。クラウドでアプリケーションを動かす場合、コンピューティングリソースは物理的には世界のどこかのデータセンターに配置されておりその詳細を把握することはできません。だからこそ可視化しておくことが重要であるという考え方です。
以下の３つの一般的なカテゴリについて紹介がされています。
Authentication and authorization（認証、認可）
セキュリティは重要な要素であり後回しにせず優先的に取り組むべきもので、理想的には全てのクラウドネイティブアプリケーションはRBAC（Role Based Access Control）によって保護されるべきだという考え方です。
OAuth2、OpenID Connect、さまざまなSSOサーバーや標準規格、そして言語固有の認証・認可ライブラリが無限にあるためセキュリティはアプリケーション開発の初日から組み込まれるべきものであり、アプリケーションが運用された後に追加されるボルトオンされるべきでは無いということが書かれています。
弊社においても昨今セキュリティへの関心が高まっておりさまざまな取り組みを行っている最中です。個人的に現場レベルだと認可の仕組みを作るぞとなった円滑に対応できるほど知識がないので課題に感じているところがあります。今後、アプリケーション開発を行っていくにあたり避けては通れない部分なのでしっかり準備していきたいです。
所感
実際のプロダクト開発の現場においては様々な事情があるので Beyond the Twelve-Factor App の15のプラクティスが完璧にできている必要はない、そもそもここで上げられているプラクティスが最適解として当てはまらないこともあると思います。
ただ、プロダクトの成長のためには現状把握や見直し改善の活動は継続的に必要であると考えていて、そのきっかけ作りや議論の種として活用できると良いのではないかと考えています。
また、プロジェクトの立ち上げのフェーズでは知識として持っておくだけでも役に立つことがあると思います。
まとめ
Beyond the Twelve-Factor App とはアプリケーション開発のための15のベストプラクティスです。 プロダクト開発の現場で全ての項目を完璧にできてないとどうこうという話ではないが知っていると役に立つTipsです。
最後に
最後に冒頭で紹介した書籍で私が感銘を受けたAWSのモダンアプリケーション開発の定義を共有して終わりにしたいと思います。
「AWSはアプリケーションの設計、構築、管理を継続的に見直し、変化を受け入れ続ける開発戦略のことをモダンアプリケーションと呼んでいます。」
作って終わりではなく継続的な改善を行うことがプロダクトの成長、ビジネス要件を満たすのに必要でこういった考え方は昨今のアーキテクトの素養として求めらているものと考えているので自身にとどまらず社内にも普及していければと思います。
