※この投稿は米国時間 2019 年 5 月 9 日に Google Cloud blog に投稿されたものの抄訳です。

クラウドへの移行で重要なのは、移行は一度限りの大規模な変更ではないということを肝に銘じておくことです。クラウドへの移行は、細かいステップをいくつも重ねて進む長い道のりにほかなりません。Google Cloud Platform（GCP）では、仮想マシン（VM）を GCP に移行する場合のガイダンスとベスト プラクティスをまとめました。このブログ投稿ではその内容を簡単にご紹介します。なお、このガイドと本稿では、VM の Compute Engine への移行に焦点を当てています。それでは、GCP のメリットから見ていくことにしましょう。

Compute Engine に移行する理由

ご存じのように、移行後の VM でアプリケーションを動かすには、データベース、メッセージング、アナリティクスなどのサービスと共にコンピューティング リソースが必要です。VM の実行環境として考えた場合、Compute Engine 上で実行することの主なメリットは次のとおりです。

• コストの削減 : 継続利用割引が適用される Compute Engineは、従来型のデータセンターでハードウェアや VM を管理する場合と比べて大幅に割安です。継続利用割引は、ほかのクラウドから GCP に移行するときにも大きなメリットとなります。

• 機敏性 : リソースの確保やプロビジョニングを待つことなく、ほとんど瞬間的に VM を立ち上げられるようになるので、お客様の多くは移行と同時に機敏性が向上します。新しいアプリケーションをすばやく立ち上げて試用し、必要に応じてオフにすることができます。

• オーバーヘッドの削減 : データセンターの運営では通常、それぞれ独自の窓口、課金モデル、契約内容を持つさまざまなベンダーとの取引が必要です。クラウドに移行すれば、そのオーバーヘッドが大幅に削減されます。これにより、担当スタッフはデータセンターの運用にまつわる雑用に振り回されることがなくなり、ビジネスの成功に必要な業務に集中できます。

移行先として Compute Engine を選択したら、移行の際にどのようなことに留意すべきでしょうか。その一部を簡単に説明します。

コストの計算

移行に取りかかる前に、移行のコストを計算しましょう。これは、現状のデータセンターや既存のクラウド環境で実行しているもののコストを評価することを意味します。GCP の VM 移行支援センターでコスト管理の方法を学び、ニーズに最もマッチするパートナーを選んでください。

移行対象 VM の評価

移行コストの評価後は、移行する VM の検討を開始します。現代の企業はさまざまな種類のアプリケーションを VM で運用しており、それらすべてを同時にクラウドに移行することは通常はありえません。移行をうまく進めるには徹底的な評価が必要ですが、GCP であれば、そうした評価を無料で行うことができます。

移行の設計

移行する VM を決めたら、移行を始める前にクラウド環境を設計する必要があります。その最初のステップは、現在の環境と GCP との違いを明らかにすることです。そして次に、GCP 上の新しいクラウド環境をどのような形にすべきかを検討します。以下の各項では、移行に先立って検討すべきことを説明します。

ガバナンスの確立

クラウド リソースの作成、アクセス、変更、破棄に関するパーミッションを誰に与えるかを明確にする必要があります。また、リソース コストの支払い方法も決めなければなりません。それには、IAM のベスト プラクティスに関するドキュメントが参考になります。

ネットワークの作成

移行後に使用するネットワークは、VM の移行前に存在していなければなりません。アプリケーションの稼働後にネットワークを設定するのは難しいため、パーミッションやアカウントと同様に、事前に作成しておくことが重要です。

運用計画の策定

クラウドで VM を稼働するようになれば、システムの常として、VM のモニタリングやロギング、運用上の管理が必要になります。移行後に慌てることがないよう、運用管理については事前の計画段階で考慮に入れておくべきです。

クラウドへの VM の移行

こうした準備を整えてから最初の VM の移行に取りかかります。最初の移行は、将来の移行のテンプレートになります。移行を重ねるうちにプロセスは改善されていくはずですが、最初の移行では特にあらゆることを記録することが重要です。

Google Cloud の移行ツールである Velostrata を使用すれば、VM の GCP への移行を迅速かつ安全に、そして大規模に行うことができます。Velostrata は、ストリーミング技術を使用して移行にかかる時間を短縮すると共に、適切なインスタンス タイプを選びやすくするために推奨サイズを提示してくれます。また、組み込みテスト機能とロールバック（必要な場合）も提供します。GCP に移行するお客様は Velostrata を無料で利用できます。

以上、VM をクラウドに移行する前に検討すべき項目を駆け足で見てきました。もっと詳しく知りたい方はこちらのドキュメントをご覧ください。

- By Ron Pantofaro, Cloud Solutions Architect, Google Cloud Platform and Tom Nikl, Product Marketing Manager

※この投稿は米国時間 2018 年 10 月 16 日に Google Cloud blog に投稿されたものの抄訳です。

私たち Google は先ごろ、Google Compute Engine のセキュリティとアクセス制御をきめ細かく管理できるようにすることを目的に、resource-level IAM と IAM Conditions の 2 つの Cloud IAM 機能を導入しました。resource-level IAM は、VM インスタンスやディスクといった個々のリソースに IAM ポリシーを設定できるようにします。また IAM Conditions は、リソース名プレフィックス、リクエストの属性（IP、デバイスなど）、時間帯など事前に定義された条件に基づいてアクセスを制御する機能です。

Compute Engine におけるリソース レベルのアクセス管理

Google Cloud Next '18 で発表された Compute Engine resource-level IAM は、VM やディスク、イメージ、その他の Compute Engine リソースのそれぞれに IAM ポリシーを適用し、環境をきめ細かく柔軟に管理できるようにするものです。次の図は、Google Cloud Platform（GCP）内の階層化されたリソース モデルを示しています。

お客様は、組織（上図の Organization）、フォルダ（同 Folders）、プロジェクト（同 Projects）のレベルで IAM ポリシーを指定でき、それらのポリシーは下位の階層に継承されるため、効果的かつ効率的にアクセス権を付与できます。上図を例にとると、「Dept X」に属する Elizabeth にインスタンス管理者の役割を与える場合は、フォルダ（Dept X）レベルで IAM ポリシーを指定します。すると、Elizabeth は、Dept X フォルダに属するすべてのプロジェクトのインスタンスを管理できるようになります。また、「Dev/test project」で共同作業を行っているデベロッパーのグループを対象に、同プロジェクトへの強力な権限を認めつつ、左隣の「Production project」へのアクセス権を制限することも可能です。

では、もっときめ細かく IAM ポリシーを指定したいときはどうすればよいのでしょうか。たとえば、テスターのグループを対象に、「Project A」のベータ イメージをテストできるようにしつつ、同じプロジェクトに属する機密性の高いイメージやリソースへのアクセスを制限するといった場合です。プロジェクト以上のレベルでしかアクセス権限を設定できなければ、テスター グループに対しては、プロジェクト内のすべてのイメージへのアクセスを認めるか、あるいは禁止するかの一択になります。この例のように機密性の高いイメージへのアクセスを制限するには、従来はベータ イメージだけを集めた別のプロジェクトを作り、そのプロジェクトの compute.imageUser ロールをテスター グループに付与する必要がありました。これではいかにも不便です。

Compute Engine resource-level IAM は、こうした課題を解決します。これを導入すれば、過剰な共有や不自然な回避策をとることなく、特定のベータ イメージに compute.imageUser ロールを簡単に付与できます。権限の設定例を見てみましょう。

gcloud beta images set-iam-policy betaTestImage1 betaImagePolicy.json
ここで使われている betaImagePolicy.json ファイルは次のように定義されています。

{
  "policy":
"bindings": [
     {
       "members": [
         "group:image-testers@example.com",
       ],
       "role": "roles/compute.imageUser"
     },
   ],
}

こうした新しい resource-level IAM ポリシーで実現できるユース ケースは他にもたくさんあります。たとえば、トラブルシューティングのために同僚や共同作業者に対してプロジェクト内の特定 VM へのアクセス権を与えたり、社内のすべての承認ユーザーとディスク イメージを共有して全員が同じバージョンのイメージにアクセスできるようにしたりすることが可能です。

Compute Engine resource-level IAM は、API、CLI、Developer Console を通じてベータ版を利用できます。詳細はドキュメントをご覧ください。

IAM Conditions によるアクセス管理

resource-level IAM ポリシーを設定するだけでなく、アクセスできる条件を定義して適用したい場合もあります。たとえば、電話サポート チームのメンバーにインスタンス管理者の役割を与えたいときに、最小権限の原則に従ってアクセスを電話の受付時間だけに制限し、不慮の事故を防ぐような場合です。

IAM Conditions の導入により、アクセス権の範囲をきめ細かい条件のもとで制御できるようになります。このときのポリシーは、条件 Z が満たされれば Y に役割 X を与えるという形で指定できます。Google Cloud Next '18 で紹介したように、現在はベースとなるポリシーに加えて、リソース名プレフィックス、アクセス レベル、日時という 3 種類の条件属性を使ってアクセス権限を強力に管理できます。以下、これら 3 つについて見ていきましょう。

1. リソース名プレフィックス属性

この属性を使用すると、リソース名のプレフィックス（接頭辞）が条件を満たすときに限り、IAM ポリシーが適用されるようになります。よく見られるユース ケースとしては、デベロッパー向けのサンドボックスがあります。管理上のオーバーヘッドを減らしてネットワークのパフォーマンスを最適化するため、デベロッパーが同じプロジェクトでプロトタイプを構築できるようにするわけです。compute.instanceAdmin.v1 ロールを個々のデベロッパーに付与する IAM ポリシーに対し、接頭辞にデベロッパー名が含まれている名前のリソースだけにアクセスを制限するという条件を挿入することで、このようなサンドボックスを作成します。次に示すのは、接頭辞が dev1 になっている VM とディスクを操作するときに限り、リード デベロッパーの dev1 に instanceAdmin ロールを与えるポリシーの例です。

{
   "policy": {
     "bindings": [
      {
        "role": "roles/compute.instanceAdmin.v1",
        "members": [
          "user:dev1@example.com",
         ]
        "condition": { 
          "title": "dev1 prefix",
          "description": "Role granted only for instances and disks with Name Prefix dev1",
          "expression": 
            "(resource.type=="compute.instances"&& resource.name.startsWith("projects/[PROJECT_NAME]/zones/[ZONE_NAME]/instances/dev1"))||(resource.type=="compute.disks"&&resource.name.startsWith("projects/[PROJECT_NAME]/zones/[ZONE_NAME]/disks/dev1"))"
        }
      }
    }
  }

*注意 : compute.instances, などのリソース タイプの形式は、Cloud IAM Conditions の将来のリリースで変更される可能性があります。

リソース名プレフィックス属性を使ってアクセス範囲を限定することで、デベロッパーは他のリソースに影響を与えることなく、自分の担当リソースの範囲で開発を進めることができます。

2. アクセス レベル属性

アクセス レベル属性を使用すれば、IP アドレスやデバイス ステータスなどのリクエストの属性に基づいて、そのリクエストにアクセスを認めるかどうかを判断できます。

アクセス レベル属性で定義できる条件は、たとえば「ソース VM インスタンスが、会社が許可した最新の OS イメージを実行している場合のみ、サービス アカウントからのリクエストを認める」とか、「社内 VPN 経由のリクエストに限り、インスタンス状態を操作するためのリモート リクエストを認める」などです。

なお現時点では、アクセス レベル属性は Compute Engine のアルファ API でのみ使用可能です。

3. 日時属性

日時属性には、IAM ポリシーの開始日と終了日、および時間帯を指定します。たとえば、「Jane が電話対応している間に限り、彼女に Stackdriver ログ閲覧の役割を許可する」とか、「ジョンは、緊急時の場合のみ、この本番プロジェクトで使用する計算リソースの管理者になる」といった指定が可能です。

IAM Conditions により、組織のクラウド コンピューティング環境をきめ細かく柔軟に保護できます。なお、IAM Conditions ではプライベート ベータ テスターを募集していますので、関心のある方はこちらからサインアップしてください。新しい IAM Conditions の機能をぜひお試しください。

- By Sophia Yang, Product Manager, Google Compute Engine and Meiyuan Zhao, Staff Software Engineer, Cloud IAM

1990 年の創業以来、ゲームを通じてエンターテインメントの可能性に挑戦し続けるポノス株式会社（以下、ポノス）。挑戦の一環として、近年、注目度が高くなっている「eスポーツ」にも対応した対戦型アクションゲーム「ファイトクラブ」をリリースしています。GCP パートナーの株式会社grasys（以下、grasys）の協力のもと、「ファイトクラブ」の企画から開発までをリードした、2 人のキーパーソンに話を伺いました。

■ 利用している Google Cloud Platform サービス
Google Compute Engine、Google Cloud Load Balancing、Virtual Private Cloud、Google Cloud Storage など


■ ポノス株式会社
スマートデバイス向けゲームの開発を事業として推進。「GO FAR BEYOND（ななめ上を、行け）」という企業スローガンに基づき、ゲームを通してエンターテインメントという文化の発展に貢献し、世界中を笑顔にする取り組みを推進。

■ 写真左から
いろはスタジオ 技術室 室長　樺山 博史 氏
いろはスタジオ スタジオ長　板垣 護 氏

GCP で世界中のプレイヤーが参加可能な性能と拡張性を両立

「Are You Ready？Fight！さぁバトルがスタート！」-- バトルで勝利することで、富や名誉を獲得できる世界の住人として、自分の分身となるキャラクターを作り、ほかの住人とリアルタイムにアクションバトルが楽しめる対戦型ゲームアプリ「ファイトクラブ」。このゲームをプロデュースする会社がポノスです。


1990 年 12 月、画像処理技術会社として大阪市に設立されたポノスは、現在、京都市に本社（京オフィス）を置き、自社で企画、開発するオリジナルゲームを、日本市場はもちろん、海外市場にも配信しています。2015 年 10 月には、東京都渋谷区に江戸オフィスを開設。江戸オフィスで企画、開発された「ファイトクラブ」は、2018 年 4 月にリリースされました。

ポノス いろはスタジオ スタジオ長の板垣 護さんは、「単なるスマートデバイス向けのゲームではなく、eスポーツを前提としたゲームを企画・開発しています。」と語ります。現在（2018 年 7 月取材時点）、「ファイトクラブ」では、平日は賞金 1 万円、週末は賞金 5 万円が進呈される「デイリー賞金大会」や、外部スポンサードによる賞金大会などが開催されています。

板垣さんは、「すでにかなりの賞金を稼いでいるプレイヤーもいます。オフライン イベントで、“ 1 か月のバイト代よりも稼ぎました ” と話しているプレイヤーもいるくらいです。」と話します。同社にも 7 名のプロゲーマーが所属しており、自社のゲームの魅力を発信する広告塔として、各種イベントや他社が主催する大会に参加しています。


リアルに賞金を稼ぐことができる「ファイトクラブ」は、世界各国でのリリースも検討しており、世界中のプレイヤーが参加しても快適にバトルができる十分なパフォーマンスと、急激なアクセスの増加にも耐える拡張性を兼ね備えた堅牢なインフラが必要でした。そこで同社では、grasys とともに必要な条件を比較検討した結果 、Google Cloud Platform（GCP）を選定しました。

ポノス いろはスタジオ 技術室 室長の樺山 博史さんは、「自社にインフラ担当がいなかったので、外部の会社の協力が不可欠でした。インフラには詳しくないし、クラウド サービスを使うのも初めてだったのですが、grasys のサポート体制は完璧で、非常にやりやすいパートナーでした。」と話しています。

リリース直前にコマンド 1 つでデータベースを簡単に拡張

同社が GCP の検討をはじめたのは、2016 年初夏より。2016 年 8 月に GCP の採用を決定し、2016 年末より開発をスタート。2018 年 3 月に「ファイトクラブ」が完成し、4 月よりサービスの提供を開始しています。GCP を採用した理由を樺山さんは、「『ファイトクラブ』は、日本国内だけでなく、海外展開も考えていたので、レイテンシー対策が重要で、専用ネットワークを持っている GCP は魅力的でした。」と話します。

「grasys が独自に検証した各リージョン間のレイテンシーの比較結果を見せてもらったり、検討の後半に負荷試験を実施したりして、GCP の採用を決めました。各リージョン間のレイテンシーは、他のクラウド サービスに比べ、最大 2 倍の差がありました。2016 年 11 月に、GCP の東京リージョンができたことも採用を決めた理由の 1 つでした。」（樺山さん）


「ファイトクラブ」の基本的なシステム構成としては、プレイヤーの情報を処理する AP サーバー、バトル用の情報を処理するバトルサーバー、プレイヤーの情報を保管するデータベース サーバー、プレイヤーやバトルの状況を一時保管するキャッシュ サーバーが、Virtual Private Cloud（VPC）上に構築されています。プレイヤーからの AP サーバーへのアクセスは、Google Cloud Load Balancing で負荷分散されています。

特長的なのは、バトルサーバーで、アプリケーションが C# で書かれています。「Windows 上で C# を動かすのではなく、.NET Core を使って CentOS の上で C# を動かすという珍しい構成になっています。」と樺山さん。また、アセットバンドルなどのキャッシュ用に、Google Cloud Storage（GCS）を CDN（コンテンツ デリバリ ネットワーク）として使っています。コマンドラインでの操作が柔軟で、導入コストが安いことが GCS 採用の決め手でした。



「ファイトクラブ」の開発は、プロデューサー兼ディレクターが 1 名、企画が 4～5 名、エンジニアは、サーバー担当が 2 名、クライアント担当が 3 名、grasys から 1 名、デザイナーが約 10 名、デバッカーやサポート担当が数名、プロモーションが 2 名程のチームで実施されました。板垣さんは、「インフラ開発を、grasys にお任せできたので、開発工数を大幅に削減できました。インフラの管理も不要なので、管理工数も減っており、管理上の効果を感じています。」と語ります。リリース後は、インフラに起因するダウンはなく、オンプレミスに比べて稼働率が向上しているので、プレイヤーにとってもメリットがあると感じています。

GCP を採用した効果を樺山さんは、「GCP の利用は初めてでしたが、使いやすかったです。全社的に G Suite を利用しているので、アカウントの管理が楽で、Google アカウントだけで、GCP の操作が行えるのは非常に便利です。いつでも、どこからでも緊急対応ができるので保守性も向上しています。リリース直前にデータベースの負荷が高くなり、データベースを増やす必要があったのですが、コマンド 1 つで簡単に拡張できました。オンプレミスだと、絶対にできないことです。」と話します。

今後の展望について板垣さんは、次のように語っています。「今後、開発するゲームにおいても、今回の GCP で得た経験やノウハウを生かし、技術を横展開していきたいと思っています。また、BigQuery を使ってプレイヤーを分析したり、Google Cloud Machine Learning Engine を利用してプレイヤーごとに違ったイベントを発生させたりすることなどにも興味があります。」


ポノス株式会社の導入事例 PDF はこちらをご覧ください。
GCP のその他の導入事例はこちらをご覧ください。

ビデオゲーム黎明期から数々の傑作ゲームを世に送り出し、今日までゲームシーンのど真ん中で活躍し続けているセガグループ。株式会社セガ・インタラクティブは、その一員として、アミューズメント施設向けにさまざまな作品を開発。『チュウニズム』のような音楽ゲームから、本格リアル競馬メダルゲーム『スターホース』シリーズなど、さまざまな作品を世に送り出してきました。今回はその最新作『ソウルリバース』で、Google Cloud Platform（GCP） が採用された理由を最前線の開発メンバーが語ります。




■ 利用しているGoogle Cloud Platform サービス

Google Compute Engine、Google Cloud Storage、Google Cloud Load Balancing など



■ 写真左から

第二研究開発本部
第一開発部 プログラムセクション

　スペシャリスト 松崎 大氏

　アシスタントマネージャー 鈴木 孝佳氏

　スペシャリスト 須見 昌之氏

　セクションマネージャー 村松 誉教氏



■ 株式会社セガ・インタラクティブ

セガサミーホールディングスが有する 3 つの事業グループのうち、エンタテインメント コンテンツ事業を司る「セガホールディングス」のアミューズメント事業部門担当企業の 1 つ。全国のユーザーとリアルタイムに対戦プレイを楽しめるネットワークゲームを中心に、プライズマシンやメダルゲームなどまで、幅広いデジタル遊具の開発・製造・販売を行っている。

10 倍のネットワーク負荷に耐えうる環境が必要だった

セガ・インタラクティブが 2018 年 2 月に正式リリースした『ソウルリバース』は、ゲームセンターなどのアミューズメント施設に置かれる 32 型タッチパネルモニター搭載の汎用筐体でプレイする多人数対戦アクションゲーム。各施設を繋ぐネットワーク越しに最大 20 人のプレイヤーが集い、2 つのチームに分かれて、敵陣営のボスである「神将」を倒すべく戦うというもの。同社では、これまで『ボーダーブレイク』（2009 年～）という、多人数対戦シューティング ゲームをオンプレミス環境で運営してきたが、『ソウルリバース』に関しては、それとは次元の異なるネットワーク負荷が予想され、従来環境ではとても対応しきれないということがわかったとのこと。




「10 対 10 ではあったのですが、プレイヤーが操作するキャラクター以外にも多くのノンプレイヤーキャラクターが登場するため、実質的には何十対何十になってしまいます。また、ゲーム性も遠方から撃ち合うシューティングから、近距離でぶつかり合うアクションへと変わり、通信に要求される精度とレスポンスも大きく跳ね上がりました。結果として、『ボーダーブレイク』の 10 倍を超えるようなネットワーク負荷がかかるという試算に。そこでオンプレミス環境の強化も含め、さまざまな選択肢を検討。最終的に GCP を導入することにしました。」

と、2015 年末の開発開始時をふり返るのは『ソウルリバース』でテクニカルディレクターをつとめた須見 昌之さん。その際、決定打となったのが、GCP がシンプルな構造であったこと。実は、これまでのセガ・インタラクティブのネットワーク対戦ゲームでは、インフラ部分を専門の別部署が担当しており、『ソウルリバース』の開発チーム内にインフラ構築のノウハウがなかったそうなのです。

「パブリック クラウドを導入する場合は、インフラ周りの整備もチーム内で行わなければなりません。そう考えると、少しでもシンプルでわかりやすいサービスを選びたかったのです。導入検討時に Google さんから、ゲーム開発に実績のあるパートナーとして株式会社grasys さんをご紹介いただき、彼らの強い熱意に打たれたという面も少なからずあったように思います。」（須見さん）

開発中もサービス開始後も大きなトラブルには見舞われず

そして翌年、2016 年 5 月頃から、GCP を使用した本格的な開発がスタート。チームとしては初のパブリッククラウドでのゲーム開発となりましたが、Google Compute Engine 上の仮想マシンで動かす方針を採っていたため、これまでのノウハウを活かしたスムーズな開発ができたそうです。




「もちろん、Google ならではのマネージド サービスを使いたいという気持ちはあったのですが、一般的なサービスと比べて特殊な通信を行う各サーバーとパブリッククラウドの相性がどうなるか、少しでも早くテストをしたいという事情もあったため、今回はリスクの少ない手慣れたやり方を選択しています。」（松崎さん）

「そうしてテスト環境が動き始めたのが 2016 年の夏頃。ただ、そこで何か問題が起きたかというとまったくそんなことはなく……。GCP はインスタンスの作成や削除が素早く行えるため非常にテストがしやすく、コマンドラインでのインスタンス操作が充実していることなどもあり、つまずくことなくサーバー構築を行うことができました。ダミークライアントで 2～3 千台のテストを実施するなど、オンプレミス時代ではできなかったようなことを手軽にできるようになったことも大きかったですね。結果として、インフラ周りではリリースまで大きなトラブルは発生しませんでした。またその後、今日に至るまで、クラウド起因の問題は発生していません。そしてインフラの運用、変更や調整など、日々の作業部分において別部署を挟まずに対応できるスピード感や自由度も大きなメリットになったと感じています。」（鈴木さん）



もちろん、これほどスムーズに開発が進んだことには理由があります。開発チーム プログラムセクションのリーダーである村松 誉教さんは、「grasys」の貢献が大きかったと評価しているようです。

「正直、我々だけでやっていたら、きっとどこかでハマってしまっていたでしょうね。何か問題が起きても、社内に聞ける人もいませんでしたから……。今回、初のパブリッククラウド導入に際し、GCP パートナーに入っていただいたのは大正解でした。Slack などで問い合わせると、ほぼリアルタイムに返事が返ってくるというのはとてもありがたかったです。」（村松さん）

BigQuery などの Google サービスを活用してさらなる品質改善を目指す

そして、正式リリースから数か月が経過した、2018 年 4 月末現在、『ソウルリバース』は、およそ 3,000 台の筐体が日本全国で稼働中。開発チームは、ゲーム体験のさらなる向上に向けて動き始めています。

「サービスが始まると、ユーザーからの問い合わせに対し、サポートから調査の依頼が来るようになります。現在は、それを膨大なログを漁り対応しているのですが、この部分を BigQuery に置き換えることを検討中です。これが実現できれば、問い合わせに素早く応答できるようになるため、我々の負担軽減だけでなく、お客さまにとっても大きなメリットがあると考えています。」（松崎さん）

「ログの活用については、今のところそうした調査にしか利用できていないのですが、今後は、お客さまのプレイスタイルの収集・解析などにも役立てていきたいですね。BigQuery や Tensorflow などを使って、ステージ構成の改善など、ゲームの品質向上に寄与できればいいなと考えています。」（鈴木さん）

その上で、より長期的には Google の Kubernetes Engine の導入も具体的に検討中とのこと。これまで自前で構築していた死活監視の仕組みをクラウド側に任せるなどして、より安定したサービスを提供していきたいと言います。「それが実現できたら、毎晩不安にならず、枕を高くして眠れるようになるんじゃないかな、と（笑）。」（松崎さん）



最後に『ソウルリバース』以外の作品にも、今後、GCP を使う可能性があるかについて聞いてみました。

「はい、十分にありえます。これまでは、オンプレミス環境の限られた帯域を社内の複数タイトルでどのように共有していくか、より大きな視点で考えていかねばならなかったのですが、GCP のような選択肢があれば、その自由度が大きく広がります。今回、GCP については『ソウルリバース 』での利用実績ができましたから、今後のパブリッククラウド活用に際し、有力な候補になると考えています。」（村松さん）


株式会社セガ・インタラクティブの導入事例 PDF はこちらをご覧ください。
GCP のその他の導入事例はこちらをご覧ください。

コンテナ型仮想化は急速に進化しているテクノロジーの 1 つで、分散アプリケーションのデプロイと管理を容易にします。人々がコンテナを話題にするとき、大抵は Linux ベース コンテナのことを指していますが、それはもっともなことです。Linux カーネルのネイティブ機能（たとえば cgroups）でリソースの分離という考え方が導入され、それがひいてはコンテナの登場につながったからです。

コンテナ化が可能なのは長らく Linux プロセスだけでしたが、Microsoft が Windows Server 2016 と Windows 10 で Windows ベース コンテナをサポートしました。これにより、既存の Windows アプリケーションを Docker でコンテナ化し、独立したコンテナとして Windows で実行できるようになりました。

Microsoft は Windows Server コンテナと Hyper-V コンテナという 2 種類の Windows コンテナをサポートしています。Windows コンテナは microsoft/windowsservercore または microsoft/nanoserver という基本イメージをベースに構築できます。Windows コンテナの詳細は、Microsoft の Windows コンテナに関するドキュメントをご覧ください。

Windows コンテナを Google Cloud で使用

Google Cloud はコンテナに最適化された VM イメージを提供しています。この VM イメージは、Compute Engine でのコンテナの実行に使用できます。また、コンテナ用の Windows VM イメージも提供しています。この Windows VM イメージには Docker が付属し、基本イメージの microsoft/windowsservercore や microsoft/nanoserver がインストールされています。

Compute Engine で Windows コンテナを実行するには、まず Windows VM が必要です。Cloud Console で Compute Engine セクションに移動し、インスタンスを作成します。起動ディスクの OS イメージとして、必ず Windows Server version 1709 Datacenter Core for Containers（Beta）を選択します。


インスタンスを作成したら、Cloud Console か gcloud で新しい Windows パスワードを作成し、RDP で VM にログインします。VM にログインすると、必要最小限の OS と UI が動作していることがわかります。幸いなことに、Docker と基本イメージはインストール済みです。Windows コンテナの実行に必要なものはこれだけです。



最初の Windows コンテナのために、この例のように “Hello World” を出力する呼び出し可能な PowerShell スクリプトを作成しましょう。

microsoft/nanoserver:1709 イメージがすでにインストールされていますが、このイメージには PowerShell が含まれていません。代わりに、microsoft/nanoserver:1709 イメージをベースとする microsoft/powershell イメージを使用します。

まず、PowerShell イメージをプルして実行します。

C:\..> docker pull microsoft/powershell:6.0.1-nanoserver-1709
...
C:\..> docker run -it microsoft/powershell:6.0.1-nanoserver-1709

これで PowerShell コンテナに入ります。“Hello World” を出力する PowerShell スクリプトを作成し、コンテナから出ます。

PS C:\> Add-Content C:\Users\Public\helloworld.ps1 'Write-Host "Hello World"'
PS C:\> exit

今度は、PowerShell スクリプトを含む新しいイメージを、変更されたコンテナを使って作成する必要があります。このコンテナの ID を取得し、docker commit コマンドを使って、その ID で新しいコンテナ イメージを作成します。

C:\..> docker ps -a
C:\..> docker commit  helloworld

以上で、コンテナ イメージを実行し、コンテナ内の指定したスクリプトを実行できるようになりました。

C:\..> docker run --rm helloworld pwsh c:\Users\Public\helloworld.ps1
Hello World!

ご覧のとおり、Google Cloud Platform（GCP）で Windows コンテナを実行できています！

以上の手順を試したい方のために、コードラボ（ハンズオン形式で体験できる解説付きのコーディング エクササイズ）が用意されています。




試し終わったら、追加の料金がかからないように、必ず VM をシャットダウンするか削除してください。

GCP 上での Windows コンテナや Windows の詳細についてはドキュメントをご覧ください。フィードバックやもっと知りたいことがありましたら、コメント欄を使ってお寄せください。

* この投稿は米国時間 4 月 2 日、Developer Advocate の Mete Atamel によって投稿されたもの（投稿はこちら）の抄訳です。

- By Mete Atamel, Developer Advocate

ハイパフォーマンスのテクニカル コンピューティングはスケーラビリティとスピードがすべてです。創薬とゲノミクス、金融サービス、画像処理などの分野のアプリケーションは、その多くが大量かつ多様な計算リソースへのオンデマンド アクセスを必要とします。計算能力が大きく高速になれば、アイデアを発見に変え、仮説を治療法に生かし、ひらめきを製品に反映させることができます。

Google Cloud は、大量のハイパフォーマンス リソースへのオンデマンド アクセスを、Compute Engine を通じて HPC（High Performance Computing）コミュニティに提供しています。しかし、これらの強力なリソースを活用して HPC ジョブをすばやく実行し、既存の HPC クラスタを Compute Engine でシームレスに拡張する方法については、まだ課題が残っています。

この問題の解決を支援するため、Google は SchedMD の協力を得て、Compute Engine での Slurm Workload Manager の起動を容易にするツールのプレビュー版をリリースしました。追加リソースが必要なときに既存クラスタを拡張することも可能です。

このツールは、SchedMD のエキスパートが Slurm のベスト プラクティスに従って構築したものです。Slurm は、TOP500 にランキングされているスーパーコンピュータの多くで使われている最先端かつオープンソースの HPC ワークロード マネージャです。


今回のインテグレーションにより、Compute Engine 上では、自動スケーリングされた Slurm クラスタを簡単に起動できるようになりました。Slurm クラスタはジョブの要件やキューの深さに応じて自動的にスケーリングします。

Slurm クラウド クラスタをセットアップすると、オンプレミス クラスタのジョブは、フェデレーションによって Compute Engine 上の Slurm クラスタを利用できるようになります。HPC クラスタをクラウド環境に用意しておけば、個々の研究者、チーム、またはジョブは、適切に調整されて弾力性もある専用のリソースを確保して、キューの順番待ちに煩わされず問題解決に集中できます。



ユーザー
Slurm でスケジューリングされるジョブのソースです。研究者、アナリスト、データ生成機器、管理者などが該当します。ここではジョブが準備され、サブミットされます。

ログイン ノード
クラスタの操作、ジョブのサブミット、リソースの利用状況の監視、管理タスクの実行、そのほか必要なメンテナンス作業のためにユーザーが使用するノードです。

コントローラ ノード
Slurm コントローラとデータベースを実行するノードです。Slurm クラスタのリソースとジョブ スケジューリングを管理します。また、/home と /apps の共通ストレージを提供する NFS サーバーを実行します。

計算ノード（複数可）
Slurm コントローラによって割り当てられたタスクを実行する専用の “計算” ノードです。ノードの数が数百に上ることもあります。需要に応えるため、ジョブの要件とキューの深さに基づいてスケーリングされます。

ここからは、Compute Engine 上で Slurm クラスタを起動する手順をたどってみましょう。

ステップ 1 : SchedMD の GitHub リポジトリから Cloud Deployment Manager スクリプトを入手します。詳細は同梱の README.md を参照してください。必要に応じて Deployment Manager スクリプトをカスタマイズすることがあります。クラスタ パラメータの多くは同梱の slurm-cluster.yaml ファイルで設定できます。

slurm-cluster.yaml では、少なくとも munge_key の内容をペーストし、GCP ユーザー名を default_users に指定し、使いたい Slurm のバージョン（たとえば 17.11.5）を指定するといったカスタマイズが必要になります。

ステップ 2 : Cloud Shell か、gcloud コマンドがインストールされたローカル端末で以下のコマンドを実行します。

gcloud deployment-manager deployments create slurm --config 
slurm-cluster.yaml

次に、Developers Console の Deployment Manager セクションに移動し、デプロイが成功していることを確かめます。



ステップ 3 : Developers Console の Compute Engine セクションに移動すると、Deployment Manager がいくつかの VM インスタンスを作成しており、その中に Slurm ログイン ノードが含まれていることがわかります。VM がプロビジョニングされ、VM 上に Slurm がインストールされて設定が行われたら、Console の SSH ボタンをクリックするか、gcloud compute ssh login1 --zone=us-west1-a を実行すれば、SSH でログイン ノードに入れます（slurm-cluster.yaml ファイルでゾーンを書き換えた場合は、ゾーンを変更しなければならないことがあります）。

ログインすると、いつもと同じように sbatch を使って Slurm とやり取りを行い、ジョブをサブミットできます。たとえば、slurm-sample1.sh という新しいファイルに以下のサンプル スクリプトをコピーします。

#!/bin/bash
#
#SBATCH --job-name=hostname_sleep_sample
#SBATCH --output=out_%j.txt
#
#SBATCH --nodes=2

srun hostname
sleep 60

そして、以下のようにサブミットします。

sbatch slurm-sample1.sh

次に sinfo と squeue コマンドを使用すれば、ジョブが計算ノードで分散処理されていることを確認できます。

サブミットされたジョブにおいて、最初にデプロイされたときよりも多くのリソースが必要になった場合は、slurm-cluster.yaml で指定された上限に達するまで新しいインスタンスが自動的に作成されることに注意してください。これは、#SBATCH --nodes=4 を指定してジョブを再度サブミットすれば試せます。一時的な計算インスタンスは、指定された時間アイドル状態が続くと、デプロビジョニングされます。

なお、Deployment Manager スクリプトは、デプロイの一環として NFS をセットアップすることに注意してください。

詳細は同梱の README をご覧ください。また、Slurm の導入にあたって支援が必要な場合は、クイックスタート ガイドを参照するか、SchedMD にお問い合わせください。

* この投稿は米国時間 3 月 23 日、Product Manager の Michael Basilyan、HPC Specialists の Wyatt Gorman と Keith Binder、Partner Manager の Annie Ma-Weaver によって投稿されたもの（投稿はこちら）の抄訳です。

- By Michael Basilyan, Product Manager; Wyatt Gorman and Keith Binder, HPC Specialists; and Annie Ma-Weaver, Partner Manager

群雄割拠、日々熾烈な競争が繰り広げられているスマホゲーム業界。この戦いを勝ちぬくためには、ゲームとしての楽しさはもちろん、快適にプレイできるネットワーク環境の構築も重要です。そこで今回は、Google Cloud Platform が、スマホゲーム開発の現場でどのように活用・評価されているかを、『A3!（エースリー）』をはじめとしたヒット作で大きな注目を集めるリベル・エンタテインメントの皆さんに語っていただきました。



■ 利用している Google Cloud Platform サービス
Google Compute Engine、Google Cloud Storage、Google Cloud CDN、Google Stackdriver など


■ 写真左から

株式会社リベル・エンタテインメント
開発部 プログラム課 課長 テクニカルディレクター
磯貝 活伸氏

株式会社リベル・エンタテインメント
開発部 企画課 課長 ゲームプロデューサー／ディレクター
久保寺 良一氏

株式会社アドバンスト・ネット
インフラ構築・運用担当
楡井 大輔氏

株式会社アドバンスト・ネット
インフラ構築・運用担当
古田 重信氏


■ 株式会社リベル・エンタテインメント

テレビゲームの老舗、株式会社セガ・エンタープライゼス（現・株式会社セガゲームス）にて、『ファンタシースター』『ソニック・ザ・ヘッジホッグ』など、数々の著名作品に携わってきた林田 浩太郎氏が 2006 年に設立した開発会社。2015 年に配信開始した音楽ゲームアプリ『アイ★チュウ』のヒット後は、自社提供のスマホゲーム開発に特化し、2017 年にはイケメン役者育成ゲーム『A3!』、本格海戦ゲーム『蒼焔の艦隊』をリリースしている。現在の従業員数は約 70 名。男女比率はおよそ半々となっている。

コスト削減や海外展開など、
今後を見据えて Google Cloud Platform への移行を決断

今回お話をお伺いしたのは、株式会社リベル・エンタテインメントが 2017 年にリリースしたスマホゲーム『A3!』開発チームの皆さん。



『A3!』は、2017 年 1 月にリリースされ、わずか 1 年強で 500 万ダウンロードを達成したという大ヒットコンテンツです。昨年末に発表された Google Play「ベスト オブ 2017」のゲーム アトラクティブ部門と、ユーザー投票部門 Top 5 ゲームの 2 部門で入賞を果たすなど、今、最も勢いのあるスマホゲームの 1 つと言えるでしょう。



そんな『A3!』の企画がスタートしたのは、2015 年末のこと。翌年春からの開発スタートに向け、まずはクラウドプラットフォームの選定が行われました。ここで、なぜ Google Cloud Platform（GCP）が選ばれたのでしょうか？　その決め手は何だったのかを、インフラ構築・運用を担当した古田 重信さんと楡井 大輔さんに聞きました。

「『A3!』の前にリリースした『アイ★チュウ』という作品でも、ネットワーク側の開発を担当したのですが、新作を作るにあたり、よりインフラのコストを下げたいという要望がありました。とは言え、もちろんそれでお客さまにストレスを感じさせるようなことがあってはいけません。さらに将来的には海外展開もしやすいプラットフォームを……と絞り込んでいくと、これはもう Google 以外ないだろう、と。」（楡井さん）

「それまで使っていた大手クラウドプラットフォームと比べ、GCP のコストはおよそ 6 割程度。当時はまだアジア地域に台湾リージョンができたばかりということもあり、国内ゲーム業界で GCP の有用性に気がついている企業は少なかったのですが、挑戦する価値はあると考えました。もちろん、我々としても初めての環境ですから、ハンズオンや質問状のやり取りなどをしっかり行い、満を持して春から開発をスタートしています。」（古田さん）

なお、『A3!』は、基本的には Google Compute Engine（GCE） 上で独自に開発。当時はまだ、Google のマネージドサービスの多くが β 版だったため、必要なものは自分たちで開発するという姿勢で臨んだそうです。ただし、ゲームの安定運用に必要となる負荷分散の工夫については、Google Stackdriver などが大いに役立ったとのこと。また、Web サイトの運用には Google Cloud CDN を活用しています。

さらに、『A3!』の開発では、クライアント側の開発においても、GCP の大きな貢献があったと、本作でメインプログラマを務めた磯貝 活伸さんは言います。

「『アイ★チュウ』を開発した時は、まずネットワーク側のプロトタイプができてから、通信周りを作り込み始めていたのですが、それだとやはり開発スケジュールが後半に逼迫してしまうんですね。そこで今回は、クライアント側も GCP を使って、仮のネットワーク環境を構築。インフラ構築と並行してクライアント側の制作をスタートさせています。 GCP を触るのは初めてだったのですが、UI が分かりやすいなど、機能が使いやすく整理されていたので惑うことなく作業を進めることができました。もちろん、プロトタイプ完成後の通信のつなぎ込みも、問題なくスムーズに完了しています。」（磯貝さん）

結果、初めての GCP 利用にもかかわらず、『A3!』は予定通り、2017 年 1 月のリリースを実現。本作プロデューサーのひとり久保寺 良一さんも、「この規模のプロジェクトを、約 9 か月という短期間で完成させたのは、業界の水準からみても、かなりの開発スピードだったのではないでしょうか。」と胸を張ります。

高速立ち上げ・暖気不要の GCE で “不慮の事態” を乗り越える

しかし、ゲームアプリの “本番” は、まさにここから。とりわけ『A3!』のような注目作品では、初日のトラブルがもはやお約束のようになっています。作品によっては、初日にサーバーがダウンし、復帰に 1 週間以上かかるというケースも……。もちろん、『A3!』もそうならないよう入念な準備をしていたのですが、初日に予想の 10 倍を超えるアクセスが殺到し、緊急メンテナンスを余儀なくされてしまいました。

「とは言え、こうしたトラブルが起きても、GCE はインスタンスの立ち上げが速いので、素早い対応が可能でした。元々、横に拡げやすいシステムを作っておいたこともあり、状況に合わせて随時、サーバーを増強。緊急メンテナンスこそ避けられませんでしたが、最悪の事態（サーバーダウン）には至ることなく、初日を乗り越えることができたんですよ。その後、3 月に行った初の大規模なゲーム内イベントでも、その軽快さに助けられています。」（楡井さん）



「GCP はインスタンスの立ち上げが速いだけでなく、いわゆる “暖気” が必要ないことも素晴らしい。他社のプラットフォームでは、立ち上げに数分～十数分かかる上、フルパフォーマンスを引き出せるようになるまでさらに待たされてしまうのですが、GCP なら 30 秒以内で起動し、しかも最初から全開で使える。この差はとても大きいですよ。さらに、データのバックアップ速度が群を抜いて速いことも、限られた時間内に作業を終わらせる助けになってくれました。他のプラットフォームでは最大 1 日はかかると言われたデータ量を、GCP ならわずか 15 分でコピーしてしまえるんです。実は、初日の緊急メンテナンスは、直後にインターネットの生放送特番を予定していたため、絶対に遅延が許されなかったのですが（笑）、このおかげで、ずいぶんと余裕をもって作業を完了することができました。」（古田さん）


以降、ゲーム内イベントなどの盛り上がりに応じて、頻繁にトラフィックの爆発的急増が発生するものの、GCE 上に構築した『A3!』のネットワークはこれに見事に対応。「一時的にでもゲームが進められなくなるような大きなトラブルや、メンテナンスの延長などもほとんど起きていません。」（久保寺さん）

この 1 月に、無事、一周年を迎え、2 月には中国進出に向けたクローズド β テストもスタートした『A3!』。今後は、GCP の売りとなっている最新のマネージドサービスも駆使して、更なるサービス品質向上を図っていきたいとのことです。

「今、気になっているのは、Cloud Spanner。喫緊の問題ではないのですが、将来的なユーザー数拡大を考えると、データベースにはもう少し余裕を持たせたい。その際、これが役立つのではないかと期待しています。あとは BigQuery ですね。サービス開始から 1 年が経過し、膨大なログデータが溜まりましたから、これを BigQuery で解析して、今後のサービス向上に役立てたいと考えています。」（楡井さん）

「そしていずれはそうしたデータを機械学習にかけて、ユーザー動向の把握に活用していきたいですね。お客さまが離脱する兆候を AI が教えてくれるようになると助かります……と、考えていくと、やっぱり GCP には大きな優位性があると感じます。『A3!』に限らず、今後の作品でも、これを使わない理由はないと話しているんですよ。」（久保寺さん）


株式会社リベル・エンタテインメントの導入事例 PDF はこちらをご覧ください。
GCP のその他の導入事例はこちらをご覧ください。

Compute Engine 環境でマネージド インスタンス グループを使用している場合でも、ワーカーの VM インスタンスをキュー内のジョブに応じて効率的にスケーリングすることは、依然として容易ではありません。時にはキューが空のこともあり、そうなると、お金やリソースを浪費しないようにワーカーをゼロにしたくなります。逆に、キューがいきなり満杯になり、確保できるワーカーがすべて必要になることもあります。また、継続的に発生する作業を一貫したペースで処理したい場合もあるでしょう。

こうした状況への対処を支援するため、私たち Google は先ごろ、マネージド インスタンス グループにおけるグループあたりのモニタリング指標に基づいた自動スケーリングをベータ リリースしました。

この自動スケーリングを使用すれば、上述のようなシナリオにも対応できるシンプルなキュー ベースのスケーリング システムを構築できます。この機能は、これまで未サポートだった Stackdriver のモニタリング指標（Cloud Pub/Sub キューの作業量など）に基づいて、マネージド インスタンス グループをスケーリングできるようにしたことで実現されています。

これは大きな進歩です。これまでの最善策は、大量の作業に備えてワーカー プールのサイズを静的に設定するか、あるいはキュー内のジョブをモニタリングするカスタム コードを作成し、現在の作業量に応じてワーカー プールを手動でスケールアップ / ダウンするかのいずれかでした。

グループあたりのモニタリング指標の使用例

グループあたりのモニタリング指標に基づいた自動スケーリングの設定方法を、例を通して見ていきましょう。ここではシンプルなセットアップを考えます。

データ ジョブを受信し、受信したジョブを順次処理するとします。1 件のジョブを処理するのに数分かかり、到着するジョブは予測不能なタイミングで急増することがあります。新しいデータ ジョブが発生すると、Cloud Pub/Sub メッセージが作成されて送信され、これらのメッセージが増えると、Pub/Sub キュー内の未処理のメッセージ数が Stackdriver Monitoring の指標としてエクスポートされます。このエクスポートされた指標に基づいてワーカーの数を増やしていき、ワーカーは Pub/Sub メッセージをプルしてデータを処理し、Pub/Sub キューの長さを短くします。

以上を実行に移すには、最初に、自動スケーリングを有効にしたマネージド インスタンス グループを Cloud Console で作成します。この例では、Pub/Sub キューを構成済みで、使用するインスタンス テンプレートとワーカー イメージの準備が整っているものとします。


次に、“Autoscale based on”（自動スケーリングの基準）を“Stackdriver monitoring metric”（Stackdriver Monitoring の指標）に、“Metric export scope”（指標のエクスポート スコープ）を“Single time series per group”（グループあたりの単一時系列）に設定します。この設定により、個々のインスタンスから独立した指標に基づいてスケーリングされるようにマネージド インスタンス グループが構成されます。CPU 使用率のような一般的なスケーリング指標とは異なり、キューの長さはマネージド インスタンス グループ内のインスタンスから独立しています。

また、“Metric identifier”（指標 ID）を、特定のサブスクリプション名でフィルタリングされた未配送の Pub/Sub メッセージ数に設定します。これにより、オートスケーラはスケーリングの基準となる適切な Pub/Sub キューを見つけることができます。


これで、マネージド インスタンス グループが適切な指標と関連づけられました。続いて、グループがスケールアップ / ダウンするタイミングを設定します。“Scaling policy”（スケーリング ポリシー）を“Single instance assignment”（単一インスタンスの割り当て）にして、それに “2” を指定します。これによってマネージド インスタンス グループは、キュー内の未処理メッセージ 2 件につき 1 つのワーカー インスタンスを持ちます。

最後に、マネージド インスタンス グループ内のインスタンスの最小数と最大数を設定します。この例では、作業がないときはグループ内のインスタンスをゼロにスケールダウンしたいので、“Minimum number of instances”（インスタンスの最小数）に “0” を指定します。また、“Maximum number of instances”（インスタンスの最大数）には、ワークロードにとって意味のある数を指定します（この例では “20” とします）。


グループあたりの指標に基づくスケーリングをプログラム的に設定することもできます。それには、Google Cloud SDK CLI ツールで記述された以下のコマンドを実行します。

gcloud beta compute instance-groups managed set-autoscaling \
    my-queue-based-scaling-group --zone us-central1-b --project my-project \
    --min-num-replicas 0 \
    --max-num-replicas 20 \
    --update-stackdriver-metric \
    pubsub.googleapis.com/subscription/num_undelivered_messages \
    --stackdriver-metric-single-instance-assignment 2 \
    --stackdriver-metric-filter \
    'resource.type = pubsub_subscription AND resource.label.subscription_id = "MY_SUBSCRIPTION"'

これで準備完了です。Pub/Sub キューにメッセージが到着するとマネージド インスタンス グループがスケールアップし、メッセージが処理されるとスケールダウンします。すべてのメッセージが処理されてキューが空になると、マネージド インスタンス グループはグループ内のすべてのマシンをシャットダウンします。したがって、使っていないリソースの料金がかかることはありません。

下の図は、マネージド インスタンス グループ内のインスタンス数が Pub/Sub キューの長さに応じてどのように変わるかを示しています（タイムステップは 10）。


キュー内の作業が増え始めると、マネージド インスタンス グループは、キュー内の未処理メッセージ 2 件につき平均 1 インスタンス増のペースでスケールアップします。キュー内の作業量がタイムステップ 6 で減り始めると、マネージド インスタンス グループもそれに合わせてスケールダウンします。タイムステップ 9 でキューが空になると、マネージド インスタンス グループもタイムステップ 10 でインスタンス数がゼロになります。作業が新たに発生するまで、インスタンス数はゼロのままです。

他のキューイング システムにも有効

以上のように、キュー内のジョブに対応する形でマネージド インスタンス グループの自動スケーリングをセットアップすることは、このうえなく簡単です。作業量を測定する 1 つの指標とワーカーごとのシンプルな作業割り当てにより、応答性の高いスケーリング システムを数回のクリックでセットアップできます。

さらに、このアプローチは Pub/Sub キュー以外のキューイング システムにも有効です。作業量を Stackdriver の指標としてエクスポートし、その指標に応じてノードごとに作業を割り当てることができれば、マネージド インスタンス グループの適切なスケーリングが可能になり、コストの最適化に役立ちます。

この機能を使ってみたい方は、詳細に関するドキュメントをご覧ください。

* この投稿は米国時間 3 月 2 日、Product Manager の Pawel Siarkiewicz によって投稿されたもの（投稿はこちら）の抄訳です。

- By Pawel Siarkiewicz, Product Manager

Google Compute Engine インスタンスの作成、複製、管理に多くの時間を割いているお客様もおられるでしょう。先ごろ、こうしたタスクを従来よりも簡単にする新しい管理機能が追加されました。

インスタンスの作成やテンプレートの活用

Compute Engine インスタンス テンプレートの最新アップデートにより、既存のインスタンス テンプレートに基づいてインスタンスを作成したり、既存の VM インスタンスからインスタンス テンプレートを作成したりできるようになりました。こうした機能はマネージド インスタンス グループとは別に提供され、VM インスタンスの作成や管理を強力かつ柔軟に行えるようにします。

たとえば、VM インスタンスをウェブ ベースのアプリケーションの一部として実行していて、開発段階から本番環境へと移行しようとしているとしましょう。今回の新機能により、インスタンスを指定どおりに正確に設定し、その黄金の設定をインスタンス テンプレートとして保存できるようになりました。そのテンプレートを使えば、希望する設定でインスタンスを必要な数だけ起動させることができます。また、オーバーライド機能を使用すると、インスタンス テンプレートから立ち上げた VM を微調整することも可能です。

インスタンス テンプレートの作成には Cloud Console やコマンドライン インターフェース、API を使用します。ここでは、インスタンス テンプレートとインスタンスを Cloud Console から作成する方法を紹介しましょう。

サイドバーから “VM Instances” を選択し、“Create Instance” ドロップダウン メニューをクリックして “From template” を選びます。そして、インスタンスの作成に使用するテンプレートを選択します。

VM インスタンス起動時に複数の永続ディスクを作成

VMインスタンス用に複数の永続ディスクを作成することも簡単です。VM インスタンスの作成ワークフローの中で、複数の永続ディスクを作成できるようになったのです。もちろん、既存の VM インスタンスに後からディスクをアタッチすることも可能で、この部分に変更はありません。

この機能は、OS ディスクとは別のデータ ディスクやアプリケーション ディスクを作成する場合に便利です。インスタンス テンプレートに複数のディスクを定義し、マネージド インスタンス グループ内のインスタンスの起動時に複数のディスクを作成する場合にも、この機能を利用できます。これにより、マネージド インスタンス グループにおいて、それぞれが複数のディスクを持つ VM のグループをスケーラブルに作成できるようになります。

追加のディスクを Google Cloud SDK（gcloud コマンドライン インターフェース）で作成する場合は、--create-disk フラグを使用してください。

稼働中の VM インスタンスからイメージを作成

複製や共有、バックアップといった目的で VM インスタンスのイメージを作成するときに、そのインスタンスで稼働しているサービスを中断したくはないものです。これに応えるべく、稼働中の VM インスタンスにアタッチされているディスクからイメージを作成できるようになりました。Cloud Console で “Keep instance running” のチェックボックスをオンにするか、API にて force-create の フラグを true にしてください。

VM インスタンスを誤って削除しないように保護

時には事故も発生します。VM インスタンスを削除してしまい、主要なサービスが中断されるといったこともあるでしょう。そこで、単純なフラグを設定し、VM インスタンスが誤って削除されることがないよう保護してください。特に、SQL Server インスタンスや共有ファイル システム ノード、ライセンス マネージャというようなクリティカルなワークロードやアプリケーションが稼働している VM インスタンスにとって保護は重要です。

フラグは Cloud Console、SDK、API から設定（または解除）できます。下記のスクリーンショットは、UI から設定する方法を示しています。また、VM インスタンスの削除保護の状態をリスト ビューで確認することもできます。

まとめ

Compute Engine をお使いのお客様は、これらの新機能を Cloud Console や Google Cloud SDK、API を介してすぐにでも利用できます。まだ Compute Engine を利用していない場合は、無料トライアルに申し込んで 300 ドル分の無料クレジットをお受け取りください。

新機能の詳細は、インスタンス テンプレート、インスタンス作成、カスタム イメージ、削除保護に関するドキュメントをご覧ください。

* この投稿は米国時間 2 月 22 日、Google Compute Engine の Product Manager である Sophia Yang によって投稿されたもの（投稿はこちら）の抄訳です。

- By Sophia Yang, Product Manager, Google Compute Engine

このたび、96 個の vCPU と 624 GB までのメモリを搭載できる Compute Engine マシンタイプの正式提供（GA）が開始されました。これで、今まで以上にインテルの新しい Xeon Scalable Processors（Skylake）によるパフォーマンス向上とコア数増強の恩恵を受けられます。垂直スケーリングできるアプリケーションで 96 個の vCPU をすべて活用すれば、総所有コスト（TCO）を削減しつつ、アプリケーションの実行に必要な VM 数を減らすことができます。

この種のハイパフォーマンス VM は、3 種類の定義済みマシンタイプとカスタム マシンタイプで利用できます。また、拡張メモリの設定を調整して、アプリケーションで必要なメモリ容量と vCPU 数に合った VM を作ることも可能です。

これらの新しいマシンタイプは世界各地の GCP リージョンで利用可能です。現在、96 vCPU の VM を起動できるリージョンは、us-central1（アイオワ）、northamerica-northeast1（モントリオール）、us-east1（サウスカロライナ）、us-west1（オレゴン）、europe-west1（ベルギー）、europe-west4（エームスハーヴェン）、asia-east1（台湾）、asia-south1（ムンバイ）、asia-southeast1（シンガポール）です。新リージョンの追加についてはリージョンとゾーンのページでご確認ください。



新しい 96 vCPU マシンタイプは、SAP HANA のようなインメモリ データベースの実行、メディアのレンダリングと制作、衛星写真解析などのエキサイティングな試みで活用されています。

「数ペタバイトものグローバルな衛星写真に前処理を行い、キャリブレートおよびクリーンアップが施された、機械学習モデルで受け入れられる “science-ready” なデータにするために、私たちは膨大な量の画像圧縮を行っています。96 vCPU マシンタイプによって強化されたコンピュート リソースと、AVX-512 のような Advanced Vector Extensions をサポートした Skylake の活用により、パフォーマンスが圧縮で 38 %、画像拡張で 23 % 向上しました。数ペタバイトもの衛星および航空写真を操作するうえで、これはとても大きな前進です。」
- Tim Kelton 氏、Descartes Labs の共同設立者

96 vCPU マシンタイプは、Skylake と、Skylake がサポートする AVX-512 命令セットの高い処理能力をフルに活用できるようにします。たとえば、Google のパートナーである Altair は、新しいマシンタイプを使うことで、HPC ワークロードのパフォーマンスが最大で 1.8 倍向上することを実証しました。

パフォーマンスとスケーリングの向上を目指すお客様をサポートするため、私たちはインテルの協力を得て、Compute Engine 上での Intel Performance libraries の無料提供も行っています。

これらのコンポーネントはすべてのマシンタイプで利用できますが、特に効果が大きいのは、Skylake サーバーの 96 vCPU インスタンスをフル活用できるアプリケーションです。

次のグラフは、96 vCPU の Compute Engine インスタンスで Intel Distribution for Python の scikit-learn を使用したときのパフォーマンス向上の例を示しています。



新しいインスタンスは GCP コンソールで作成できます。gcloud コマンドライン ツールを用いた新しい仮想マシンの作成手順については、こちらのドキュメントをご覧ください。


私たちは、最新鋭のコンピュート インフラへのアクセスを GCP で提供することに努めています。今すぐ無料トライアルにサインアップし、300 ドル分の無料クレジットでお試しください。

* この投稿は米国時間 2 月 14 日、Compute Engine の Product Manager である Hanan Youssef によって投稿されたもの（投稿はこちら）の抄訳です。

- By Hanan Youssef, Product Manager, Compute Engine

Shazam や Schlumberger といったお客様は、Google Cloud のスケールや NVIDIA Tesla GPU のパワーを利用して、イノベーションやアクセラレーション、コスト節減を進めています。そうしたお客様へのサポートを強化すべく、Googleはこのたび、オンデマンドの Google Compute Engine VM に接続された NVIDIA Tesla GPU の使用料金を最大 36 % 値下げし、GPU のメリットを拡大しました。米国のリージョンの場合、VM に接続された各 K80 GPU の料金は 1 時間あたり 0.45 ドル、各 P100 GPU は 1 時間あたり 1.46 ドルとなります。

値下げされた GPU をカスタム マシンタイプおよび継続利用割引と併せて利用すると、インスタンス料金をさらに最大 30 % 抑え、高度に並列化されたコンピュート タスクを GPU で実行して、お得な料金で優れたパフォーマンスが得られます。

こうした GPU を使用する VM では、パフォーマンスとコストを考慮して VM の構成をきめ細かく指定することが可能です。具体的には、特定のアプリケーション向けに vCPU と GPU の数やメモリ容量を指定して VM を作成できます。

また、GPU とともに高いディスク パフォーマンスが必要な場合は、オプションで最大 3 TB のローカル SSD を GPU VM に接続することもできます。さらに、Google Cloud で GPU を使用するお客様がベアメタル パフォーマンスを得られるように、GPU は VM に直接パススルーされます。

大規模な並列処理能力を必要とする科学者やアーティスト、エンジニアが NVIDIA Tesla GPU を使用すれば、ディープ ラーニング、物理シミュレーション、分子モデリングを数日ではなく数時間で実行できます。

ワークロードの規模にかかわらず、Google Cloud Platform（GCP）は適切な量の処理能力を提供し、ジョブを実行できるようにします。

Google はさらに、プリエンプティブル ローカル SSD の料金を、オンデマンド ローカル SSD と比べてほぼ 40 % 安くしました。米国では 1 か月あたり 1 GB を 0.048 ドルで使用できます。

NVIDIA Tesla GPU と プリエンプティブル ローカル SSD の値下げがお客様に新しい機会をもたらし、ビジネスやエンジニアリング、科学の興味深い問題を解決するのに役立つことを願っています。

詳細は GPU のドキュメントを参照してください。料金の情報については、Compute Engine のドキュメントにおける GPU 料金のセクションをご覧いただくか、Google Cloud 料金計算ツールをお試しください。質問やフィードバックがありましたら、ヘルプのページをご活用ください。

強力な GPU を使用するインスタンスを使い始めるのは簡単です。Google Cloud Platform Console で作成し、起動するだけです。まだ GCP アカウントをお持ちでない方は、ぜひアカウントを申し込んで 300 ドル分の無料クレジットをご利用ください。

* この投稿は米国時間 11 月 20 日、Product Manager である Chris Kleban によって投稿されたもの（投稿はこちら）の抄訳です。

- By Chris Kleban, Product Manager

Google Cloud Platform（GCP）全体を支える SDN（Software-Defined Network）スタックの Andromeda は、バージョン 2.1 のリリースに合わせてイントラゾーン ネットワークのレイテンシを大幅に改善しました。Andromeda 2.0 と比べて Compute Engine VM 間のネットワーク レイテンシは 40 % も低減され、2014 年に初めて Andromeda を導入したときと比べると、レイテンシはおよそ 8 分の 1 になっています。

クラウドに移管され、ウェブ ブラウザ経由でアクセスされるアプリケーションが増えてくると、レイテンシは特に重要になってきます。指標としては帯域幅が最も重視されがちですが、アプリケーションのパフォーマンスの決定因子としてはレイテンシのほうが重要な場合が多いのです。

たとえば、HPC アプリケーションや memcache、インメモリ データベースといったワークロードのほか、金融取引、デジタル広告、動画、ゲーム、リテールなどではレイテンシを小さくすることがきわめて重要です。HTTP ベースのマイクロサービスについても、レイテンシが小さくなれば大幅に反応が良くなります。

Andromeda 2.1 におけるレイテンシの改善は主として、Linux の準仮想化デバイス ドライバである virtio の上に構築されたハイパーバイザ バイパスによるものです。Andromeda 2.1 は、パフォーマンスが重視されるパケット単位の処理でハイパーバイザを完全にバイパスし、共有メモリ ネットワーク キューを介して Compute Engine のゲスト VM と Andromeda のソフトウェア スイッチが直接通信できるようにすることで、レイテンシの低減を実現しました。

以前のアプローチでは、ハイパーバイザ スレッドがゲスト VM と Andromeda ソフトウェア スイッチの間のブリッジになっていました。パケットは、VM からハイパーバイザ スレッド、ローカル ホストの Andromeda ソフトウェア スイッチを経由して物理ネットワークに入り、相手先の Andromeda ソフトウェア スイッチからハイパーバイザ、VM に届くようになっていたのです。

しかも、このハイパーバイザ スレッドは、パケットをブリッジングしていないときにはスケジューリングから外れていたため、新しいパケットを処理するときのテイル レイテンシが高くなっていました。1 回のネットワーク ラウンドトリップで、コストのかかるハイパーバイザ スレッドのウェイクアップが 4 回も必要になることが多かったのです。

Andromeda 2.1 のハイパーバイザ バイパスによって最適化されたデータパス

実際のパフォーマンス

新しい Andromeda 2.1 スタックでは VM 間のネットワーク レイテンシが顕著に小さくなります。次に示す数値は、オリジナル スタックのラウンドトリップ時間の中央値と比較して、レイテンシがどれくらい低減されたかを示しています。

Andromeda のバージョンアップに伴うレイテンシ低減の度合い

こうしたラウンドトリップ時間の短縮は、レイテンシの影響を受けやすいアプリケーションのパフォーマンスに直接反映されます。ハイパフォーマンスのインメモリ NoSQL データベースである Aerospike を例にとってみましょう。次に示すように、新しい Andromeda スタックにより、Aerospike のリクエスト レイテンシは小さくなり、リクエスト スループットは向上しています。


Andromeda SDN は Google Cloud の基盤を支える技術であり、それゆえどのアプリケーションを実行する場合でもイントラゾーンのレイテンシには同様の改善が見られるはずです。

柔軟性と確実性を提供

Andromeda SDN は、どのハードウェア ベースのスタックよりも高い柔軟性を実現します。SDN であれば、仮想ネットワーク インフラストラクチャ全体をスピーディに開発、総点検できます。新しいクラウド ネットワーク サービスや機能を実装したり、セキュリティ パッチを適用したり、パフォーマンスを大幅に改善したりすることも可能です。しかも、SDN の柔軟性のおかげでコードを徹底的にテストできるため、ダウンタイムやリブートはもちろん、VM のマイグレーションすら必要とせずに、自信を持ってそれらを Google Cloud にデプロイできます。

Andromeda SDN が提供する新機能とネットワーク パフォーマンスの向上にご期待ください。

* この投稿は米国時間 11 月 2 日、Staff Software Engineer である Jake Adriaens によって投稿されたもの（投稿はこちら）の抄訳です。

- By Jake Adriaens, Staff Software Engineer

家庭用ゲーム機においても「オンライン対応」が当たり前の時代。しかしオンラインゆえにユーザーのトラフィックは予測困難で、バックエンドシステムには従来以上の柔軟性や高性能が求められます。今回「Google Cloud Platform」を採用することで、厳しい条件のバックエンドを、高性能、高可用かつ低コストで実現した事例をご紹介します。

■写真左から



■ 利用している Google Cloud Platform サービス
Google Compute Engine、Cloud Storage、Cloud Load Balancing


■ 株式会社ディンプス
大手ゲーム会社から独立した開発者たちによって、2000 年に設立。業務用および家庭用コンピュータ ゲームの研究、開発を行う。株主には、国内の著名なゲーム パブリッシャーが名を連ね、さまざまなプラットフォームに向けた、ゲーム、マルチメディア コンテンツの開発を手がける。

独自性を持ち、かつコスト効果の高いサービス実現に必須だったクラウド移行

株式会社バンダイナムコエンターテインメントが販売する、全世界規模での大ヒットゲーム「ドラゴンボール ゼノバース」。2015 年に発売され、悟空などの人気キャラクターと一緒に戦える、ファンにはたまらないゲームです。その続編である「ドラゴンボール ゼノバース 2」は期待の新作で、もちろんオンライン対応。ディンプスは、この両方を開発した実力派の制作会社で、「ゼノバース ２」のオンラインサービスのバックエンドに Google が提供する「Google Cloud Platform」を全面採用しました。

実は、同社は 2000 年の創業当時から、自社が開発するゲームのオンライン対応に着手。2005 年には本格的なオンライン対戦ゲームを運営開始しました。特筆すべきは、このゲームに向けて、独自のオンラインゲーム用サービスを可能にするため、自社にサーバーを設置し他のオンラインゲームとの差別化を図っていたことです。
ディンプスの田中さんは「2005 年当時はクラウドサービスが今ほど一般的ではなかったので、米国から巨大なサーバーを輸入し、オンプレミスで運用をしていました。初期導入や運用のコストも、とても大きかったですね」と当時を振り返ります。

このようにディンプスは自社でオンライン対応のノウハウを蓄積しつつ、一方で、ネットワークとバックエンドシステムに関しては、より高い技術力を持つパートナーとの協力体制を模索していました。そんな中、業界内で定評があったシリコンスタジオ株式会社とパートナーシップを締結。1 作目の「ドラゴンボール ゼノバース」では、オンライン対応に関わる開発や運用について、両社が協力してサービスの提供を行いました。
シリコンスタジオは、バックエンド領域での技術力に加え、自社で運営するデータセンターを持っています。これはネットワークサービスを提供するうえで、コスト面、運用面での大きなメリットです。では、両社が最新作である「ドラゴンボール ゼノバース 2」のバックエンドを、既存のデータセンターを使わず全面的に Google Cloud Platform へと移行した理由は何だったのでしょうか。
それは「コスト」に関する「柔軟性」と圧倒的な「優位性」だったといいます。

オンラインゲームのバックエンドに要求される適正なスペックは、ゲームの仕様やリアルタイムのプレイヤー数、ビジネス戦略などによって常に複雑に変化します。この変化に、合理的なコストで柔軟に対応できるバックエンドを確保するには「オンプレミスからクラウドへの移行は必然だった」と田中さんはいいます。

またシリコンスタジオでは、オンラインゲームの分野において、こうしたニーズが高まっていくことを視野に、2014 年ごろからクラウドサービスの検証や比較検討を始めていました。「ドラゴンボール ゼノバース」は、基本的にはオンプレミスのシステムで運用しつつ、一部を Google Cloud Platform を利用する形で、クラウドの運用実績を積んでいました。クラウドサービスの中から、Google Cloud Platform を選択した理由として、シリコンスタジオの岡田さんは圧倒的な「コスト」の優位性を挙げます。

「これまでオンプレミスでシステムを運用していた実績がありますので、それと同等の性能を IaaS 上のインスタンスで実現できることを基準に、各種クラウドの比較検討を進めました。Google Cloud Platform は、他の著名なサービスと比較して、料金が半額以下になる見込みがあり、それが選択理由のひとつでした。」

また課金体系が、他のサービスと比べてわかりやすい点にも魅力を感じているそうです。
シリコンスタジオの関谷さんは「他のクラウドサービスの場合、ある程度の性能を確実に確保しようとすると、月単位のリザーブ契約となり、コストが増える傾向にあります。一方、Google Cloud Platform では、そうした契約が不要で、かつ使ったリソースの量が増えれば、その量に応じて自動的にボリュームディスカウントがかかる仕組みになっています。われわれの場合には、この仕組みのほうが使い勝手が良いのです」と話します。

コスト面に加え「信頼性」「安定性」も実証－活用範囲の拡大を視野に

運用を開始してからは、コスト面のメリット以外に Google Cloud Platform の特長のひとつである「ライブ マイグレーション」にも大きなメリットを感じているそうです。ライブ マイグレーションは、IaaS 上のインスタンスを止めることなく、Google 側で自動的にインフラ部分のメンテナンスや機能強化を行う仕組みです。

「無停止でのライブ マイグレーションは、一般消費者向けにサービスを提供しているわれわれの立場からは、非常にありがたいです。」（岡田さん）

「加えてライブ マイグレーションは、インフラ部分の性能強化も自動的に行われる点が興味深いですね。われわれの場合、検討段階から現在に至るまで、継続的にオンプレミスと Google Cloud Platform 上のインスタンスとの間で性能比較を行っています。検討を開始した当時は『性能面でクラウドがオンプレミスの物理環境を超えることはない』と考えていたのですが、現時点で既にクラウドのほうがオンプレミスよりも高いパフォーマンスを出せるようになっています。」（関谷さん）


インフラの性能が、Google によって継続的に改善されることは、ユーザーにさまざまなメリットをもたらします。たとえば、稼働中のインスタンスに対し予想外のアクセスが集中しても、ライブ マイグレーションによってインフラ側の性能が上がっていれば、そのままでも十分に対応できる可能性が高まります。逆に、従来と同等のパフォーマンスを得るために必要なインスタンスのコストは相対的に下がっていくため、ユーザーが適宜調整を行えば、ランニングコストを圧縮することも可能です。

「ドラゴンボール ゼノバース 2」での Google Cloud Platform 全面採用を経て、両社では、今後さらにその活用範囲を拡大していくことも検討しているそうです。


「ゼノバース 2 では、オンプレミスで動かしていた前作のシステムを、そのまますべてクラウドに移行することを目標に構築しました。移行という部分は大成功でしたが、これだけではまだ Google Cloud Platform の本当の力を引き出せていないと思っています。ワールドワイドに展開するタイトルにおいては、コンテンツ配信を高速化するためにエッジロケーション（世界各地に設置された Google 専用ネットワークへの接続ポイント）を効果的に使えないかとか、プレイヤーデータ管理の仕組みとして分散データベースである『Cloud Spanner』を活用できないかなど、今後のタイトル開発では検討していきたいです。」（田中さん）

「Google Cloud Platform のマネージドサービスや、 PaaS である『App Engine』などについて、既に機能検証や、実案件への導入を始めつつあります。最新の機能についても、随時、検証や評価を進めながら、ニーズに応じて最適な部分に Google の技術を取り入れたいと思っています。さらに使い勝手の良いサービスに進化させていってほしいですね。」（関谷さん）
両社では、これまでの運用を通じ、技術的な問題に対する Google の対応にも信頼を感じているとのこと。加えて今後の活用レベルの向上にも期待に応えてくれるという感触を得ているようです。



株式会社ディンプスの導入事例 PDF はこちらをご覧ください。
GCP のその他の導入事例はこちらをご覧ください。

マネージド インスタンス グループは Google Compute Engine の重要な機能の 1 つです。この機能を使って同じインスタンスのコレクションを 1 つの単位として管理すれば、新しい VM をすばやくデプロイし、統一的に構成、設定することができます。

私たち Google は先ごろ、Compute Engine VM をプログラムで大規模に更新できる新しい Managed Instance Group Updater をベータ リリースしました。この Updater はマネージド インスタンス グループに完全に統合されているため、インスタンス上のソフトウェアの更新、パッチの適用、ステージング / テスト デプロイのロールアウトが今までになく簡単になります。

新しい Updater は次の機能をサポートしています。

• 新旧のインスタンス テンプレートを用いたインスタンスの更新
  
• 同時に更新するインスタンス数（1 個、一部、全部）の指定
  
• インスタンスの置換中に処理能力を維持するため、追加インスタンスの一時的なデプロイ
  
• マネージド インスタンス グループに含まれる全インスタンスの再作成もしくは再起動（テンプレートの変更なし）
  
• インスタンス更新の間の一時休止設定によるデプロイ ペースの制御
  

機能を 1 つずつ説明するのではなく、上記のようにまとめて説明すると威圧的に感じられるかもしれないので、よくある 3 つのユース ケースを例に、Updater の機能について紹介します。

• 単純な更新
  
• カナリア テスト
  
• 全インスタンスの再作成
  

なお、この投稿では UI と gcloud コマンドラインの両方で Updater の使い方を説明しますが、Updater の機能は API 経由でも使用できます。

単純な更新（基本的なローリング更新）

まずは、一度に 1 インスタンスずつ更新して、マネージド インスタンス グループ全体にアップデートをデプロイするという初歩的なユース ケースから見ていきます。

my-instance-group というインスタンス グループが、myapp-version-a というテンプレートを実行してすべてのインスタンスを起動しているとします。このグループに対してソフトウェアの新バージョンをデプロイするため、Updater を使って myapp-version-b というテンプレートをデプロイしましょう（OS のパッチ適用 / 更新でも同じ方法が使えます）。

gcloud beta compute instance-groups managed rolling-action 
start-update my-instance-group --version template=myapp-version-b

上記操作により、my-instance-group は、myapp-version-a のインスタンスを削除し、同時に myapp-version-b のインスタンスを作成して、その新インスタンスが健全な状態になるのを待ってから次のインスタンスの作業に移ります。そしてそのサイクルを、全インスタンスが更新されるまで続けるという形で myapp-version-b をデプロイします。

更新をロールバックしたい場合は、ターゲットを myapp-version-a に変えて同じコマンドを実行します。

gcloud beta compute instance-groups managed rolling-action 
start-update my-instance-group --version template=myapp-version-a

このようなローリング更新は Updater のデフォルト動作であり、通常のデプロイにおいて非常にうまく機能します。ただし、マネージド インスタンス グループが非常に大規模な場合は、一度に 1 インスタンスずつの更新には多くの時間がかかります。そこで次に、基本的には同じやり方ですが、一度に全体の 4 分の 1 のインスタンスを更新してみましょう。

gcloud beta compute instance-groups managed rolling-action 
start-update my-instance-group --version template=myapp-version-b 
--max-unavailable 25%

max-unavailable という新しいパラメータを使っていることに注目してください。このパラメータは、同時にオフライン状態にできるインスタンスの数を Updater に指示します。インスタンス数が数十、数百、数千のいずれであれ、インスタンスの更新は指定された割合で進みます。

それなら、同時にすべてのインスタンスを更新できるのではないかと思われるかもしれません。答えはイエスです。max-unavailable に 100 % を指定すれば、マネージド インスタンス グループは全インスタンスをまとめて更新します。テスト環境やバッチ処理システムのように、安定したアップタイムの維持が必要とされない場合は、これがとても役に立ちます。

カナリア テスト

次は、もっと高度なユース ケースについて考えてみましょう。全面的な更新に踏み切る前に、インスタンスのサブセットに新ソフトウェアをデプロイすることはカナリア テストと呼ばれ、堅牢で可用性の高いシステムを構築するうえでベスト プラクティスとされています。これにより、新ソフトウェアの影響を最小限に抑えつつ、実際の環境で新ソフトウェアをテストできます。

前述の「単純な更新」と同じ例のもとで、1 つのインスタンスだけに myapp-version-b をデプロイしてみましょう。

gcloud beta compute instance-groups managed rolling-action 
start-update my-instance-group --version template=myapp-version-a 
--canary-version template=myapp-version-b,target-size=1

my-instance-group は、myapp-version-a のインスタンスを 1 つ削除し、myapp-version-b のインスタンスを 1 つ作成します。それ以上の更新は行いません。

インスタンス グループのスケーリングが必要になった場合は、myapp-version-b の 1 インスタンスを残してテストを続けつつ、スケーリングを行います。その後、myapp-version-b をもっと大きなグループ（ここでは全体の半分）にデプロイできる状態になったら、次のようにします。

gcloud beta compute instance-groups managed rolling-action 
start-update my-instance-group --version template=myapp-version-a 
--canary-version template=myapp-version-b,target-size=50%

my-instance-group は、両者が半々（50 % ずつ）になるまで myapp-version-a インスタンスを myapp-version-b インスタンスに置き換えていきます。自動スケーリング機能によってインスタンスを増減させるときも、my-instance-group はこの割合を保ち、設定された水準でのカナリア デプロイを維持します。

完全に移行できる状態になったら、全インスタンスで myapp-version-b を実行するよう Updater に指示します。これは、「単純な更新」のときと同じ処理です。

gcloud beta compute instance-groups managed rolling-action 
start-update my-instance-group --version template=myapp-version-b

全インスタンスの再作成

新しいテンプレートを使わず、現在のテンプレートを使い続けながら全インスタンスを置き換えたい場合もあるでしょう。これは、イメージ ファミリーを使っていて、インスタンス全体にイメージの最新バージョンを使わせたいときによく見られるパターンです。全インスタンスのローリング置換の開始は、ローリング更新の開始と同じパターンを踏襲しています。

gcloud beta compute instance-groups managed rolling-action replace 
my-instance-group --max-unavailable=10%

ここでは、オフラインにしてもよいインスタンスの割合を指定するために、「単純な更新」のときと同じ max-unavailable パラメータを使っていることに注意してください。

次のステップ

今回説明した 3 つのユース ケースは Managed Instance Group Updaterの最も一般的な使用例ですが、このツール全体から見れば、ほんの一部の機能を紹介したに過ぎません。

max-unavailable や max-surge などによる柔軟な制御、カナリア更新のサポート、start-update、restart、recreate といった豊富なコマンドにより、さまざまな形でマネージド インスタンス グループを管理できるようになりました。

詳細はこちらのドキュメントをご覧ください。また、質問やフィードバックは GCE ディスカッション グループまでお寄せください。

Managed Instance Group Updater の試用は Cloud Console から可能です。Google Cloud Platform（GCP）をまだお使いでない方は、こちらからサインアップしていただければ、Compute Engine と Updater を試せる 300 ドル分のクレジットを自動的に入手できます。

* この投稿は米国時間 9 月 6 日、Product Manager である Pawel Siarkiewicz によって投稿されたもの（投稿はこちら）の抄訳です。

- By Pawel Siarkiewicz, Product Manager