「超レガシーな企業でもクラウド移行は実現できる」――情シス担当の熱意から始まったコープさっぽろの挑戦：「全部AWSに持っていったらいいやんけ」で進めた移行

OSやネットワーク構成は古くシステムや基盤も組織ごとに縦割り――。北海道の生活協同組合、コープさっぽろはレガシー環境を改善していくために「全部AWSに持っていったらいいやんけ」の精神でクラウド移行を選んだ。どのように進めていったのか。

[高橋睦美，＠IT]

　いまだに紙やFAX、固定電話でのコミュニケーションが主流で、ITシステムはベンダー依存。「レガシーな会社だからクラウド移行やデジタルトランスフォーメーション（DX）の取り組みなんてとても無理だ」と思っている人はいないだろうか。実は、それは覆すことができる。ただそれには「情報システムの中の人」の熱い思いが必要だ。

　それを実証するのが、北海道の生活協同組合、コープさっぽろの事例だ。約181万人の組合員に「人と人」「人と食」「人と未来」をつなぐ事業を展開している同社は現在、基幹系システムはもちろん、ECサイト「eトドック」などあらゆるシステムのクラウド移行を進めている。首都圏から札幌に移住し、AWS（Amazon Web Services）エンジニアとして活躍する若松剛志氏（デジタル推進本部システム部 インフラチームリーダー）と山崎奈緒美氏（デジタル推進本部システム部 エンジニア、崎はたつさき）の2人が「AWS Summit Online 2021」のセッションでその道のりを紹介した。

「全部AWSに持っていったらいいやんけ」で進めたクラウド移行

　実はコープさっぽろは、AWSかいわいでちょっとした話題を呼んでいる。なぜなら、CDO（最高デジタル責任者）の対馬慶貞氏が、元東急ハンズ・メルカリといった経歴を持つ長谷川秀樹氏をCIO（最高情報責任者）としてスカウトし、両氏がリードを取る形で複数の「AWS Samurai」をはじめ次々とAWSエンジニアを集め、変革に取り組んでいるからだ。

コープさっぽろ デジタル推進本部システム部 インフラチームリーダー 若松剛志氏

　それ以前のコープさっぽろは、他の多くの企業と同じように超が付くほどのレガシー環境だったという。

　「古いOSや複雑なネットワークがあり、システムや基盤も組織ごとに縦割りで、それぞれ担当者がいる状態でした。全部で190システム、650サーバくらいあったと思います」（若松氏）

　レガシー環境をどう改善していくか――長谷川氏の答えは「全部AWSに持っていったらいいやんけ」というシンプルなもの。その方針でクラウド移行が始まった。

　ただ一般にはクラウド移行といっても「何から始めればいいか」で悩むケースが多いだろう。どれから手を付ければいいのか、重要度によるのか、それとも負荷の高いものから進めるのか、指針に迷うことは珍しくない。だが長谷川氏の方針はやはりシンプルで「どうせ中身なんか完璧に把握できないのだから、全部コピーしてしまえ」というものだった。

　「クラウド移行においてはよく『リフト＆シフト』という言葉が使われます。クラウドに持っていく、すなわちリフトに当たっては一つ一つ中身を確認して、クラウドネイティブな構成にシフトすることを考えがちです。ですが長谷川は『まず全てAWSの世界に上げてからどうするか考えよう』とかじを切ったのです」（若松氏）

　コープさっぽろではまずV2V（Virtual to Virtual：仮想環境を別の仮想環境に移行）、P2V（Physical to Virtual：物理環境を仮想環境に移行）で既存システムをクラウドにコピーする作業を進め、次のステップでFaaS（Function as a Service）やSaaS（Service as a Service）へのシフトを検討しているという。

　しかし、コピーにも前準備が必要だ。「OSやミドルウェアの要件を整理しないと、OSが古くて必要なツールがインストールできなかったり、データベースのライセンス関連の問題が起きたりする恐れがあります」（若松氏）。それ以前に、管理から漏れているシステムが存在する可能性もあるので、その洗い出しも含めてシステムやサーバをリスト化し、優先順位付けに利用したという。

　またAWSはオンプレミスから移行するためのサービスとして「AWS Server Migration Service」と「CloudEndure Migration」を提供している。コープさっぽろでは、ダウンタイムが少なく、「AWS Direct Connect」経由で移行でき、帯域制限が可能で直接VPCにコピーできるといった理由から、CloudEndure Migrationを選択したという。

　コピー後にはセキュリティグループの設定が必要だが、そこで何を設定したらいいか、コピー元の環境が古すぎて分からないこともあった。そこで「AWS Application Discovery Service」を活用して通信状況を監視し、何の通信をしているか把握した上でセキュリティグループの設定を実施したという。「かなり便利なサービスでした」（若松氏）

　コープさっぽろのオンプレミス環境には多数のWindows Serverが存在しており、Active Directoryを用いて管理していたが、それもAWSのマネージドサービスである「AWS Directory Service for Microsoft Active Directory」に移行した。

　こうして準備を整えた上でコピー作業に入っていったが、時にはやはり障害も発生する。データベースのライセンス問題に抵触したり、クラスタ構成をいったんやめなければいけなかったり、OSが古過ぎたりするなど幾つかのパターンごとに分け、整理していったという。

AWS移行後の変更は面倒、アカウント設計は早めを推奨

　若松氏はAWS移行作業を経て見えてきたポイントを紹介した。

　1つはアカウント設計の重要性だ。コープさっぽろには、本格移行前から幾つかのAWSアカウントが存在しており、そのために苦労した面もあったという。「後からアカウント回りを変更するのは結構面倒です。最初から複数アカウントを運用する前提で全体設計を進めることが重要です」（若松氏）。そこでコープさっぽろでは「AWS Organizations」を利用し、アカウントの階層付けや共有方法、どのようなポリシーで制御するかを最初にしっかり検討し、整理したという。

　コープさっぽろではその検討以前から、他社のSaaS形式のシングルサインオンサービスを用いてIDを管理してきた。そのIDをそのまま活用するため、「AWS Identity and Access Management」（IAM）のIDプロバイダーと連携させ、他社SaaSのIDでAWSのマネジメントコンソールにログインできるよう設計した。

　さらに「AWS Security Hub」と「AWS Config」を利用し、あらかじめ定めたポリシーに違反しているリソースを検出する仕組みを整えた。同社にとって不必要なルールは省いているが、現時点ではあまり作り込みはせず、基本的にはAWS側で定義されているルールをそのまま適用しているという。

本社、データセンター中心から「インターネット中心」のネットワーク構成へ

　コープさっぽろでは、AWSのアカウントの間は「AWS Transit Gateway」で、AWSとオンプレミスの間はAWS Direct Connectで接続している。ただ、全体的なシステム構成としては、コープさっぽろの本部を中心にネットワークが組まれている。若松氏いわく「本部にどでかいルーターがあり、そこに全てのネットワークが刺さっている恐怖の構成」だそうだ。

　他にも、3カ所あるデータセンターを冗長な構成と考えており、今後、データセンターを中心にした一般的な構成に変更する予定だ。

　「長谷川が常々言っていることですが、最終的には『インターネットを中心にしたネットワーク構成』を目指したいと思っています。つまり、サーバを全てAWSに入れ、インターネット越しに全てAWSにつながればいいという世界です」（若松氏）。ひいては、データセンターでの運用、「JP1」による管理やActive Directoryといったオンプレミスを支えてきたツールもなくしていきたいという野望を抱いているそうだ。

　こうした構成は、長谷川氏が常々言う「構成はシンプルに、格好悪いのはあかん」というコンセプトに通じるものがある。「シンプルにすることで障害点が減りますし、運用も楽になるため、ここに向かって突き進んでいきたいと思います」と若松氏は述べた。

コープさっぽろの現在のシステム構成（左）と目指したいシステム構成（右）

機能ごとにアカウントを分離し、インフラをすっきり整理整頓

　続いて山崎氏が「宅配注文サイト　インフラリニューアルの裏側」というテーマで、宅配注文サイト「トドック」のリニューアルと、並行して実施したインフラのリファクタリングを説明した。

　eトドックは、コーポさっぽろが2009年から運用してきた通販サイトだ。当時の環境に合わせて作られたまま、デザインが多少古くさくなってきたこともあり、2020年12月に「トドック」としてリニューアルを実施した。並行して、2019年からスマートフォン向けに提供してきた「トドックアプリ」にも改修を加えた。これに伴い、IDとパスワードによる認証から、Auth0やSNSログインを活用した方式に変更したという。

　こうして顧客の目に触れるフロント部分はモダンなインタフェースに改修できたが、裏側は「4カ月という短い期間で実施したこともあり、だいぶごった煮感のある状態でした」と山崎氏は述べた。「Amazon EC2」と「Amazon RDS」があり、宅配注文を受け付ける基幹APIサーバ群とはVPCピアリングで、オンプレミスとはVPNでつながるという、よくあるといえはよくある構成だ。

コープさっぽろ デジタル推進本部 エンジニア 山崎奈緒美氏（崎はたつさき）

　「ここで新たな課題が出てきた。まず、本番、検証、開発環境が同一なためにオペレーションミスが発生してしまった。システム単位でのコストが把握できないこともあった。サイト部分と基幹APIの部分も一緒になってしまっていた」（山崎氏）。さらに、AWS CloudFormationsのStackSets（複数のAWSアカウントの管理を効率化する機能）が効かなかったり、権限設定をするサービスコントロールポリシー（SCP）が配布できなかったり、Security Hubでリソースの検出ができなかったり……と、せっかくAWSで利用できる機能がフルに生かせず、若松氏が述べた原則も適用できない状態だったという。

　そこで取り組んだのが、インフラのリファクタリングだ。まず本番、検証、開発といった機能ごとにアカウントを分割し、サイトの部分と基幹APIも分離、整理した上でAWS Organizationsに入れることにした。

　またVPNに変えてAWS Transit GatewayとAWS Direct Connectの組み合わせに変更した。以前は踏み台サーバが多段になっており、開発者間で取り合いが発生していたため廃止した。さらに、乱立していたIAMユーザーではなく、IAMロールを使ってプログラムを実行するよう変更するなど、さまざまな整理整頓を実施したという。

　加えて、あらかじめ発生のタイミングが分かっているスパイクアクセスに備え、スケーラビリティの向上を図った他、可観測性を高めるため、アカウント分離をしていても横串で見ていけるようにする「New Relic」を採用し、インフラ、アプリ、リソースを監視することにしたという。

　一連のリファクタリングを経て、インフラはだいぶすっきりしたという。何より大きいのは、フロント機能と宅配注文の基幹APIの部分でアカウントを分離したことで、若松氏が最初のパートで話していた障害点の減少、運用負荷の低減が実現できた点だ。

　コープさっぽろでは今後も、レコメンド機能の追加や非ログイン機能などさまざまな機能を追加していく方針だ。当然、サービスが拡張すればするほどAPIリクエスト数も増え、スパイクアクセス時のデータベースの負荷も高まるだろう。それを見越して、負荷が高まった際「コンピュートリソースならまずは『AWS Lambda』でできるか、駄目そうだったらコンテナで処理できるかを検討し、それでも駄目ならEC2を利用する」といった具合に、どのような順番で解決策を考えていくかルールも整理しているという。

　「ポイントは、スケールアウトしやすいのかどうかです。なるべくクラウドネイティブなマネージドサービスを活用し、それが難しい場合はなるべく疎結合にし、ワークロードでリソースを分離していくという方針で検討しています」（山崎氏）

事業会社こそAWSスペシャリストを採用すべし

　山崎氏は最後に、コープさっぽろの取り組みを踏まえて次のように述べた。

　「事業会社こそ、AWSスペシャリストを採用すべきです。クラウドを利用することにより、情シス主体でシステムをコントロールできるようになっていきます。システム開発の面白い部分を、自分たちでやらずにベンダー任せにするのってもったいなくありませんかと思うのです」

　中には「うちの会社はレガシーだから無理」と思う会社もあるかもしれないが「コープさっぽろも超レガシーです」と山崎氏は述べた。

　また「長谷川さんというキーマンがいるからできたんじゃないですか」と言われることもあるという。だが山崎氏は、対馬氏の野望を聞き「私もやってみたい」と思ってコープさっぽろに転職してきた自身の経験を踏まえて「確かに、魅力的なキーマンがいるのは重要なこと。だからこそ、情シス部長の皆さまには、もっと夢を、心に秘めた熱い気持ちを周囲に広めていただきたいと思います」と講演を締めくくった。