AWSに入門しようと思って何冊か本を読みながら勉強してるところ。で、今は↓を読んでる。面白い。
この書籍の中でThe Twelve-Factor AppとBeyond the Twelve-Factor Appが紹介されているので、チェックしておこうと思った。
The Twelve-Factor App読み直してみようかな。Beyond the Twelve-Factor App知らなかったから、これも読んでみよっと。https://t.co/rcZN7C8ib1
— Mitz Shiiba (@bufferings) May 6, 2023
今回はThe Twelve-Factor Appを読む
両方一気に読むの大変そうだから、今回はThe Twelve-Factor Appを読むことにする。Beyond the Twelve-Factor Appはまた今度。
以前に読んだことあるので、記事書いてるかも？と思って探したらあった。7年前かー。書いたこと自体、完全に覚えてなかった。Spring CloudとかCloud FoundryとかOpenStackを触ってた頃だな。k8s触る前。懐かしい。
The Twelve-Factor App
てことで、新たな気分で The Twelve-Factor App を読み直してみる。
結果を先に書いておくと「自分の中では、ほぼ全部、普通のことになってた」でした。楽しかった。
I. コードベース
バージョン管理されている1つのコードベースと複数のデプロイ
- 複数のコードベースから1つのアプリをデプロイしない
- 1つのコードベースから複数のアプリをデプロイしない
- 1つのアプリが複数の環境にデプロイされるけどコードベースは同じ
ってことよね。これは今は自分の周りでは普通になってる（以降「自分の周りでは」を省略する）。
モノリポの場合はどうなの？ってことに関しては『AWSで実現するモダンアプリケーション入門』には「リポジトリの運用スタイルとは関係がないと言えるのではないでしょうか」って書かれてる。ほほー。モノリポ使ったことないけど、いい感じにディレクトリを分けてたら大丈夫そうかな。
II. 依存関係
依存関係を明示的に宣言し分離する
隠れた依存関係を持たずに、明示的に宣言するってこと。これも今は普通かな。package-lock.jsonとかDockerfileとか。
III. 設定
設定を環境変数に格納する
環境ごとの設定ファイルをアプリケーションに持つんじゃなくて、環境変数などで外から与えること。それによって、どの環境でも同じアプリケーションを使える。
これも、k8s使うと普通のことになってる。環境変数以外にもConfigMapとかで設定を外から差し込んだりする。以前は、例えばステージング環境用の設定ファイルを入れてビルドしたりしてたなぁ。
IV. バックエンドサービス
バックエンドサービスをアタッチされたリソースとして扱う
これ、正直よくわかってない。というのも、リソースとして扱うのが当たり前？になっていて、それ以前の方法がよく分かってない。どうやってたの？
V. ビルド、リリース、実行
ビルド、リリース、実行の3つのステージを厳密に分離する
リリースしたあとに、サーバーの中に入って直接コードを触ったりしないんだよ！ってことよね。昔は直接触ったりするの聞いたことあるけど、今どきは、そんなことしないよね。
VI. プロセス
アプリケーションを1つもしくは複数のステートレスなプロセスとして実行する
Webアプリケーションは、ステートレスにする。これも、普通だなぁ。
スティッキーセッションはTwelve-Factorに違反しており、決して使ったり頼ったりしてはならない。
って書いてある。へー。僕もスティッキーセッションは好きじゃないので、良い。ロードバランサーの説明とかで、スティッキーセッションの説明を見かけるから需要はあるんだろうけど。
VII. ポートバインディング
ポートバインディングを通してサービスを公開する
これも普通になってる。Dockerとかk8sだとポートをバインディングして使うもんね。
VIII. 並行性
プロセスモデルによってスケールアウトする
あんまりよくわかってない。
- 作業の種類ごとに異なるプロセスタイプに割り当てて処理する
- 例えば、HTTPのリクエストはWebプロセスで処理して、重い作業は別のワーカープロセスにやってもらったりする
- アプリケーションは、複数のプロセスを複数のマシンにまたがって動かせないといけない
だから、スケールアウトできる。
みたいなことが書いてあるんだけど、プロセスモデルじゃないやり方ってどういうものなんだろう？
IX. 廃棄容易性
高速な起動とグレースフルシャットダウンで堅牢性を最大化する
さくっと起動して、さくっと終了できて、捨てられる。ふむ。これもコンテナ使ってると普通だな。
X. 開発/本番一致
開発、ステージング、本番環境をできるだけ一致させた状態を保つ
- デプロイの間隔：数時間
- コードを書く人とデプロイする人：同じ人
- 開発環境と本番環境：できるだけ一致
自分の周りだと、コードを書く人とデプロイする人はずっと前から同じ（自分たち）だし、他の2つはできるだけそうしたいなってところだな。トランクベースな開発でサクサクデプロイしていくやり方が好きだし、本番環境でMySQLを使うなら、開発環境でもDockerとか使ってMySQLを使いたい。
XI. ログ
ログをイベントストリームとして扱う
ふむ。
Twelve-Factor Appはアプリケーションの出力ストリームの送り先やストレージについて一切関知しない。 アプリケーションはログファイルに書き込んだり管理しようとするべきではない。代わりに、それぞれの実行中のプロセスはイベントストリームをstdout（標準出力）にバッファリングせずに書きだす。
んー。これは特定のフォルダに出力しておいたら、持っていってくれるみたいなのも多いかなぁ。アプリケーション自体は、それがどこに持っていかれるかは知らないのだけど。
stdoutで持っていってくれる方が楽だから、基本はそうしたいな。
XII. 管理プロセス
管理タスクを1回限りのプロセスとして実行する
これは、どういうことなんだろう？
例えば、package.jsonのscriptにワンオフのスクリプトを定義して、コンテナのビルドはWebアプリと同じようにしておいて、実行するときに起動引数とかで、Webアプリの起動の代わりにそのスクリプトを実行するk8sジョブを使う、みたいなことなのかな？
DBのmigrationは、ビルドプロセスの中に組み込むのが好きだし、そういう感じで管理タスクを1回限りのプロセスとして実行すればいいのかなぁ。それなら好きな感じだな。
The Twelve-Factor Appを読んだまとめ
前回記事を書いてからの7年間で、自分の中では、だいたいそういうやり方が普通になってるなぁ。The Twelve-Factor Appを知らなくてもk8sを使うとそうなってしまう感じというか。
k8s以外でも、そういうやり方を大切にして開発しようと思う。
書籍を読んでて休憩したくなったらBeyond the Twelve-Factor Appを読もうと思う。
