views4GCPのストレージサービスについてまとめてみた。Exp:47127ニチアサ好きの本サイト管理マン。TweetShareHatena注意この記事は2014年3月25日に更新されたもので、内容が古い可能性がありますのでご注意ください。Modulesの簡単なサンプルを配備し、動作を確認しました。今回は、それぞれのModulesごとにScalingの設定を行い、動作を確認してみたいと思います。GAEでScalingといえば、リクエスト量や処理量に応じて自動でやってくれるというイメージですが、Modulesのリリースにより、設定でそのスケーリングのルールを設定できるようになりました。新登場したのは、Manual-ScalingとBasic-Scalingです。それぞれのaumatic-scalingとの違いは次の通りです。HTTPリクエストは60秒。すべてのリクエストは無期限に動作します。manual-scaling設定のインスタンスは、インスタンスの開始に/_ah/startを選択することができます。HTTPレスポンスコードを返すことなく、数時間に及ぶプログラムやスクリプトを実行することができます。classから選択して設定が可能。classから選択して設定が可能。classから選択して設定が可能。インスタンスはメモリーをベースとした使用状況により解放されます。インスタンスはメモリーに残り、状態はリクエスト間で保存されます。インスタンスが再起動したとき、/_ah/stopリクエストがログに出現します。methodが登録されていた場合、インスタンスが実際に停止する前にそれを完了するための30秒間の猶予を持ちます。インスタンスはidle_timeoutパラメータをもとに解放されます。インスタンスがアイドル状態で、idle_timeoutより長い時間リクエストを受け取っていなければ、インスタンスが解放されます。インスタンスはリクエストによってオンデマンドで生成され、アイドル状態の間は自動で停止します。インスタンスの/_ah/start宛の空のGETリクエストがAppEngineによって自動で送られます。ConsoleUIからての停止)によって停止されたインスタンスは強制的に停止するまえに実行中のリクエストを終わらせるための30秒の猶予を持ちます。インスタンスはリクエストによってオンデマンドで生成され、idle_timeout設定を基にしたアイドル状態になると自動で停止します。ConsoleUIからての停止)によって停止されたインスタンスは強制的に停止するまえに実行中のリクエストを終わらせるための30秒の猶予を持ちます。インスタンスは次のようにURLで割り当てることができる。mappingを行いたい場合にも、モジュールやそのインスタンスにURLを割り当てられる。requestにより取得できる。manual-scalingに同じ。Engineは処理量に応じてインスタンスの数を自動的にスケールする。このスケーリングの根拠はモジュールバージョンに対応する形でアップロードされた設定ファイルのautomatic-scalingです。モジュール内の設定ファイルを使って、それぞれのモジュールバージョンごとにインスタンスの数を設定できる。インスタンスの数は一般的にメモリに展開されているデータセットの数や要求されるオフライン作業のためのスループットに合わせる。scalingなモジュールバージョンは最大のインスタンス数をbasic_scalingのmax_instancesパラメータを使うことで設定できる。動作するインスタンスの数は処理量に応じてスケールする。instance-hoursGAEにデプロイしたアプリケーションのScalingの設定は、デフォルトではautomatic-scalingになっています。automatic-scalingは、リクエスト量や処理量に応じて自動でリソース割り当てを変えてくれて便利なのですが、リクエストに対する限界時間が60秒であったり、タスクの有効期限が10分であったりと時間的制限が厳しいのが悩みの種でした。Scalingまずはautomatic-scaling設定(スケーリングの記述をしない)モジュールをデプロイして、deadlineを確認します。サンプルプログラムは65秒待ってからログにもやしが生えるだけの簡単なものです。automatic-scalingでは、リクエスト応答まで60秒間の猶予しかないので、失敗するはずです。ログにもやしも生えていません。予想通り失敗しました。automatic-scalingは便利ですが、タイムアウト設定を変えられないのが難点です。Scalingでは次に、manual-scaling設定のmoduleを配備してみましょう。manual-scalingならば、リクエストに対する制限時間はないはずなので、ログにもやしが生えるはずです。</manual-scaling></appengine-web-app>appengine-web.xmlにタグを追加しました。タグの値は、このモジュールが動作するために、いくつのインスタンスを生成するかを意味しています。APIを使って停止をするまで、この値の数のインスタンスが常にメモリ上に存在することになります。次に、サンプルプログラムです。これは先ほどと同じです。もやしがLogsに生えました。manual-scaling設定にすれば、60秒を超えるような処理のリクエストにも対応できます。Moduleとで耐久レースです。内容は単純、一時間ごとにLogsにもやしを生やして、25本(25時間)のもやしが育てられたほうが勝ちです。BackendsへはTaskQueuesを使って処理を委譲します。GETでサーブレットを呼び出します。動作させるプログラムはこちらです。log.info("もやしは一時間に一本生えます。</backend></backends>Manual-Scalingモジュールの設定はこちら。backendsうーん、こちらは処理の途中で何度かインスタンスが再起動してしまっています。2日ほど待ちましたが、結局、正常終了は一件もありませんでした。Moduleうんうん、うまくいっている...と思ったら例外が出ていました。manual-scalingのモジュールにも時間制限があるようで、24時間までとなっている模様です。公式ドキュメントを見ると無制限と読めますが、さすがにそこまでは無理ということなんでしょうか。一度も途中停止はしていないし、Backendsより安定しているととってもよさそうです。サポートに問い合わせたところ、現時点ではDeadlineは24時間が仕様と回答されました。Modulesの機能自体の仕様がまだ最終化されていないので、これからも変わるかも~とのことです。