アドプラットフォーム事業で開発運用業務を行っているアプリケーションエンジニアの山本です。 私は2024年4月にアドウェイズに新卒入社して、現在はオンプレミスからパブリッククラウドへの移行を中心とした業務を担当しています。
2024年も残りわずかとなりましたが、皆さんにとって今年はどんな一年だったでしょうか？ 私にとって今年は学生から社会人へと変わる節目の年であり、多くの学びと成長の機会に恵まれた一年でした。
また、同期のエンジニアとも仲良くなることができました。 特に、富士山を見るために山梨県・静岡県まで車を走らせて一泊二日の旅行をしたのはとても楽しかったです。
さて、今回の記事では、新卒1年目ながらコアサービスのクラウド移行プロジェクトに参加した経験についてお話します。 私と同年代のエンジニアや学生の方、さらにはAWSなどのクラウドサービスに興味のある方を対象に記事を書きました。 クラウド移行の具体的なプロセスや実践的な学びとしてご参考になれば幸いです！
目的
私の所属するクラウド移行チームでは、既存の社内リソースをオンプレミス環境からクラウド環境へ移行することを目的とした活動を行っています。 その活動の一環として、現在は弊社で運用しているアフィリエイトサービスのWebアプリケーションをクラウド環境に移行するプロジェクトに取り組んでいます。
弊社のアフィリエイトサービスには、利用者がサービスを効率的に活用するためのWebアプリケーションが備わっています。具体的には、以下の3つの管理画面を提供しています：
- アフィリエイトパートナー様向けの管理画面
- 広告主様向けの管理画面
- 社内向けの管理画面
これらの機能について、社内外への影響を最小限に抑えたうえで、安全にクラウド移行を完遂するのがプロジェクトのミッションです。 本記事では、クラウド移行に向けた準備で大変だったことや、準備の中で得た学びについてご紹介します。
取り組んだこと
プロジェクトは2024年12月現在も進行中ですが、これまでに以下の取り組みを行いました。
- 現状の構成について調査
- 移行後の構成図の作成
- 移行の遷移図の作成
- 移行に向けた構築・実装
- 移行前のテスト・リハーサル
今回は、これらの取り組みのうち、調査・設計に当たる1〜3の項目について掘り下げてご紹介します。
1. 現状の構成について調査
初めに、Webアプリケーションが現状どのような構成になっているかを調査しました。 調査の目的は、アフィリエイトサービスの全体像から今回のクラウド移行の関心ごとに当たる部分のみを切り出すことにあります。
基本的な調査方法は、ソースコードの確認と、実際にオンプレミス環境のサーバにアクセスしての調査です。どのようなプロセスが動いており、どのサーバやサービスと通信しているかを明らかにしていきました。
こうした調査を進める中で得られた情報をもとに、Webアプリケーションそのものに当たる部分と、それに関連する要素を整理した構成図を作成しました。実際に、以下のような構成図が完成しました。
ここで、構成のポイントを2つに分けて解説します。
1つ目は、現状のWebアプリケーションは役割の異なる2種類のサーバがある点です。 具体的には、静的処理を担当するWebサーバと動的処理を担当するアプリケーションサーバがあります。 アプリケーションサーバではCatalystが動いています。
(Catalyst: MVCのアーキテクチャを持つPerl製のWebフレームワーク)
リクエストの流れとしては、ユーザからの全てのリクエストをWebサーバで受け取り、必要に応じて一部の処理をアプリケーションサーバに委譲する仕組みとなっています。
2つ目は、現状でも一部の通信はクラウド環境と連携している点です。 具体的には、Webアプリケーションが提供する管理画面の中でデータを扱う際に、AWS環境のAurora MySQLやS3と通信しています。
しかし、Webアプリケーションそのものはオンプレミス環境で稼働しているため、こちらもAWS環境に移行することがプロジェクトのゴールとなります。
調査をしていて大変だったのは、設計の意図やどのような用途で使われているか分からないものがあったことです。 こういったものは社内Slackの過去のメッセージにまで調査範囲を広げて調べました。
結果として、過去のメッセージから不足していた情報を見つけることができたので事なきを得ました。
2. 移行後の構成図の作成
次に、クラウド移行後の構成図を作成しました。 先ほど作成した現状の構成図をもとにAWS環境に置き換える形で設計を行い、構成図を作成します。
ここで、移行後の構成図のポイントを2つに分けて解説します。
1つ目は、オンプレミス環境では分かれていた2種類のサーバを1つのサーバに統合したことです。 具体的には、オンプレミス環境の異なるサーバで動いていたWebサーバの機能とアプリケーションサーバの機能を、1つのEC2インスタンスで動かすように統合しました。
サーバを統合することで全体の台数を減らすことができるため、費用の削減やアップデート作業などの運用コストを下げるといった効果が見込めます。
2つ目は、URLのリライト機能の代替としてCloudFrontを設置したことです。
オンプレミス環境では、統合脅威管理 (UTM) の機能を使ってURLのリライト機能を実現していました。 ここで、URLのリライト機能は通常ALBのリスナールールで代替できます。 しかし、今回のオンプレミス環境で設定されていたリライトの条件がリスナールールでは実現できませんでした。
代わりに、CloudFrontではその条件を実現することができたため、ALBの前段にCloudFrontを設置しました。
CloudFrontの設置は今回のクラウド移行における大きな挑戦の一つであり、技術的な制約とサービスの要件を擦り合わせながら設計を行うことの大変さを痛感しました。
3. 移行の遷移図の作成
これまでのステップで、現状の構成図と移行後の構成図を作成しました。 これらをもとに、設計の最終段階として移行の遷移図を作成しました。
今回のクラウド移行では、リリースを2回に分けて実施する計画です。
- 1回目のリリース: Webサーバの機能をクラウド環境に移行
- 2回目のリリース: アプリケーションサーバの機能をクラウド環境に移行
ここで、移行の各段階におけるシステム構成を明確にするために、以下の4つの遷移図を作成しました：
- Webサーバの機能 移行直前の構成図
- Webサーバの機能 移行直後の構成図
- アプリケーションサーバの機能 移行直前の構成図
- アプリケーションサーバの機能 移行直後の構成図
これらの遷移図を作成することで、リリースの各段階におけるシステム構成を正確に把握し、移行作業の安全性と確実性を高めることを目指しました。実際に、以下のような遷移図が完成しました。
情報保護のため、画像にぼかしを入れて掲載しています。 ひとまずは情報量がかなり多いということが画像の雰囲気から伝われば幸いです。
代わりに、作成するにあたって意識したポイントを2つご紹介します。
1つ目は、移行直前の図は「トラフィックを切り替えるだけで良い状態」をイメージして作成することです。
クラウド移行の本質は、ユーザからのトラフィックがオンプレミス環境からクラウド環境へ切り替わることです。したがって、移行直前の図としてはトラフィックをクラウド環境へ切り替える準備が整った状態を表現します。
2つ目は、移行直後の図は「トラフィックを切り替えた後の状態はどうなるか」をイメージして作成することです。
トラフィックを切り替えることで、ユーザからのリクエストはクラウド環境へ流れるようになります。したがって、移行直後の図としてはリクエストの流れがどう変化するのか、どのサーバが利用されてどのサーバが利用されなくなるかを表現します。
こうして完成した移行の遷移図は他チームのメンバーにも共有しました。 具体的には、アフィリエイトサービスの開発・運用に関わるチームのメンバーを集めた会議を開き、移行作業がどのように進行するのかを説明しました。
他のメンバーに説明するということは、まず自分が遷移図を正しく理解していなければなりません。今回は関心ごとの多い複雑な遷移図となったため、説明できるようになるまで苦労しました。しかし、この遷移図を説明できるようになったとき、プロジェクトに対する理解がグッと深まったのを憶えています。
学んだこと
今回はクラウド移行の中でも調査と設計に焦点を当てましたが、これだけでも多くの学びがありました。ここでは、その中から3つの重要な学びをご紹介します。
あらゆる角度から情報を集める
プロジェクト当初の私は、現状の構成図を作成するにあたり甘い考えを持っていました。 具体的には、システムの全体図を確認しながら必要に応じてソースコードを読めばすぐに完成するだろうと思っていたのです。
しかし、実際には必要な情報が不足していたり、ソースコードのどの部分を読めば良いのかに迷ったり、さらには設計の意図が分からない部分もありました。
こうした状況で役立ったのが、社内Slackの過去のメッセージから情報を探し出すことでした。ソースコードやサーバから得られない情報が、時には社内での過去のやりとりに転がっていることもあります。あらゆる角度から情報を集めることの大切さを学びました。
作図しながら理解を深めていく
システムには構成図が付きものですが、私はこれまで構成図は設計者が他のエンジニアのために作成するものだと思っていました。
しかし、その構成図がない場合はどうしたら良いでしょうか。 当然ですが自分で作らなければなりません。
このとき、全てを理解してから構成図を作ろうとするのではなく、作図の過程で理解が深まることを学びました。 システム構成図は他者に構成を理解してもらうための図であると同時に、自分自身が理解を深めるためのツールでもあることに気付くことができたのです。
意思決定の理由を残す
システム設計では、後になって設計の意図が分からなくなることがしばしば起こります。これは、当時設計に携わっていた人でさえ忘れてしまうことがあります。
私の所属する部署では、こうした問題が起こらないようにADR (Architectural Decision Record) を書く文化が定着しています。 ADRとは、ソフトウェアの設計に関する意思決定とその理由を記録したドキュメントです。
ADRがあれば、なぜそのような設計をしたのかという背景を残すことができます。 これは、他のエンジニアにとって理解の助けになるのはもちろんのこと、未来の自分が設計の意図を思い出すための備忘録としても機能します。
今回のプロジェクトでも、CloudFrontを選択した理由とその背景をADRに記録しました。 コーディングにおけるコメントのように、システム設計においても意思決定の理由を残すことの大切さを学びました。
まとめ
今回は、新卒1年目としてのクラウド移行での学びについてお話しました。 インフラの作業は影響範囲の広さから責任重大ではありますが、それ以上に学びがあり、サービスを一望できる面白さがあります。
これからも、日々の業務でたくさんの学びと楽しさを見つけていきたいです！
