SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

DeveloperZine(デベロッパージン)- エンジニアの意思決定を支える技術情報メディア ProductZine

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

大規模解析サービスを支えるGCP活用事例

大規模サービスにおけるオートスケーリングを構成する上で考慮すべきポイント

大規模解析サービスを支えるGCP活用事例 第4回

GCPでオートスケーリングを実現する

 さきほどのポイントを、GCPでどのように実現するか説明します。サーバのステートレス化についてGCP固有の対応は不要なのでここでは追加で説明はしません。

 GCPではオートスケーリングの機能はマネージドインスタンスグループの一機能の「オートスケーラ」として標準で用意されているので、これを利用します。

 マネージドインスタンスグループはステートレスなアプリケーションが稼働するインスタンスの管理機能で「オートスケーラ」の他に、異常なインスタンスを自動修復する機能も持っています。

コンピュータリソース不足の回避

 GCEはオンデマンドでコンピュータリソースを提供してくれるクラウドサービスですが、無制限にリソースが利用できるわけではありません。

 プロジェクトやリージョンごとにリソースの上限値が設けられており、その上限に達してしまうとGCEインスタンスが全く起動しなくなってしまいます。

 GCPではリソースの上限と使用量は管理画面やAPIで確認ができ、ある程度までであれば上限緩和を依頼できるので、これによりリソース不足は回避することができます。

 それでも上限に達してしまう場合は、別のリージョンでインスタンスを起動などによってリソース不足を考える必要があります。

適切なスケーリングポリシーの設定

 「オートスケーラ」は以下の特徴をもっています。

  • スケーリングポリシーを選択し、それぞれのポリシーに対して目標使用率レベルを設定することでその値に近づくように自動的にインスタンス数を増減させる
  • 必要以上のリソースの追加/削除を回避するため、使用率データの解釈時、追加/削除インスタンス数の判断時に、値を切り上げまたは切り捨てることによって常に控え目に動作する
  • CPU使用率が50%を超えた時にインスタンスを1台増やすというような細かいスケーリングの設定はできない

 また、「オートスケーラ」に設定できるスケーリングポリシーは4種類存在します。

  • CPU使用率
    • マネジメントインスタンスグループのCPU使用率の平均値を用いる
  • HTTP(S)負荷分散処理能力
    • HTTP(S) Load Balancingを利用している場合に利用可能
    • マネジメントインスタンスグループ全体、もしくは1インスタンスの1秒間あたりのHTTPリクエスト数(RPS)を用いる
  • Stackdriver Monitoringの指標
    • 標準指標もしくは、ベータ版であるカスタム指標を用いる
    • 標準指標はStackdriver側であらかじめ用意されている指標
    • カスタム指標はAPIを使って自分で登録する指標
    • カスタム指標は将来的に追加でコストがかかる可能性が高い
  • キューベースのワークロード
    • Cloud Pub/Subのワークロードを用いる
    • アルファ版の機能であり、プロダクションで使うことは推奨されていない

 スケーリングポリシーは複数組み合わせることもでき、複数のポリシーが定義されている場合は、1番多くのインスタンス数を要求するポリシーが適用されることになります。

 GCPでオートスケーリングを構成する際には、これらのポリシーをサーバの特性に合わせて選択することになります。

起動時間の短縮

 起動時間は、以下の2つの時間に分解することができます。

  1. GCEインスタンスの起動時間
  2. スタートアップスクリプト[1]の完了時間(アプリケーション起動時間)

 1.はあまりカスタマイズの余地がないですが、2.は工夫次第で大きく短縮することができます。

 2.で一番有効なのは、マシンイメージを自分で作成できるカスタムイメージの機能を利用することです。時間のかかる処理、例えばパッケージのダウンロード/アプリケーションのインストールなどをできる限りカスタムイメージに組み込むことで、スタートアップスクリプトの処理を削減することができ、2.の時間が短縮が期待できます。

[1] GCEではインスタンス起動後の処理をスタートアップスクリプトという形で記述することができます。

安全な停止

 安全な停止を実現するためには、停止前処理の時間を設けることがポイントになります。

 解析サーバであれば、アプリケーションプロセスが終了のシグナルを受け取ると新規の解析処理を実行しないようにし、一定時間待機するようにすれば実現可能です。

 Webサーバであれば、接続ドレインというHTTP(S) LoadBalancingの一機能を使うことでユーザーセッションを正常に終了することができます。

 接続ドレインはインスタンス停止時に新しい接続の確立を防ぎつつ、設定したタイムアウト時間が経過するまでセッションは維持してくれる機能です。

 また、GCPにはインスタンス停止前にスクリプトを実行してくれる、シャットダウンスクリプトという機能が存在するのでこちらを上手く組み合わせるといいかもしれません。

次のページ
KARTEでのオートスケーリング構成例

この記事は参考になりましたか?

大規模解析サービスを支えるGCP活用事例連載記事一覧

もっと読む

この記事の著者

竹村尚彦(株式会社プレイド)(タケムラ ナオヒコ)

 株式会社プレイド エンジニア 2014年からプレイドで、インフラを中心にKARTEの裏側を全般的に担当。 プレイド入社前はNECにてクラウドサービスの立ち上げにエンジニアとして従事。 2011年、同志社大学工学部を卒業。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

CodeZine(コードジン)
https://codezine.jp/article/detail/10522 2018/01/11 14:00

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー