はじめに
こんにちは！インフラチームの高畑です！
ついに夏到来で遊びたい気持ちを必死に抑え込みつつ日々活動をしている私ですが、皆さんはいかがお過ごしでしょうか。
今回はウィルゲートのメディアサービスをとあるパブリッククラウドから AWS に移行した際の出来事をブログに書き綴ろうと思います！
これまでのメディアサービス
これまでのメディアサービスはとあるパブリッククラウドで運用を行なってきたため、サーバ負荷増加などの影響でスケールアウト、スケールアップをしようにも多少手間と時間がかかっていました。
また、WAF として SiteGuard Lite を利用していたのですが、設定が非常に複雑かつ管理が大変だったりという問題もありました。 DoS 攻撃に対する防御も過去に Norikra を利用して行なうようにしたのですが、別途 Norikra 専用サーバを用意して運用を行なっていたためサーバ費用や運用コストが若干なりとかかっている状態になっていました。
AWS に移行するメリット
これらのメディアサービスを AWS に移行することにより、
- AMI からスケールアウトなど素早く手軽にできる
- AWS WAF による手軽な WAF 環境構築
- AWS Shield Standard の自動 DDoS ブロック
- 社内の AWS ナレッジを横展開で持っていける
- Terraform などの IaC コードを流用できる
- マネージドサービスを利用することによりセキュリティアップデートなどある程度 AWS 側でやってくれる
などのメリットを享受することができます。
AWS に移行するために行ったこと
負荷試験の実施
ホスティング先を変更するにあたり、ちょうど良い機会でもあったため負荷試験を実施しました。 今回負荷試験を行うにあたり、 Gatling という負荷試験ツールを利用しました。 シナリオの作成を GUI から行うことができ、レポートがリッチな感じでとても見やすく非常に便利なツールでした。
最初は数人が同時にログインした状態からスタートして徐々に接続を増やしていく想定で負荷試験を行い、想定したアクセス数を捌けるようにサーバの構成を見直していきました。
負荷試験に関する詳細は後日別の記事で紹介する予定です。
IaC の刷新
これまでのパブリッククラウドでは Terraform でインフラ環境を管理するのではなく、コントロールパネル上から手動で管理していた状態でしたので、これを機に Terraform のコード化を行いました。 これにより、これまでの IaC に対するナレッジを横展開することができるだけではなく、コード管理されていることやレビューが出来ることへの安心感を持つことができました。
ウィルゲートでは、 IaC（ Terraform、Ansible ）に関する社内ガイドラインを制定しており、これに沿うような形でコード化していっています。
また、Terraform だけではなく Ansible のコードも刷新しました。 これまではメディアサービスそれぞれでリポジトリを作成し独自の設定を突っ込んでいたのですが、先日 Ansible のコードを共通化したためそちらに統合させることにしました。
↓ Ansible のコードを共通化した話は下記を参照 tech.willgate.co.jp
ほぼほぼ作り直しになるため、既存のコードの見直しも一緒に行なっていきました。 インフラチーム内でコードレビューをしつつ、アプリケーション側と認識をすり合わせながら作っていったため若干時間はかかったものの無事作り上げることができました。
移行時に起こった問題
実際に AWS 環境に移行をしてみて下記のような問題が勃発しました。
RDS のコネクション数が瞬間的に飛び抜ける
元々の環境では捌いていたクエリが AWS の RDS に移行してからというもの軒並み捌ききれなくなり、コネクションが瞬間的に上がるという問題に直面しました。
というのも、元々の環境では自前で DB サーバを構築してゴリゴリのチューニングを行なっていたため、重いクエリもある程度は捌いていた状態でした。 それに引き換え、AWS の RDS は設定したインスタンスタイプに応じて自動計算されたパラメータ（ innodb_buffer_pool_size など ）がセットされるようになっています。 そのため、元々捌けていたクエリが RDS にした途端に捌けなくなり、結果的に詰まるといった自体に陥りました。
事前に負荷試験を行なった上での移行作業だったのですが、このような状況になってしまいちょっと悲しい気持ちになったのは秘密です。
今回に関してはあまり時間もなかったため、EC2 で DB サーバを用意してレプリケーションを組むことで対応をしたのですが、近いうちに RDS へ移行していきたいと考えています。
メンテナンス明けのキャッシュない問題
メディアサービスで重要となってくる画像ですが、ウィルゲートでは CDN を利用して配信を行なっています。
ホスティング先が変わるにあたり CDN の画像キャッシュを一度削除したため、メンテナンスが明けてから画像配信サーバ（オリジンサーバ）の負荷が上昇するようになっていました。 メンテナンスを明ける前にある程度サーバを温めてはいたのですが、それでもキャッシュできていないページが結構あったために起きた問題です。
これに関しては一旦CDN キャッシュが出来るまで画像配信サーバをスケールアウトして対応を行いました。
また、API のレスポンスを Redis にキャッシュさせているのですが、メンテナンス期間中にキャッシュの有効期限が切れたために急激に API サーバへアクセスが流れて DB が詰まるなどの問題も発生してキャッシュの重要性を再確認させられる事態となりました。
切り戻しが発生した
これまでに挙げた問題に加えて他にも細かい問題が頻発していたため、一度元々の環境に戻すといった作業が発生しました。 切り戻しを行い、問題点を全て洗い出して対応した後に再度切り替えのメンテナンスを実施するといった形となり、アプリケーション側にも協力をしてもらいつつ進めていきました。
結果的に無事切り替えが完了したので今はホッとしていますが、流石にこの時はお豆腐メンタルになりましたね。
移行プロジェクトが終わってみて
ここまでに約 2 ヶ月ほどかけて移行をしていたのですが、現在動いている環境を移行することは、新規で構築するよりも遥かに難しいということを思い知らされました。 ホスティング先ごとの仕様の理解などまだまだ足りていないなと痛感しています。
また、今回の移行に関してインフラチーム内で KPT を実施しました。 RDS 周りの話や機能要件の確認が甘かったなどの Probrem が多く、今後どんどん改善できたら良いなと思っています。
今では Prometheus + Grafana で逐一モニタリングを行いながら、日々パフォーマンスの改善を行なっています。
まだまだ課題が山積みなので、これからゆっくりと着実に改善していきます。
おわりに
今回、結構大きな移行プロジェクトを行なってみて、やはり移行は考えることが多くすんなりとはうまくいかないもんだと痛感しました。 やり残したことや、一旦で対応してしまった部分も多いので、今後改善していければと思っています。
