皆さん、こんにちは。 プロダクト技術本部の穂積です。
本日は、2023年9月に完了した、自営のデータセンターからAmazon Web Services（AWS）への移行についてお話したいと思います。
以前、下記ブログでも紹介しましたが、今回はもう少し深堀りしてご紹介します。
始まり
事の起こりは2018年6月に遡ります。
弊社では、長年にわたり自営のデータセンターを運営していました。しかし、そこでの運用は多くの課題を抱えており、改善が求められていました。
一方で、その当時は、通信事業者や信頼性が重要視される金融系業界でもクラウド化の波が押し寄せ始めており、新技術を活用したサービスが次々と展開されていました。こうした変化を目の当たりにし、我々も新しい時代に対応するためのインフラを構築する必要があると考えました。
そこで採用したのが、「AWSファースト」戦略です。この戦略のもと、私たちはAWSに移行することを決定しました。
移行の目的と期待する成果
移行の目的は、やはり事業環境の変化に柔軟かつ迅速に対応できる新しいインフラ環境を手に入れることです。
期待した成果は以下のとおりです：
- コスト面:
- 変動費型の事業基盤への移行により、利用状況の変化に柔軟に対応
- サービスごとのコスト見える化
- インフラ/開発コストの削減
- デリバリ:
- ハードウェア / ソフトウェアの購入・構築なしでタイムリーに準備
- 新機能リリース期間の短縮
- 投資回収期間の短縮
- 品質と生産性:
- 耐障害性向上
- 構築自動化による生産性向上
- レガシーからAWSマネージドサービスへ移行
- エンジニアリング:
- クラウドネイティブへシフト
- 最新のクラウド機能をビジネスへ組み込み
- クラウドノウハウの蓄積と共有
このような数々の利点を見据えて、私たちはAWSへの移行を進めました。
このブログを通して、移行のプロセスやその後の成果を皆さんに共有できればと思います。
移行計画
移行の全体計画概要
まず初めに、システム移行の順序を計画するにあたり、移行難易度を整理しました。
計画の基本方針として、比較的容易に移行できるシステムから順次AWSへ移行を進めていくこととしました。
- 新規システム
これらは最初にAWS上で構築されることが前提です。 - 既存システムで他のシステムと連携していない、規模が小さいシステム
独立度が高く移行しやすいため、早期の移行対象としました。 - 既存システムで他のシステムと連携しているが、大規模ではないシステム
少々複雑ではあるものの、比較的迅速に対応可能です。 - 既存システムで他システムと密に連携していて、大規模なシステム
こうしたシステムは移行の中で最も難易度が高く、慎重に進める必要がありました。
会員基盤などの基幹システムは4番目に分類され、監視システムなど自営のデータセンターに残さざるを得ないものを除き、最終的にはすべてAWSへ移行していく計画です。
使用したアプローチ
移行方針として採用したのは「リフト＆シフト」です。これは、迅速な移行を最優先にし、移行後にAWS向けの最適化を進める方法です。
リフト＆シフトのリフト時点では、通常アーキテクチャを自営のデータセンターのものと同じくすることが多いですが、弊社ではいくつか次のような置き換えを行いました。
- データベースはAWS RDSに置き換え
データベースの管理効率とスケーラビリティを向上させるためです。 - ドメインはRoute53に置き換え
ドメイン管理を一元化することで、シンプルな運用を実現しました。 - ログ保存はCloudWatchLogsとS3に置き換え
ログ保存場所の統一とデータの永続性を強化しました。
他にもいくつかありますが、これらの変更は、置き換える際のコストとその後に得られるメリットを十分に考慮した結果です。
このようにして、慎重かつ計画的にAWSへの移行を進めました。
移行前の評価と準備
AWS移行プロジェクトの準備段階についてご紹介します。大規模な移行を成功させるためには、入念な準備が必要不可欠です。
評価と準備のポイント
移行前に行った評価や準備は、以下の通りです。
1. クラウドへの理解を深める
社内で有志による勉強会を開催し、クラウドの基本を学びました。また、ユーザー会（JAWS）に積極的に参加し、外部からの情報を収集しました。さらに、AWS最大のイベントであるre:Inventにも参加し、クラウドの未来を実感しました。
2. 戦略策定と役員の賛同を得る
「AWSファースト」戦略を立案し、コスト試算を行いました。中期計画としてこれを全社で推進するため、役員の賛同を取り付けました。
3. CoEの組織と準備
AWSのコンサルタントの協力を得て、他社の成功事例から学びました。そして、社内にクラウド移行の中心となるセンターオブエクセレンス（CoE）を組織しました。クラウド移行用に社内の既存の規定を再整備し、その規定に沿ったクラウド基盤を整備しました。移行計画も各システムの担当者と共有しました。
実行
移行の反省と対策
移行初期、比較的移行が簡単だと考えていたシステムを半年間で40ほど移行する計画を立てました。しかし、実際に移行できた数はわずか8システム。目標を大きく下回りました。この失敗の主な要因は、準備不足と甘い計画にありました。
1. 準備不足の露呈
初期の移行段階では、準備の甘さが顕在化しました。十分に整備したつもりのクラウド基盤でしたが、作業手順の作成漏れや、想定外の作業が多発しました。さらに、依頼者と作業者の間での意思疎通が不十分だったため、手戻りが多発しました。
対策として、自営のデータセンター時代の作業を洗い直し、すべてに対応できるよう作業手順を見直しました。また、担当者間の意思疎通を円滑にするため、調整役をアサインしました。
2. スケジュール管理の不備
初期のシステム移行では、各担当者に任せることでスケジュールにばらつきが生じ、構築やセキュリティアセスメント担当者への依頼が集中してしまいました。
解決策として、構築からリリースまでの各工程を具体的な日程に落とし込み、それを基に担当者と合意形成を図りました。これにより、負荷の集中を避けることができました。
3. 関係者とのコミット不足
AWS移行に関する合意は得ていたものの、急な開発案件や障害対応でリソースが他に割かれ、移行が滞ることが度々ありました。これに対しても、スケジュールの厳密な管理と、進捗状況の継続的なヒアリングを実施し、さらに各担当者の上司にもスケジュールに合意してもらうことでリスクを軽減しました。
これらの反省を基に、次年度には計画を大きく上回る80システムの移行を達成し、プロジェクトの軌道修正に成功しました。スケジュール管理の重要性と、移行のための準備の徹底がいかに大事か、深く学んだ日々でした。
基幹データベース移行の挑戦
その後、順調に移行が進みました。しかし、最終段階では、関連システムが多く存在する基幹データベースの移行という大きな壁が待ち受けていました。この移行は、すべてをメンテナンス時間内に完了させる必要があり、かつ管理者不在の関連システムの存在やテラバイト級のデータ量の移行など多くの課題がありました。
評価環境でのリハーサルを1回、本番環境では2回の移行リハーサルを実施しましたが、初回の本番移行は権限設定の移行漏れで失敗。しかし、2回目で改善し、無事に成功を収めました。この過程で、多くのエンジニアが深夜にも関わらず尽力してくれたことに、心から感謝しています。
また、データ移行にはAWS Database Migration Service（DMS）とexpdp/impdpを併用しました。当初はAWS DMSのみでの移行を考えていましたが、様々な課題に直面し、併用する選択をしました。本データ移行は、株式会社システムサポート様に多大なご協力をいただき、実現することができました。詳しくは、以下のリンクをご参照ください。
完了後の評価
4年間にわたる自営のデータセンターからAWSへの移行プロジェクトを振り返り、その成果を評価してみたいと思います。 多くの課題や困難に直面しましたが、関係者の皆様やパートナー企業、AWS担当者の皆様の協力のおかげで、プロジェクトは無事に完了しました。
コスト面での成果
私たちの移行プロジェクトでは、80％以上のインフラコストを変動費化することができました。これにより、必要な時に必要なリソースを柔軟に利用できる環境が整い、コスト効率が大幅に向上しました。
デリバリ効率の向上
AWSへの移行により、必要なリソースは即時に利用開始が可能となりました。これによって、デリバリまでのスピードが劇的に向上し、迅速なビジネスニーズへの対応が可能になりました。
品質と生産性の向上
移行後のシステムは耐障害性が格段に向上しました。しかし、今回は主にリフト＆シフト戦略を採用したため、定型作業の自動化はまだ道半ばにあります。さらなる自動化が今後の課題です。
エンジニアリングスキルの向上
移行を通じてクラウドノウハウを大いに蓄積できました。しかし、クラウドネイティブなエンジニアリングへの完全なシフトや、最新クラウド技術をビジネスの中に取り入れることは一部に留まっています。ここも今後の成長エリアとして捉え、継続的なスキルアップを目指しています。
一部サービスの再設計の効果
基本的にはリフト＆シフトで進めた移行でしたが、中には大胆にリファクタリングを行い、AWSのマネージドサービスを活用してクラウドネイティブなアーキテクチャに生まれ変わったシステムもありました。クラウドネイティブ化に成功したシステムでは、以下のような具体的な成果も得ることができました。
- リリース工期の30％短縮: リソース展開の迅速さが、全体のプロジェクト期間を短縮することに寄与しました。
- 投資コストの27％削減: より効率的なシステム設計によるコスト削減が実現しました。
- 運用工数の削減: サーバやリソースの増強、データベースのバージョンアップ作業が自動化され、運用負担が軽減されました。
これらの成果を糧に、今後はさらにクラウドの利点を最大限に活かせるよう、進化し続けていきたいと思います。
移行が成功した要因
次に、今回AWS移行が成功した要因を挙げたいと思います。
このプロジェクトには様々な挑戦がありましたが、無事に成功を収めることができた要因は、大きく分けて以下の3つです。
1. トップダウンのAWS移行判断
プロジェクトの初期段階では、基幹データベースのような一部のシステムは移行が難しいと考えていました。しかし、自営のデータセンターとAWSにデータを分散させることでコストが増大する試算となり、高難度の移行に踏み切ることになりました。ここで、経営層は移行のリスクを承諾し、全社を挙げての取り組みを促進してくれました。結果として、AWS移行にモチベーションを持てなかったシステム担当者の動機付けにもつながりました。
2. 移行をリードする能動的社員の存在
プロジェクトの推進には、進んで挑戦する能動的なシステム担当者の存在が欠かせませんでした。彼らは常に先陣を切ってトライし、発生した課題を迅速に見つけ出し、その解決策を他のシステム担当者に共有してくれました。これにより、後に続くシステム担当者にとっては多くの障壁が取り除かれ、スムーズに移行を進めることができました。
3. CoEによる技術支援
技術面での不安を抱えるシステム担当者も少なくありませんでしたが、CoEの存在が非常に大きな助けとなりました。移行に向けた基盤をしっかりと整備してくれることで、システム担当者は困難な状況でも「何とかなる」という安心感を持つことができました。その結果、技術的な障壁を乗り越え、移行を進めることができたのです。
これらの要因が揃い、AWS移行プロジェクトを成功に導くことができました。組織の一体感や前を行くリーダーシップ、そして確かな技術支援がプロジェクトの鍵を握ることを改めて実感しています。
最後に
昨年、何度か「AWS移行をしてよかったですか？」と尋ねられることがありました。
移行前に私たちが期待していた効果はほぼすべて実現できたため、私は自信を持って「はい、よかったです」と答えることができました。
しかし、それは私個人の視点での話です。他の社員はどのように感じているのか、気になったのでアンケートを取ってみました。
アンケートから得られた意見をいくつかご紹介します。全体的に、ポジティブな意見が多く、私たちBIGLOBEにおけるAWS移行は成功だと評価しています。
ポジティブな意見
- コストが削減できた
- インフラが簡単に操作できる
- マネージドサービスを組み合わせると、開発や運用が非常に楽になった
ネガティブな意見
- コストを安くするために必要なサーバ管理（起動、停止）が手間
- 知識がないとインフラ操作が難しく感じる
- コンポーネントが多すぎて、トラブルシューティングが大変
もちろん、全てが完璧というわけではありませんでしたが、AWS移行のメリットを享受することができました。今後はさらにクラウドネイティブなアーキテクチャへのシフトを推進し、改善を続けたいと考えています。このシフトの成果が出た際には、ぜひまたブログでその内容を共有させていただきます。
追伸：AWS移行から本ブログ執筆までの1年間、私たちはAWS利用料金の削減に取り組んでいました。当初のAWS利用料金試算時の為替レートは1USD=114円でしたが、現在155円と円安が進んでしまっており、移行時のAWS利用料金が当初の試算と比較すると大幅に悪化していたためです。削減活動の結果、約20％のコスト削減を達成しました。これもまた一つの成功例として、いつかご紹介できればと思っています。
