商品点数1900万点――「モノタロウ」の強みを伸ばす、コンテナ、Kubernetes活用の裏側：ビジネス成長とともに「複雑性」に立ち向かう

間接商材を中心としたECサービス「モノタロウ」では、AWSやGCPへのリフト＆シフトを進めている。＠ITが主催した「ITmedia Cloud Native Week 2023春」に登壇したMonotaROの藤本洋一氏が、同社におけるクラウドネイティブ推進とマネージドサービスを活用する上での注意点や組織に根付かせるためのポイントを語った。

[ANDG CO., LTD.]

　多種多様な産業で利用される間接資材を中心としたECサービス「モノタロウ」。「資材調達ネットワークを変革する」をミッションに毎年20％の成長を続けながら、システムのモダン化、組織横断でのクラウドネイティブな取り組みを推進してきたという。

　本稿では、＠ITが開催した「ITmedia Cloud Native Week 2023春」の基調講演に登壇したMonotaROの藤本洋一氏（IT部門 CTO-Officeグループ）の講演内容をお伝えする。

ビジネスの成長に伴い、システムのモダン化を着実に進めるモノタロウ

MonotaRO IT部門 CTO-Officeグループ 藤本洋一氏

　MonotaROは、間接資材の在庫を持ち、オンラインで販売しているEC企業。システムは自社で開発、運用している。間接資材とは、用紙などの事務用品や、軍手や自動車のオイルフィルターといった消耗品、電動ドリルやレンチなどの工具、作業服やヘルメット、厨房（ちゅうぼう）機器、医療、介護用品など、原材料以外の物品のことだ。越境ECなどグローバルに事業を展開しており、商品点数はおよそ1900万点、ユーザー数は700万以上、売上高は2260億円（2022年度）だ。

　モノタロウのシステムは、利用者が閲覧するECサイトのような商流部分であるSoE（System of Engagement）領域と、海外サプライヤーから商品を輸入し、出荷倉庫でピッキングし、顧客に配送する物流部分であるSoR（System of Record）領域に分けられる。

商流、物流を担うモノタロウのシステム（藤本氏の講演資料より）

　オンプレミス環境で動作していたモノタロウのシステムの一部は役割に応じてクラウド移行した。

　2017年にECサイト（受注、在庫、顧客、配送）をAmazon Web Services（AWS）、データパイプラインなどをGoogle Cloud Platform（GCP）に構築、移行し、フロントエンドのスケーラビリティとデータ活用は大きく進展した。基幹システムはオンプレミス環境で動作している。その後、ビジネスの拡大に伴い、AWSにOMS（Order management system）パッケージ、GCPにPIM（Product Information Management）パッケージを導入し、商品情報検索の基盤も構築、同時に物流拠点も拡大が進んだ。

システムはオンプレミス、AWS、GCPに展開（藤本氏の講演資料より）

　藤本氏は「ビジネス成長とともにシステムやデータ連携が複雑化しており、同時にコスト意識も求められるという状況となっており、システムのモダナイゼーションを戦略的に進めている」と述べ、現在の取り組みの中で「Replatform（コンテナ化＋Kubernetes）」「Refactor（12 Factor App化）」「Rebuild（商品情報、検索基盤）」の3つを紹介した。

インフラチームへの依存を解消するためPoCを実施し、責任分界点を明確化

　1つ目のReplatform（コンテナ化＋Kubernetes）は、AWSのVM（仮想マシン）上に移行したECサイトにおける取り組みだ。ホストOSのEOL（End Of Life）対応、VMコストの増大、インフラチームへの依存が課題となっており、アプリケーションの大きな変更はせずにコンテナ化、Kubernetes活用を進めることで責任分界点を見いだす方針を採ったという。

　藤本氏はモノタロウにおけるコンテナ化の3ステップを紹介した。

　コンテナ化前は、VMの構築がインフラチーム管轄で、手動または半自動で複数VMにデプロイする運用で可用性を確保していたため、アプリケーションの一部機能がOSに依存していた。アプリケーションをコンテナ化した第2段階では、OSはアプリケーションチームに移管し、マネージドなCI/CD（Continuous Integration/Continuous Delivery）やコンテナリポジトリを活用できるようになった一方、コンテナ管理に課題が生まれた。そして最終段階でKubernetes環境を導入し、アプリケーションチームはコンテナイメージとマニフェストファイル（yaml）の管理をするだけで、可用性を確保できるようになったという。

コンテナ化の3ステップ（藤本氏の講演資料より）

　「コンテナ化を3ステップで進めた理由は、ビルドパイプラインを構築することで、VMホストに依存していた構築の部分が、Infrastructure as Code（IaC）によりコード化され、再現性や環境依存の分離ができるためだ。コンテナイメージを使ったテストや構成管理、ログ、メトリクスの計測も可能になるなど、なるべく早い段階からコンテナ化のメリットを享受できるようになる」（藤本氏）

　コンテナ化が組織に定着し、DevOpsチームが機能し始めることで、本番環境におけるコンテナやKubernetes活用も見えてくるという。

　藤本氏は、社内のPoC（概念実証）で本番環境にコンテナやKubernetesが適用可能か評価を進めた例として「Amazon Elastic Kubernetes Service」（Amazon EKS）の導入PoCについて説明した。

　PoCにおける検証項目は、権限委譲、スケーラビリティの向上、ネットワーク構成といった粒度の大きなものとした。一方、目的はスポットインスタンスの活用やIPアドレスの枯渇を避けるなど、具体的なものとし、評価の観点も明確にした。体制としてはアプリ、コンテナ、ネットワークの3チームで進めることで、責任分界点を見いだしていった。

　責任分界点の例として、CI/CDパイプラインがある。開発者がGitリポジトリにリリースタグをプッシュすると、ビルドパイプラインが実行され、コンテナレジストリにイメージがプッシュされ、タグが割り当てられる。そのタグに対応するyamlをデリバリーツールである「ArgoCD」が参照し、同期することでyamlの定義に沿ってデプロイされる。

　デプロイ先の各種設定はクラウドインフラチームがIaCで管理する。これにより、アプリケーション開発者は意識する必要なく、クラウドインフラチームが指定した権限でPodを実行できる。ArgoCDを責任分界点として、アプリケーション開発者とクラウドインフラチームの責任分担が可能になるわけだ。

ArgoCDが責任分界点となるので、開発者はデプロイ環境を意識する必要がない（藤本氏の講演資料より）

　PoCの評価は、コンセプトとスコープに基づいたという。体制、学習コスト、サポート、コミュニケーションなど多角的に評価して、合理的な判断を尊重した。PoCの達成度を確認して成功と判断されれば、プロジェクト化される。藤本氏は「Kubernetesは単純に点数評価できるものではない。こうしたPoCによる評価を蓄積することで、クラウドネイティブ技術を評価できる組織になっていく」と説明した。

ベストプラクティスの導入やマネージドサービスの活用でモダン化を推進

　2つ目のRefactor戦略は、モダンなWebアプリケーションのあるべき姿を示した12のベストプラクティスにまとめた方法論「12 Factor App」に基づいて行われている。ファイルシステムのような状態を持つものを分離、コンフィグも外出し、クレデンシャルを分離、管理、リリース手順の改善、ブランチ戦略、ログ基盤化といった取り組みを進めている。

12 Factor App項目とモノタロウでの方針（藤本氏の講演資料より）

　モノタロウのテックビジョンに「守→破→離」がある。型を覚える、観察、最善策を選ぶという流れを経て新しいものを組織にもたらす考え方だ。12 Factor App化に当たっては既存のリリース手順を習熟することで現状を理解し、どのように変更するかを検討した。そして、社内での事例化を進め、社内事例の横展開や学習の動機付けにつなげていったという。

　3つ目のRebuild（商品情報・検索基盤）は、テックビジョン「システムを顧客価値につなげる」に基づいて行われた。1900万点ものアイテムを扱うモノタロウにおいて、商品検索のパフォーマンスが高まれば、顧客に提供できる価値が高まるためだ。

　従来の検索システムである「Apache Solr」から「Elasticsearch」および「KVS」（Key-Value Store）に置き換えることを前提に、周辺システムを構築し、ストラングラーパターンで移行することにした。新たな検索システムはGCPの「Dataflow」や「Cloud Spanner」などのマネージドサービスを活用している。AWS上の商品データベースがリアルタイムにBigQueryと連携するクラウドネイティブな構成を実現している。

新しい商品情報、検索基盤では、商品データ作成時間の67％短縮を実現した（藤本氏の講演資料より）

　同構成のポイントについて藤本氏は「商品点数の増加で時間がかかる部分に、マネージドサービスを多く活用している。フロントエンドのトラフィックの伸びが影響する部分はKubernetes上にAPIを構築して対応している。一見複雑そうに見えるが、モジュール間はPub/Subやストレージを介して疎結合な設計になっているため、比較的少人数の複数チームで並行して開発できている。マネージドサービスは規模次第で費用もかかるが、人の手間や時間を考慮すると、費用で解決してもよい場面もある」と説明した。

　藤本氏はクラウドネイティブ化の取り組みを振り返った上で、注意点も紹介した。

　「マネージドサービスにもSLA（Service Level Agreement）があり、100％の動作保証がされているわけではない。そのため、エラー対応は当初から考慮することが望ましい。例えば、マネージドサービスが内部エラーを返した場合、エクスポネンシャルバックオフのようなリトライの仕組みが重要だ。とはいえ、全てにおいてリトライするのも現実的ではなく、別の対応が必要になるケースもある。こうしたトレードオフはシステムごとに判断すべきで、設計段階から冪等（べきとう）性を検討することも重要だ。サービスアカウントを活用して権限をクリアにしつつ作り込むことで、リリース後の運用改善にもつながる。マネージドサービスは早いと思われがちだが、垂直にはスケールしない。水平スケールする性質があるため、周辺システムも並列処理などを検討すべきだ。また各種サービスを組み合わせることで発生するネットワーク遅延もある。SREの文脈で『推測するな、計測せよ』という格言があるように、ダッシュボードを活用した継続的なテストや計測も欠かせない」

クラウドネイティブの先行事例や知見を社内で共有し、ビジネスの高度化を目指す

　モノタロウのクラウドネイティブ推進に当たっては、前述のようなコンテナ化、Kubernetesの活用や12 Factor App化などの取り組みに注力するのではなく、組織にクラウドネイティブを根付かせる点も重視している。具体的には、先行したプロジェクトで得られた知見を社内に展開できるよう、クロスファンクショナルチーム（CFT）を結成し、IT Infra Visionという会議体を展開している。

　CFTの主な目的の一つに、IT課題の集約がある。全社的な権限分離、コスト、DR（災害対応）、セキュリティなどの課題を中央集約的に解決できるのか、すでに稼働しているクラスタをどう管理していくべきなのか、その場合の組織上の責任分界点はどうなるか……といった議題について方針決定に関わるメンバーを交えて議論する。そして、将来的なビジョンに合意した上で、優先度を付けてアクションにつなげていく。藤本氏は、Kubernetes基盤化を例にCFTの活動を説明した。

　コンテナオーケストレーションとしてKubernetesを導入する際、単一のサービスだけではコストに見合わない。Kubernetesが提供するネームスペースを利用するなどして複数サービスを乗せられると、基盤としてのスケールメリットが出てくる。それらをCFTがレビュー、議論してアクションにつなげていく。一方、自分たちが触った経験のないものはレビューや判断が難しい課題もある。そこで、クラウドベンダーと、チケットベースの問い合わせだけでなく、定例会、ハンズオンなどのワークショップなどで連携を図っている。

　モノタロウでは今後、サプライチェーンの高度化にも挑戦しようとしている。自社の倉庫とサプライヤーの在庫をシステム上で連携し、自社の倉庫で欠品している商品はサプライヤーの倉庫から顧客に直接配送する「引当出荷倉庫オプション」という仕組みだ。この実現にはデータ管理の在り方や各種システム間の連携方法も異なるため、新たな挑戦となる。

モノタロウにおける今後の技術的チャレンジ（藤本氏の講演資料より）

　藤本氏は、こうした今後の活動にもクラウドネイティブ推進の取り組みが生かせるとし、最後に次のようにコメントして講演を締めくくった。

　「ビジネスの高度化に向けて、開発だけでなく、業務知識とアーキテクチャ観点でのドメイン分割とインタフェースを通じた結合化を進めたい。モノタロウのテックビジョンを通じたケイパビリティ向上を進めることで、ビジネス成長を支えるアジリティが実現できると考えている。クラウドネイティブの推進で、スケーラビリティが改善するだけでなく、システム間の連携やデータ活用が実現でき、次のチャレンジにもつながる」