ほぼ 10 年モノ熟成 Perl の倒し方 (AWS 移行編)

このエントリーをはてなブックマークに追加

概要

ほぼ 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 インスタンスタイプを決定する際、特に意識した方が良いのは、下記の2点かと。

  • 1 プロセスの単位時間あたりの処理能力 (これが求まれば、お試しタイプを決められます)
  • 強いインスタンスほど、 I/O が強い (金!金!金!)


RDS で意識しとくと良い事

RDS では、下記3点ですかね。

  • 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 で話してみたいと思っていましたが、トークに応募するのをすっかり忘れていたというオチ。。。)

Enjoy!!!
新しい記事
前の記事
Next Post »
Related Posts Plugin for WordPress, Blogger...