Google Cloud Platform Japan Blog
最新情報や使い方、チュートリアル、国内外の事例やイベントについてお伝えします。
セキュリティ比較 : コンテナと VM の違いとは
2017年8月22日火曜日
ここ数年、大企業やスタートアップの間でコンテナが大きな人気を集めています。コンテナは、開発ペースを大幅に引き上げ、リソースの効率的な利用によってコストを減らし、本番環境の一貫性を高めます。とはいえ、従来の VM ベースのアプリケーションに比べると、コンテナにはセキュリティに関して独特の意味合いがあるにもかかわらず、そのことがあまり理解されていないようです。
Google には、10 年以上にわたってコンテナ ベースの本番インフラストラクチャを運用してきた実績があります。この投稿では、従来の VM ベースのアプリケーションとコンテナにおけるセキュリティの違いについて、私たちの見方を皆さんとシェアしたいと思います。
コンテナ化されたワークロードは、いくつかの点で従来のアプリケーションとは大きく異なります。コンテナには次のような利点もあります。
アプリケーションがモジュール化される（モノリスからマイクロサービスへ）
リリースのオーバーヘッドが軽減される（便利なパッケージング形式と、明確に定義された CI/CD）
寿命が短いため、陳腐化したパッケージの残存リスクが低減される（数か月～数年が数時間～数日へ）
稼働後に、最初の状態からの逸脱が発生しにくい（ワークロードが短命で、簡単に再構築や再プッシュが行えるため、メンテナンスのための直接アクセスが減る）
では、こうした違いがセキュリティにどのような影響を及ぼすのかを見てみましょう。
コンテナのセキュリティ境界にまつわる誤解
コンテナのセキュリティに関するよくある誤解の 1 つは、コンテナは VM と同じようにセキュリティ境界となるべきなのに、そのような保障がないので VM よりもセキュアでないデプロイ方法だという見方です。しかし本当は、コンテナはミニ VM ではなく、アプリケーションをパッケージングして送り届けるための便利なメカニズムだと考えるべきなのです。
従来のアプリケーションが VM 内で完全に隔離されているわけではないのと同様に、攻撃者や悪意のプログラムが実行中のコンテナの外に飛び出し、同じ VM で実行されている他のコンテナを支配することもありえます。しかし、適切に保護されたクラスタのコンテナであれば、カーネル、共通のコンテナ インフラストラクチャ（Docker など）、VM サービスのいずれかに未パッチの脆弱性が残っていないかぎり、プログラムがコンテナの外に出ることはできません。
VM への攻撃のリスクを軽減するため、
Google Container Engine
は
フルマネージド ノード
を提供するとともに、VM 内の脆弱性や陳腐化したパッケージ（サードパーティによるアドオンを含む）を積極的に監視し、必要に応じて自動更新や自動修復を行っています。したがって、新しい脆弱性が見つかったとしても、コンテナの外に出るための攻撃手段は限られます。
適切に保護され、更新されている VM であれば、通常のアプリケーションとコンテナ ワークロードの両方に対してプロセス レベルの分離機能を提供します。また、Linux のセキュリティ モジュールを使用すれば、コンテナの攻撃対象領域はさらに狭まります。たとえば、オープンソースのコンテナ オーケストレーション システムである
Kubernetes
は、コンテナからアクセスできるシステム コールに制限を加えるために、
AppArmor
、Seccomp、および SELinux とのネイティブな統合をサポートしています。
コンテナの分離をサポートするために Kubernetes が提供しているツールは他にもあります。PodSecurityPolicy を使えば、ワークロードがノード レベルで実行できることやアクセスできることに制限を加えることが可能です。また、特に機密性が高く、VM レベルでの分離が必要なワークロードの場合は、
taint and toleration
を使用することで、互いに信頼できるワークロードでなければ同じ VM でスケジューリングされないようにすることができます。
VM 内のアプリケーションでもコンテナ ワークロードでも、セキュリティ確保のための最終的な防壁は VM が提供します。セキュリティ レベルがまちまちなプログラムを同じ VM の上で実行したりしないのと同じように、セキュリティ レベルがまちまちなポッドを同じノードで実行することは避けるべきです。ポッドの間に確実なセキュリティ境界はないのです。
陳腐化したパッケージの排除
VM で実行されているアプリケーションに対する最も一般的な攻撃対象は、陳腐化したパッケージです。実際、既知の脆弱性の 99.9 % は、共通脆弱性識別子（
CVE
）が公開されてから 1 年以上もの間、悪用され続けています（
Verizon Data Breach Investigation Report, 2015
）。モノリシック アプリケーションでは保守担当者が OS やアプリケーションに手動でパッチを適用することが多く、VM ベースのワークロードはしばしば長期にわたって更新されずに実行され続けます。
コンテナの世界では、マイクロサービスと明確に定義された CI/CD パイプラインのおかげで、従来よりも簡単にリリース頻度を高めることができます。コンテナ化されたワークロードは一般に短命で（数日、場合によっては数時間）、パッケージの陳腐化によって生まれる攻撃対象領域は大幅に狭まっています。
Container Engine のホスト OS はハードニングされており、自動更新されます。さらに、
フルマネージド ノード
を採用すればゲスト OS とシステム コンテナでも自動パッチおよび自動更新が行われるため、既知の脆弱性によるリスクはさらに低くなります。
要約すると、コンテナは、高いリリース頻度を可能にする CI/CD パイプラインとの連携により、できるかぎり頻繁に最新のパッチで更新される体制を確立しているのです。
一元的なガバナンスのために
VM で従来のアプリケーションを実行していると、本番環境でどのソフトウェアが実行されているのかを正確に把握することはほぼ不可能であり、ましてどのソフトウェアがデプロイされようとしているのかを管理することはできません。これは重大な欠点であり、その根本原因は 3 つあります。
VM は不透明なアプリケーション パッケージング形式であり、デプロイ前に内容を検査して一覧化するためのワークフローを効率的な形で確立することが難しい。
VM イメージ管理は標準化されておらず、広く採用されてもいないため、プロジェクトにデプロイされたことのあるすべてのイメージを追跡することは難しい。
VM ワークロードは寿命が長く、しかもアプリケーションおよび OS の更新やメンテナンスの際に管理者によって頻繁に操作されるため、それが原因でデプロイ時のもともとの状態から大きく逸脱してしまうことがある。
また、大規模な形でアプリケーションの状態を正確に把握することは難しく、それゆえ一般的なセキュリティ管理では、アプリケーションや OS の挙動、設定の異常を見つけることに重点を置くことで妥協してしまうのです。
それに対してコンテナは、より透明で検証しやすく変更不能なアプリケーション パッケージ形式のため、デプロイ前にコンテナの内容を検査して一覧化するためのワークフローを簡単に確立できます。さらにコンテナには、標準化されたイメージ管理メカニズム（特定コンテナのすべてのバージョンを追跡している一元的なイメージ リポジトリ）もあります。コンテナは一般に短命で、簡単に再構築や再プッシュが可能であり、実行中のコンテナがデプロイ時の状態から逸脱することも減ります。
これらの特徴は、コンテナの開発やデプロイのワークフローをセキュリティの管理下に置くうえで役に立ちます。適切なプロセスとコンテンツによって構築された適切なコンテナだけがデプロイされるようになれば、企業は本番環境で実行されているものを正確に知り、管理することができます。
セキュリティに対する責任の共有
VM ベースの従来のアプリケーションは、ある意味でコンテナ化アプリケーションよりも単純なセキュリティ モデルを提供しています。その実行環境は、一般に 1 人のオーナーによって作成、管理され、本番デプロイされるコードは IT によって全面的に管理されています。頻度の低い長期的なリリースには、一元化されたセキュリティ チームがすべての本番プッシュを詳細にチェックできるという意味もあります。
それに対してコンテナは、アジャイルなリリース プラクティスを実現し、スピーディで頻繁な本番プッシュを可能にする一方で、一元的なセキュリティ評価のための時間は VM アプリケーションよりも短く、セキュリティの責任をデベロッパーに委ねています。
コンテナを採用する企業は、開発のペースが上がり、セキュリティの責任が一元化されないことによるリスクを緩和するために、上述したベスト プラクティスも採用すべきでしょう。本番環境にデプロイされる外部依存コード（たとえばオープンソースのベース イメージ）を一元管理するプライベート レジストリの導入、脆弱性や問題のある依存コードを検出するイメージ スキャニングの CI/CD プロセスへの統合、既知の良質なソフトウェアだけが本番デプロイされるようにするためのデプロイ時間管理の確立などがそうです。
要するに、由緒正しく品質の高いセキュアなソフトウェアの自動的で効率的なサプライチェーンを確保すれば、セキュリティ面で大きなメリットが得られ、しかも手動のレビューを定期的に組み込むこともできるのです。
まとめ
VM ベースのアプリケーションが持つセキュリティ上の制約の多くは（現状では）コンテナにも当てはまりますが、アプリケーションのパッケージングとデプロイのためにコンテナを使用すると、より正確で効率的なセキュリティ管理への道が開けます。
このブログでは、コンテナ、セキュリティ、効果的なソフトウェア開発チームについて深く掘り下げる記事をこれからも掲載していきます。ご期待ください。
Google Cloud Platform
（GCP）のセキュリティ モデルの詳細を学びたい方は、
こちらのウェブ ページ
を参照してください。
* この投稿は米国時間 8 月 9 日、Product Manager である Jianing Guo によって投稿されたもの（投稿は
こちら
）の抄訳です。
- By Jianing Guo, Product Manager
Codefresh による Kubernetes と Container Engine への自動デプロイ
2017年8月22日火曜日
編集部注 :
今回は、Google のパートナーである
Codefresh
の投稿をお届けします。Codefresh はこのほど、社名と同名のデリバリ ツールと
Google Container Engine の密接な統合により
、Kubernetes へのコンテナのデプロイを容易にしました。本稿では、この統合と、Container Engine へのデリバリを数分で自動化する方法が詳しく紹介されています。
Codefresh は、コンテナのデリバリを支援するこだわりのツールチェーンです。お客様は Codefresh を利用して、コンテナのビルド、テスト、デバッグ、デプロイに関連するタスクを自動または手動で行っています。Kubernetes で動作するコンテナ ベースのアプリケーションはスケーラビリティと信頼性が高く、私たちはそうしたコンテナのデプロイ プロセスを効率化することを目指しています。そこでこのたび、Codefresh で Kubernetes へのデプロイを 10 分間でセットアップできるようにしました。
私たちはこの統合を、新規ユーザーと上級ユーザーの協力を得てテストしました。Kubernetes の初心者ユーザーからは、「Codefresh を使えば、ごく簡単にアプリケーションを Kubernetes にデプロイできる」という感想が寄せられています。一方、上級ユーザーからは「簡単に Kubernetes のフル機能にアクセスし、アプリケーションに応じてそれらを構成できる点が気に入っている」という声をいただいています。
4 つのステップで Kubernetes へのデプロイを開始
ほんの数ステップで Codefresh を立ち上げ、Kubernetes へのコンテナのデプロイを開始できます。以下の短い動画はそのプロセスを紹介しています。
これらのステップは次のとおりです。
ステップ 1 : Google Cloud でクラスタを作成
Google Cloud Console
から Container Engine に移動し、“Create a container cluster”（コンテナ クラスタを作成）をクリックします。
ステップ 2 : Codefresh を Google Cloud Platform（GCP）に接続
Codefresh
（無料です）にログインし、Admin -> Integrations に移動して Google アカウントでログインします。
ステップ 3 : クラスタを追加
クラスタを追加すると、自動パイプラインと手動のイメージ デプロイで利用できます。
ステップ 4 : デプロイを開始！
ポート、レプリカを設定し、サービスをエクスポーズするか、デフォルトに従います。
ステップ 5（オプション）: 生成された Yaml ファイルを調整
Codefresh の構成画面では deployment.yml と pod.yml ファイルも生成します。これらのファイルは直接編集できます。上級ユーザーは自分の yml ファイルを使って、Codefresh に認証やデプロイなどを処理させることができます。
ビルド、テスト、デプロイ パイプラインを接続
Codefresh と GCP を構成したら、テスト、承認ワークフロー、認証を含むデプロイを自動化できます。Codefresh を使用すれば、開発者や DevOps チームは、事前に合意しておいたルールや基準に基づいて、どのような場合にイメージを手動テストに回すか、カナリア クラスタにデプロイするか、もしくは本番環境にデプロイするかを設定できます。
さらに、このインフラストラクチャと自動化の組み合わせにより、チームは迅速なイテレーションを行うことができ、最終的に、変更を含むコードの品質を向上させることができます。
GCP と Codefresh の共催ウェビナーのご案内
もっと知りたくはないですか？ Container Engine 担当プロダクト マネジャーの William Denniss 氏と、Codefresh のフルスタック デベロッパーである Dan Garfield が、Kubernetes ネイティブなパイプラインへの接続によって開発がいかにスピードアップするかを紹介します。8 月 30 日開催のこのウェビナーには
こちら
から申し込みできます。
Kubernetes へのデプロイを始めてみませんか。Codefresh では 1 か月あたり 200 回、無料でビルドできます。新規アカウントには 500 ドル分の GCP クレジットが提供されます
1
。ぜひ
お試しください
。
1 通常の利用条件が適用されます。
* この投稿は米国時間 8 月 8 日、Codefresh の CEO である Raziel Tabib 氏によって投稿されたもの（投稿は
こちら
）の抄訳です。
- By Raziel Tabib, CEO, Codefresh
ダーク ローンチとは何か : CRE が現場で学んだこと
2017年8月21日月曜日
新しいサービスを立ち上げるときは、予期されるトラフィックに対応したいと思うと同時に、途中で何かが起こっても実際のユーザーに影響を及ぼすことは避けたいと考えるものです。では、どうすればサービスの本格稼働の前に問題を見つけることができるのでしょうか。そんなときはダーク ローンチ（dark launch）を検討してください。
ダーク ローンチとは、実際のユーザーから発生したトラフィックをコピーして新サービスに送信し、新サービスからの結果をユーザーに返す前に破棄することです（注 : ダーク ローンチを “
フィーチャー トグル
”（機能切り替え）と呼ぶこともありますが、それだとサービスの立ち上げに伴う “ダーク” な隠れトラフィックの側面を捉えることはできません）。
ダーク ローンチでできることは次の 2 点です。
新サービスが、既存サービスと同様に実際のユーザーのクエリに対応でき、以前にはなかった不具合が発生するようなことがないことを確認する。
現実的な負荷のもとでサービスのパフォーマンスがどうなるかを測定する。
ダーク ローンチは通常、元のトラフィックの一部から開始し、全トラフィックが新バックエンドにコピーされる 100 % のローンチへと徐々に移行していきます。その過程で、正常かどうかを確認したり課題に対処したりするのです。新サイトに対するトラフィックのソースがすでに手元にある場合、たとえば既存のフロントエンドから新フロントエンドに移行するような場合は、ダーク ローンチが非常に適していると言えるでしょう。
どこでトラフィックを分けるか : クライアント？ それともサーバー？
ダーク ローンチを検討するにあたってカギとなるポイントの 1 つは、どこでトラフィックのコピーや分岐を行うかということです。通常これはアプリケーションのフロントエンドで行います。つまり、（負荷分散後に）ユーザーから HTTP リクエストを受信してレスポンスを計算する最初のサービスのところです。ここは変更によるフリクションが最も低いため、分岐点として理想的なのです。
この場合の変更というのは、新しいバックエンドに送る外部トラフィックの割合を変更することを指します。ダーク ローンチのトラフィックの割合を 0 % に戻すよう迅速にアプリケーションのフロントエンドに設定変更をプッシュできることは、ダーク ローンチのプロセス上（非常に重大なことではないにしろ）大切なことなのです。
既存のアプリケーション フロントエンドを変更したくないときは、アプリケーション フロントエンドの新旧バージョン双方に対してトラフィックを分岐し、レスポンスの差分を処理する新しいプロキシ サービスにリプレースするのもよいでしょう。
ただし、これには負荷分散の設定を調整してダーク ローンチ前にプロキシを挿入し、その後取り除く必要があるため、ダーク ローンチの複雑さが増します。そのプロキシには独自のモニタリングやアラートがほぼ確実に必要となるでしょう。ユーザー トラフィックのすべてがそこを通過することに加え、まったく新しいコードとなるためです。それが壊れてしまったら、かなり困ったことになります。
そのほか、クライアント レベルでトラフィックを
2 つの異なる URL
に送るという方法もあります。1 つはオリジナル サービスに送り、もう 1 つは新しいサービスに送るのです。完全に新しいアプリケーション フロントエンドのダーク ローンチを行い、既存アプリケーションのフロントエンドからトラフィックを送ることが現実的ではない場合（たとえば、オープンソース バイナリによって稼働していたウェブ サイトを自分のカスタム アプリケーションで稼働させようと考えている場合）、この方法が唯一の解決策となります。しかし、このアプローチにも別の課題があります。
クライアントを変更することで生じる主なリスクは、
クライアントの動作を制御できないこと
です。新しいアプリケーションへのトラフィックを抑制する必要がある場合は、少なくとも関連するすべてのモバイル アプリケーションに設定の更新をプッシュしなくてはなりません。しかし、大半のモバイル アプリケーションには設定変更を動的に伝達するフレームワークが組み込まれていないため、このようなケースでは新たにモバイル アプリケーションをリリースする必要があります。また、モバイル アプリケーションからのトラフィックが倍増し、ユーザー データの消費量が増える可能性もあります。
クライアントの変更で生じるもう 1 つのリスクは、宛先変更が通知されることです。特にモバイル アプリケーションの
ティアダウン
がいつも外部から注目されている場合、これは危険です。レスポンスの差分取得やロギングについても、クライアント内で行うよりもアプリケーション フロントエンドで行うほうがとても簡単です。
ダーク ローンチの効果測定法
ダーク ローンチは、その効果を実際に測定しないのであれば、実施する意義はほとんどありません。では、トラフィックを分岐させたときに、どうすれば新サービスが実際に稼働していることを把握できるのでしょうか。負荷がかかっている状態でどのようにパフォーマンスを測定すればよいのでしょうか。
その最も簡単な方法は、ダーク ローンチのトラフィックが増加している状況下で新サービスの負荷をモニタリングすることです。事実上、これはあらかじめ用意されたトラフィックではなく本番のトラフィックを使っているため、非常に現実的な負荷テストとなります。ダーク ローンチの比率が 100 % となり典型的な負荷サイクルを超えたら（一般的には最低 1 日は必要ですが）、実際にサービスを稼働させてもサーバーが落ちることはないと、ある程度確信できるでしょう。
サービスの宣伝を計画している場合は、サービスに対する追加の負荷を最大限に拡大し、控えめな乗数に基づいたサービス立ち上げの見積もりを調整しましょう。たとえば、エンドユーザーの待ち時間に影響を与えることなく、ライブ ユーザーのクエリごとにダーク ローンチのクエリを 3 つ生成できるとします。これで、ダーク ローンチを行ったサービスがピーク時の 3 倍のトラフィックをどう処理するのかをテストできることになります。
ただし、3 倍に膨れ上がったトラフィックがシステムに流れ込むと運用上のリスクを背負うことになる、という点は覚えておいてください。“こっそり行う” ローンチであるはずなのに、突然 “明るくなる” 危険性を秘めることになります。別の言い方をすれば、サービスがまさに火を噴いて、黄色やオレンジの光を放つようになるかもしれないのです。ダーク ローンチをまだ SRE に相談していないのであれば、今すぐ彼らへの連絡手段を確保し、何を計画しているかを伝えましょう。
サービスごとにピークの時間帯は異なります。世界中のトラフィックに対応し、直接ユーザーとつながっているサービスの場合は、だいたい米国時間の月曜から木曜の午前にピークを迎えます。この時間帯にユーザーがトラフィックを独占することが多いためです。
逆に、写真アップロード受信サービスのようなものは週末にピークを迎える傾向があります。ユーザーは週末に多くの写真を撮影しますし、お正月など大型連休の時期にはトラフィックが急増するのです。したがって、ダーク ローンチを行うにあたっては、待つことが妥当な範囲内で最も重いトラフィックをカバーするようにしてください。
また、ダーク ローンチ中は常にサービス負荷を測定すべきだと私たちは考えています。それがサービスを示すデータであり、ほとんど努力をしなくても測定できるためです。
ただし、負荷だけに気を取られないようにして、以下の測定についても考慮してください。
ログの必要性
受信リクエストを従来のバックエンドと新しいバックエンドに分離するポイントは、一般的にはアプリケーションのフロントエンド部分にあたりますが、この部分は通常、レスポンスが戻ってくるところでもあります。つまりこの部分は、記録したレスポンスを分析するにあたって最適なポイントとなるのです。新しいバックエンドの結果はユーザーには戻さないため、通常はアプリケーション フロントエンドのモニタリングからは直接見えないようになっています。代わりに、アプリケーションがこのレスポンスを内部でログ化します。
アプリケーションは通常、レスポンス コード（20X、40X、50X など）や、バックエンドに対するクエリのレイテンシ、さらにはレスポンスのサイズなどをログ化しようとします。適切な比較による分析のためには、こうした情報を新旧両方のバックエンドでログ化する必要があります。たとえば、もし旧バックエンドが、あるリクエストに対して 40 倍のレスポンスを返してきたとしたら、新バックエンドも同様のレスポンスを返すことが見込まれます。そのときのログは、開発者が簡単に比較でき、簡単に違いを見つけ出せるようなものでなくてはなりません。
また、新旧サービスからのレスポンスは、ダーク ローンチ期間中は常にログ化し、比較することを
強くお勧めします
。そうすることで、新しいサービスが実際のトラフィックで想定どおりに動くかどうかを把握できるためです。ロギングのボリュームが非常に大きく、パフォーマンスやコストへの影響を抑えるためにサンプルだけを使うことにした場合は、ログ サンプルには含まれていないものの、トラフィック内で見つかっていないエラーがあるということを考慮するようにしてください。
保護用のタイムアウト
新バックエンドが、一部のトラフィックやすべてのトラフィックにおいて旧バックエンドよりも遅くなることは十分にありえます（もちろん速くなることもありますが、それだとあまり面白くありません）。この遅延の原因が、アプリケーションまたはクライアントが、クライアントにレスポンスを返す前に新旧バックエンドの両方のレスポンスを待っているためだとすれば問題です。
一般的なアプローチとしては、新バックエンド コールを非同期にするか、もしくは適切に短いタイムアウトを適用し、その後リクエストを破棄してタイムアウトをログに残すようにすることです。ただし、後者はライブ トラフィックの平均およびパーセンタイル レイテンシに悪影響を及ぼす可能性があるため、前者の非同期アプローチをお勧めします。
非同期アプローチでは、新サービスに対するコールに適切なタイムアウトを設定し、メイン ユーザーのパスからそのコールが非同期になるようにします。こうすることで、ダーク ローンチが本番のトラフィックに与える影響を最小限に抑えることができます。
差分 : 変更部分とその重要性
新旧サービスからのレスポンスが明らかに異なるダーク ローンチでは、新サービスの信頼度が最も高くなります。これは通常、ミューテーションではできません。同じミューテーションを 2 度並行して適用させることができないためです。そんなことをすると、衝突や混乱が生じてしまいます。
差分は、新バックエンドが旧バックエンドと暫定的に互換性があることを確認できる、ほぼ完璧な方法です。Google では通常、
プロトコル バッファ
フィールドのレベルでこれが行われます。リストの順番を変更するなど、違いを容認することをよしとするフィールドもあります。ここで妥協が必要となります。というのも、正確で意味のある比較には追加の開発作業が必要ですが、そうした比較を行えばローンチのリスクが低減できるからです。また、差分のあるレスポンスの数が少ないと思われる場合は、実際にサービス開始の準備が整う前に、“差分のエラー バジェット” を新サービスに与え、その予算内に収めるようにしてもよいでしょう。
特にコンテンツが複雑な場合、新旧の結果は明確に差があるようにしなくてはなりません。そうすることで、新サービスが旧サービスの暫定的な代替サービスとなることに確信が持てるようになります。複雑なレスポンスの場合は、差分にエラー バジェットを設定するか（たとえば、レスポンスの差分を最高 1 % まで許容する）、もしくは、情報量が少なかったり差分がつけにくかったりするフィールドを比較対象から外すことを
強くお勧めします
。
これですべてうまくいくのですが、この差分の最適な方法とはどういったものなのでしょうか。サービス内のインラインで統計をエキスポートし、差分のログを取ることも 1 つの方法ですが、これが常に最適な方法となるわけではありません。ダーク ローンチのリクエストを発行するサービスから、差分やレポートをオフロードするほうがよい場合もあります。
Google では差分サービスを複数用意しています。バッチを比較するものもありますし、ライブ ストリームのデータを処理するもの、ライブ トラフィックの差分を見るための UI を提供するものもあります。自分のサービスにおいて、差分によって何が必要なのかを見極め、適切なものを採用しましょう。
本番稼働へ
ダーク ローンチでトラフィックを 100 % 新サービスに課すことができれば、本番に移行することは論理上たいしたことではありません。トラフィックが新旧サービスに分けられたポイントで、旧サービスのレスポンスの代わりに新サービスのレスポンスを返すだけです。新サービスに対してタイムアウトを適用している場合は、そのタイムアウトを旧サービスへと変更します。
これでおしまいです。旧サービスのモニタリングを無効にし、電源を切り、コンピュータのリソースを再利用し、ソース コードのリポジトリから消しましょう（旧サービスの停止を祝うためにチームで食事会を開催するかどうかは自由ですが、私たちは開催することを強くお勧めします）。本番稼働しているサービスはすべてサポートや信頼性が求められるものなので、サービスを停止して数を減らすことは、新サービスを追加することと同じくらい重要なことなのです。
しかし、残念ながら人生はそう簡単にはいきません（id Software の John Cash 氏がかつて、「私は『理論』に移動したい。そこではすべてが機能しているからだ」と述べていました）。新サービスにバグがあった場合に備えて、旧サービスを少なくとも数週間は稼働させ、トラフィックを受信できるようにしておかなくてはならないでしょう。
もし新サービスに不具合が発生したら、再帰的に稼働することがわかっている旧サービスを最終的なリクエスト処理担当とするようにしてください。そうすることで、時間のプレッシャーをあまり感じることなく新サービスの不具合を修正できます。
新旧サービスの切り替えは、上述の説明より複雑な作業になるかもしれません。次回のブログ記事では、移行の複雑さやリスクを高める問題について掘り下げたいと思います。
まとめ
既存トラフィック上で新サービスを立ち上げる際、ダーク ローンチが貴重な手段となり、その管理がさほど難しくないことを理解いただけたでしょうか。このブログ シリーズの第 2 弾では、ダーク ローンチの調整が難しいケースを検証し、その手ほどきについて解説します。
* この投稿は米国時間 8 月 3 日、Customer Reliability Engineer である Adrian Hilton によって投稿されたもの（投稿は
こちら
）の抄訳です。
- By Adrian Hilton, Customer Reliability Engineer
ゲスト投稿 : MLB ファン向けの新サービスを Container Engine で構築した Loot Crate
2017年8月19日土曜日
編集部注 :
Loot Crate
は、ゲームやポップ カルチャーなどのファンの間ではよく知られた企業で、テーマごとのお楽しみボックスを 65 万人の会員に毎月届けています。同社はバックエンド サービスを Heroku で構築していますが、新たに手がけた “Sports Crate” サービスでは Rails アプリを Google Container Engine でコンテナ化し、Jenkins で継続的デプロイを行っています。本稿ではその概要を紹介しましょう。
私たち Loot Crate は 2012 年の創業以来、ファン向けサブスクリプション ボックス分野の世界的なリーディング企業として事業を展開しています。エンターテインメントやゲーム、ポップ カルチャーなどのクリエイターとパートナーシップを組み、ファンに向けて毎月テーマごとのお楽しみボックスを配送したり、インタラクティブな体験やデジタル コンテンツをプロデュースしたり、オリジナル ビデオ作品を撮影したりしています。創業から 5 年で、1,400 万以上のお楽しみボックスを世界 35 地域のファンに届けました。
2017 年初頭、私たちは MLB（メジャー リーグ ベースボール）ファン向けの Sports Crate サービスを立ち上げることを任されました。2017 年の MLB シーズンが幕を開ける（開幕日は 4 月 2 日）、ほんの数か月前のことです。そのため、できるだけ早くサイトを立ち上げ、興味のある人からのメールを収集する必要がありました。
また、私たちのウィッシュ リストにも、トラフィックの増加に応じたサイトのスケーリングや、自動的なゼロダウンタイム デプロイ、秘密情報の効果的な管理、Docker イメージのメリットの活用などが含まれていました。
それまで当社のサービスは Heroku で構築していましたが、Sports Crate では
Container Engine
を試すことにしました。Container Engine を使えば、トラフィックのピーク時にもアプリがスケールしやすく、Google にログインするだけでリソースが管理でき、コスト管理も容易になると考えたからです。
Jenkins による継続的デプロイ
私たちのゴールは、シンプルな git push コマンドを使って Container Engine にアプリをうまくデプロイすることです。そこでまず、自動スケーリングする 2 ゾーンの Kubernetes クラスタを Container Engine 上に作成したうえで、クラスタに自動デプロイする方法を模索しました。
多くの調査を行い、Google Cloud のソリューション アーキテクトである
Vic Iglesias
氏とも話し合った結果、
Jenkins Multibranch Pipelines
を採用することにしました。
Kubernetes での継続的デプロイ
について解説したガイドに従って操作すると、すぐにクラスタ内で Jenkins が稼働し、デプロイを操作できる状態になりました。
次に、Container Engine へのデプロイに向け、Rails アプリの Dockerfile を作成します。ここでは構築時間の短縮を図るため、Ruby とインストール済みの gem を使って独自のベース イメージを作成しました。また、Jenkins が Docker イメージを構築するときに、アセットをプリコンパイルして
Google Cloud Storage
にアップロードするための
Rake タスク
も作成しました。
Dockerfile を作成したら、Jenkins Pipeline をセットアップして Docker イメージを構築し、
Google Container Registry
にそのイメージをプッシュして、Kubernetes とそのサービスを自社の環境にデプロイします。GitHub ブランチ名に基づいた switch 文を使っている GitHub リポジトリに Jenkinsfile を置き、どの Kubernetes のネームスペースにデプロイするかを選択します（当社には、3 つの QA 環境と、ステージング環境、本番環境があります）。
Jenkinsfile は、GitHub からコードをチェックし、構築した Docker イメージを Container Registry にプッシュして、（成功と失敗を確認しながら）さまざまなデータベース マイグレーションを実行する Kubernetes のジョブを稼働し、テストを実行します。そして、アップデートされた Docker イメージを Container Engine にデプロイし、そのステータスを Slack にレポートします。このプロセス全体にかかる時間は 3 分未満です。
ローカルの開発環境で秘密情報の管理を改善
私たちは次に、ローカル環境での開発をより簡単で安全なものにすることに取り組みました。
私たちは開発をローカルで行い、Heroku 設定または UI に追加する環境変数を使って Heroku ベースのアプリをデプロイします。これはつまり、Heroku にログインできる人や Heroku へのアクセス許可を持つ人であれば、誰でも環境変数を参照できるわけです。
Sports Crate サービスでも同様に環境変数を使用しますが、より安全に扱いたいと考え、アプリが簡単に利用できる Kubernetes Secrets に環境変数を置きました。これにより、隠す必要のある秘密の情報をコードベースや開発者の PC から守ることができます。
ローカルの開発環境では
Railtie
を使った環境変数を利用し、開発環境の秘密情報を読み出して解析を行い、Rails 環境に配置します。これで開発者は、リポジトリに “cd” し、アプリがスタートする前に Kubernetes Secrets のプルダウンにて “rails server” や “rails console” を実行できるようになります。
TLS の解除と負荷分散
効果的に TLS 解除と負荷分散を行うことも必要でした。そこで、Kubernetes の
Ingress リソース
を
Nginx Ingress Controller
で利用することにしました。というのも、
Google Cloud Platform
（GCP）の Ingress Controller では、HTTP から HTTPS への自動リダイレクト機能が利用できないからです。私たちの証明書で設定された Ingress リソースと、固定 IP を持つサービスの裏で稼働している Nginx Ingress Controller を用意すれば、私たちのアプリに外部からアクセスできるようになります。さあ、だんだんとまとまってきましたね！
自動スケーリングとモニタリング
インフラの基本的な部分が GCP 上ですべてそろったら、今度は自動スケーリングやモニタリング、さらにはデプロイの実践やログに関する QA チームの教育に着手しました。
ポッドの自動スケーリングは
Kubernetes の Horizontal Pod Autoscaling
を実装することで対応しました。これは、CPU の使用率を確認し、アプリへのトラフィックが増えるとポッドを自動的にスケーリングします。
モニタリングについては、
Datadog の Kubernetes Agent
を使用し、重大な問題を検知するための指標を設定して
PagerDuty
にアラートを送るようにしました。
ロギングには
Stackdriver
を使用することにしました。Stackdriver Logging コンソールを使い、情報が必要なアプリ、ネームスペース、ポッドなどを適切にドリルダウンする方法を QA チームに教えました。
サービス始動
サービス開始が目前に迫る中、私たちは新しいアプリの負荷テストを実施しましたが、大量のトラフィックをうまくさばいていたのには驚きました。ポッドは必要に応じて自動的にスケーリングしていましたし、QA チームは Jenkins Multibranch Pipelines による継続的デプロイが大変気に入ったようです。全体的に見て、Container Engine は要件をすべて満たしており、私たちのほうも 1 か月足らずで新サービスを立ち上げることができました。
次のプロジェクトとしては、他の Rails モノリシックアプリを Heroku から Container Engine に分離マイクロサービスとして移行させ、最新の Kubernetes 機能を利用できるようにします。ただでさえ強力な Rails アプリが、Container Engine への移行によってさらにパワフルになることを、私たちは楽しみにしています。
* この投稿は米国時間 7 月 12 日、Loot Crate の DevOps 担当 Director である Greg Brown によって投稿されたもの（投稿は
こちら
）の抄訳です。
- By Greg Brown, Director, DevOps, Loot Crate
オンデマンド / プリエンプティブル VM 向けのローカル SSD を値下げ
2017年8月18日金曜日
このたび、
Google Compute Engine
のオンデマンド仮想マシン（VM）に接続される
ローカル SSD
の利用料金が最大で 63 % 値下げされました。米国のほとんどのリージョンでは毎月 GB あたり 0.080 ドルになります。
プリエンプティブル VM
向けのローカル SSD についても、米国のほとんどのリージョンで従来よりも 71 % 安い料金（毎月 GB あたり 0.064 ドル）で提供されます。
私たち Google は、お客様のイノベーションに役立つテクノロジーを手軽に利用していただくため、テクノロジーの発展によるコスト削減を常に料金に反映させ、お客様の負担を軽減することを追求しています。
Compute Engine のローカル SSD は物理的に接続された高性能のブロック ストレージであり、お客様のインスタンスが存在するかぎり内容は消去されません。
NVMe と iSCSI の両インターフェース
をサポートし、世界で最も厳しい条件が要求されるワークロードにも対応できる高い IOPS と帯域幅性能を提供します。主に、スクラッチ ディスク、キャッシング レイヤ、NoSQL などのスケールアウト データベースなどで望ましいオプションとして使用されています。
また、重要な特徴として、どのようなマシンにも任意の容量で接続できることが挙げられます。仮想マシンの vCPU 数やメモリ量によって接続できる容量の大きさが決まるようなことはありません。
GPU
を利用するインスタンスにも接続できるので、最高性能のシステムを柔軟に構築できます。
今回は、通常のオンデマンド インスタンスに接続されたローカル SSD の値下げとともに、プリエンプティブル VM に接続されたローカル SSD の値下げも実施しました。プリエンプティブル VM とは、24 時間以上実行することができず、Google が他の目的のために計算能力を必要とする場合には 24 時間が経過する前にプリエンプト（シャットダウン）されることもある仮想マシンです。この点を除けば、他の Compute Engine VM と同じように使用できます。
このようなプリエンプティブル VM を設けたことで、データセンターの能力を効率的に使用できるようになり、その節約効果はお客様にも還元されます。お客様は、現在のローカル SSD のクォータを維持しつつ、プリエンプティブル VM 向けの特別なローカル SSD クォータを確保できます（詳細は
こちら
）。
プリエンプティブル VM によって計算コストを大幅に引き下げることに成功した
Google Cloud Platform
（GCP）のお客様は、その過程ですばらしいユース ケースを多数生み出しています。ローカル SSD が接続されたプリエンプティブル VM を使用することで、金融市場分析、データ処理、動画再生、ゲノム データ分析、メディア変換、その他さまざまなビジネスおよびエンジニアリング タスクをこなしており、なかには 1 つのジョブで数千ものプリエンプティブル VM コアを使っているケースもあります。
ローカル SSD の料金値下げによって新しい可能性が生まれ、ビジネスやエンジニアリング、科学分野での興味深い課題を解決することにつながれば、私たちにとってこれに勝る喜びはありません。
詳細については
ローカル SSD
と
プリエンプティブル VM
のドキュメントを参照してください。料金の詳細は Compute Engine の
ローカル SSD 料金体系ページ
をご覧になるか、Google の
料金計算ツール
をお試しください。質問などがありましたら、
こちらのページ
に記載されている方法でお送りください。
私たちは、皆さんが Google 製品を使って作ったものにとても興味があります。Compute Engine で構築したすばらしいシステムのストーリーやデモをシェアしたい方は、
Twitter
、
Facebook
、
G+
でご連絡ください。
* この投稿は米国時間 8 月 8 日、Product Manager である Chris Kleban と Michael Basilyan によって投稿されたもの（投稿は
こちら
）の抄訳です。
- By Chris Kleban and Michael Basilyan, Product Managers
Forrester レポート : Google Cloud を Insight PaaS のリーダーと評価
2017年8月17日木曜日
大手市場調査会社 Forrester Research のレポート『The Forrester Wave™: Insight Platforms-As-A-Service, Q3 2017』において、
Google Cloud Platform
（GCP）が Insight PaaS のリーダーと評価されました。
このレポートは、PaaS を提供するクラウド プロバイダーを分析、評価したものです。レポートによると、Insight PaaS は以下のことを容易にします。
大規模で複雑なデータ セットの管理とアクセス
行動時にインサイトを提供するアプリケーションの更新と進化
技術の更新とアップグレード
チーム メンバーの作業の統合と調整
Forrester は 8 社のベンダーを評価しました。この評価は、現行サービス、戦略、市場での存在感という 3 つの大きな観点に沿った 36 の評価基準に従って行われています。
8 社の中で、Google Cloud の Insight PaaS は、現行サービスと戦略の両方で最も高いスコアを獲得しました。
「Google は、評価対象となった 8 社の中で、ハイパーパラメータのチューニングによる本格的な機械学習の自動化や、コンテナ管理、API 管理のようなインサイト実行機能を提供する唯一のベンダーでした。データ サイエンティスト向けに高い柔軟性や拡張性を求める企業や、PaaS を使ったソリューション構築に習熟しているクラウド アプリケーション開発チームにとって、Google は魅力あるベンダーに映るでしょう。」
—
The Forrester Wave : Insight Platforms-As-A-Service, Q3 2017
Insight PaaS 市場に対する Google の取り組みには長い歴史があります。私たちは 2008 年にサーバーレス コンピューティングのビジョンとともに
Google App Engine
でこの市場に参入し、2010 年に
Google BigQuery
でサーバーレス データ処理サービスをラインアップに加えました。2016 年には機械学習機能（
Cloud Machine Learning Engine
）を GCP に追加し、TensorFlow（Google のオープソース機械学習フレームワーク）のパワーを広く利用できるようにしました。
私たちは、Snap や The Telegraph といった企業が、こうした技術を活用して行っているビジネスやサービスにいつも驚かされています。これまでの Insight PaaS をベースに、さらにサービスを充実させ、未来を開く素晴らしいアプリケーションの構築をお手伝いできることを楽しみにしています。
レポートの無料コピー版をご希望の方は、
こちら
からお申し込みください。
* この投稿は米国時間 8 月 7 日、Head of Analyst Relations である Regina Hoshimi によって投稿されたもの（投稿は
こちら
）の抄訳です。
- By Regina Hoshimi, Head of Analyst Relations
ソニーネットワークコミュニケーションズ株式会社の導入事例：BigQuery の導入でデータサイエンティストが “価値ある仕事” に集中できるように
2017年8月17日木曜日
ソニーネットワークコミュニケーションズと言えば、インターネットプロバイダ（ISP）事業「So-net」が有名ですが、実は、ソニー製品・サービスのクラウド・アプリ開発・運用でも大きな役割を果たしています。そんな同社のデータ分析に、今、Google Cloud Platform（GCP）が活躍。80：20ルールなど、同社が抱えていた悩みを、GCP が、BigQuery がどのように解決したのかを聞いてきました。
■ソニーネットワークコミュニケーションズ株式会社
クラウド＆アプリ事業部門 クラウド開発運用部 2 課 課長
川田 雅人氏
■ 利用している Google Cloud Platform サービス
BigQuery
、
Cloud Dataflow
、
Cloud Pub/Sub
、
Container Engine
など
■
ソニーネットワークコミュニケーションズ株式会社
1995 年 11 月、ソニーコミュニケーションネットワーク株式会社として設立。翌年から『So-net』として ISP（Internet Service Provider）業務を開始。現在は、ISP 事業のほか、法人向けのクラウドを軸にした IT ソリューションや、インテグレーション事業など、多彩な事業を展開。クラウド＆アプリ事業部門ではソニー製テレビ向けアプリ『Video & TV SideView』など、ソニー製品・サービスに対するクラウド開発・運用や、アプリケーション開発を行っている。
脱「80：20 ルール」に向けて GCP を導入
ソニーネットワークコミュニケーションズ株式会社 クラウド＆アプリ事業部門は、ソニー製品・サービスに対するクラウド開発・運用や、アプリケーション開発を行う部署。データビジネスの生産性を向上させるために、そこで得られたビッグデータを活用しデータ分析を通じて、製品・サービス内容や、ユーザーエクスペリエンス（UX）を向上させることも大きな役割の 1 つとなっています。
「こうしたデータの分析をおよそ 4 年前から本格化させているのですが、オンラインサービスやアプリの普及に比例して、月間 100 億レコードを超えるまでに増え続けているデータ量をしっかり分析できる環境作りが急務となっていました。データの質・量を増やしつつもクエリは速くすることでデータ運用を効率化し、価値ある分析業務に集中できる仕組みを構築することによって、ビジネスの PDCA サイクルのパフォーマンス向上を図りました。さらに、データサイエンティストが満足する分析環境であるだけでなく、彼ら以外のビジネス担当者などにも分析業務のすそ野を広げていくことが、ビジネス基盤としての必要条件ととらえ、チャレンジしたいと考えていました。」
と、語るのはクラウド＆アプリ事業部門クラウド開発運用部 2 課 課長の川田 雅人さん。ちなみにそれまで同社では、他社クラウドプラットフォーム上で、Hive や Spark などといったビッグデータ処理ツールを利用していたのですが、その環境では「80：20ルール」の呪縛から逃れれないことも問題になっていたと川田さんは語ります。
「データ分析の業務において問題となる 80：20 ルールとは、作業時間の 8 割が分析ではなく、その準備に割かれてしまう状況のこと。データを集めたり、それを変換・加工したりする前準備にほとんどの時間を費やしてしまい、価値のあることには 2 割の時間しか割けていないんです。データ分析チームは、データサイエンティスト、データエンジニア、ビジネス担当から構成されています。私自身、データエンジニアとして長らく、この問題に悩まされていたのですが、マネージドサービスである BigQuery が、我々をこうした準備やインスタンスの容量・性能設計業務から開放、運用にパラダイムシフトをもたらしてくれました。」（川田さん）
この成功を受けて同社では、データの効率的運用や処理時間の短縮、そして費用削減などを目的に、2016 年より GCP を本格導入。BigQuery を中心に、Cloud Dataflow や Cloud Pub/Sub、そして、Google Container Engine（GKE）などといった Google のテクノロジーを駆使して、複数アプリ・サービスの商用データ分析基盤を構築します。
「これはいわゆるプライベート DMP（Data Management Platform）なのですが、ユーザセントリックに分析し理解すること、セグメントを作りビジネスに活用すること、これらの目的のために、必要な全てのデータは BigQuery に投入し管理します。BigQuery の安価なストレージとクエリ課金モデルによって、目的に必要なボリュームのあるデータを躊躇なく扱えています。データをシンプルに 1 つの場所に入れられることで、データ管理、分析、集計、BI（Business Intelligence） ツールも含めて環境が一元化され、データ分析チームの作業効率は大きく向上。高速で、必要なデータをすぐに取り出せる BigQuery だからこそ実現できたと考えています。」（川田さん）
GCP の成長が、我々のビジネスも成長させていく
また、マネジメントサービスを導入したことで、これまで頭を悩ませていた監視・メンテナンス業務からデータ分析チームが開放されたということも大きかったそう。雑事に謀殺されず、データの利用や、データ構造の最適化に注力できるようになったことも大きな変化だったと川田さんは言います。
「BigQuery の強みは、GCP 内外に保存された生データをどんどん投げ込んでいけることなんですが、それでは最高のパフォーマンスは引き出せません。やはり目的に合わせてデータ構造を最適化する必要があるんです。これについては今年 3 月にサンフランシスコで行われた Google Cloud Next '17 でも熱い議論が交わされていましたね。我々の場合、BigQuery 内のストレージに、ほぼ生の蓄積データとそれぞれの目的に特化したデータマート層、その間に分析しやすく結合・変換・補完などがされている中間層といったデータ構造を導入することで効率性、生産性を高めています。これによって専門的なデータサイエンティストが最高のパフォーマンスを引き出せるようにしたほか、簡単な SQL なら書けるというマーケターにとっても使いやすい環境を構築することができました。」（川田さん）
そしてもう 1 つの工夫としてクエリ開発＆実行フレームワークも構築。クエリとスケジュール、出力先を指定できる簡単なテンプレートを作ることによって、その中身をデータサイエンティストが自在にカスタマイズできるのはもちろん、SQL を少し書けるという程度の人がフォーマットをほんの少しだけチューニングして使うということもできるようにしました。これによって、誰でも簡単に、分析結果をすぐに商用サービスに適用できるようにしているそうです。
今後の展望としては、
Cloud Datalab
や、
Cloud ML
（Machine Learning）などといった機械学習系のフレームワークとの連携を既に始めているほか、現在は非公開ベータ版として提供されている次世代のインテリジェントデータサービス
Cloud Dataprep
による、さらなる省力化にも期待しているという川田さん。
「今、我々の業務が、GCP に支えられているという実感があります。GCP が成長すると我々のビジネスも成長していくのです。これからもぜひ一緒に進化していきたいですね。」（川田さん）
ソニーネットワークコミュニケーションズ株式会社の導入事例 PDF は
こちら
をご覧ください。
GCP のその他の導入事例は
こちら
をご覧ください。
12 か月間のトライアル
300 ドル相当が無料になるトライアルで、あらゆる GCP プロダクトをお試しいただけます。
Labels
.NET
.NET Core
.NET Core ランタイム
.NET Foundation
Access Management
AlphaGo
Ansible
Anvato
Apache Beam
Apache Maven
API
Apigee
APIs Explore
App Engine
App Engine Flex
App Engine flexible
AppArmor
AppEngine
AppScale
AprilFool
AR
Artifactory
ASP.NET
ASP.NET Core
Attunity
AWS
Big Data
BigQuery
Billing Alerts
Bime by Zendesk
Bitbucket
Borg
BOSH Google CPI
Bower
BreezoMeter
BYOSL
Capacitor
Chromium OS
Client Libraries
Cloud API
Cloud Audit Logging
Cloud Bigtable
Cloud CDN
Cloud Client Libraries
Cloud Console
Cloud Consoleアプリ
Cloud Container Builder
Cloud Dataflow
Cloud Dataflow SDK
Cloud Datalab
Cloud Dataprep
Cloud Dataproc
Cloud Datastore
Cloud Debugger
Cloud Deployment Manager
Cloud Endpoints
Cloud Foundry
Cloud Foundry Foundation
Cloud Functions
Cloud IAM
Cloud IAP
Cloud Identity
Cloud IoT Core
Cloud Jobs API
Cloud KMS
Cloud Launcher
Cloud Load Balancing
Cloud Machine Learning
Cloud monitoring
Cloud Natural Language API
Cloud Networking
cloud Pub/Sub
Cloud Resource Manager
Cloud Resource Manager API
Cloud SDK
Cloud SDK for Windows
Cloud Source Repositories
Cloud Spanner
Cloud Speech API
Cloud SQL
Cloud Storage
Cloud Storage FUSE
Cloud Tools for PowerShell
Cloud Tools PowerShell
Cloud Translation
Cloud Translation API
Cloud Virtual Network
Cloud Vision
CloudBerry Backup
CloudBerry Lab
CloudEndure
Cloudian
CloudML
Cluster Federation
Codefresh
Codelabs
Cohesity
Coldline
Colossus
Compute Engine
Compute user Accounts
Container Engine
Container Registry
Container-Optimized OS
Container-VM Image
Couchbase
CRE
CSEK
Customer Reliability Engineering
Data Studio
Dbvisit
DDoS
Debugger
deep learning
Deployment Manager
Developer Console
Developers
DevOps
Disney
Docker
Dockerfile
Drain
Dreamel
Eclipse
Eclipse Orion
Education Grants
Elasticsearch
Energy Sciences Network
Error Reporting
ESNet
Evernote
FASTER
Fastly
Firebase
Firebase Analytics
Firebase Authentication
Flexible Environment
G Suite
gcloud
GCP
GCP 移行ガイド
GCP導入事例
gcsfuse
GitHub
Go
Go 言語
Google App Engine
Google Apps
Google Certified Professional - Data Engineer
Google Cloud
Google Cloud Certification Program
Google Cloud Client Libraries
Google Cloud Console
Google Cloud Dataflow
Google Cloud Datalab
Google Cloud Datastore
Google Cloud Endpoints
Google Cloud Explorer
Google Cloud Identity and Access Management
Google Cloud Launcher
Google Cloud Logging
Google Cloud Platform
Google Cloud Resource Manager
Google Cloud Security Scanner
Google Cloud Shell
Google Cloud SQL
Google Cloud Storage
Google Cloud Storage Nearline
Google Cloud Tools for IntelliJ
Google Code
Google Compute Engine
Google Container Engine
Google Data Analytics
Google Data Studio
Google Date Studio
Google Deployment Manager
Google Drive
Google Earth Engine
Google Genomics
Google maps
google maps api
Google Maps APIs
Google SafeSearch
Google Service Control
Google Sheets
Google Slides
Google Translate
Google Trust Services
Google VPC
Google 公認プロフェッショナル
GPU
Gradle
GroupBy
gRPC
HA / DR
Haskell
HEPCloud
HIPAA
Horizon
HTCondor
IaaS
IAM
IBM
IBM POWER9
icon
IERS
Improbable
InShorts
Intel
IntelliJ
Internal Load Balancing
Internet2
IoT
Issue Tracker
Java
Jenkins
JFrog
JFrog Artifactory SaaS
Jupiter
Jupyter
Khan Academy
Komprise
kubefed
Kubernetes
KVM
Landsat
load shedding
Local SSD
Logging
Looker
Machine Learning
Magenta
Managed Instance Group
Maps API
Maps-sensei
Mapsコーナー
Maven
Maxon Cinema 4D
MightyTV
Mission Control
MongoDB
MQTT
MySQL
Nearline
Network Time Protocol
Networking
neural networks
Next
Node
NoSQL
NTP
NuGet パッケージ
OCP
OLDISM
Open Compute Project
OpenCAPI
OpenCAPI Consortium
OpenShift Dedicated
Orbitera
Organization
Orion
Paas
Panda
Particle
Percona
Pete's Dragon
Pivotal
Pivotal Cloud Foundry
PLCN
Pokemon GO
Pokémon GO
Poseidon
Postgre
PowerPoint
PowerShell
Protocol Buffers
Puppet
Pythian
Python
Rails
Raspberry Pi
Red Hat
Regional Managed Instance Groups
Ruby
Rust
SC16
ScaleArc
Security & Identity
Sentinel-2
Serving Websites
Shared VPC
SideFX Houdini
SIGOPS Hall of Fame Award
Sinatra
Site Reliability Engineering
SLA
Slack
SLI
SLO
Snap
Spaceknow
SpatialOS
Spinnaker
Spring
SQL Server
SRE
Stack Overflow
Stackdriver
Stackdriver Agent
Stackdriver Debugger
Stackdriver Diagnostics
Stackdriver Error Reporting
Stackdriver Logging
Stackdriver Monitoring
Stackdriver Trace
Stanford
Startups
StatefulSets
Storage & Databases
StorReduce
Streak
Sureline
Sysbench
Tableau
Talend
Tensor Flow
Tensor Processing Unit
TensorFlow
Terraform
The Carousel
TPU
Trace
Transfer Appliance
Transfer Service
Translate API
Uber
Veritas
Video Intelligence API
Vision API
Visual Studio
Visualization
Vitess
VM
VM Image
VR
VSS
Waze
Webyog
Wide and Deep
Windows Server
Windows ワークロード
Wix
Worlds Adrift
Xplenty
Yellowfin
YouTube
Zaius
Zaius P9 Server
Zipkin
ZYNC Render
アーキテクチャ図
イベント
エンティティ
オンライン教育
クラウド アーキテクト
コードラボ
コンテスト
コンピューティング
サポート
ジッター
ショート動画シリーズ
スタートガイド
ストレージ
セミナー
ソリューション ガイド
ソリューション: メディア
データ エンジニア
データセンター
ビッグデータ
ファジング
プリエンプティブル VM
フルマネージド
マイクロサービス
まっぷす先生
マルチクラウド
リージョン
ロード シェディング
運用管理
可用性
海底ケーブル
機械学習
月刊ニュース
資格、認定
新機能、アップデート
人気記事ランキング
導入事例
内部負荷分散
認定試験
料金
Archive
2017
8
7
6
5
4
3
2
1
2016
12
11
10
9
8
7
6
5
4
3
2
1
2015
12
11
10
9
8
7
6
5
4
3
2
1
2014
12
11
10
9
8
6
5
4
3
2
Feed
月刊ニュースレターに
登録
新着ポストをメールで受け取る
Google
on
Follow @GoogleCloud_jp
