“超レガシー”なコープさっぽろ、AWS移行まつりをどう成し遂げたのか

　移行ポイントの一つはアカウント設計だ。

　「複数のアカウントを運用する前提でシステムを設計しました。後からアカウント設計を変更することは難しく、最初にきちんと作り込むことが肝心です。当社ではAWS移行のプロジェクトが始動する前から、アカウントが幾つか存在しており、移行計画が複雑化しました」（若松氏）

　具体的には、「AWS Organizaitons」で複数アカウントの共有方法やバックアップなどのポリシーを設定した。また、他社のSaaSでID管理をしていることから、「AWS IAM」（Amazon Identity and Access Management：IDとアクセス管理）のIDプロバイダーとシングルサインオン（SSO）システムを連携させて「AWS マネジメントコンソール」にログインできるよう設計した。

　セキュリティについては、「AWS Security Hub」と「AWS Config」を活用して、ベストプラクティスや推奨されるフレームワークを適用し、ポリシーに違反するリソースを検出してガバナンスを確保できるようにした。ネットワークについては、AWSアカウント間は「AWS Transit Gateway」で、AWSとオンプレミス間は「AWS Direct Connect」でつないだ。

CTO長谷川氏「構成はシンプルに! かっこ悪いのはアカン!」

　実際にオンプレミスからのシステム移行では「一つ一つ中身を把握し作り替えるのは時間がかかる」との考えから、V2V（Virtual to Virtual）やP2V（Physical to Virtual）でシステムをそのままコピーしてAWSに移行させる“Lift”を行い、AWSでクラウドネイティブな構成に作り替える方法を採用した。

　「移行対象を把握するために、システムやサーバのリスト化が必要です。OSやミドルウェア、データベースはライセンスの問題が生じるので、事前に条件を整理します。また、ハードウェアやアプリケーションの保守期限も、移行の優先順位を決める際に必要となる情報なので把握しておきます。移行ツールは、『AWS Server Migration Service』と『CloudEndure Migration』がありますが、ダウンタイムの少なさやAWS Direct Connect経由で移行が可能なこと、帯域制限が可能なこと、直接『Amazon VPC』にコピーできることから、CloudEndure Migrationを採用しています」（若松氏）

　「Active Directory」（AD）の移行は、AWSのマネージドADである「AWS Directory Service for Microsoft Active Directory」に移行することで、運用管理の負担を減らした。

　「システムを単純にコピーするわけですが、『Oracle Database』や『SQL Server』のライセンスの問題やクラスタが組まれたシステムを一度解かなければならないといった障害が生じました。OSが古すぎてCloudEndure Migrationがインストールできないケースもありました。コピーできないパターンを整理して、全てを移行させることを目指して取り組んでいます」（若松氏）

　今後は、コープさっぽろの本部を中心に、店舗、物流、工場、3つのデータセンターがつながるハブ＆スポーク型で組まれているネットワークを、データセンターを中心としたネットワークに移行させたいと考えている。さらに、インターネットを中心によりシンプルな構成にする方針だ。

　「全てのサーバをAWSにし、AWS Deirect Connectを廃止し、AWSを中心としたネットワークにしていきたい。運用管理ツールやADの廃止も目指していきます。長谷川がよく言うのですが『構成はシンプルに！　かっこ悪いのはアカン！』に向かって突き進んでいければいいと思っています」（若松氏）

宅配注文サイトのインフラを2020年にAWS基盤にリニューアル

　エンジニアの山崎 奈緒美氏（デジタル推進本部）が登壇し、宅配注文サイトのインフラをリニューアルした事例を紹介した。コープさっぽろは、2009年から宅配注文サイト「eトドック」を運営していたが、2020年12月に「トドックサイト」にリニューアル。また先行して2019年8月にはスマホアプリ「トドックアプリ」を刷新し、IDパスワード方式のログインではなく、Auth0の認証コードによるログインやSNSログインに対応した。

　従来、eトドックはオンプレ環境で運用しており、VPNを介してAWSで構築した基幹API環境と接続させていた。また、トドックアプリと基幹APIは別アカウントで構築し、VPCピアリングによって接続していたという。eトドックからトドックサイトへのリニューアル時は、トドックサイトをAWSの基幹API環境に相乗りさせ、4カ月という短期間で移行を完了させた。これによって、さまざまな課題が生じたという。

　「本番、検証、開発環境が同一のためオペレーションミスの発生や、システム単位でのコスト把握ができない、組織単位でのリソース共有が効かない、『AWS CloudFormation StackSets』が効かない、SCP（サービスコントロールポリシー）ポリシーが配布できない、AWS Security HubとAWS Configでポリシー違反リソースの検出ができないといった問題が発生しました。またAWS IAM Userの乱立や踏み台サーバによる多段接続といった課題を解消したいとも考えていました」（山崎氏）

　これは若松氏が「アカウント設計に着手するより前に、アカウントが幾つか作られていたことが原因で移行に苦労している」実例でもある。さらに言えば、単にレガシーシステムをそのままコピーして“Lift”した後に、クラウドネイティブな構成にどうやって“Shift”させるのかを問われる局面だ。

　課題に対し、同社はインフラ構成のリファクタリングに取り組んだ。

　「まずはアカウントを分離して、本番、検証、開発環境を分けること、トドックサイトのインフラと基幹API環境を分けること、各アカウントをAWS Organizationsで一元管理することに取り組みました。インフラアーキテクチャの改善として、データセンターや検索エンジンとの接続を『AWS Site-to-Site VPN』からAWS TransitGatewayとAWS DirectConnectによるネットワーク構成へと変更し、踏み台サーバの廃止などに取り組ました。あわせて、インスタンスの最適化や『Amazon Aurora』のスケールインおよびスケールアウトを自動化させました」（山崎氏）

図1　AWS移行後の課題（出典：AWSサミットでの投影資料）

図2　インフラ構成のリファクタリングで実施したこと（出典：AWSサミットでの投影資料）

　また、アカウントを分離したことで横ぐしでシステムを監視しにくくなったことから、システム性能監視ツールである「New Relic」を導入した。

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

　山崎氏は今後のロードマップを次のように説明する。

　「今後はトドックサイトにレコメンド機能や非ログイン機能、電子組合員機能などを追加し、お客さまが組合員登録後にシームレスに初回の宅配を注文できるようにする予定です。その際は、APIリクエストの増加やスパイクアクセス時のデータベースの負荷といった課題が生じると考えています。レコメンド機能の実現については、購入商品と購入者属性の機械学習なども必要になると思います」（山崎氏）

　同氏はレガシーシステム刷新の課題に直面する企業へのアドバイスを語り、講演を締めくくった。

　「事業会社にこそAWSスペシャリストを採用すべきです。AWSという共通言語によりエンジニア間の認識を統一できます。クラウドサービスを利用すれば、情報システム部門が主体でシステムをコントロールできるようになります。システム開発の面白い部分をベンダー任せにするのはもったいない。『うちはレガシーシステムだからできない』と言われるかもしれませんが、コープさっぽろのシステムは“超レガシー”です。情シスの方はもっと夢を語り、心に秘めた熱い気持ちをぶつけていただきたいなと思っています」（山崎氏）