IT業界は、開発者がサクっと修正して、サクっと本番環境に適用する、DevOptsという世界観を基本としたプラットフォームをすごく売りたいようである。そのキーテクノロジーにコンテナを使っている。
コンテナ自体は便利だなと思う反面、コンテナを本番環境でガシガシ使われると、インフラエンジニアというか運用エンジニアには困ることがある。コンテナの中にプログラムやミドルウェアが埋め込まれるので、コンテナの中まで入らないと原因追及できないということだ。
これまでは、インフラ、と言いながらも何かが起こった時に、とりあえずOSのログを確認し、そこにミドルウェアとの関連を見つければ、ミドルウェアのログまでは見に行っっていた。ミドルウェアあたりに開発者とインフラエンジニアの境界があり、過去はどっちの担当だい？というので揉めていたこともあったが、最近は「両者が見る」みたいな暗黙の了解があった。できていた。
ところが、コンテナに完全に含まれてしまうと何が何だか、となる。ただ、ログまでコンテナの中に入れるのではなく、ログはコンテナの外に吐き出し、プラットフォーム側でログ管理するみたいなことが、サーバー運用の中では当たり前である。だから、ログ管理プラットフォームみたいなものが用意されていて、コンテナの中までは見なくて良くなっている。
が。
はっきり言って、ログだけをインフラ観点で見てもけっこうしんどい。コンテナがブラックボックスの状況でログだけあっても。だから、出したログは開発者の方で見てね、という話になるのが一般的に思う。ログを吐き出す仕組みくらいはインフラの方で面倒見るので。
ログの中身がコンテナの中身寄りというか、アプリ寄りであればまだ開発者側で対応できるが、インフラ起因の場合はどうか。ネットワーク、ストレージ、コンテナを動かすサーバーなど、いくら抽象化したところでインフラは残る。このDevOptsという商品は抽象化が激しいので、「想定外のことが起こった時」に追いかけるハードルが高い。
また、監視観点はログばかりではなく、プロセス・ポート・リソース・サービスなど、切り口はいろいろある。OSだけ見ていれば定型的な監視文化はあったのだが、コンテナになると急に難しくなる。
なので、各パブリッククラウド企業は、インフラの部分はウチで面倒見るよ、だからうちのパブリッククラウドのコンテナ実行環境に載せてね、という秋波を相当に送っている。送っているが、結局そうなると、足を絡めとられることになる。全ての開発成果を特定のパブリッククラウドの環境だけに吸収されるとしたら、未来永劫そこにかかる費用を吸い取られることになる。
昨今では、Red HatのOpenShiftや、VMwareのTanzuなど、オンプレミスから各種パブリッククラウドまで、場所を選ばずDevOptsできるプロダクトも出てきている。これはインフラに依存しないDevOptsと言う強みはある。あるけれども、結局はRed HatにしろVMwareにしろ、に依存することになる。サブスクリプションなり保守費用なりが固定で発生し続けるので、このDevOptsという取り組みはプラットフォーム事業者における主導権争いの面が非常に強いな、と思って見ている。
ここまでの話の通り、DevOptsは聞こえはいいのだけど「じゃ、そこまでシステム改修を頻繁にやります？」という話にだいたい戻る。自社システムで業務利用で、内製化して社内システムエンジニアをたくさん抱え、猫の目のように改修するのなら適合するだろう。だが、たいていはシステムなんて、リリースしたらそのまま使い続けるか、改修するとしてもそこまで頻度は多くない。多くないのにDevOptsのプラットフォームそのものにお金をたくさん払い続けるのはもったいない、となる。そんなにお金がかかるなら、今までのやり方のほうがいいよねと。
アプリケーションがユーザーに届くという結果は、今までのやり方だろうが、DevOptsだろうが変わりなく、結局は縦に切るか横に切るかみたいな問題である。横に切った時に、業界の筋線維みたいなものをぶった切ることは間違いなく、そこで新しく、どう本番運用すべきかという文化を作り出せるかがポイントだ。縦割りを横割りするときに、これまで従事していたタレントを排除しないようにしなければいけない。排除するような仕組みだと、業界全体としては確実にパワーダウンする。普段は便利だけれど、何か起こった時に脆弱になっては意味がまるでないと思う。
