新卒3ヶ月の僕が自社サービスのインフラを移行した話② ~移行編~

こんにちは
taskey Railsエンジニアの田代です。作っているもの

peep [ピープ] - チャット小説オリジナル作品1000本以上/毎日更新！

この記事は「新卒3ヶ月の僕が自社サービスのインフラを移行した話① ~勉学編~」の続き、移行編です。AWSのロードマップがほしいなという方は前編をご閲覧下さい。

移行の前準備、負荷テスト、移行時の手順等を書かせていただきました。こちらだけでも完結出来るように心がけております。

対象者: Rails(Puma) on ECSでの起動タイプFargateを検討しているエンジニア、負荷試験を検討している皆様

Fargate移行時のrequest数遷移の様子

そもそもECS起動タイプFargateって何がいいの？

起動タイプがEC2ですと、コンテナを動かす大元がEC2になってしまう為、サーバを横並びにする時に毎回インスタンスを増やしておかなければなりません。これが意外と手間で、大方のサービスは時間帯によってRequest数が変わるので、ピーク時のサーバ数を維持しておかなければいけません。AutoScalingなんて有って無いようなものです。「CIとかでCLIで時間帯によって増やせばええやん」となるかもしれませんが、実装コスト的にはあまり現実的ではありません。

そこで、Fargateです。Fargateはコンテナを動かすリソースがEC2インスタンスでは無いため、インスタンスの準備をする必要がありません。ですのでタスク毎にリソースが割り振られ、EC2ではなし得ない自由なAutoScaleを可能としてくれます。(AWSへスタンディングオベーション)

引用元: https://aws.amazon.com/jp/blogs/news/aws-fargate-a-product-overview/

Fargateは去年の後半に日本へ上陸、今年の初めに値下げもされました。まだEC2に比べ多少割高ではあるのですが、AutoScaleが可能なので結果的には安上がり！！これぞクラウドの為せる技ですね。すごい。(※Fargateは今後更に使いやすく、安くなっていくと思います。)

サーバ移行ロードマップ

弊社技術顧問 + CTO と話し合いながら下記手順で行うこととなりました。

1. 想定構成パターンの洗い出し
2. 各想定構成パターン + 現行パターンでの負荷試験の実施 
3. 負荷試験実施結果を元に移行後の設計決定
4. 各環境毎の移行 & いらないモノの削除

※想定構成: 今回セキュリティ面等の洗い出しも行った為、各トレードオフの洗い出しをする必要があった

今回の移行では各設定項目や構成の最適化も行うため特に負荷試験には特に重きを置きました。
実際には手戻りも発生したので「1. 負荷試験 & 最適化」,「2. 移行してみた」でまとめさせて頂きました。

1. 負荷試験 & 最適化

[想定構成パターン洗い出し]

▪ワーカー数とスレッド数(数の比較)
▪サブネット構成(Public？Private？)
▪セキュリティ構成(nat？bastion？)
▪CPU、メモリ、メモリソフト制限(ソフト制限て何？？CPUとメモリはどれくらいがいいの？)

ズラズラ並べました。大方ここらへんがチューニング項目だと思います。
考えることが多い 。。つらい。。知見もない。。。

[負荷試験]
今回の負荷試験ではloader.ioを使用しました。
負荷試験ツール選定のポイントとしては直感的なわかりやすさ、課金をすれば大方自由な時間、Client数でのRequestが出来るという点でした。

Application Load Testing Tools for API Endpoints with loader.io

上記項目をすべて網羅することはなかなか難しく、下記項目を特に試験していくことにしました。

▪1thread VS 5thread 
▪1worker VS 2worker VS 6worker
▪アプリケーションサブネットとALBサブネット別または同じ
▪nat有無
▪Fargate VS EC2

順に進めていくと徐々にツボが抑えられていくので、最適解を探すマップには良いと思います。

また「Fargate VS EC2」では移行後の現行と同等スペックを探すことになります。ですので、ユーザストーリを作った上での試験が望ましいです。
それ以外は1つのRequest setでの比較で問題ないと思います。

負荷試験のコツとして

1. 軽めの負荷をかけて平均レスポンスを記録する
2. ギリギリまで責めれるRequest数とその時のAvg responsを記録する

この手順をセクション毎にまとめていき、都度振り返り、予想を立てていくと負荷試験は進めやすいです。

[負荷試験結果からトレードオフの検討、最適化]

今回負荷試験結果より下記項目がわかりました。

▪ワーカは多めが良い(CPU x 1.5くらいが丁度いい)
▪サブネットを分けると性能がやや落ちる
▪メモリは大体余るのでCPU優先が良い
▪1worker辺り512MB(多めではある)で合計メモリを設定すると良い
▪ソフト制限はメモリの3/4位が丁度いい
▪FargateはEC2に比べ若干性能が落ちる

細かい数値は出せないのですがとても良い知見が貯まりました。
予想はしていたものの実際に経験してみるのはやはり血肉になります。

特に驚いたのが、下記項目です。

▪ サブネットを分けてセキュリティを上げた場合Responsが落ちる場合がある。
▪ AWSの基本的なインスタンスやFargateの場合、6workerだとメモリが基本的に余るのでメモリの心配はあまりいらない。
▪ FargateはEC2に比べ若干性能が落ちたが、少しの横並びで解決するし今後のFargate展開を考えたらすぐに良くなる気がする。

今回の負荷試験では結果を弊社AWSのアドバイザーに見せながら諸々の検討、さらにCTOと技術顧問と相談しつつ移行後の設定を決めていきました。

ちなみに負荷試験中にはFargateの強みでもあるAutoScalingの設定も実際に触りながら確認を行いました。

2. 移行してみた

[移行手順]

1. dev環境で実際に移行を行いながら手順書の作成
2. 手順書を元にdev環境でもう1つ移行して手順書のチェック(CTO)
3. dev環境のEC2時に使用していた残骸の削除
4. 手順書を元にstaging環境の移行
5. staging環境のEC2時に使用していた残骸の削除
6. 手順書を元にproduction環境の構築
7. production環境ドメインのALB向き先を切り替え
8. staging環境のEC2時に使用していた残骸の削除

弊社ではdev, staging, productionと3つの環境が整っている為、上記の様な手順を踏まえました。また移行環境を新規サブネットで作成することにより、現段階のインフラの整理まで行うことが出来ました。
ただ1点、staging環境のみDBのサブネットの構成が違っており、そこは多少躓きました。理想と現実って感じでした。
残骸の削除は特に気持ちよかったです。EC2インスタンスがすっかり無くなったり、よく分からなかったSG等を整理出来たのは大きいと思います。

今回のサーバ移行ではサービス停止もなく無事完了することが出来、一安心です。

3. 今後

今回の経験でインフラの知見が大分貯まりました。なんでもやってみるもんだなぁと思いました。

移行は一息付きましたがFargateの強みであるAutoScalingでの弊社最適解に関してはまだ見つかっておりません。

今後、実際にAutoScalingでの運用をしてみてEC2の時との比較とかも書けたらいいなと思っております。タスク数が二ョロニョロ遷移していくのを眺めながらお酒を飲むのが楽しみです。(浮いたAWSの料金でCTOにお酒おごって貰いたい)

CM

[募集]

[主催コミュニティ]

平成.rb

[ドラム叩いてるバンド]