年末年始がバタついていそうで、アドベントカレンダーを書く時間もなさそうなので怪文書を投稿します。
他にも活動している中で共有できそうな項目などがあれば、怪文書として投稿する日があるかもしれません。
私は、会社員としても茨谷企画としても、定期的に「このアプリをコンテナ化すべきか？」という相談は受けることが多いです。
この問いに関しての自分が今まで他者へしてきた回答や、自分なりの考えについて書いておきます。
これが正しいといったこともないですし、全く別の考えの人もいるとは思うので最終的には意思決定者がどう判断すべきかということを考える必要があります。
個人的にはコンテナを使った開発・運用が好きなので推奨したいところではあるんですけどね。
コンテナ化すべきか？
「コンテナ化すべきか？」という問いは、背景がそれぞれの組織や人によって全く持って異なります。
- 流行ってるからうちもコンテナ化したい
- コンテナ化すると開発・運用が楽になるかもしれない
- 採用でコンテナ技術を利用していると有利に働くかもしれない
ここに書かれていないことも多くありますが、相談にのるケースとしてはこういった理由が挙げられます。
1つ目は、導入から運用までやり抜く覚悟があるならありかもしれませんが、それだけの理由であれば余りオススメしません。
2つ目は一旦飛ばして3つ目ですが、確かにそういった側面もありそうです。
開発しているアプリによりますが、Vagrantでの開発なんてもう嫌だという時があるかもしれません。
さて2つ目の「コンテナ化すると開発・運用が楽になるかもしれない」は、はたして本当でしょうか？
コンテナ化すると開発・運用が楽になるか？
ケースバイケースです。
楽にならないケースでは、どういった特徴があるのかを個人的にまとめておきたいと思います。
- 課題について把握できていない
- 技術を新規導入しても、運用できる正社員・もしくはフルタイムの人がいない
- too muchな技術を利用する
必ずしもこれに該当しているからといって、楽にならないわけではないですが、大体はこういった傾向があるかなと母数が10数程度ではあるものそう判断しています。
では、楽にならない理由について書いておきます。
課題について把握できていない
課題を正しく把握できていない場合は、コンテナ化だけではなく他の技術採用についても失敗する可能性があります。
それこそtoo muchな技術であったり、そもそも本来解決したい課題を解決できていないということになりがちです。
ということで、コンテナ化云々よりかは現状の課題について見直すのが先に必要です。
必要であれば一緒に課題の洗い出しや壁打ちなどもやりますが、それでも本当に解決すべき課題を見つけるのは難しいです。
現在の課題についていえばある程度把握できるかと思いますが、今後その組織・個人のサービスの方向性や事業戦略を踏まえた上で、「将来のある時点までに〇〇が必要だ」といったことも加味した上で判断するのが望ましいので、かなり難しい判断が迫られます。
100%の確信は得られないにしても、それがコンテナを利用することで解決するのであれば今すぐにでもベットしましょう。
そうでないなら、コンテナに知見がある人や組織にお金をかけてでも相談してみてください。
自分が見ている視座では見えていないことも見えてくるかもしれません。
技術を新規導入しても、運用できる正社員・もしくはフルタイムの人がいない
コンテナ化するのであれば大体の場合、新規導入になるケースが多いと思います。
フルタイムである必要はないものの、何人かがコンテナについて運用・メンテできるような事業状況でなければ、そこにベットするのはリスクが高いように思います。
その状況がコンテナ化で覆せるのであればベットしても良いとは思いますが、そういったケースは本当にあるのかは分かりません。
too muchな技術を利用する
これは昔から様々な方々が言っていることですが、明らかにtoo muchな技術を採用するのは避けておいた方が良いです。
近い将来必要になるが今はtoo muchというケースは例外ですが、基本的には「必要になりそう」で導入するのは勧めません。
もし必要になりそうなのであれば、導入するのではなく変更しやすいアーキテクチャにしておくなどの工夫をしておくのが大事です。
too muchなケースは、「サービスが1つしかないのにk8sクラスタで構築する」といった場合になります。
サービスがというのはクライアントから見て1つではなく、社内で管理しているWebアプリケーションが1つという意味です。
少なくともk8sではtoo muchなので、Cloud RunやApp Runner、Heroku、Amazon ECSなどの方が適しているかもしれません。
有識者がもし近くにいれば相談してみて、どういった技術が最適そうかを壁打ちしてみるのも良いでしょう。
コンテナ化したい
今までの話を踏まえて、それでもコンテナ化するべき、したいというのであればコンテナ化をするためにどういった作業が必要なのかを把握する必要があります。
新規立ち上げと既存サービスのコンテナ化は全く異なる勘所があるので注意が必要です。
どちらにも共通しているのは、
- モニタリングに必要なAgentなどのサイドカーが想定している環境で動作するのか？
という点です。
これは技術検討の段階で必ずチェックしておきます。
新規サービスでコンテナ化したい
新規サービスでコンテナ化するのは、比較的容易です。
社内で決まっている技術があれば、それを利用するのが望ましい場合が多いので、それに従ってください。
社内で初めてコンテナを導入する場合は、公式が載せているチュートリアルや、様々な方や組織が投稿している構成を参考に立ち上げます。
後は何とかリリースに間に合わせましょう。
全く知見がない状態でリリースに間に合わないと最初から分かっている場合は、スケジュールをずらすか別の技術に切り替えるのも1つの手段としてはアリです。
既存サービスをコンテナ化したい
非常に難易度が高いです。
以前、私が現時点で所属しているスタディストで書いた記事がありますが、約1年半かかっています。
規模としては、大規模ではないものの2013年頃から開発し続けられているサービスというのもあって、下準備や入念なテストや移行期間を設けて1年半という歳月がかかりました。
この既存サービスのコンテナ化でやったことを振り返ると、以下のステップが挙げられます。 ※1
- やること・やらないことの整理
- 関係者への周知と教育
- 他部署を含めたリリースフローの把握と見直し
- アプリケーションコードを12Factor Appになぞらえて携帯性を高める
- 開発、CI/CDからコンテナ化する
- ステージング環境やテスト環境のコンテナ切り替え
- 本番のコンテナ切り替え
ここに書かれていない項目もあるかとは思いますが、個人的には大体これらに集約されると思っています。
この中で何が時間が難しいのか？といえば、携帯性を高めると本番の切り替え、そして関係者への周知と教育です。
長くなるので端的に書きますが、「携帯性を高めた」と思っていてもコードの全てを把握できているわけではないので、必ずどこかで落とし穴にはまります。
精査しながら進めるのも良いですが、早い段階から単体テストやE2Eテストなどを利用して、トライアンドエラーを繰り返しながら進めるのが個人的にはオススメします。
「本番の切り替え」は、携帯性を高めるにも関連していますが、並行期間の有無、本番環境特有の環境差分でハマりやすいです。
並行期間がある場合は、旧環境とコンテナ環境とで処理可能なリクエストが変わらないかどうかといった観点が出ます。
サービスを停止して切り替えなどはオススメできませんし、いきなり全てコンテナへリクエストを飛ばすのもオススメできないので、並行期間はあった方が良いです。
本番環境特有の環境差分は、コンテナに限らずハマります。
絶対にはまるので、早い段階から自分のみ、自組織のみでもいいので検証できるようにしておきましょう。
ほぼほぼ何かあります。
関係者への周知と教育は、時間がかかりますし相手にとっても非常に負担になります。
サービス開発者からしたらサービス開発に必要な技術も勉強しながら、コンテナについても学ばなければならなくなります。
心理的負荷もかなりあるかと思います。
であれば、サービス開発者にはまず理解しなくても開発・運用できる環境を提供するというのをゴールとして設定すべきです。
こうすることでできるだけ認知不可を下げるように勤めます。
構成図を含め、図示した移行前後の差分などを可視化しておくのも良いでしょう。
プロダクトマネージャーには、事前に移行スケジュールやプロダクトロードマップを踏まえながら、それぞれのスケジュール・ロードマップを調整することが大事です。
いきなり「〇〇月××日にはリリースしないでください」となると、お互い困ることになります。
早めに調整しておくことで、CSや営業に周知も早く行うことができます。
これはサービスやアプリの利用者にも早く情報が届くということに他なりません。
こういったことを定期的に根気強く続けていくことが必要です。
さいごに
ここまで読んでくれた人は、怪文書を全て読んだ方か、ここまでスクロールして飛ばしてきた人かと思います。
どちらにせよ、ここまで見てくれてありがとうございます。
今だと古い資料かもしれませんが、CNCFが公開しているCloud Native Trail Mapという素晴らしい資料があります。
こういった資料や12Factor Appをベースにしながら、コンテナ化をする必要があればしていきましょう。
またコンテナ化するのがゴールではありません。
あくまで課題を解決するための手段であり、スタート地点でしかないことに注意してください。
もし相談にのってほしいなど興味がある場合は、[茨谷企画の簡易的なページ](https://zuki.dev/work/）があるので、そちらをご覧の上、ご連絡ください。
それでは良いコンテナライフを。
※1 それぞれの話について語ると、どれに関しても長くなってしまうので割愛しますが、もし知りたい人がいたらお声がけください。
