おはようございます。レアジョブDevOpsチームのshinoです。
世間では消費税増税だとか軽減税率だとか話題になっています。
特に軽減税率は複雑ですよね。
私は考えることをやめました。
さて、私は普段AWS上でレアジョブのシステム基盤に関わる業務を行っています。
↓AWSに移行した話
現在は、運用コストの削減、信頼性の向上、パフォーマンス効率の向上などの改善を主に行っています。
AWS上でアーキテクチャの設計や運用を考える際には、どのような点に気をつける必要があるのでしょうか？(突然の問題提起)
AWS上での設計や運用に関するベストプラクティスをまとめたAWS Well-Architected Frameworkなるものもありますが、こちらは非常に概念概念していて
「具体的にどうすれば？」
となる方も多いと思います。僕はなります。
今回はAWS上でのパフォーマンス効率化、特にEC2 Auto Scalingを導入する際にポイントとなることを言語化したいと思います。
EC2 Auto Scalingとは
Doc: EC2 Auto Scaling
端的に言えば
EC2インスタンス を
リソースの使用状況に合わせて
自動で水平スケールする
サービスです。
他にも手動でのスケールやスケジュールベースのスケールもできますが、Auto Scalingを使う一番の恩恵は需要に合わせて自動スケールする機能だと思います。
すごく素敵なサービスに思えますが、無条件でAuto Scalingを導入できるわけではありません。
EC2 Auto Scalingを導入するためにポイントとなるアーキテクチャ設計があります。
EC2 Auto Scailing導入のポイント
既存のEC2クラスターにAuto Scalingを導入する際に気をつけることが大きく2つあります。
インスタンス間の差異を無くす
どういうことかというと
AとBで設定に差があったらだめ、ということです。
・・・当たり前といえば当たり前なんですが。
例えばAはスレーブDB1を、BはスレーブDB2を直接参照しているような設定になっているとAuto Scalingできません。
自動で起動終了されるインスタンスは同じAMIから作られるので、同じクラスター内の既存のインスタンス間で差異がある場合は、差異がなくてもアプリケーションとして正常になるように改善する必要があります。
逆に言えば、アプリケーションの動作に関係ないcronが特定のインスタンスで動いていてそのインスタンスは消したくない、などという状況であればインスタンス間の差異があってもAuto Scalingの導入はできます。
その場合は、インスタンス保護を用いたり、Auto Scalingのインスタンス終了設定の「新しいものから消す」という設定と、最低起動台数の設定を組み合わせることで、既存のインスタンスを終了させずに保つことができます。
スケーラビリティを獲得するためにインスタンスをステートレスにしましょう。
クラスターごとにエンドポイントを設ける
ELBを使ってクラスターを形成していたらエンドポイントが既にあるはずなので、これも当たり前のように思えます。
ここで大事なのは、スケーラビリティを獲得するために意識的にエンドポイントを作る必要があるということです。
例えば、APIがスレーブDBを参照する場合を考えます。
この場合、スレーブDBのエンドポイントを設けていれば全てのAPIインスタンスはそのエンドポイントを参照すればいいので、APIインスタンス間で設定に差異は生まれません。
しかし、エンドポイントを設けていない場合、特定のDBインスタンスを参照することになります。
APIインスタンスごとに特定のスレーブDBを指定するような設定を行えば、APIインスタンス間に差異が生まれ、Auto Scalingを適用することができなくなります。
また、一般的に、エンドポイントという抽象的なものに比べて、特定のDBインスタンスという具体的なものの方が変更の影響を受けやすいです。
つまり、変更される可能性が高いものに依存するということは、それだけ依存する側も変更を加える必要があります。
スレーブDBの台数を増やす場合などを考えると運用コスト的にもつらいことが想像できると思います。
Auto Scalingを用いることでインスタンスが勝手に増えて勝手に減るので、その変化の影響を受けない疎結合な依存関係を作る必要があるということです。
クラスター間の依存関係を作る際は、より抽象的なもの＝エンドポイントに依存させることで、ステートレスな変更容易性を獲得し、疎結合なアーキテクチャを実現させましょう。
あとがき
今回はEC2 Auto Scalingの導入に関して、アーキテクチャに必要なことをざっくり言語化しました。
導入する際は、どのAMIを使うか、どんなメトリクスをどんな閾値でトリガーとするかなどまだ考えなければいけないことはありますが、それはまたの機会に。
我々はこれからもAWS上での設計・運用のベストプラクティスを目指して邁進して参ります。
そんなチャレンジを一緒にして頂ける仲間を募集しております！
