オンプレサーバ60インスンタンスをaws移行で3インスンタンスに圧縮したときにハマった3つのこと

オンプレサーバ60インスンタンスをaws移行で3インスンタンスに圧縮したときにハマった3つのこと:

はじめに

この記事は

「DeNAその2 Advent Calendar 2018」

23日目の記事です。

先日弊社からこのような記事が公開されました。
https://fullswing.dena.com/archives/2638

こちらの先陣として私のチームの開発サーバをオンプレからAWS(EC2)に移行したときのお話です。

※用語説明
環境 = 主要なJenkinsJobやアプリサーバが動作する汎用開発環境の単位

オンプレ使用状況

openstack上の仮想マシン

スペック: cpu:8core mem:12GB storage:200GB

インスンタンス数: 60

1インスンタンスあたりの環境: 2

環境の合計: 120環境

aws使用状況

Amazon EC2

インスタンスタイプ: c4.8xlarge

スペック: cpu:36 mem:60GB storage:2.5TB

EBS: 1つ (諸事情によりルートは別EBS)

インスンタンス数: 3

1インスンタンスあたりの環境: 40

環境の合計: 120環境

60インスンタンスを3インスンタンスに圧縮するメリデメ

圧縮するメリット

• コストを下げることが可能
  
  
  • サーバリソースの遊びが少なくなるため、その分のコストが浮きます
• 管理が楽になる

圧縮するデメリット

• インスタンスが1つ落ちたときの影響が大きい
• 工数がそこそこかかった (実績は1人月程度)
  
  
  • 昔からの負の遺産の改善やコミュニケーションも込み

ハマった３つのこと

1インスタンスの同居環境数を 2 => 40 に対応させようとしたときにハマりました。

ポートがバッティング

インスタンス数圧縮行うには、理論上1インスタンスにどれだけの環境を詰め込めるのか知る必要がありました。

試してみると、ポートの設計で最大10環境、スクリプト類で最大9環境、proxy(nginx)の設定で最大15環境まで対応していることがわかりました。

この環境数ではコスパが良くないので、これを40環境まで対応する改修を行いました。

ポートの設計 => バッティングしないように再設計

スクリプト類 => 環境名(例aaa01)の下一桁でアクセスポートを決めていた部分を二桁に対応

proxy => 管轄がインフラだったので依頼して40環境分アクセスできるように変更

サーバリソースが足りない (memory / cpu / io)

なにも考えずに c4.8xlarge で40環境を一斉にアクティブな状態にすると、
必要メモリは120GB以上
cpuは100%に張り付いてsshの応答すら返さない
iowaitでまくり
load average 200以上

でまともに使用できませんでした。

スペックを上げるとコストが・・・となります。

リソースをバカ食いしているのは plackのworkerが世代交代する時の処理 だったので、worker自体の起動タイミングをチューニングしました。

各環境はすべてを毎日使っているわけではなく、120環境中平均して40環境ほどデイリーで使われていました。

なので、夜中に全workerをcronでstopし、朝の作業開始時に必ず実行するであろうJenkinsJobでworkerをstartさせるようにしました。

これにより、その日使われる環境分だけリソースを消費するようにできました。
c4.8xlarge x ebs1つ で20環境は同時に捌ける想定なので、3インスンタンスあれば賄えました。

スポットインスタンスが不安定

普通のオンデマンドインスンタンスに比べて スポットインスタンス だと、コストを最大1/4程度に抑えることができます。

もちろんデメリットはあって、
急にインスンタンス中断する(落ちる)可能性がある
インスンタンスタイプ/リージョン/az によって中断割合が違う
中断の頻度「<5%、5～10%」と言われてもなんだかよくわらない

と、コストが低いだけの扱いづらさがありますが、コスト削減効果は大きいので利用することにしました。

そんな中選んだいい塩梅のインスンタンスタイプが、 c4.8xlarge です。

※選んだ当時は <5% だったはずなんですが、いまは 5～10% と少し落ちやすくなっています。

現状の運用では 1~2週間に1インスンタンス程度のペースでランダムな時間帯に瞬断されます。

落ちにくいインスタンスタイプは他にもあるのですが、今回必要なスペックで絞るとなかなかいいものがなくて最終的にはここに落ち着いています。

瞬断の対応としては、spotがダウンする通知をメールで受けたり、regeonやazを各インスタンスでバラけさせたり、落ちた実績のあるazは使用しないようにしています。

今後この瞬断の影響が大きいようなら、一時的に同スペックのオンデマンドに切り替えてからゆっくり対応を考えようと思っています。

さいごに : EC2以外のawsサービスは使わないの？

コンテナ技術などの選択肢はなかったのか？ という質問をよく受けるのでそちらに答えておくと、

60インスタンスという規模の移行には影響する人も多く、移動は必須、期限もあって、これのための工数は確保されていない、という状況での対応だったので、最小工数で行うためにできるだけ同じ状態で移行させたいという意図がありました。

オンプレの開発サーバは私のチームはこれ以外にもあって、それらを移行するときに他のawsサービスも検討していくつもりです。