アーカイブ動画
登壇者プロフィール
株式会社ZOZOテクノロジーズ
SRE部 川崎 庸市氏
ヤマトホールディングス株式会社
執行役員 データ戦略担当 中林 紀彦氏
マルチクラウドで実現する「ヤマトデジタルプラットフォーム」
最初に登壇したのは、ヤマトホールディングスの中林紀彦氏。ヤマトホールディングスでは今年1月よりマルチクラウドによる「ヤマトデジタルプラットフォーム（YDP）」の構築に取り組んでいる。
「YDPはAWSも使っているが基本AzureとGCPによるマルチクラウドです。本格的に着手したのが1月以降なので、ZOZOの川崎さんに学ばせていただこうと、今日は楽しみに来た」と中林氏は切り出し、セッションを開始した。
その背景にあるのが、ヤマトホールディングスが策定した経営構造改革プラン「YAMATO NEXT100」だ。今後のヤマトグループにおける中長期の経営のグランドデザインとして、2020年1月に発表された。CX、DX、Innovationをキーワードに、物流のエコシステムを創出する企業へと進化することを目指す。
「これを実現するために、3つの事業構造改革と3つの基盤構造改革に取り組んでいる」と中林氏は話す。
3つの事業構造改革とは「宅急便デジタルトランスフォーメーション（DX）」、「ECエコシステムの確立」「法人向け物流事業の強化」。3つの事業構造改革とは、「グループ経営体制の刷新」「データ・ドリブン経営への転換」「サステナビリティの取り組み」である。
事業構造改革の取り組みで挙げた「宅急便のデジタルシフト」では、ロボットなどを導入することでデジタル化を目指していくという。
「例えば、顧客接点としてLINE公式アカウントを用意し、受け取り日時の変更や再配達依頼などがスムーズにできるようにしている」（中林氏）
「ECエコシステムの確立」は、EC向け新配送商品「EAZY」の導入だ。
「EC利用者・EC事業者・配送事業者の全てをリアルタイムなデジタル情報でつなぐことで、購入・配送・受け取りの利便性と安全性、効率性を向上させることができる」（中林氏）
「法人向け物流事業の強化」では、様々な業種・業界に特化したサービスの提供を進めている。緊急事態宣言以降、医薬品の宅配が増えた。そこでオンライン診療の医薬品を配送するスキームを構築し展開している。
一方、基盤構造改革ではグループ経営体制を刷新するために、主要事業会社を1社に統合。データ・ドリブン経営への転換を目指し、4年間で1000億円のIT/デジタル投資を行う。
「そのうちの何割かがクラウド投資。2021年に約300人規模のデジタル組織を立ち上げ、5つのデータ戦略を実施することからDXを進めていく。そして、2024年3期までに事業全体で約4000億円の投資を行い、2兆円まで売り上げを伸ばしていく。今年はこの目標に向けた取り組みの1年目。営業利益率6％を目指し、大きな改革を進めている」（中林氏）
ヤマトグループのアーキテクチャーの基本方針で参考にしているのが建築の分野である。都市設計になぞらえて、アーキテクチャーをデザインしているという。
「都市設計（システム全体像の策定）、区画整理（コンポーネントモデルやオペーションモデル、データモデルの策定）、耐震設計（非機能要求グレードの策定）と3段階に分けて定義していく」（中林氏）
ZOZOTOWNではどのようにクラウド移行を進めたのか
続いて、ZOZOテクノロジーズの川崎庸市氏が登壇し、「ZOZOTOWNのクラウド活用戦略」についてセッションを行った。
「ZOZOTOWNはオンプレミスベースで構築してきたサイトを、クラウドにシフトしてそれを最適化していくというクラウドのモダナイゼーションを実施した。その中でどうクラウドを活用し、どう運用しているのか。ツールの選択について説明したい」と、切り出す川崎氏。
川崎氏は元々大手インターネット企業で、基盤部分の開発を担当していた。その後、前職の外資系ソフトウェアベンダーでクラウドのアーキテクトとしてアーキテクチャーの策定支援に従事している。「インフラ運用の自動化、効率化が目下の関心事」と川崎氏は笑みを浮かべる。
ZOZOTOWNは日本最大級のファッション通販サイト。1998年に輸入CDなどの通販サイトから始まり、2004年にZOZOTOWNのサイト運営が開始された。当時のサイトはオンプレミスで構築していた。その後、ビジネスが拡大し、インフラの拡張性・俊敏性が要求されるようになったという。
「一つの大きなモノリスのシステムはビジネスの拡大に従い、巨大化していった。コードも肥大化しており、オンプレミスには限界がくると思っていた」（川崎氏）
特に年に数回実施しているセール時期は、大量のリクエストが発生する。オンプレミスのシステムでは対応できないと考え、2018年にクラウドへのリプレースを開始した。そして今年、マイクロサービスのアーキテクチャーへの移行を進めている。
現在、マイクロサービス化に取り組み、以下のようなアーキテクチャーの変遷を行っている。
フロントエンドと統合DBというアーキテクチャーから、リクエストが要求される参照系機能をクラウドで提供するスタイル。APIにより必要なデータをリフト＆シフトで移行した。「昨年末、ようやくこのシステムでセールを乗り越えることができた」と川崎氏は話す。
「ZOZOTOWNにおけるクラウドテナンシーの方針は、基本はシングルクラウドで、要件に応じてマルチクラウドを検討する。シングルクラウドで始め、アプリやインフラの信頼性の向上に集中する」（川崎氏）
マルチAZ（アベイラビリティーゾーン）やマルチリージョンを使う、可用性の構成を組む、回復性の設計を行う、運用基盤や体制を強化するなどできることが多々あるからだ。だが、シングルクラウドでは実現できない高い信頼性が必要とされる場合において、「信頼性とコストのトレードオフを考慮しマルチクラウドを検討している」と川崎氏は力強く語る。
同社におけるクラウド利用パターンの基本は「オンプレミスとクラウドのハイブリッド」と川崎氏。その中でマイクロサービスやデータの基盤に関しては、シングルクラウドを活用。マルチクラウドではパーソナライズ検索機能を提供している。
クラウド化で得た知見
マルチクラウドはメリット、デメリットがある。メリットは信頼性向上、リスク分散や可用性の向上、可搬性確保やベンダーロックイン回避という柔軟な選択肢が得られる。一方のデメリットは、複数のクラウドを活用するのでアーキテクチャーの複雑化、学習、運用、インフラなどのコストが増加する可能性がある。
川崎氏はZOZOTOWNのリプレースで、さまざまなマルチクラウドに関する知見を得たという。例えば信頼性については、単一クラウドのSLAを越える信頼性確保が可能になることは間違いないが、回復性の設計などを中途半端にすると、逆に信頼性低下につながることもある。
また選択肢が増える一方で、運用の効率性やベンダーロックイン回避のために特定のクラウドに依存しない選択をすると、シングルクラウド以上の制約条件ができてしまい、最大公約数のメリットしか得られないかもしれない。
またアーキテクチャーの複雑化、学習コストが増えることで、アジリティが低下し、ビジネスチャンスを逃す可能性もあるという。
「アジリティの低下は、弊社で実際にあったこと」と川崎氏は吐露する。「求められるビジネス要件、得られる信頼性、必要とするコスト、開発体制、習熟度レベルなどとトレードオフで考えるべき」と、川崎氏は釘を刺す。
実際にZOZOTOWNでは、クラウド移行は既存サービスを回しながらだったため、サブシステムごとにn％リリースにより段階的に行ったという（ストラングパターン）。クラウドで構築するアプリはコンテナベース。アプリ基盤にはKubernetesを採用し、クラウドネイティブに最適化している。
利用技術やツール選定方針は特に社内で指定があるわけではなく、ケースバイケースで適したものを選定している。例えばマネージドサービスの活用は、運用負荷軽減やポータビリティなどが考慮ポイントになる。
特にステートが発生するデータストアなどのサービスについては、自前で作って信頼性を確保するのは難しいため、マネージドサービスを使う。もちろん、ビジネス要件やサービスの成長に応じて、マネージドで要件が満たせないこともある。
そういう時は必要に応じて自作も考えることもある。技術としてはオープンソース、またはオープンソース互換を採用する方針。特定クラウドに依存する技術・ツールも必要に応じて採用しているという。
「クラウドは進化し続けるのがメリットだが、裏を返せば常にアップデートされるので、壊れる可能性もある。クラウドは壊れることを前提に、いかにシステムがダウンタイムを起こさずに回復していくかを重視することが必要。
そのため、回復性を高めるための能力、システムを構成して自動化することは心がけているし、システムが今どのような状態にあるかを把握できる可観測性、SREを重要視している」（川崎氏）
構成管理の自動化の徹底も行っている。CI/CDを起点にアプリ・インフラ環境の構築、リリース、構成変更を実施。「最初にパイプラインを作るのにコストはかかるが、得られるメリットは大きい」と川崎氏は続ける。
クラウドはアップデートされ、サービスもどんどん変化する。そのため、ミスの低減、開発効率とリリーススピードの向上、運用・開発業務の非属人化をすることで、組織や活動をスケールさせることができるというメリットがあるのだ。
オンプレミス/シングルクラウド/マルチクラウドの使い分けポイント
二人のセッション後は、中林氏と川崎氏によるパネルディスカッションが行われた。
中林：ZOZOでは、書き込みのあるものはオンプレに残し、それ以外はシングルクラウドに移行してマルチクラウドにしているのでしょうか。
川崎：最初はシングルクラウドでリプレースを開始しました。某クラウドで大規模障害が発生し、大きなビジネスリスクを感じたことが、マルチクラウド検討のきっかけとなりました。
中林：マルチクラウドにしようとしてプランを立てたわけではなかったんですね。うちはベンダーロックインの問題が想定されるので、最初からマルチクラウドにしようと思っていました。
ただ、学習コストなどオーバーヘッドが大きいので、シングルクラウド中心に進めていたのですが、私たちもDNSの大規模障害に当たってしまったのです。そこで、マルチクラウドで構築を進めないといけないと考え始めました。
川崎：大規模障害でマルチにしましたが、実は今、シングルクラウドに落ち着いています。シングルでもできることはあるというのが、これまでの学びです。
中林：オンプレは残す方針なのでしょうか。
川崎：オンプレにはロジックと密接に絡んだ大量のデータがあるので、それを一度にすべてクラウドに移行するは難しいですね。ですが、大きな流れではクラウド化を進める方向です。
中林：データがポイントなんですね。
川崎：クラウドはコンテナや軽量化や、仮想化技術にフォーカスが当たっていて、どこでも動いて軽いというトレンドがあります。一方、データは重力があるので、クラウド化するのにはコストもかかるし、技術的難易度も高い。特に決済が絡むと、トランザクションでシングルDBに対してコミットしなければなりませんからね。
中林：クラウド移行の際、データの重力があるので、データの母艦を何にするのか悩んでいます。主要のクラウドベンダーのデータストアのところを比較しているのですが、川崎さんも実践しましたか。
川崎：実際にマルチクラウドを検討する場合に、データの書き込み部分の検証をしましたが、現状では難しいと判断しています。
中林：クラウド技術のアップデートはすごく早いですよね。その情報をどのようにキャッチアップしていますか。
川崎：クラウドベンダーから情報を提供いただいたり、逆にこの機能は重要だということをフィードバックしています。クラウドの機能については、常時注目しています。
中林：ベンダーから情報をもらうことは重要ですね。ｎ％リリースというお話がありました。ｎをどう切り出す際に工夫したことや課題になったことがあれば教えてください。
川崎：フロントエンドからバックエンドのAPIに対してどのくらいリクエストを送るかという仕組みを、最初にクラウド化したときに作っていたのです。その仕組みを使えば、この1％はクラウドAに向けるか、99％はBに向ける。0％の指定でオンプレに戻すことができるようになっているのです。
中林：なるほど。n％リリースができる機能を作っておくということですね。
クラウド環境構築における技術選定はどうしてる？
中林：マネージドサービスを使うのか、OSSのような標準的なものでコンテナ化して移行するのかなど、技術選定は難しいと思います。意思決定する基準について教えてください。
川崎：方針としては、クラウドでデータストアを構築する場合、分散環境になります。ただ、分散のデータストアで可用性や安定性を保ちつつスケールさせるのは難易度が高いですよね。
それを実践するためにどれだけの運用コストや学習コストがかかるのか、またクラウドベンダーが高いSLAで提供しているのかなどで、選定していくのが良いと思います。
インターフェースはMySQLなど、比較的選択肢が多いものを選べば、周辺ツールやエコシステムを活用しやすいと思います。ただし、マネージドで100％は全部提供できるわけではないので、自由度は残しておくこともお勧めします。
中林：アーキテクチャーの複雑さがある。そう考えると、OSSなど標準的なミドルウェアなどの開発手法を採用するのも1つの手ですね。
マルチクラウドは理想型ですが、現実的にはどこかシングルクラウドにひっぱられる傾向があります。それとどう付き合っていくかは課題だと考えています。
川崎：データの基盤はデータストア、分析基盤サービスで構成されます。その際、データの蓄積されるところに、レイテンシーやフローを考えると良いのではないでしょうか。
参加者からの質問に回答
続いては参加者からの質問に答える形で、ディスカッションが進行された。
Q.ヤマトさんの発表で、アーキテクチャー基本方針を都市設計に例えていたのがわかりやすかったです。どのようなプロセスで設計していったのでしょうか。
中林：アイデアや構想はメンバーや複数のベンダーから、意見をもらいながら、まとめていきました。ZOZOではアーキテクトを自前でデザインされているのでしょうか。
川崎：マイクロサービス化に向かう部分など大枠については、内部のアーキテクトがビジネス要件に照らし合わせてシステムのデザインを考えました。
Q.2020年からマイクロサービス化を進めたとありますが、どこから着手していったのでしょう。
川崎：手をつけやすく、かつビジネス的に効果的なところから始めました。例えばクラウドでスケーラビリティを要求し、書き込みが発生していないところからです。
最初に作った大きなアーキテクチャーとしては、API Gatewayパターンで、流れてくるトラフィックを1カ所で受ける入り口を用意しました。入り口にあたる基盤を固めました。その後、データのストアや、書き込みが発生しているところに着手していきました。
Q.マイクロサービス化でパフォーマンスが悪くなりませんか。
川崎：モノリシックなアプリケーションと比べてパフォーマンスが悪化するのは、マイクロサービス化の宿命です。ですが、そこを極力悪化しないように最適化していくことです。
中林：やりながら調整していくしかないと思います。
Q.クラウドベンダーとの距離、関係性を教えてください。
中林：データの母艦にしているところは可用性や信頼性が求められるので、2週間に1度、海外のエンジニアと打ち合わせをしてリクエストをしたり、アーキテクチャーのデザインを見てもらいます。
また当社のシステムもミッションクリティカルなので、止まるとビジネスインパクトが大きい。トラブルがあった際は、開発メンバーに30分以内に連絡がいくようにしてもらっています。母艦にしているベンダーとは深く付き合わないといけないと思います。
川崎：当社も非常に近い付き合いをさせてもらっています。コミュケーションプラットフォームにSlackを使っているのですが、そのチャンネルの中にもベンダーの担当者に入ってもらい、非常に近い形でコミュニケーションできる形にしています。
例えば機能の質問、フィードバック、何か問題があったときの問い合わせなどは直通でできるようになっています。技術的な新機能の提供、アップデートなどの情報も非常に早く提供してもらえるようになっています。
Q.クラウド化への移行はどのくらいの組織規模で行っているのですか。
川崎：クラウドにまつわるリプレースにかかわる人数については、比較的少人数でやっています。
中林：社員は10人ぐらいですが、もっと増やしたいと思っています。
川崎：ある特定の機能を開発する場合、アウトソースの基準はありますか。
中林：組織の構築を始めたのが今年の年初からで、内製化するリソースがいないのが実情です。OCやプロトタイプは社員だけでできますが、大規模な開発はヤマトシステム開発かパートナーさんに頼んでいます。内製化率を高めたいとは思っているのですが。
川崎：うちは内製化率が高いですよ。クラウドに移行するには、学習する環境が必要になります。そこで用意しているのが技術顧問制度です。検索やiOSやRubyなど特定のテクノロジーにおいて優れた人を技術顧問として採用し、開発や運用に携わる人たちが容易にコミュニケーション取れる仕組みを作っています。そういう形で技術伝授する方法は効果的だと思います。
中林：フルコミットではなく、テーマに応じて関わってもらっているのですか。
川崎：必要に応じてですね。オンデマンドでの支援をはじめ、勉強会や定例会を開催していただいています。
中林：我々もアドバイザリーボード、ベンダー、開発会社の知見のある人たちに入ってもらって、いろんなレビューをしてもらっています。特にマルチクラウドは誰からも学べませんからね。顧問や外部アドバイザリーの協力を得ながら、自分たちで試行錯誤して情報をピックアップしていくのが正しい道だと思います。
Q.シングルクラウドとマルチクラウドでセキュリティコストはどう変わりますか。
川崎：シングルよりもマルチクラウドの方がセキュリティコストはかかります。またセキュリティをどう担保するかで、インフラコストもかかってきます。
Q.同じようなシステムでリプレースを考えています。シングルクラウドとマルチクラウドどちらを選ぶのか。
川崎：方針のところでも説明したように最初はシングルクラウドで始めるのが良いと思います。そこで信頼性を高めるために回復性の設計、運用基盤の自動化をしっかり固めて、さらなる上の可用性を求めるのであればマルチクラウドを求めるという流れが良いと思います。
中林：ありがとうございます。まずはシングルクラウドで足場を固めて、そこからマルチに展開するのが重要なポイントだということが学べました。また機会があればよろしくお願いします。
関連するイベント
