Software Design (ソフトウェアデザイン) 2022年11月号で"なぜコンテナ・Dockerを使うのか？"という問いかけがなされていたので、自分も思うところを書いてみたい。
コンテナのメリットは？
自分が思うコンテナのメリットは次の３つ。
- 環境を再現しやすい
- 一つ一つのコンテナの設定が分離しているので把握しやすい
- AWS ECSやECRといった様々なマネージドサービスに乗っかれる
1. 環境を再現しやすい
なんといっても環境を再現しやすい。ホストに直接ミドルウェアをインストールしつつ動かす方式だと、ホストに施した設定に依存する点が多く、"〇〇だと動いたのに！"なんてことが大変多い。下手をすると、本番環境で使いたいOSだと動作しない、などということさえ出かねない。
この点、コンテナで動かすようにしていると、基本的にコンテナが動くなら環境を選ばない（※）。これはC#.NETのようにどちらかというとマイナー気味なフレームワーク（失礼）を使う際には大きな安心感となる。
※ ただし絶対ではない。例えばARM/x64のようにCPUのアーキテクチャが違うとか。
またチーム開発の場合、別のメンバー（含む六か月後の自分）に同一の開発環境を提供するのも容易い。これも嬉しいところ。
2. 一つ一つのコンテナの設定が分離するので把握しやすい
一つ一つのコンテナに必要な分をDockerfileにまとめることになるため、それぞれの記載内容が自然と限定される。これは大きなメリットで、どこになにが依存しているのかわかったものじゃない、という惨状を避けることができる。
肥大化した超巨大な設定群がどこにどう依存しているのかよくわからないままモリッとかけられていて、もうなにが必要でなにが不要なのかもわからない、今さら各モジュールごとに分離するのも至難を極める、なんて地獄の状況に陥りづらい、ということである。これはとてもとてもとても助かる。
3. AWS ECSやECRをはじめとする様々なマネージドサービスに乗っかれる
ECSにはAutoscaling（ということはAuto Recoveryも含む)やデプロイ、ロールバックといった仕組みが予め備わっている。ビルドした結果を保存するためのECRもある。これらを自前の仕組みで構築しなくて済むのは大変に助かる。
CPUやメモリをはじめとするメトリクスも元から使えるので監視のためのソリューションを入れる必要もなく、大変よろしい。
これが自分の中では最大の理由で、もしこれらの優秀なマネージドサービスがなかったらコンテナ化には二の足を踏んだことだろう。
ではコンテナ化のデメリットは？
構成が複雑化する。この結果、構築に一手間増える他、トラブルシューティングに苦労しやすい。
それに見合うだけのメリットは十分にあるのだが、ECSで構築した一連のリソース群がうまく動かなかった時はウッとなる。ネットワーキングからアプリまで、あちこちに障害の原因があり得るので切り分けが大変なのだ。
EC2じゃダメなんです？
EC2ではダメということはない。ダメということはないのだが、トラブルシューティングはどちらかというとEC2直で運用しているほうがやりやすかったりもするのだが、EC2上でプロセス監視を入れてオートリカバリを入れてディスク監視入れてメモリ監視入れてCPU監視入れてホストのセキュリティパッチあてて、とやりながらデプロイどうしようとかロールバックどうしようとかあれこれあれこれ考えて構築しないといけないのはなかなか重い作業で、正直特に理由がないならEC2直は避けたいのが本音である。これらはサービスを動かすための要因でしかなく、頑張って作ってもサービスの使い勝手がよくなるわけではない――不便になるのをある程度防ぎはする――という点も悩ましい。
オンプレで物理サーバーを自前で運用することを思えば、EC2も隔世の感がある素晴らしいサービスなのだが、ECSに慣れてしまうと、うん。
