概要
ほぼ 10 年モノの Perl 製 Web アプリを AWS へ移行し、 1 年ほど近く運用してみたので、ふりかえってみました。
はじめに
どもー、 2017 年もよろしくお願いします。開発エンジニアの @__munepom__ です。概要に書いたことを社内勉強会で発表したので、せっかくだからブログにまとめておきます。
『10年モノ熟成Perlの倒し方』というタイトルですと、某 Hokkaido.pm #13 での別の方の発表タイトルと被りそうでしたので、ほぼ 10 年モノにしておきます。
ほぼ 10 年モノ熟成 Perl を AWS へ移行してみた
コミットログを見る限り、時は 2007 年。私が担当しているフォーカスエリアのウェッブアプリが産声を上げたようです。
(SMP は、複数のモジュールやコンポーネント、アプリケーションが協調して動作するようになっているため、、、
フォーカスエリアという名目で SMP の機能の一部を中心に専門領域を持ちつつ、製品全体を見ています。)
このウェッブアプリなんですが、弊社のデータセンターでまったりと運用されていました。
7 年後
AWS のスケーラビリティを活用して、より多くのリクエストを捌ける状態にしたいなー！
というプロジェクトが始まりました。
2 年後
深淵なる事情により、ようやく AWS への移行が完了しました。
1 年後
RDS 強制アップグレードという試練を乗り越え、今に至るという状況です。
AWS 移行をふりかえってみる
インフラチームとの協業はお早めに！
プロジェクト開始当初は、非同期処理を使いまくるような、夢見る AWS 構成図が描かれていたようです。(私はその頃入社していないので、詳しい事情は unknown)
しかし、深淵なる事情によりプロジェクトは停滞し、、、
結局、移行期間は4ヶ月 (内、インフラエンジニアがまともに協業できるのはラスト2ヶ月) しか無いという状況になりました。
アプリの機能改良もやらねばという中で、 AWS 移行とアーキテクチャ変更の同時進行は無理だろう、ということで、、、
現状の稼働環境でのコンポーネント構成をほぼそのままマルっと EC2 インスタンスで稼働させ、 ELB と RDS を利用するという、よくあるウェッブアプリの構成でやろう！と相成りました。
(テスト環境構築と検証、案外工数かかりますし)
結局、インフラエンジニアがチームに加入してから、一気にベロシティが上がったので、インフラ移行系のプロジェクトでは、インフラチームを早めに巻き込むことが重要です。
データの流れを全て把握しておくこと！
単純にお引越しできれば良いのですが、、、移行したいサービスのデータの流れを全て把握しないと、移行はできません！ (当然か)
既存環境に残るサービスで、移行したいサービス内の設定ファイルを参照したり、 DB を直接参照する輩がいたりで、影響範囲の洗い出しに苦労した記憶が。
曲芸すぎるんだよー！ (この時ばかりは密結合を呪いました)
あと、マイクロサービスの泣き所ですが、サービス停止時の影響範囲は考慮し、クリティカルなものは対処しておきましょう。
EC2 インスタンスタイプ決めで意識しとくと良い事
EC2 インスタンスタイプを決定する際、特に意識した方が良いのは、下記の２点かと。- 1 プロセスの単位時間あたりの処理能力 (これが求まれば、お試しタイプを決められます)
- 強いインスタンスほど、 I/O が強い (金！金！金！)
RDS で意識しとくと良い事
RDS では、下記３点ですかね。- OID が変わるケースがあるため、ソースコードにハードコーディングされている場合は抹殺しておく (稼働前に気付いて良かった)
- Multi A/Z 構成は、速度が若干低下する (稼働率向上のためには、止むなし)
- 強いインスタンスほど、 I/O が強い (金！金！金！)
金！金！金！
EC2, RDS 共に、パワーのあるインスタンスは、お金が結構かかります。
1 年以上運用する事が確定しているなら、リザーブドインスタンスを適用して、コストダウンを図りましょう！
スポットの利用は、 AWS の運用だけに集中する方がいないと、厳しいのではないかと思います。。。
AWS 環境で 1 年近く運用してみて
good! 稼働率が上がった！
SMP は、 3 ヶ月に 1 度停止リリースを行なっていますが、その影響をほとんど受けずに済むようになりました。
AWS 環境は稼働しっぱなしなので、結果的に稼働率は上がりました！
good! 独立してリリースできるようになった！
既存環境だと、複数サービスが同居している環境内で一気にリリースをしなければならなかったので、リリースタイミングが制限されていました。
しかし、独立した環境へ移行したので、リリースタイミングを調整できるようになり、リリース作業が楽になりました。
hmmm... RDS 強制アップグレード、あるよ
運用開始で 1 年も経たず、 RDS のアップグレード通知が来てしまいました。
まあ、こればかりは仕方ないので、 AWS 側で勝手にアップグレードされる前に、こちらで段取り決めて実施しました。
AWS 移行前に影響範囲は洗い出せていたので、落ち着いて対処できました。
リードレプリカがある場合は、事前にアップグレードしておきましょう！
やっとかないと、アップグレードできません！
ほぼ 10 年モノ熟成 Perl を Docker 化してみた
現在進行中です。
これを完遂できれば、リリースがさらに楽になるだけでなく、、、
Perl や CPAN モジュールのバージョンアップが簡単にできるようになり、変化に強いアプリへと進化するはずです。
変化に強くしておけば、いずれ別言語での実装もやりやすくなるでしょうし。
変化に強くしておけば、いずれ別言語での実装もやりやすくなるでしょうし。
Coming soon!!!
さいごに
あ、今週末の YAPC::Kansai は遊びに行きます！よろしくお願いしまーす！
(YAPC::Kansai で話してみたいと思っていましたが、トークに応募するのをすっかり忘れていたというオチ。。。)
(YAPC::Kansai で話してみたいと思っていましたが、トークに応募するのをすっかり忘れていたというオチ。。。)
Enjoy!!!
