検索
連載

ナビタイムはコストを半減、「スポットインスタンスを制する者はAWSのコスト最適化を制する」ほぼ月刊AWS(2)(2/2 ページ)

「Amazon EC2」の購入オプションは複雑ですが、うまく使えばコストを大きく引き下げられるとされるのがスポットインスタンスです。ナビタイムジャパンは、これを使ってEC2のコストを半減できたといいます。

Share
Tweet
LINE
Hatena
前のページへ |       

 また、オンデマンドとスポットの組み合わせについては、まずオートスケーリンググループの「オプションのオンデマンドベース」という設定項目で、最初に起動するオンデマンドインスタンスをリザーブドインスタンス購入数と同値に設定。これによって、スケーリング時に必ずリザーブドインスタンスが最初に使われるようにしました。


単一のミックスインスタンスグループにオンデマンドインスタンスとスポットインスタンスを共存、さらにオンデマンドインスタンスとしてリザーブドインスタンスが起動するように設定した(AWS Japan Summit Online 2020におけるナビタイムジャパンによる講演の資料より)

 さらに、ベース数以上のスケーリング時のオンデマンドインスタンスの割合を設定する「オンデマンド割合」という項目はゼロに設定することで、ベース以上は全てスポットインスタンスが起動されるようにしました。

 こうしたオートスケーリングの運用により、乗換NAVITIMEでは、割引のないオンデマンドインスタンスを全廃できたわけではありませんが、従来比で90%以上削減できたといいます。また、リザーブドインスタンスの利用率はおよそ95%を維持できているといいます。


割引なしのオンデマンドインスタンスの利用時間は、90%以上削減できた(AWS Japan Summit Online 2020におけるナビタイムジャパンによる講演の資料より)

 では、乗換NAVITIMEにおけるAmazon EC2のコストは、全インスタンスをオンデマンドで起動した場合に比べてどう変わったのでしょうか。1年間の利用状況で比較すると、約50%の節約が実現したとのことです。

ミックスインスタンスグループにおける5つの問題と要望

 ナビタイムの田中氏は、上記の戦略で遭遇した問題点として、次の5つを挙げています。

 第1に、ミックスインスタンスグループでは、指定したインスタンスタイプの順に、自動的な起動を試みるようになっていますが、リザーブドインスタンスとして購入したインスタンスが起動せず、予定外のオンデマンドインスタンスが立ち上がることがあるとのことです。対策としては、予定外のインスタンスタイプが立ち上がってきた場合、通知を受けてシャットダウンし、希望のインスタンスタイプが起動することを祈って待つというやり方をしているそうです。田中氏は、オンデマンドで起動するインスタンスタイプが指定できるようになってほしいと話しました。

 第2に、スポットインスタンスが起動できないことがあるという点です。これは基本的にはスポットインスタンスの仕様上仕方ないと言え、ナビタイムでも複数のインスタンスタイプを指定することで回避しています。しかし、旧世代のインスタンスタイプはたいてい立ち上がるものの、新世代のインスタンスタイプは起動しないことが多々あるとのことで、もう少しスポットプールを潤沢に用意してほしいと田中氏は話しました。

 第3に、コンバーターなど、中断しては困るプロセスもあるため、割引のないオンデマンドインスタンスを全廃できていない点を、田中氏は指摘しました。こうしたプロセスは、夜間や土日に稼働する必要がないため、リザーブドインスタンスを使うのもコスト効率が悪いといいます。同氏は東京リージョンにも、「Scheduled Reserved Instances」が欲しいと話しました。

 第4に、1年あるいは3年単位のコミットによりインスタンスタイプやサイズ、OS、リージョンなどを問わず割引が得られる「Savings Plans」が活用できないことです。これは問題点というより、ナビタイムではリザーブドインスタンスを活用した運用が確立してしまっているため、メリットが得られないと田中氏は話しました。

 第5に、さらなるコスト最適化のため、ナビタイムではArmベースのインスタンスタイプの利用を進めていますが、ArmとAMDでは仮想インスタンスイメージのAMIが異なり、単一のオートスケーリンググループに共存できず、複数のグループでの運用を余儀なくされているといいます。田中氏は、単一のオートスケーリンググループにおけるこの2つのAMIの共存、あるいはAMIの統一を実現してほしいと話しました。

「capacity optimized」という配分戦略

 スポットインスタンスの価格は上述の通り、スポットプールごとに変動します。スポットプールはアベイラビリティゾーン(AZ)、インスタンスタイプごとに設定されています。

 いずれかのAZのいずれかのインスタンスタイプの空きがなくなると、そのインスタンスタイプは起動できない、あるいは中断するということになります。このため、Auto Scalingで、最も空きが大きいスポットプール(つまり特定AZの特定インスタンスタイプ)にスポットインスタンスを集中配分するポリシーとすれば、中断する(あるいは起動できない)インスタンスの数を最小にできると、AWSの滝口氏は説明しました。

 これは「capacity-optimized」と呼ばれる配分戦略で、AWSマネジメントコンソールでオートスケーリングを設定する場合、「スポット割り当て戦略」に、この配分戦略がデフォルトで選ばれるようになっているとのことです。

Copyright © ITmedia, Inc. All Rights Reserved.

前のページへ |       
[an error occurred while processing this directive]
ページトップに戻る