こんにちは、モノタロウ コアシステムエンジニアリング部門 配送ドメイングループの安見です。 この記事では私が関わっていた社内システムを仮想サーバ(AWS EC2)からコンテナに移行した後にコンテナをやめて仮想サーバに戻した話をご紹介します。
諸説明
コンテナ移行について
システムのコンテナ移行とは、アプリケーションやサービスを動作させるための必要なすべての環境を、一つの「コンテナ」としてパッケージ化して動作できるようにすることです。これにより、アプリケーションは他のシステムと独立して実行され障害分離ができたり、環境の違いによる影響を受けにくくなるため移植性が向上したりといったメリットが生まれます。
我々のグループでもシステムをコンテナ化することになりました。 我々のグループのシステムを以下に示します。
コンテナ化対象システムについて
配送ドメイングループでは、Order Management System(OMS)と呼ばれる受注の倉庫引当に関するシステムを扱っています。このシステムの引当ロジックのメイン部分は外注システムとなっており、配送ドメイングループでは主に基幹システムとこの外注システムの受発注情報と引当情報の連携部分について開発を進めています。
上記は簡易化された図で表されているので、簡単なもののように見えますが実際は
といった感じで、非常に様々な連携機能が動いているものとなっています。
このシステムをコンテナ化することになるのですが、コンテナ化するにあたって、まずは一部機能だけをコンテナ化することになりました。 これに関しては前任担当者の方が設計、実装、リリースまで行いました(この作業自体に半年)
私の担当はこれを他機能に横展開することやCI/CDを整えることでした。 しかし、ここで様々な問題に直面することになります。
直面した様々な問題
リリース後の多数の残課題
リリースした後の機能には以下のように多数の残課題や運用課題がありました。(詳しくは説明しませんが沢山あったことを感じてもらえれば)
- 定期的にクラスタアップグレードする必要がある
- 機能のコンテナ最適化設計
- EFSのマウント失敗
- bitnami/kubectlのイメージの503エラー
- リリースしてなくても、configファイルだけ適用される
- Podで発生するエラーの通知改善
- 開発環境のbuildジョブ実行の次の日に自動でリリースされてしまう
- stg環境のEKSを土日祝停止
- ローカル開発用のdocker-composeのイメージ取得先が古い
- codebuildのエラーハンドリング
- Cost-Serviceタグをつける
- ECRライフサイクルポリシー改善
- システムの通知先/向き先変更の修正残し
- argoCDの導入
- インフラとアプリのリポジトリ分割
- etc…
展開する機能の数が多すぎる
とりあえず1機能だけ展開して、土台はできた状態にはなっていました。しかしながら、機能数自体は18機能あり、当然安直に横展開できない機能も存在します。 さらに展開した機能は各機能の中でも安全のために負荷が低いものを選んでいたため、実際に負荷が高い機能が耐えられるのかわからないという問題もあります。 機能のテストに関しても、主要機能のテストだけでも膨大な量になっており大変です。
また、これらコンテナ化はグループ内で初めての取り組みであり、メンテできる人間も少ない点もネックでした。
コンテナ化のメリットが薄かった
そもそも受けられるコンテナ化の恩恵が我々のシステムでは以下の理由から少なかったという点もあります。
- システムが並列実行できるように設計されていない(拡張性があまり必要ない)
- 新規開発者が環境を整える機会が少ない(移植性があまり必要ない)
- 運用周りもCI/CDが既に整っている(運用が大して楽にならない。むしろ学習コストがかかる)
- システムが既に独立しており、コンテナ化で分割する余地がない
- etc..
上記を改めて考えると
あれ?移行しない方がよくない?
となり、全てを巻き戻すことに。。。
なぜこうなったか
この時期、コンテナ化が社内で推進されており、波が来ていました。 そして、新規システムをコンテナ化する話は様々ありましたが、既存システムを移行する話は(その時点では)なかったので、試してみるのに機会として妥当な案件に思えました。 これにより、
サービスの特性やメリットデメリット等を深いところまでは分析できないままに移行に踏み切りました。
このことから得られる学びとしては流行りや流れでやる、ではなくキチンとメリットデメリットを分析することが重要ということです。 言葉にすると当たり前な気がしますが、固定観念として良いものであると受け入れているものを導入する際に、一度立ち止まって自社のシステムに合うかどうかを考えられる人は意外と少ないのではないでしょうか?
よかったこと
結果的に全て戻すことになったのですが、個人的によかったと思えることは途中まで進んでいた案件だったが、これまでかけたコストを気にせずに戻す意思決定をすることができたことです。 実際にこのままコンテナ化を進めていても、コストはかかり運用面も楽にならず悲しい結果になっていたであろうことは想像に難くありません。このような撤退の意思決定を上から厳しく追及されない社風だったのが幸いしたと思います(とはいえ振り返り・反省は必要ですが)
また個人としても、コンテナについてもそこまで分かってない状態からコンテナ化(+撤退)に携わることで色々な経験ができたことについてはとてもありがたかったです。感謝。
まとめ
社内システムのコンテナ化を進めて、撤退しました。とはいえコンテナ化をやめたからといって、その移行がダメであるということでは全くなく、むしろ推奨したいと思っています。ただし、既存のシステムを別のものに移行する場合はそれが良いとされているものでも相応の移行コスト(大規模なシステムならより一層)がかかるので、かかるコストと受ける恩恵を天秤にかけて考える必要があるというのが、この記事の学びであり結論となります。
追記: 現在なら...
実は上記の状況以降に、コンテナ基盤グループが発足して支援体制が整ったことで現在では解決できる問題も多数存在することがわかっています。 それらの一部について紹介します。
- argoCD
- 全面的にコンテナ基盤グループにて構築・管理
- kubernetesのアップデート
- 全面的にコンテナ基盤グループにて実行
- configの管理など
- CVSを脱却して、リリースコストの削減が可能
- Cost-Serviceタグ
- コンテナ基盤グループにて設定
- codebuildのエラーハンドリング
- 同様のつらみが基盤グループでもあったらしく、知識面などでサポートあり
- 相談による最適化で発生していなかった問題もさまざまありそうでした。
- dockerイメージの最適なタグ運用
- 最適なブランチ戦略
また、全社的にはコンテナ化が推進されているため会社のモダナイズの動きに合わせていける点も当初考慮していなかった大きな利点に思います。
具体的には、
- プロダクトを移動したとしても同じスキルセットで業務を遂行可能となります
- 他のグループ・チームが担当しているシステムもコンテナ化されたりすることで型ができたり、知見が溜まっていることが期待できます
- これにより、調査に時間をかけず適切な解決策が簡単に手に入るかもしれません
さらに最近では、開発者向けのコンテナ技術(docker、 kubernetes等)に関する研修も豊富に計画されてきており、体系的に知識習得が可能となっています。
総じて、コンテナ化やその開発・運用に対するサポート体制が整ってきており、全社的にはコンテナ技術を使用することが大いに推進されている状況となっております。
モノタロウでは随時エンジニアの採用募集をしております。この記事に興味を持っていただけた方や、モノタロウのエンジニアと話してみたい!という方はカジュアル面談 登録フォームからご応募お待ちしております。