Google Cloud Platform Japan 公式ブログ: 5月 2015

うるう秒がやって来る！〜 6 月 30 日の ” 1 秒”に備えよう〜

2015年5月26日火曜日

* この投稿は、米国時間 5 月 21 日、Site Reliability Engineers の Noah Maxwell & Michael Rothwell によって投稿されたものの抄訳です。うるう秒Google Compute Engine うるう秒って何？うるう秒はどうやって発生するの？たとえば Google はうるう秒にどう対処するの？ブログなぜうるう秒をぼかすの？ Google Cloud Platform のどのサービスが影響を受けるの ? どのような影響を受けるの？Leap Indicator Google の NTP サービスはどうなっているの？ここHelp & Support Center

-Posted by Noah Maxwell & Michael Rothwell, Site Reliability Engineers

Google Cloud Launcher に 25 の新ソリューションを追加、Cloud Monitoring も統合

2015年5月22日金曜日

* この投稿は、米国時間 5 月 21 日、Group Product Manager の Ophir Kra-Oz によって投稿されたものの抄訳です。去る 3 月、Google は Google Cloud Launcher の利用開始を発表しました。Bitnami か Google Click to Deploy で設定された、人気の高い 120 種類以上のオープンソースアプリケーションパッケージを起動できるようにしたのです。それ以来、Google には多くのお客様からソリューション追加のリクエストが届きました。そうしたリクエストに Google はお応えします。 3 月の発表からまだ 3 か月も経っていませんが、Cloud Launcher に 25 種類の新しいソリューションを追加しました。新たに追加されるのは、Chef、Crate、OpenCart、Sharelock、Codiad、SimpleInvoices などです。ソリューションは今後も随時追加していきます。
同時に、14 種類の新 OS を Cloud Launcher に追加します。この中には、Windows、Ubuntu、Redhat、SUSE、Debian、CentOS が含まれます。作業をすばやくシンプルなものにするため、初期作成フローも単純化しました。

図 1 - アップデートされた Cloud Launcher の OS セクション Cloud Launcher のソリューションインターフェースも新しくなりました。ソリューションを比較しやすくするため、価格、サポート（ OS のみ）、無料体験の詳細情報が追加されています。

図 2 - アップデートされた Cloud Launcher のソリューション詳細インターフェース
すぐにデプロイできる完全なソリューションを提供するという Google のビジョンに則り、50種のソリューションについては Google Cloud Monitoring を統合することとしました。MySQL、Apache、Cassandra、Tomcat、PostgreSQL、Redis といったコンポーネントにはレポートが組み込まれ、DevOps にアプリケーションの統合ビューを提供します。

図 3 - Apache Web Server のための Google Cloud Monitoring Dashboard
今から Cloud Launcher を始めても、Google Cloud Platform 上で使いたいアプリケーションパッケージをものの数分で起動できます。そしてぜひ、Cloud Launcher 内のリンクからご意見をお寄せください。メーリングリストにも参加して、アップデート情報を受け取り、議論に参加してください。快適なシステム構築を！

ビッグデータを低コストで超高速転送

2015年5月21日木曜日

* この投稿は、米国時間 5 月 12 日、 Software Engineer の Stanley Feng によって投稿されたものの抄訳です。どんなアプリケーションでも、少なくとも何らかのデータがなければ動きません。ゲーム分析、気象予報モデリング、ビデオレンダリング、Apache Flume や MapReduce などのツール、データベースのレプリケーションといったビッグデータアプリケーションは、言うまでもなく大量のデータを処理、転送します。一見単純なウェブサイトでも、辞書、記事、画像、その他あらゆるタイプのデータを VM 間でコピーしなければならないことがあります。そして、そのようなデータでも、蓄積されればかなりのサイズになるかもしれません。しかも、データにはファイルシステムを介してアクセスしなければならないことがあります。すると、scp のような旧来のツールでは、増えていくデータサイズに対応しきれなくなる恐れがあります。
一般に、ビッグデータアプリケーションはディスクからデータを読み出し、それを変換してから scp などのツールでデータを他の VM に転送して、さらなる処理を行います。scp は、スレッディングモデルから VM CPU の暗号化ハードウェアに至るさまざまな面で制限を抱えており、最終的には VM 当たりの仮想ディスク読み書きクォータによって制限されます。scp の転送速度は 128 MB / 秒（シングルストリーム）か 240 MB / 秒（マルチストリーム）ほどです。
現在のフローを図示すると、次のようになります。

一般的なデータパイプラインのシナリオ
ここでは、VM 間で大量のデータを転送するためのまったく新しい方法を紹介します。Google Compute Engine Persistent Disks は、ディスク上のすべてのデータのポイントインタイムコピーを作る Snapshots という機能を持っています。この機能は一般にバックアップのために使われますが、すぐに新しいディスクに変換することもできます。このようにして作った新ディスクは、作成元とは異なる実行中の VM にアタッチ（接続）できます。こうすると、第 1 の VM から第 2 のVM にデータを転送できるわけです。スナップショット機能を使ったデータ転送は、次に示す 3 つの単純な手順で実行できます。

ソースディスクからスナップショットを作ります。

新しいデスティネーションディスクにスナップショットをダウンロードします。

新しい VM にデスティネーションディスクをアタッチ、マウントします。

Persistent Disk Snapshot を使えば、1024 MB / 秒（ 8 Gbps ）以上のスピードで、VM 間でデータを転送できます。これは、scp の 8 倍のスピードです。次のグラフは、scp と Persistent Disk Snapshot を使ったときのデータ転送速度を比較したものです。

scp と PD Snapshot のデータ転送速度比較
スナップショット機能を使ったデータ転送でとてつもなく大きなメリットが得られるのは、Persistent Disk Snapshot のパフォーマンスが非常に高いからです。次のグラフは、永続ディスクのスナップショットを取得するのに要する時間と実効スループットを示しています（この実験では PD-SSD が使用されています）。スナップショットを取得するのに要する時間（青い棒グラフ）は、サイズが 500 GB まではほぼ同じで、1 TB になると少し長くなっています。そのため、スナップショットプロセスの実効スループット（スピード）は、ほぼ線形に増えていきます（赤の折れ線グラフ）。

Google Compute Engine Persistent Disk Snapshot のスピードは、業界内でも突出しています。次のグラフは、スナップショット機能を提供している他のクラウドプロバイダーとの間でアップロード時間を比較したものです。ご覧のように、Google Compute Engine のアップロード時間はサイズが大きくなってもほとんど変わりませんが、競合他社の場合のアップロード時間はサイズの増加とともに顕著に上がっていきます。

Google Compute Engine のテストは、PD-SSD を使用して us-centra1-f で実行。スナップショットサイズは、32 GB、100 GB、200 GB、500 GB、1000 GB
Persistent Disk の価格は 1 か月当たり 2.6 セント / GB です。 VM の利用料金以外に、これだけのコストがデータコピーのためにかかるのは高いと思われるかもしれません。しかし、転送目的で使われるスナップショットは短命（ 10 分未満）で、価格は秒単位で比例案分されるので、実際の平均コストは 500 GB のデータの転送ごとに 0.003 ドルほどです。スナップショットは転送が完了したら直ちに削除できます。そのため、1 セント未満の料金で、かつ従来のツールの 8 倍のスピードで 1 TB のデータを転送できることになります。
実際に試してみたい方は、ドキュメントにスナップショットコマンドの詳しい説明があります。また、Persistent Disk Snapshot の安全な使い方については、以前のブログを参照してください。快適なスナップショットライフを！
-Posted by Stanley Feng, Software Engineer, Cloud Performance Team

Google Cloud Platform の価格を引き下げ

2015年5月19日火曜日

* この投稿は、米国時間 5 月 18 日、Technical Infrastructure の Senior Vice President、Urs Hölzle によって投稿されたものの抄訳です。クラウドサービスのプロバイダーには多くの選択肢があります。しかし、アプリケーションやワークロードに最適なクラウドサービスの選択は、意外と難しいのではないでしょうか。 Avaya や Snapchat、Ocado、Wix などのお客様には、Google のイノベーションと実証済みのパフォーマンスに加えて、柔軟な価格モデルを備えた Google Cloud Platform を選択いただきました。最近では、低価格で高速なコールドデータサービスの Google Cloud Storage Nearline や NoSQL データベースの Google Cloud Bigtable などの新しいサービスをご紹介しましたが、本日発表の価格改訂は、Google Cloud Platform の魅力をさらに引き上げることができると考えています。
本日、すべての Google Compute Engine インスタンスタイプの価格を引き下げるだけでなく、短期的でステートレスな計算能力を提供する、新しいクラスのプリエンプティブル VM を、非常に低価格かつ固定料金制のプランでご案内できることを発表しました。自動割引、分単位の課金、マシンタイプ変更へのペナルティがないこと、長期的コミットメントが必要ないことなどと相まって、私たちが価格やパフォーマンスで業界をリードしている理由がおわかりいただけると思います。
プライスダウン 昨年、Google Cloud Platform の価格はムーアの法則に従うことをお約束しました。そして本日、その約束を果たすべく、仮想マシンの価格を最大 30 %まで引き下げます。

設定	価格引き下げ率（米国）

Standard High Memory High CPU Small Micro	20% 15% 5% 15% 30%

欧州とアジアでも、同様に価格を引き下げます。Google Cloud Platform の価格に関する詳細は、Compute の価格に関する詳細は、Compute Engine 価格ページをご覧ください。

上図のように、Google Compute Engine の価格は、2013 年 11 月の発売以来、下がり続けています。 Google Compute Engine プリエンプティブル VM の特徴 もしワークロードが柔軟なら、新しいプリエンプティブル VM は短期間のバッチジョブをレギュラー VM よりも 70 ％安価に実行できます。プリエンプティブル VM はレギュラー VM とそっくりですが、可用性がシステムの供給と需要に影響されることが異なります。プリエンプティブル VM は、アイドル状態となるはずのリソースを活用して実行されるため、実質的なコスト削減をもたらします。Descartes Labs などのお客様は、Hadoop MapReduce や視覚的効果のレンダリング、財務分析、その他の計算処理などのワークロードにとって、プリエンプティブル VM が素晴らしいオプションになりうることをすでに理解されています。
重要なのは、プリエンプティブル VM の価格が固定されていることです。他のクラウドプロバイダーのインスタンスとは異なり、プリエンプティブル VM ではコストを正確に予測できるのです。

Regular n1-standard-1		Preemptible n1-standard-1	コスト低減率
$0.050 ／時間		$0.015 /時間	70%

プリエンプティブル VM の価格については、Google のドキュメントページを参照ください。価格に関する詳細は、価格ページをご覧ください。まずは手始めとして、ワークロードをテストできる無料トライアルもご用意しています。

- Posted by Urs Hölzle, Senior Vice President, Technical Infrastructure

プリエンプティブル VM 登場: 標準価格の 3 割で使える、まったく新しい VM

2015年5月19日火曜日

* この投稿は、米国時間 5 月 18 日、Senior Product Manager の Paul Nash によって投稿されたものの抄訳です。多くのデベロッパーは、単にウェブサービスを利用することにとどまらず、膨大な計算能力を必要とするワークロードのためにクラウドを利用しています。クラウドなら、スケーラビリティが高く”ペイアズユーゴー”（使った分だけの課金）で高いコストパフォーマンスが得られます。クラウドで行われている処理は、ビデオエンコード、ビジュアルエフェクトのレンダリング、データ解析やシミュレーション、ゲノミクスのためのビッグデータクランチングなどです。これらのユースケースは、大量のコンピューティングリソースを消費しますが、大抵は散発的に実行されるだけなので、クラウドコンピューティングはベストマッチです。
そして今日、すべての地域のすべてのお客様を対象として、Google Compute Engine プリエンプティブル VM をベータリリースしました。プリエンプティブル VM は、通常のインスタンスとまったく同じですが、1 つだけとても大きな違いがあります。プリエンプティブル VM は、いつシャットダウンされるかもしれないのです。ずいぶん乱暴な話に聞こえるかもしれませんが、1 つのインスタンスを継続的に使える状態にしておく必要のない、分散的でフォールトトレラントなワークロードでは、この特徴が大きくものを言います。無期限のアップタイムの保証を捨てれば、通常のインスタンスよりも大幅に料金が安くなるのです。プリエンプティブル VM の価格は固定です。変化する市場価格のもとで賭けに出るリスクを負わずに、いつでも低コストが保証され、必要コストが予測できます。使い始めた最初の瞬間からコスト節減効果が上がります。価格は、コア時間あたりわずか 0.01 ドルです。
一部のお客様は、すでにプリエンプティブル VM でコスト削減を実現しています。

Citadel 社は、クラウドソリューションの一部としてプリエンプティブル VM を使っています。同社 CIO の Joe Squeri 氏は、次のように述べています。「これは最高の効率、イノベーション、達成だ。私たちはクラウドのリソース消費が大きいので、地域によって変わる価格体系をうまく使いこなすという複雑でわかりにくい作業をせずに、魅力的な価格で使える Google Cloud Platform のプリエンプティブル VM を歓迎している」

ディープラーニング AI の Descartes Labs 社は衛星画像の解釈に力を入れており、最近では約 3 万の CPU を使って、わずか 16 時間で 1 ペタバイトの NASA の画像を処理するという大規模な実験を成功させています。同社 CEO で共同創設者の Mark Johnson 氏は、次のように述べています。「シードファンドで成り立っている私たちのようなスタートアップ企業からすると、大幅なコストダウンを実現できるプリエンプティブル VM の価格モデルは画期的だ。全世界の作物の作況を確認、判定するための処理データが増えているだけに、将来もこのサービスを使い続けられるのはとてもすばらしい」

Google 自身の Chrome セキュリティチームは、数千の仮想マシンで実行されている Chrome 最新コードに対し、Clusterfuzz ツールを使ってノンストップの無作為なセキュリティテストを実行しています。計算能力を上げれば、セキュリティバグを今までよりも早く見つけ早く修正できるようになります。プリエンプティブル VM の導入により、同チームはコストを半減させつつ、2 倍の規模でテストできるようになりました。

Google のデータセンターでは、さまざまな理由により予備リソースを維持していますが、プリエンプティブル VM はこの予備能力を活用します。Google のデータセンター利用率を最適化するために必要になったときには、Google が能力を回収できるようになっています。その代わり、Google はこの種の仮想マシンを大幅に値引きして提供します。ただし、プリエンプティブル VM の実行時間は 24 時間に制限され、それよりも早くプリエンプション（シャットダウン）される場合もあります。しかし、この制限を除けば、高速で簡単なプロビジョニング、一貫して高いパフォーマンス、永続ディスクに書き込まれるデータの常時暗号化など、Google Compute Engine のすべての機能が手に入ります。
プリエンプティブル VM は、今ある Google のツールを使って作ることができます。Google Developer Console で 1 つのボックスにチェックをいれるか、gcloud コマンドラインに “--preemptible” を追加するかです。プリエンプティブル VM が強制終了されるときには、30 秒前に通知が届くので、その時間を使ってクリーンにシャットダウンすることができます（保存も含みます）。
Hadoop on Google Compute Engine を使っているお客様には、さらに簡単な方法があります。オープンソースの bdutil ツールを使えば、Connector for Hadoop を介して Google Cloud Storage から直接データを取ってくる Hadoop クラスタを作れますが、bdutil はプリエンプティブル VM をミックスインできるようになりました。 “--preemptible .25” を追加すれば、クラスタの 25 %をプリエンプティブル VM として実行することができます（割合は自由に設定できます）。
プリエンプティブル VM の詳細な使い方についてはドキュメントを参照してください。価格体系の詳細については、Compute Engine 価格ページを参照してください（価格計算機ツールとクラウドプロバイダー間の本当の価格比較の詳細も同じページにあります）。疑問、フィードバックなどがある場合には、getting help page をご利用ください。
プリエンプティブル VM は、Google Cloud Engine から最大限の価値を引き出すために間違いなく役立ちます。これを使ってすばらしい新アプリケーションを作られたら、是非お話をお聞かせください。
-Posted by Paul Nash, Senior Product Manager

分散 SQL データベースの Crate が Google Compute Engine で Click-to-Deploy 可能に

2015年5月18日月曜日

* この投稿は、米国時間 5 月 7 日、ゲストの Tyler Randles 氏によって投稿されたものの抄訳です。今回のゲストは Tyler Randles 氏です。Tyler は、オープンソースの分散型 SQL データベースソフトウェアである Crate のデベロッパーエバンジェリストです。Crateシェアードナッシングアーキテクチャクエリのパフォーマンスを向上自社のテクノロジースタックを簡略化TechCrunch Disrupt を受賞Click-to-Deploy

Compute EngineClick-to-Deploy ソリューションCrate と Google意見をお聞かせください

- Google Cloud Platform Japan Team

Google Cloud Debugger が Google App Engine に対応 - トラブルシューティングをもっと容易に

2015年5月15日金曜日

* この投稿は、米国時間 5 月 7 日、Product Manager の Keith Smith によって投稿されたものの抄訳です。Cloud DebuggerGoogle Cloud DebuggerGoogle Compute EngineGoogle App Engine

メールでのフィードバックStack Overflow-Posted by Keith Smith, Product Manager

Google Cloud Platform のグローバルイベント Next、6 月東京開催決定

2015年5月14日木曜日

Next詳細、お申し込みはこちら

AppScale と App Engine の協働で高い柔軟性を実現

2015年5月14日木曜日

* この投稿は、米国時間 5 月 5 日、 Google Cloud Platform の Global Head of Solutions、Miles Ward によって投稿されたものの抄訳です。

Google App Engine の開発背景には、Google が開発を行う環境と同じものを、世の中のデベロッパーが利用できるようにしたいという思いがありました。古いモデル、使いにくいソフトウェア、あるいは限られたインフラに制約されることなく、Google で生まれたイノベーションを開放しました。開発時の思いは今でも忘れず、私達の活動と目的となっています。Google Cloud Platform

ModulesManaged VMsproject wikiAppScale Github pageAppScale's Fast StartGoogle Compute Engineフィードバック-Miles Ward, Global Head of Solutions, Google Cloud Platform

株式会社 Aiming（エイミング）の導入事例 (2): BigQuery で集計をリアルタイムに、コストを 1/5 に

2015年5月14日木曜日

* 5 月 19 日、一部内容を更新しました。

数百万のゲームユーザーに比例して、そこで生まれるデータの量も膨大なものとなります。それをどう活用しているのか、どう処理しているのか、気になるところですよね。前半では、株式会社 Aiming、企画・運営グループインフラエンジニアマネージャー野下洋さんに、Google Cloud Platform の利用の仕方や、クラウドベンダーの選定についてお聞きしました。後半では、開発グループリードソフトウェアエンジニア芝尾幸一郎さんに BigQuery の利用方法をお聞きします。 BigQuery へ移行芝尾さんはどういった仕事をされているのですか？主にやっているのが、社内の横断的なデータ分析基盤を作ること。これが一段落すると分析作業をやるようになると思います。Aiming の前は、Hadoop を使ったデータ分析のシステムをやってました。
BigQuery はどのように利用されてるのですか？社内の KPI ツールとして Monolith という、社内にサーバがある Web のツールなんですけど、社内の各タイトルの売上だとかが一覧で見れるツールがあります。そこで、BigQuery で集計した結果をグラフだとかで見れるようにしています。 BigQuery にデータをどう送っているのかというと、各ゲームのサーバーから td-agent (fluentd) を使って、ゲームによっては 1 度ログサーバーに集約するものもあるし、そのまま BigQuery に送っているものもあります。
どうして BigQuery を利用するようになったのですか？以前の製品では、データを送って、集計のためのクエリーを製品上に保存する仕組みだったので、そこで売上集計の SQL だとかを 1 日に 1 回とか 1 時間に 1 回というタイミングで実行し、その集計結果を一旦社内の Web サーバーに貯めこんでおいて、売上とかイベント時の参加者グラフだとかを見るようになっていました。そこで課題だったのが、以前の製品があまり速く集計を返せない、例えば売上などは前日の値になる、今の値が見たくても、何分か待って集計しないとわからない。これを BigQuery に変えたことで、社内にサーバがあることは変わらないのですが、今の値が見たいなら、集計の SQL は、その Web サーバ側で持っているので、直接 BigQuery に問い合わせにいきます。その問い合わせた結果は数秒で帰ってくるので、それをそのまま Hicharts を使ってグラフ化することで、前日じゃなくて今のデータが見れるようになりました。移行を検討するとき BigQuery 以外にも選択肢はあったと思いますが、BigQuery を選んだ理由は？理由はいくつかあって、まず速い。同僚は安いという点をあげていますね。1 Gで $0.020 ドル（編集注: 2015 年 4 月時点での月毎のストレージコスト。ストリーミングインサートのときは、10 万行に対し $0.01）。以前の製品のときはもっとかかっていたのが、試算したら数分の 1 となって、これは本当か（笑）と。何かの冗談に違いないと。それが本当なら価格競争力がある、それで BigQuery にしようとなりました。ゲームへの定着を測るどういったデータを集計し、見ているのですか？基本的にはユーザーのアクティブな行動を見てます。アクティブユーザー数、何日間継続して使ったか、新規登録ユーザー数だとか。その中でも重視しているのは、アクティブユーザー数から新規登録のユーザー数を引いたものです。それをよく見ていて、継続して利用するユーザーを知りたい。例えばリワードを打ったり、CM を打つと、1 万とか 2 万人が入ってくるんですけど、そのユーザーというのは次の日にはゲーム遊ばず、定着してくれないこともある。知りたいのはゲームにユーザーが定着しているか。そのためにアクティブユーザー数を取りたいというのはありますね。ゲームにおけるデータの重要性をどう考えていますか？今まで見えていなかったので、どんぶり勘定でやるしかなかった。例えばリワードを打つと一時的にユーザーは増えるものの減っていってしまう。それは定着していないからなんですけど、それが例えば 5 日間連続で利用したユーザーで線を引くことで、この施策が当たったかどうかわかるようになる。今まではなんとなく、増えているような感じがする、流行っているような感じがする、だったのが、実際に定着するところまで見れるようになったことは大きいと思います。
このツールは、社内の人誰でも見れるのですか？許可を得れば見れます。会社の方針としても、みんながデータを見ることで、自分の会社のタイトル同士を比較して、リワードを打ったときの状況を予測したり、理解を深めることができますから。
芝尾さん個人として BigQuery に変更して、特に何が気に入りました？個人的には、以前の製品は集計に数分かかって寝てしまうことがあったのが、BigQuery は数秒で終わるので試行錯誤がし易いことです。分析を主体にする人、企画運営する人、グラフが見たい人、経営者、いろいろ立場によって利点は違いますが、僕が利点だと思うのは、レスポンスが早いので分析するときにダレないこと。途中で眠くなる問題は結構大きいですからね（笑）。以前はオンプレミスで Hadoop を使われていたそうですが、その観点で BigQuery や以前の製品のようなクラウドのサービスとの違いをどう考えていますか？だいぶ楽です。Hadoop でファイルシステムを構築して、調子が悪くなってクラスターが落ちたから新しいクラスターを入れるとか、ノード数が大きくなれば速くなるけど、その分メンテナンスが大変になります。データセンターにハードウェア差し替えに行くだとか。結局 Hadoop を使うのは、社外にデータを出したくないというところからで、それが Hadoop を使う理由でしたから。実際に BigQuery を使うと、やっぱり社内で持つのはないなとという感じですね。こういう部分は会社としてのポリシーの柔軟さだと思います。やはり、自社で持ってるとラッキングから全部やらなければならないのが、クラウドではスケーリングを気にしなくていいのが大きいですね。データを外に出すということで、クラウドのセキュリティについてどう考えていますか？問題に思ったことはないですね。鍵の管理を徹底して、IP で絞れば外に漏れることもない。心理的な抵抗だとは思います。楽さには抗えないですから。ゲームが面白かったことを数値化今後 BigQuery をどう使っていく予定ですか？ログレスのデータも BigQuery に入り始めたので、いろいろ分析していきたいです。当面の目標は各タイトルのデータを BigQuery に置いて横串で見れるようにすることですね。また、過去のデータを集計したものを見せるという形が残っているので、全てのタイトルのデータをリアルタイムに集計して、企画や運営の人に見せられればと思っています。まさにBigQueryを使ったリアルタイムな何かができるのではと。
データ分析を今後オンラインゲームにどう活用していきたいですか？面白いゲームを作ってなんぼですから、データ分析でも ”その面白さは数値として出ている” と言えるようになりたい。昔のクリックゲームや、少し前のソーシャルゲームはデータ分析の結果（結果が出ていることと）同じようにやれ、というのがありましたが、ユーザーの性質が変わってきて、スマートフォンでも、よりゲームらしいゲームをしたいとなってくると、データ分析は面白かったことを検証するために使われるようになると思います。導入事例はこちら

シンプルで繰り返せるデプロイを。Google Cloud Deployment Manager ベータ版

2015年5月13日水曜日

* この投稿は、米国時間 5 月 5 日、 Technical Program Manager の Chris Crall によって投稿されたものの抄訳です。Google Cloud Deployment Manager

インフラストラクチャのデプロイをテンプレートに定義し、コマンドラインまたは RESTful API を経由してデプロイする

テンプレートは jinja や Python をサポートしているので、デプロイメントが要求するロジックに、ループ、条件、パラメータ化された入力などのプログラミング構造を有効活用できる

デプロイメントの表示や削除を行う UI を Google Developers Console でサポート

ストレージへのコンピュートからネットワーキングまで、Google Cloud Platform のリソースとの緊密な統合により、デプロイメントのプロビジョニングおよび可視化を迅速に実行

Screen Shot 2015-04-21 at 10.32.52 AM.png

デプロイメント例Deployment Managerこちら-Posted by Chris Crall, Technical Program Manager

株式会社 Aiming（エイミング）の導入事例 (1): 安く、安定したクラウドへ。オンラインゲームを Google Cloud Platform へ移行

2015年5月13日水曜日

今回の事例は、300 万人以上の人が遊んでいる “剣と魔法のログレス”、500 万ダウンロードを超えた “ロードオブナイツ”、成長を続けるオンラインゲーム市場、特にスマートフォンゲームの市場の中でさえもヒット作を生み出し続けている株式会社 Aiming さんです。 MMORPG やシュミレーションゲームに強く、以前からオンラインゲームを作ってきたチームが殆どで、スマートフォンにシフトしても同じように企画し、技術を使っていけていることが強みであると、企画・運営グループインフラエンジニアマネージャーの野下洋さんが説明してくれました。前半はまず、野下さんに Aiming についてと、Google Cloud Platform の選定理由や利用方法をお聞きし、次回、開発グループリードソフトウェアエンジニア芝尾幸一郎さんに BigQuery についてお聞きします。ゲームをして、ゲームを作る会社いくつか Aiming さんについて書かれた記事を読んでいると、仕事中でもゲームをするという習慣があるそうですねゲームをするのが偉い、という記事もありますよ（笑）。自分を含むインフラチームでもゲームしている人が多いですね。凄く面白いと思っているのが、ゲームをやっていることで、企画の人がいろんな意見を自分からも吸収していくし、みんながゲームをやっていることでいろいろな可能性が生まれる。そういう風通しの良さも含め面白い会社です。その中でも社長が負けず嫌いで、自分で率先してゲームをやりますし、取締役で、インフラチームのトップに萩原という人がいるんですが、とにかくゲームを知っていて、それだけゲームをしている。それを見ていても、もっとゲームをやらないと、となってきます。国内のゲームだけでなく海外のゲームも含めて。その社長の椎葉さんの話は良く見聞きしますが、会社ではどういった方なんですか？会社では、フレンドリーな人で、一緒に野球をやったり、フットサル一緒にやったり。大会に一緒に出たりもしてます。尊敬している人です。大勢の人が遊んでいるゲームを運営されていますが、インフラチームは何人くらい？東京に 5, 6 人、大阪に 2 人。AGS（Aiming Global Service Inc.）というフィリピンにある子会社に数十人。日本では高レベルの作業をして、週次のメンテナンスは AGS に実施してもらっていますが、まだまだ人材が不足しています。インフラチームの仕事内容について教えてください。多岐にわたっていますが、サービスのインフラ部分については、サーバーを構築していくことなのですが、そのとき 2 通りあって、1 つは、今後も増やしていく予定の海外のゲームの導入。このときまず、構成をチェックして、そのままでは問題がある部分が出てくるので、それを修正して構築します。もう一つは、自社で開発する国内向けのゲームを、開発メンバーと話し合ってこういう構成にしよう、こういうふうに作ろうと進めていくことが中心です。その後の運用は AGS にお願いしています。仕組みだけを作って AGS に、というのが理想ですが、そこまではまだ完全にはやれていないですね。クラウドの採用基準以前、別の方がされていた講演で、クラウドの採用基準は、様々な意見を集めて、ひたすらクラウドベンダーの営業と話すという内容を聞きましたが、今はどうしているのですか？当時は安さ、いかに安くするかを重要視してました。必要な要件をならべて、相見積とって、安くさせて、としていました。今は会社の状況や規模も変化して、コスト面だけでなく、もっと使い勝手だとか、運営までを見越した選定をしていくようにしています。難しいですけどね。
今回古いゲームを Google Cloud Platform に移行したそうですが、それはどういうきっかけから？そのゲーム（ロードオブナイツの海外版）は、最初は一番実績のある AWS でやってみようかと EC2 を使っており、その後、とあるクラウドサービスへ移行しました。かなりコストに差があったんですよ。でも残念ながら安定性が低かった。それで Google Cloud Platform は使ったことなかったのですが、さらに安かったし、安定しているという話も聞いていたので、使おうとなりました。それと Google Apps for Work を使っているので認証が楽ということもありました。なぜその点を重要視したかというと、今後セキュリティをさらに意識していく必要があって、認証を Google Apps と連携することで強固にできる、とっかかりとしてはそれもありましたね。実際に移行の話があってから、どれくらいの期間で移行させたんですか？社長から直接自分に、安いクラウドにしてほしいという話があって、一週間くらいで Google に決めて、そこから 1 ヶ月もしないうちに移行を終えてますね。2, 3 週間くらいで移行したのかな。Google Cloud Platform の事前評価というのも簡単な評価しかしていないですね。とりあえずゲームを動かすというところにフォーカスして、動けば使ってみようという感じでした。移行というとプログラムだけじゃなくてデータの移行もあったと思います。それぞれのクラウドの違いからくる、問題はありましたか？それはないですね。クラウドに依存する作り方はしてないので、CentOS の環境があれば動く構成になっています。ただ、これまで移行してきた中でモレがあったことはありましたけど、それはナレッジ化していたので、ほぼノーミスで今回は移行できましたね。まだ使われて間もないですが、Google Cloud Platform を利用した感想は？（Compute Engine の）インスタンスを 30 くらい立ち上げていて、以前のクラウドサービスから移行後もサービスに影響を与える問題はゼロ。多少再起動したりということはありましたけど、特に問題なく、ほぼ何の問題もなく動いてますね。他に利用している Google Cloud Platform のサービスはありますか？
特に BigQuery を使っています。Cloud Storage はまだ使っていないのですが、Amazon の S3 をずっと使ってきて、転送量が高く移行しようかという話は出ています。オンラインゲームのためのクラウド選定今後も新しいアプリケーションをリリースしていくと思いますが、オンプレミスも含めて、今後サーバの選び方についてどういう考えを持っていますか。そしてその中での Google Cloud Platform について。これまで検証をしてきた中で、MMORPG とシュミレーションゲームという 2 つの大きなゲームジャンルで、MMO ではデータベース負荷が激しく、クラウドではまだ怖いところがある。他のプロジェクトでは Fusion IO を使い、物理サーバーを買って、Fusion IO を挿してという形なので、それをそのままクラウドに持って行こうとすると、それに対する知見がないこともあって、クラウドではまだ難しい。でも、もう 1 つ、シュミレーションゲームの方向だと Google を使っていく方向になるかとは思います。あと日本でリリースするときに、日本リージョンがないこと、実際それで特に問題はないことははわかりつつも、海外リージョンの Google を国内向けのタイトルで使う程のこだわりはなくて、そのゲームにあわせた最適なクラウドを選ぶときに、最適であるという観点から日本のリージョン使えるベンダーを選ぶことも、その 1 つの要素であるので。その他に、英語対応しているのも必須です。AGS でも使えるようにしなければならないので。それと料金が安いのと、中には無茶苦茶なプロジェクトもあって、リリースするまでの期間が長い、例えば 4 月にリリースするとと言っていたのが 1 年延期みたいなことがあるので、無料期間設けてもらったりとか、そういったところを柔軟に対応してもらえると本当に助かりますね。作りの面でも、共有ストレージを作れない、1 つのサーバ上に何台かの仮想サーバーを立てて、スケールアウトしていくクラウドがあるのですが、そうなると物理サーバがメンテするとき全部止めないといけない。でも共有ストレージ化されているのだったら、vMotion のような機能で動かせ続けられるので、そういったメンテナンス性がどの程度かというのは意識しています。セキュリティ面では、コントロールパネルに対してどういうセキュリティが設定できるかということは見てて、例えば IP 制限がかけられるとか、パスワードの定期変更の通知があるかといったことは見てますね。性能はあまり見れていないですが、ベンチマークして、指標を立てるということはやっています。サーバーは、自動でスケールさせるようにしているのですか、それともあらかじめ必要なリソースを確保しておく？前もって確保させていますね。うちのゲーム、例えばログレスを見るとわかると思うのですが、ワールドという概念があるゲームが多くて、それはインフラエンジニアからすると素晴らしいと思っていて、人数を制御できるので。ゲームとしては、良い面も悪い面もあって、ユーザーのみんなが同じところで遊べた方が絶対にいいですけど、ただそうはいってもサーバ障害が起こるよりはいいですから。それで、ローンチする前に 2, 3 ワールド準備しておくんですね。ある程度のユーザーが集まってきたら負荷をみて、別のワールドに流すようにしながら、ある程度ワールド増やしていく。その後、時間がたって、サーバに対してのデイリーのアクティブが下がってきたら、今度はユーザーをマージさせるようにしてるんですよ。そこで気になるのが、サーバーが最初増えるので、ワールド区切るようにしていくと、サーバの台数に制限があるクラウドは使えないです。そういう運営を見据えた選定はしてますね。高速なリージョン間通信を活かしたゲーム作り今後 Google Cloud Platform をどう使っていきたいか、何かあれば教えてください。他のリージョン間でもローカル通信できるというのはいいですね。結局なくなってしまったんですけど、使いたいというプロジェクトもあったんですよ。でも、それを使ったゲームが作れたらとは思っています。あと、サーバーを立てて MySQL をインストールして使うわけですけど、Google なら Cloud SQL があるように、そういうものを使っていくのがベストだと思うので、使っていく方向を探りたいですね。以前、my.cnf をいじる職人さんがいましたが、そういうことに頭を使わずに済むようになったらいい。何億というレコードになると性能という問題に直面しますが、そこは Google が良きに計らってくれて、こちらはデータを入れておけばいいというような。仕事なくなるかもしれないですけど（笑）

次回後半は、BigQuery の利用について話していただきます！導入事例はこちら

Industriromantik と Compute Engine を使ってクラウドで 3D 画像をレンダリング

2015年5月12日火曜日

* この投稿は、米国時間 5 月 1 日、Google Cloud Platform US Team によって投稿されたものの抄訳です。今回のゲストは、Industriromantik のテクニカルディレクター Fredrik Averpil 氏です。Industriromantik は静止画および動画のコンピュータ生成を専門とするデジタル制作会社で、Fredrik はカスタムのコンピュータグラフィックスパイプラインを開発しています。
Google Compute Engine

図1. これらの高解像インテリアは、我々のカスタムコンピュータグラフィックスパイプラインを使用してレンダリング・制作したものですセットアップ方法Pixar Tractor

図2. Google Compute Engineのインスタンスは VPN トンネルを介してローカルオフィスのネットワークにアクセスするZFS # Create folder on GCE file server running on public IP address 1.2.3.4 over SSH port 22 ssh -p 22 -t -t 1.2.3.4 -o UserKnownHostsFile=/dev/null -o CheckHostIP=no -o StrictHostKeyChecking=no -i /home/fredrik/.ssh/google_compute_engine "sudo mkdir -p /projects/projx/" # Upload project files to GCE file server running on public IP address 1.2.3.4 over SSH port 22 rsync -avuht -r -L --progress -e "ssh -p 22 -o UserKnownHostsFile=/dev/null -o CheckHostIP=no -o StrictHostKeyChecking=no -i /home/fredrik/.ssh/google_compute_engine" /projects/projx/ 1.2.3.4:/projects/projx/ # Copy files from bucket onto file server running on public IP address 1.2.3.4 over SSH port 22 ssh -p 22 1.2.3.4 -t -t -o UserKnownHostsFile=/dev/null -o CheckHostIP=no -o StrictHostKeyChecking=no -i /home/fredrik/.ssh/google_compute_engine "gsutil -m rsync -r gs://your-bucket/projects/projx/ /projects/projx/"VPNV-Ray for Maya # Copy files from Google Compute Engine file server "fileserver-1" onto local machine gcloud compute copy-files username@fileserver-1:/projects/projx/render/*.exr /local_dest_dir

図3. Tractor のダッシュボード。待機ジョブと標準的なレンダリングジョブのタスクツリーを示している自動化

図4. Tractorのタスクツリー
query Python API Google Cloud SDK

図5. ストックホルム、Etaget でのエクテリアの高解像 3D レンダリングZync Render まとめGoogle Cloud SDKGoogle Compute EnginePixar TractorZync Renderhttp://fredrik.averpil.comhttp://www.industriromantik.se-- Google Cloud Platform Japan Team

Cloud Logging Connector ベータ公開: Cloud Pub/Sub へストリーム

2015年5月11日月曜日

* この投稿は、米国時間 4 月 30 日、Product Manager の Deepak Tiwari によって投稿されたものの抄訳です。Google Cloud Logging

Google BigQuery へリアルタイムでログをストリームできるので、ログデータを分析して直ちにインサイトを見つけることができる。

Google Cloud Storage（Nearline を含む）へログをエクスポートできるので、長期にわたってログデータをアーカイブして、バックアップやコンプライアンス要件を満たすことができる。

Google Cloud Pub/SubCloud Dataflow Cloud Pub/Sub Google Cloud Pub/Subドキュメンテーション

Cloud Pub/Subへのエクスポートを設定するLogs ViewerDevelopers ConsoleGoogle App EngineGoogle Compute Engine

Developers Consoleの中でエクスポートをワンクリックで設定

Dataflowの中でログデータを変換するGoogle Cloud Dataflow

トップカスタマーの主要なデータだけを表示: Cloud Dataflow では、カスタマ ID やアプリケーション ID によってログをグループ分けし、特定のログをフィルタで除外し、システムレベルまたはアプリケーションレベルの基準を特定の形で組み合わせて適用できます。

ログデータを分析しやすいように加工: 販売キャンペーン情報を顧客対話のログや他のユーザープロファイル情報に追加できます。

リアルタイムの分析: 詳細な分析のためにデータを準備することに加えて、Cloud Dataflow ではリアルタイムで分析することもできます。従って、異常の監視、セキュリティ侵入の検知、アラートの生成、リアルタイムでのダッシュボードの更新、などが可能です。

ドキュメンテーションはじめるにはGoogle Cloud PlatformCloud Logging ドキュメンテーションフィードバック-Posted by Deepak Tiwari, Product Manager

Google Cloud Bigtable をベータ公開：Google の検索や Gmail をサポートするデータベースが Google Cloud Platform で利用可能に

2015年5月8日金曜日

* この投稿は、米国時間 5 月 7 日、Product Manager の Cory O’Connor によって投稿されたものの抄訳です。今のビジネスはますますデータセントリックになり、IoT（Internet of Things）の時代の到来とともに、データから効率的にインサイトを引き出せるようになる必要性がでてきました。こういった状況で、アプリケーションよりもインフラの構築や管理に時間を費やすのは機会を逃しているようなものです。
そこで、今回、Google Cloud Bigtable ベータ版の公開を発表します。Google Cloud Bigtable は、業界標準かつオープンソースの Apache HBase API を介してアクセス可能な、フルマネージドの高性能できわめてスケーラブルな NoSQL データベースサービスです。Cloud Bigtable の裏側は、Google が提供するサービスのほぼすべてに使用されているデータベース、Bigtable です。 Google Cloud Bigtable は、大規模なインジェスチョン、分析、およびデータ処理量の多いワークロードに優れており、膨大なデータを処理しなければならない企業やデータ主導型の組織、例えば金融サービスやアドテクノロジー、エネルギー、生物医学、電気通信業界の企業などに最適です。 Cloud Bigtable の特長は以下の通りです。

高いパフォーマンス：アンマネージド NoSQL データベースの 1 桁のミリ秒のレイテンシおよび 2 倍以上のコストパフォーマンスを得られます。

オープンソースインターフェース：Cloud Bigtable は HBase API を介してアクセスされるので、既存のビッグデータや Hadoop エコシステムの多くとネイティブに統合され、Google のビッグデータ製品をサポートします。さらに、業界標準のフォーマットを使用し、シンプルなバルクインジェスチョンツールを介して、既存の HBase クラスタとの間でデータをインポート/エクスポートすることができます。

低コスト：フルマネージドサービスと優れた効率性で、Cloud Bigtable の総所有コストは直接競合する製品の半分以下で済みます。

セキュリティ：Cloud Bigtable は、複製型ストレージ戦略で構築され、すべてのデータは操作中および休止中の両方で暗号化されます。

シンプル： Cloud Bigtable クラスターの作成や再構成は、シンプルな UI を介して行え、10 秒未満で完了できます。データが Cloud Bigtable に入るとストレージがオートでスケールし、複雑なキャパシティ要件の見積りを行う必要はありません。

製品としての実績と高い完成度：過去 10 年以上にわたり、 Bigtable は Google の最も重要なサービスに使用されてきました。また、HBase API は運用と分析が組み合わされたワークロードのための業界標準インタフェースとなっています。

Cloud Bigtable を提供するサービスパートナーもおり、ユーザーが独自の環境でデータストレージに取組むための、新しいアプローチをサポートします。

SunGard は大手の金融ソフトウェアおよびサービス会社であり、スケーラブルかつ管理が容易な金融データのプラットフォームを Cloud Bigtable で構築する際に助けになります。実際、毎秒 250 万という大量の取引メッセージをインジェストすることが可能な金融監査証跡システムをすでに Cloud Bigtable で構築しています。

Pythian は世界的なデータコンサルティング会社であり、OpenTSDB と Cloud Bigtable を統合して、モニタリングおよびメトリック収集のプラットフォームを提供しています。

CCRi はオープンソースの時空間データベース “GeoMesa” のコントリビュータおよびサポーターです。GeoMesa と Cloud Bigtable を統合することで、CCRi はリアルタイムな地理空間分析のためのスケーラブルなプラットフォームをクラウドで提供しています。

Telit Wireless Solutions は IoT において世界的なリーダーであり、IoT EAP (アプリケーションイネーブルメントプラットフォーム)である "m2mAIR" を Cloud Bigtable と統合して、データインジェスチョンにおいて高いパフォーマンスを可能にしています。

今回の発表で、どなたでも Google Cloud Bigtable ベータ版を利用できます。Google ではすでに Qubit のようなユーザーが Cloud Bigtable にペタバイト級の HBase デプロイメントを移行するのをサポートしています。こうしたパワフルな Google の技術を使って、驚くべき革新的なアプリケーションが作成されるのを楽しみにしています。技術的な質問があれば、’google-cloud-bigtable’ というタグを付けて Stack Overflow にポストしてください。また、フィードバックや機能のご要望があれば、フィードバックリストに送ってください。

-Posted by Cory O’Connor, Product Manager

Streak による App Engine の 6 つのポイントをご紹介

2015年5月1日金曜日

* この投稿は、米国時間 4 月 28 日、Streak の CEO であり co-founder である Aleem Mawani によって投稿されたものの抄訳です。
StreakGoogle App Engine

App Engine 上に構築する際に学んだ 6 つのポイントを以下に示します。さらに詳しく知りたい場合は（アプリケーションのアーキテクチャ概要および 15 分間の Q&A を含め） webinar を参照してください。

1. ユーザーの GET リクエストへの高速対応

これは App Engine に固有のものではなく、ほとんどの Web アプリケーションにも言えることです。ユーザーの GET リクエストには迅速に対応しなければなりませんが、App Engine の場合すべてのリクエストに対して 60 秒でタイムアウトします。実際、ユーザーとの対話後の全待ち時間が 200ms 以上にもなれば、ユーザーはアプリが遅いと思うでしょう。リクエストに高速に対応するには、計算や複雑なクエリなどの重い処理をバックグラウンドあるいは書き込み時のいずれかで行う必要があります。そうすれば、ユーザーがデータをリクエストしたときには（読み出し時には）、すでに事前に計算されており、提供する準備ができていることになります。

2. Managed VMs の利用

次に Managed VMs についてみてみましょう。Managed VMs は App Engine のための新しいホスティング環境で、大規模なコンピューティングリソースを活用したり、カスタムのランタイムを実行したりすることができます。例えば、我々はバックエンドのデータ処理モジュールを App Engine のフロントエンドインスタンスではなく、n1-standard-1 マシン（1 CPU と 3.75 GB のメモリ）のインスタンスにホストしています。これは、sustained use discounts という継続割引を利用することで優れたコストパフォーマンスが得られます。Managed VMs は App Engine のフロントエンドインスタンスよりも起動が速く、我々のバックグラウンド処理のニーズに最適です。

3. 高速読み出しのための非正規化

Cloud Datastore は NoSQL データベースですので、データモデリングに関しては RDBM とは異なったアプローチが必要になります。SQL の join が存在しないので、データの非正規化と複製は行わなければなりません。データの複製が面倒に感じることがあっても、読み出しを非常に高速にすることができます。

4. アプリケーションのモジュールへの分割

Modules によって App Engine のアプリをさまざまなコンポーネントに簡単に分割できます。例えば、ユーザーサイドのトラフィックとバックグラウンド処理とに別々のモジュールを持たせることができます。各モジュールはそれぞれ yaml ファイルを持っているので、インスタンスのサイズ、バージョン番号、使用するランタイム言語、など多くのパラメータを設定することができます。前述のように、バックエンドモジュールには性能対コスト比に優れた Managed VMs を使用する一方で、フロントエンドモジュールには素早くスケール可能な App Engine のフロントエンドインスタンスを使用しています。ドキュメントではアプリ構築の方法を説明しています。

5. 積極的なデプロイとトラフィック分割の使用

App Engine ではバージョン管理、デプロイメント、およびロールアウトが簡単にできますので、Streak のデプロイメントは始終行っています。実際、変更を顧客に提供するために、ときには 1 日に 20 回デプロイを実行することがあります。積極的にデプロイを行ってアプリの多くのバージョンを作成し、選択的に新機能を有効にしてユーザーに提供しています。トラフィック分割により新しいバージョンのトラフィックはわずかしか増加しないので、問題があっても早期かつ高頻度で補足できます。それぞれの新しいコードのデプロイは小さな機能しか持たないので簡単に対処することができます。従って、コードベースで関連する問題を見つけるのも容易です。また、Google Cloud Monitoring と（下記の #6 をベースとした）当社独自のシステムを使用して、これらデプロイの変更を監視しています。

6. BigQuery を用いたログファイルの分析

アプリケーションとリクエストのログはパフォーマンスを知るうえで貴重な情報となり、製品の改善に役立ちます。スタートしたばかりなら、最新のリクエストに関するログビューアのリストだけでも役立ちますが、ある規模に達したら、集計データや特定ユーザーのリクエストを分析する必要がでてくるでしょう。我々は Google BigQuery にログをエクスポートするためのカスタムコードを作成しましたが、今では Developers Console から直接ログをストリームすることができます。これらによって、優れたユーザーエクスペリエンスを構築することができます。

Webinar を見てみる

App Engine は我々の成功にとって不可欠なものとなっています。アプリケーションがスケールするにつれて App Engine もスケールするので、運用に対してではなく、顧客に提供する機能の構築に焦点を当てることができます。当社のアーキテクチャ概要と 15 分間の Q&A を含め、App Engine 利用のポイントの詳細については、webinar をご確認ください。

-Posted by Aleem Mawani, CEO and co-founder, Streak

Google Cloud Platform Japan Blog

うるう秒がやって来る！〜 6 月 30 日の ” 1 秒”に備えよう〜

Google Cloud Launcher に 25 の新ソリューションを追加、Cloud Monitoring も統合

ビッグデータを低コストで超高速転送

Google Cloud Platform の価格を引き下げ

プリエンプティブル VM 登場: 標準価格の 3 割で使える、まったく新しい VM

分散 SQL データベースの Crate が Google Compute Engine で Click-to-Deploy 可能に

Google Cloud Debugger が Google App Engine に対応 - トラブルシューティングをもっと容易に

Google Cloud Platform のグローバルイベント Next、6 月東京開催決定

AppScale と App Engine の協働で高い柔軟性を実現

株式会社 Aiming（エイミング）の導入事例 (2): BigQuery で集計をリアルタイムに、コストを 1/5 に

シンプルで繰り返せるデプロイを。Google Cloud Deployment Manager ベータ版

株式会社 Aiming（エイミング）の導入事例 (1): 安く、安定したクラウドへ。オンラインゲームを Google Cloud Platform へ移行

Industriromantik と Compute Engine を使ってクラウドで 3D 画像をレンダリング

Cloud Logging Connector ベータ公開: Cloud Pub/Sub へストリーム

Google Cloud Bigtable をベータ公開：Google の検索や Gmail をサポートするデータベースが Google Cloud Platform で利用可能に

Streak による App Engine の 6 つのポイントをご紹介

12 か月間のトライアル

Labels

Archive

Feed

Company-wide

製品・サービス

デベロッパー