この記事は アイスタイル Advent Calendar 2024 10日目 の記事です。
はじめに
アイスタイルでWebアプリケーションエンジニアをやってます、itohisです。
ふと気がついたんですが、昨年もアドカレ10日目に執筆をしていました。今年もよろしくお願いします。
私は今年もクラウド移行業務に関わる事が多くありました。
今回はそんな中でWEBアプリケーションをオンプレミスからクラウドへ移行リリースするにあたり、他チームの助けを借りて相談・準備をしておいて良かったお話をします。
クラウド移行はわからないことだらけ🌩️
アイスタイルでは段階的にクラウド移行を進めていて、アプリケーションエンジニアが比較的広い範囲に責任を持ってクラウドリソースを構築します。 特別にAWSのスキルが高くなくても、皆「やったるで！」の精神で開発を進めるため、ぶっちゃけると本当にわからないことも多いです。
今回の私の担当はフロントエンドアプリケーション、つまり＠cosmeユーザーが利用する、とある画面を表示するシステムのクラウド移行でした。
このシステムはリクエスト経路上にオンプレミスのネットワークを経由していて、AWS Direct Connectというオンプレとクラウドをつなぐ専用線の利用が必要になることがわかりました。
組織内では既にDirectConnect利用の実績があり、契約している帯域制限があります。
この帯域制限により、クラウド移行リリースのタイミングで通信量が急増して通信量が上限に達し、通信ができなくなってしまう恐れがありました。
もし通信ができなくなれば、他のシステムにも大きく甚大な影響が出ると考えられます。
さて、こうなればリリース前に通信量増加の予測しておきリスクを回避したいですが、
通信量の監視方法がまったくわからない！
困ったなあ、という所でしたが幸いにもアイスタイルにはクラウド領域に特化したサポートチームが存在するので、今回はここに頼りつつ解決することにしました。
知らないことは知っている人たちに相談しよう👂️
私は一人で長時間悩みがちなのが悪いところですが、本当に相談してよかったです。
やはり、専門外の部分は専門家に相談してみるべきでした。
相談の結果、リリース前のクラウドリソースに通信量の負荷をかけて計測し、通話しながら同時監視していただけることになりました。
あまり具体イメージがつかないかもしれないので、例を紹介します。
以下のような形で計測しました。
実際にユーザーからのアクセスされた場合と同等、もしくはそれ以上負荷シナリオを作成します。
これをJMeterなどの負荷試験ツールで一定時間継続してリクエストする形で負荷を掛け続けます。
◆ 計算例
秒間リクエスト数 × 1Reqeustあたりの通信量 × 通る回数 x 8(ビット換算)
例）10 × 200KB x 2回 x 8 = 通信量は 32Mbps
- 通信量はSSR(サーバーサイドレンダリング)されたレスポンス容量から計算、リクエスト容量は軽微なので無視
- 通信量計算はビットで取り扱うのでバイトから換算します
- 「通る回数」は、オンプレ⇔クラウド間を往復するのは1度ではなかったので、その回数
以上の点などを考慮しながら、複数パターンを想定しました。
1シナリオにつき短くても600秒(10分)などの時間がおすすめです。(理由は後述)
サポートしてもらって判明したこと💡
実際に試験を行うと、きれいな予想通りの通信使用量グラフが出ました。
「これだけやれば安心かな」と私もサポートチームも納得のいく形に落ち着きました。
※監視はNewrelicによって行っています
実際の通信量は伏せますが、10分間 × 4度のシナリオを実施し、4つの山ができています。
予想通りの結果が得られました。
結果だけでなく専門チームと通話しながら進めることで以下のようなことがわかりました。
通信量の監視方法を教えてもらった
私が問い合わせた段階で、実は通信量を監視するダッシュボードの用意がありました。
どうしましょう...と相談したら「実はそれ見れるようになってますよ」っと教えてもらいました。
調べることも大事ですが、専門化にまず聞いてみるというのも場合によっては有効です。
帯域制限は上りと下りと別の回線制限がある
帯域制限と聞いて、私は勝手に上り下りの容量の合算だと思い込んでいました。
自宅のネット回線と同様に上り下りがあり、それぞれの制限が独立していて試算より余裕があることがわかりました。
よくよく考えたら当然でしたが、相談しなかったら試算を見誤るところでした。
試験実施時間は長いほうが良い(10分以上)
監視ツールではリアルタイムに通信量のメトリクスが監視できますが、表示まで5分程度のラグがありました。
これを前提に進行するのが重要で、10分以上の実行で、かつインターバルも5分程度設けます。
これで非常に監視がわかりやすくなりました。
実は試験1回目はスムーズに進行せず、2回目の実施でグラフのようなきれいな結果が測定できました。
この結果を元に安心してリリースに挑むことができました。
リリース後の通信量も概ね負荷試験通りの結果となりました。
相談のすすめ🤝
他者と相談することで一人では気づかない懸念点や新しい工夫が見つかります。
私は 「三人寄れば文殊の知恵」 という言葉が好きなのですが、まさにこれだと感じました。
わからないことにチャンレジすることも重要ですが、時には他者を頼ることで解決する課題もあります。
「話すの億劫だけど、俺も相談してみよっかな～...」という方の助けの一歩になれば嬉しいです！
本日の記事は以上となります。
引き続き アイスタイル アドベントカレンダー 2024 をお楽しみください！