Google Cloud Japan 公式ブログ: 2月 2015

Google Apps for Work 導入が進むヘルスケア業界

2015年2月27日金曜日

* この投稿は、米国時間 2 月 20 日、 Google Apps for Work, Director of Security の Eran Feigenbaum によって投稿されたものの抄訳です。
様々な業界の大小あらゆる規模の企業で、クラウドコンピューティングによって仕事の進め方やコラボレーションの仕組みが変わりつつあることが実感されるようになってきました。それが特に顕著なのが、素早く正確に、かつセキュリティを確保しながら情報にアクセスできることが極めて重要であるヘルスケア業界です。

米国の HIPAA 法（医療保険の相互運用性と説明責任に関する法令）の対象機関が個人の医療情報の保管に Google の強固なインフラを活用しているのはそのためです。Google ではヘルスケア業界向けに、HIPAA への準拠をサポートし、従業員が必要な時に必要な場所で情報にアクセスできるようなツールを提供しています。Google Apps の HIPAA 準拠には、Gmail、カレンダー、Google ドライブ（ドキュメント、スプレッドシート、スライド、フォームを含む）、Vault、サイトなどがあります。Google Apps をご利用中のお客様、および新たに利用を開始するお客様は、Google Apps ヘルプセンターから BAA（Business Associate Agreement）を取得することができます。

Google Apps は数百万のお客様にご利用いただいていますが、HIPAA コンプライアンスは、医療情報を扱う企業や組織にとって極めて重要であると同時に、病院をはじめ健康関連の組織、政府にとって考慮すべき重要事項です。米国イリノイ州で骨関節を専門に扱う大手施設 Rockford Orthopedics（ロックフォード・オーソペディック）のCIO、Joe Ganneman 氏は、「HIPAA コンプライアンスの観点からすると、データをローカルに保管しようとするよりも、実際にはGoogle のようなクラウドインフラストラクチャにデータを保管する方がより確実だと思います」と言っています。また、ワイオミング州の CIO、Flint Waters 氏も次のように語っています。「Google Apps を使うことで HIPAA の厳しい要件を満たしているという確信が得られ、市民に対して、データは安全性に優れたアーキテクチャに保管されていると示すことができます」

HIPAA は Google が対応している数多くの法規制や規格のほんの一例で、Google では様々な業界のお客様がクラウドの恩恵を受けられるよう支援しています。法規制が厳しい業界で事業を営む組織の場合、Google のサービスを利用することで、コンプライアンス要件の適合に必要なツールや保護策を手に入れることができます。

Android for Work の提供を開始します

2015年2月26日木曜日

* この投稿は、米国時間 2 月 25 日、 Android and Chrome for Work, Director of Product Management の Rajen Sheth によって投稿されたものの抄訳です。
Android スマートフォンのユーザーが 10 億人以上となるなか、スマートフォンやタブレットは、数年前に私たちが利用していたコンピューターよりもはるかにパワフルなツールとなりました。メールの確認、ドキュメントの編集、売り上げの確認、契約の承認などの一連の業務において、今やスマートフォンは必要不可欠です。しかしながら、多くのユーザーにおいては、スマートフォンやタブレットを業務で利用できる環境が整っておらず、その利便性が十分に活かされていない状況です。
Google は本日、企業におけるスマートフォンの活用を支援するため、Android for Work プログラムを発表しました。このプログラムによって企業が Android プラットフォームをより安全で、管理しやすく、さらにイノベーティブに活用できるようになります。
Android for Work プログラムは、以下の4つの機能によって構成されます。

仕事用プロファイル - 業務データを隔離して保護するための仕事専用のプロファイルを設定できるようになりました。これらは Android 5.0 (Lollipop) に組み込まれた、ファイルシステムのデフォルト暗号化、SELinux (強制アクセス制御機能)、マルチユーザー機能の上に構築されています。企業は、重要なデータの漏洩を心配することなく業務アプリを展開することができ、ユーザーは、個人データと仕事用データを混同したり誤って消去してしまう心配をすることなく、個人用アプリと承認された業務用アプリを併用できます。

Android for Work アプリ - 仕事用プロファイルが搭載されていない機種(Android 5.0より以前) 向けに、Android for Work アプリも用意されています。アプリからは、メール、カレンダー、連絡先、ドキュメント、Webページ、承認された業務アプリへのアクセスが可能なうえ、社内の IT 部門によって管理できます。

Google Play for Work - Google Play for Work を利用することで、Google Play 上のあらゆるアプリを仕事用プロファイル向けに展開でき、業務に利用するアプリを安全に管理できます。Google Play for Work は社員に向けたアプリの展開を容易にし、IT 部門はアプリの配布と管理を簡単に行うことができます。

プリインストールアプリ - Exchange および Notes に対応したメール、連絡先、カレンダーアプリが予めインストールされており、 Google ドキュメント、スプレッドシート、プレゼンテーションによって文書の編集もできます。

Android for Work プログラムの開始にあたり、Android のプラットフォームを利用するパートナー企業の協力をいただいています。

パートナー企業により今後以下が提供される予定です。

モバイルデバイスの一元管理 - エンタープライズモビリティマネージメント (EMM) パートナーは、標準管理 API を統合することにより、単一のダッシュボードを用いて新旧すべての Android デバイスを管理できるシンプルなソリューションを提供します。Android for Work が持つすべての機能は EMM パートナーによって提供され、プロバイダーの数は今後も増えていく予定です。

セキュアな業務アプリ - ソフトウェアベンダーおよび開発者は、Google Play に存在する Android アプリを修正や特別な枠組みなしにすべての Android デバイス向けに安全に展開できます。また、IT 部門がアプリごとに利用ポリシーを設定するために、共通管理設定を用意することも可能です。

革新的なデバイス - 新たなデバイスやユーザー体験を作り出し、ユーザーにとってより多くの価値を提供する Android スマートフォン / タブレットメーカーも、Android for Work プログラムにとって重要な役割を果たします。

EMM パートナー、アプリ開発パートナー、デバイスメーカーという幅広いパートナーと共に、Android for Work プログラムは企業に最適な選択肢と柔軟性を提供します。詳細は google.com/work/android(英語) をご覧ください。

Google Cloud Platform 専用チャネル開設のお知らせ - GCP の最新情報をいち早く日本のデベロッパーやビジネスへ

2015年2月23日月曜日

2014 年 4 月の Google Cloud Platform (GCP) の日本市場本格展開のお知らせからもうすぐ 1 年、遠隔画像診断センターエムネスの診断システム、エイチームによるソーシャルゲームのバックエンドといった GCP 活用事例や、サービスパートナーやトレーニングに関する情報、そして定期的に GCP の最新動向や Kubernetes などの Google の取り組みを Google for Work ブログの中でお伝えしてきました。これからも、よりタイムリーに Google のクラウドテクノロジーをプラットフォームとして活用している、または検討している日本のデベロッパーやビジネスへ最新情報をお伝えすべく、Google Cloud Platform のブログと Twitter を開始します。日本国内の皆様に向け情報を発信していきますので、フィードの登録やフォローして、Google Cloud Platform の最新情報をご確認ください! Google Cloud Platform Japan 公式ブログ http://googlecloudplatform-japan.blogspot.jp/ Twitter 公式チャネル : GCP Japan https://twitter.com/googlecloud_jp

Google 主催、集中講座「イノベーションはどうやったら起きるのか？」を実施します。

2015年2月23日月曜日

アイディアが生まれ、ナレッジを共有する土壌をITがどう支えるかを考える
ビジネスのグローバル化やワークスタイルの多様化など、企業を取り巻く環境が絶えず変化し続ける中、その変化に対応しさらなる変革を遂げていくために、今や様々な企業が『改善』や『改革』に取り組んでいます。私共 Google 社内においても、新たな価値やサービスを創り出していくために、あらゆる制約を超えてチームが協働できる環境づくりを心がけています。皆がアイデアを出しあい、シェアし、高め合う文化が根付けば、企業はもっとイノベーションを生み出せるようになると考えているからです。
Google の企業向けソリューションを展開する Google for Work では、過去 10 年間に行われたセミナーやイベントにおいて最も多く質問・疑問があがったテーマにフォーカスをあてて、昨年11月から集中講座を開講してまいりましたが、ついに今回、その最終回となるイノベーションをテーマにしたセミナーを 3 月 3 日 (火) に実施します。新しいアイデアが生まれ、発展し、実際にサービスや製品として形になる裏側や、イノベーションを引き起こす社内環境をGoogle がどのように構築してきたのかについて、Google Drive for Work (Google が提供するファイル共有サービス）を用いた実際の事例を交えてご紹介します。ぜひこの機会に、奮ってご参加ください。

◆開催概要◆
◆テーマ：　　　イノベーションを引き起こす社内環境を実現するには？　　　Google が実践する Google Drive for Work を用いたコラボレーション
◆日程：　　　2015年3月3日（火）　　　14:30～17:00 （14:00 受付開始）
◆場所：　　　グーグル株式会社セミナールーム　　　東京都港区六本木6-10-1 六本木ヒルズ森タワー
◆参加費：　　　無料
★お申し込み/詳細はこちら
主催：グーグル株式会社
皆様のご来場をお待ちしております！
《お問い合わせ先》グーグル株式会社 Google for Work セミナー事務局 google-for-work-japan@google.com

Google 社員の働き方紹介 vol.2

2015年2月20日金曜日

Google 社員の取り組みや働き方について、月に 1回ご紹介していきます。第二回目は、Google for Work でセールスを務める勝谷さんにお話を伺いました。

Q. 普段どんなお仕事をされているのですか？
大手企業様向けに、Google Apps のみならず、Drive for Work や Chromebooks for Work といった比較的新しいサービスや製品を販売する活動をしています。実際にお客様先に出向いて、製品のご説明をさせていただくのが日々の業務の大半を占めています。従来は、IT 部門のお客様とやり取りさせていいただくことが多かったのですが、ここ最近は IT 部門に限らず営業部門や企画部門など、あらゆる部門のお客様からのお問い合わせやご要望が増えています。
Q. お客様とのエピソードで心に残っていることなどありますか？
Google には昨年5月に入社したので、社歴はまだ 10 ヶ月ほどですが、前職で通算 5 年、販売パートナーとして Apps ビジネスに携わってきた中で、述べ数千社以上のお客様とお会いしてきました。そうした中で、Apps を導入される前のお話や、導入後のお話を沢山聞かせていただいているのですが、Apps を導入いただいたお客様は大概満足されていて、導入後 1,2 年も経過すると、『この仕組みがないと、今と同じスピードで仕事ができない』と言ってくださるのです。こうしたお客様からの声や、実際に導入したテクノロジーがその会社の一部になっているという事実が、私にとっては何にも代えがたい喜びです。
Q. お客様からのご要望に対して、どのような提案をしているのですか？
ITのコンシューマライゼーションが進むにつれて、最近ではシャドーIT※1 に頭を悩ませるお客様が増えてきています。また、ストレージという観点でも、年々増え続ける電子データの管理方法に課題を抱えているお客様も業種業界問わず多数いらっしゃいます。そんな時に我々が、『企業としてこれを使ってください』と Drive for Work などのサービスを提供するだけでも、お客様は非常に満足してくださいます。
お客様のご要望に対して私たちが常に気に留めているのは、過去 5年より、今後5年のほうが、ITの進歩はより早いスピードで進んでいくということ。それにも関わらず、企業の仕組みはそのままで、『じゃあこれから次の5年を考えましょう』というようなペースだと、技術の格差はどんどん開いていく一方です。時代の進化、技術の進歩に応じて、ツールや企業の仕組み、働き方が準じて変わっていかないと、いつかそれが開きすぎてしまうし、いち従業員としての満足度が上がっていかない、ということにもつながってしまうと思います。お客様が早い変化に対応できるような仕組みやサービスを提供し続けることが、Google for Work がお客様に提供できる最大の付加価値であり、我々のミッションであると考えています。 ※1 会社で承認されていない個人所有のデバイスやサービスを仕事で勝手に使ってしまうこと

Q. 担当されている Drive for Work とはどのようなサービスですか？
Google が提供する、企業向けオンラインファイル共有サービスです。特徴を一言で言うと、容量無制限、且つ『全部のせ』のサービスであると言えると思います。通常、ストレージを用意しても、ファイルをアップして、取り出して、という作業だけでは仕事は終わりません。業務の流れとしては、ストレージにアップしたファイルに、会議をしながら同時編集をしたり、ファイルをスケジュール表に添付してそこから閲覧させたり、ポータルサイトに公開したり、といった作業が発生します。つまり、ストレージ単体ではなく、実際に業務で使う他の機能と連携していることが大事なのですが、Drive for Work の場合、Gmail、カレンダー、サイト、といった Google Apps の機能があらかじめ含まれているので、それらすべての作業をひとつの ID で一気通貫で出来るというのが優位性になっています。
私自身も日常的に Drive for Work を活用し社内外でファイルのやり取りをしていますが、例えばこれまでは提案書のプレゼンテーションの中に事例の動画ファイルを入れようとしたらそれは大変でしたが、今ではどんなに重いファイルでもリンクひとつで共有できるので、無駄な手間やストレスが減り大変助かっています。容量を気にせず、更に企業として求められる監査やログの機能が充実しているというのも引き合いが高いポイントでしょうか。
Q. 普段どんな働き方をされていますか？
営業なので、お客様先やパートナー様先に出かけていることも多く、働く場所にとらわれずに比較的自由に動いています。また、成果主義且つフレックスタイム制でもあるということで、お客様からはよく、『会社に来ないようになって、社内の人との関係が希薄になるんじゃないですか？』と聞かれるんです。でも、実際はぜんぜん違います。私はGoogle に来てから、空いている時間も出来る限り会社に来るようにしています。もちろん環境としては、自宅にいても出先にいても会社と同じように仕事が出来ます。でも、やるべきことをやるために、そしてそれをもっと早くやるために、色々な人の協力を得ることが必要で、そのためには実際に顔をつきあわせて相手の表情や空気を感じながら意見を交わすことが大事だと気付いたんです。
そしてその思いを支えるインフラとして、オフィス環境が充実しているというのは非常にありがたいことだと思っています。沢山の会話が生まれるカフェやコラボレーションスペース、フリースペースがあり、私自身も自席にこだわらず、その時々に最大のパフォーマンスを出せる場所を選んで仕事をしています。結果を出すために企業、組織はあるわけですが、それを支える空気や環境が Google にはあるのかなと感じていて、そういう意味ではうまいこと会社の思惑通りになってしまっているのかも知れません（笑）。
Q. 今後どんな事を実現していきたいですか？
日常生活で言えば、やはり仕事をしている時間が長いので、仕事自体がもはや生活の一部になっています。そこで、ワークライフバランスを実現していきたいというよりは、むしろ、仕事をもっともっと充実させて、ライフ自体、プライベート自体も一緒に充実したものにしていければと考えています。どちらかというと、『ワークライフインテグレーション』と言われる考え方に近いですね。我々が提供している Google for Work のサービスも、そういったことを支援できるツールであると本当に信じてお客様にもご紹介をしています。そうしたツールを使っていただくことによって、企業で働く一人ひとりの仕事の充実、そしてその積み重ねとして企業の生産性向上や利益の向上を支援していけたら、と願っています。

ーーーーーーーーーーーー Google 社員の働き方紹介 vol.1 は こちら

[GCP] PerfKit Benchmarker: クラウドのパフォーマンスを計測する新しいオープンソースツール

2015年2月18日水曜日

* この投稿は、米国時間 2 月 11 日、 Google Cloud Platform Performance Team によって投稿されたものの抄訳です。
クラウド上でアプリケーションを開発していく中で、パフォーマンスが何よりも懸念すべきことである場合もありますよね。単に料金や機能チャートを見ているのとは違い、クラウドが実際に提供していることを評価しようとすると驚くほど難しいことが分かります。Google Cloud Platform のユーザーが、どうやって相対的なパフォーマンスを計測しているのか調査していると、まさにこの問題に直面していることは明らかでした。
クラウドパフォーマンスの評価をもっと簡単にしたい、そう考えて他のクラウドプロバイダー、アナリスト、学術的な専門家からのインプットをもらいました。その結果として生まれたのが、PerfKit Benchmarker という名前のパフォーマンスベンチマークフレームワークです。PerfKit は独特で、クラウドに用意したリソースに対し、エンドツーエンドでの時間を計測します。加えて、ピークパフォーマンスの殆どの標準的なメトリクスをレポーティングが可能です。これで、アプリケーションのスループット、レイテンシー、バリアンス、オーバーヘッドが透過的にわかるようになり、さらにクラウドプラットフォームを横断してベンチマークできる簡単な方法を手に入れられるようになります。
結果の評価に役立つように、データの視覚化用のツールとして、PerfKit Explorer も構築しました。加えて、実際にネットワークパフォーマンスを内部的にテストしたデータを使って、あらかじめて作っておいたダッシュボード集も含まれているので、最初にデータのインプットをしなくても、PerfKit Explorer で遊べます。
ソースコードは、ASLv2 ライセンスでリリースし、コントリビューターの皆さんが、コラボレートしたり、各ベンチマークのバランスを保つことを容易にできるようにしています。何か追加したかったり、削除したいことがあるなら、Github であなたの参加を歓迎します。
PerfKit は、今の時代のベンチマークフレームワークであり、クラウドテクノロジーの変化にあわせて発展できるように設計されています。常に最新のワークロードを計測しているため、インフラストラクチャーのニーズに対し何をするのがベストであるのか、データに基づいた判断が可能になります。新しいデザインパターン、ツール、プロバイダーの出現にあわせ、PerfKit を最新の状況に適合させていきます。現状でも、有名なベンチマークが含まれていますし、それに複数のクラウドプロバイダーを横断して実行できる一般的なクラウドワークロードもカバーしています。

サンプルのパフォーマンスダッシュボード
過去 1 年、この分野の研究の第一人者の方や、企業、GCP のユーザーまで 30 以上の人や会社と作業してきました。そこでいただいたフィードバックや貢献していただいたことに対し感謝しています。このような企業には、次の企業が含まれます: ARM、Broadcom、Canonical、CenturyLink、Cisco、CloudHarmony、CloudSpectator、EcoCloud/EPFL、Intel、Mellanox、Microsoft、Qualcomm Technologies, Inc.、Rackspace、Red Hat、Tradeworx Inc.、Thesys Technologies LLC。加えて、スタンフォードや MIT が、3 ヶ月に一度のコミュニティから提案されたデフォルトのベンチマークや設定についての議論を主導することを引き受けてくれたことには、心が踊りました。
簡単に使えて役に立つツールを、皆さんが見つけられるように願っています。 - Posted by the Google Cloud Platform Performance Team

[GCP] Kubernetes の全容を知りたいと思いながらも、ためらってしまう質問

2015年2月17日火曜日

Martin Buhr によって投稿ブログコンテナクラスタ管理ツール発表

Google にはすでに成熟した堅牢なクラスタ管理システム（1 週間に 20 億個のコンテナを起動）があるのに、なぜ Kubernetes が開発されたのですか。

Kubernetes はどのように Docker と関連しますか。 Docker Swarm との違いは何ですか。

Google の Kubernetes のオープンソースプロジェクトへの取り組みが、今後も長期的に継続される保証はありますか。

Kubernetes は Google Cloud Platform の包括的な戦略にどのように適合し、推進させますか。

オンプレミスや他のパブリッククラウドでのデプロイに向け、 Google が Google Cloud Platform とは別に Kubernetes の改良を進める動機は何ですか。

現在、そして今後の Kubernetes と Google Container Engine の関係はどのようなものですか。

Kubernetes G+ ページ Kubernetes が開発された理由
技術コンセプトChromiumcgroupscadvisor
Urs Hölzle重力井戸
Kubernetes はどのように Docker と関連しますか。 Docker Swarm との違いは何でしょう。
Kubernetes

こちら投稿
Google は Kubernetes での取り組みを継続しますか。お客様やパートナーからは、「プロジェクト/アプリケーション/事業の未来を Kubernetes の長期的な実行可能性に賭けようとする場合、 Google がその間に関心を失い、プロジェクトが失速する可能性はありませんか」といった質問を受けます。OpenShift バージョン 3コントリビューター
Kubernetes はどのように Google のクラウド戦略に適合しますか。
その他のクラウドやオンプレミスでの Kubernetes1

Kubernetes と Google Container Engine の関係Google Container Engine
大きな期待投稿
この領域で多くの経験を積んでいるとはいえ、 Google がすべての答えにたどり着いたわけではありません。社内での取り組みからは見えてこない要件や検討事項があるからです。それを踏まえた上で、 Google が構築に取り組んでいる内容をチェックしてみてください。

試用バグの報告サポートの利用プルリクエスト（PR）の送信1：サプライチェーンの多様化やベンダーリスク管理の理論では、事業やインフラストラクチャの重要な要素で単一のサプライヤーに依存することが推奨されていません。これは、独占所有権のある IT システムやソフトウェアの大手ベンダーに何年も依存してきた数多くのお客様の経験により実証されています。 Docker と Kubernetes の優れた点の 1 つは、さまざまなリソースプール間でのアプリケーションの移動（ノートパソコンからサーバー、サーバーからサーバー、データセンターからデータセンター、クラウドからクラウドなど）に伴う摩擦が大幅に低減されることです。

[GCP] Google Cloud Platform Build-Off: SxSW でアプリケーションをデビューさせよう

2015年2月16日月曜日

Greg Wilson　によって投稿

Google Cloud Platform (GCP)Google Cloud Platform Build-OffGoogle Cloud Platform クレジットと 24 時間 365 日のサポート

テクノロジーが音楽、映画、ゲームに対してできることの限界を広げるアプリケーションを Google Cloud Platform で構築。

個人、または最大 3 人までのチームで申し込む。

2015 年 2 月 5 日から 28 日までの間にアプリケーションをサブミット。

アプリケーションは、オリジナリティ、世の中のニーズ、Google のツールの利用、技術面から評価されます。

公式 Build-Off サイトG+Twitter

[GCP] 1 月を振り返って: クラウドの料金、コンテナの新しい連載、そして GCPUG

2015年2月16日月曜日

* この投稿は、プロダクトマーケティングマネージャー Charlene Lee のポストをもとに、Google Cloud Platform チームが編集しました。

さあ、1 月を改めて振り返りましょう。US でポストされた、1 月の振り返りと一緒に見て行きます。

コンテナを探る

コンテナは、ソフトウェア開発の世界では、引き続きホットトピックですよね。それは Google でも同じです。実際、Kubernetes と cAdvisor が、Black Duck Software のオープンソースルーキー・オブ・ザ・イヤー賞に選ばれました！
1 月 17 日には、Docker Meetup Tokyo #4 が開催されました。国内でも Docker コンテナを使い業務運用している事例が生まれはじめ、大きな変化が訪れる予感がしてきます。
この変化、この新しいパラダイムを理解するための、連載を始めました。あたり前に使われるのはもう少し先だと思いますが、何故今パラダイムのシフトを起りつつあるのか、この ”コンテナレボリューション” を一緒に見て行ける内容になっています。
第一回目は、”コンテナ、Kubernetes、最新のクラウドコンピューティングの動向” でした。VM にはない、コンテナなら可能なことを何か。それと、1 インスタンスのコンテナ、Docker（分散アプリケーションのためのオープンプラットフォーム）、Kubernetes（インテリジェントに管理されたコンテナのクラスター）、Google Container Engine（Google がホストする Containers-as-a-service）、これらの関係を見ていきます。
コンテナの世界、それに Kubernetes を作成の基となる Google の根本的な原理をもっと深く知りたいなら、“コンテナクラスターを構成するものとは？” を読んでください。コンテナクラスターマネージャーを構成する要素や、大規模なクラスターとしてコンテナを動かす理由がわかります。
もうひとつ、直ぐに日本語版も公開しますが、“Everything you wanted to know about Kubernetes but were too afraid to ask.” で、今さら聞けない Kubernetes についてお伝えしています。そして、まだまだ連載は続いていくので、お楽しみに。
Google Cloud Platform (GCP) におけるコンテナという面では今月はあまり紹介できなかったのですが、去年の 9 月に Google Container Engine のアルファ版がローンチし、続いて Google Container Registry のベータ版をリリースしました。これで、GCP 上にプライベートな Docker イメージのストレージが作れ、GCP という環境に置くことで、それを高いセキュリティで運用できる、コンテナをプロダクションレベルで運用していくために必要なサービスです。ベータ段階なので皆さん利用でき、ストレージ以外の料金もかからないので、是非試してください。

クラウド料金をわかりやすく

ホットトピックといえば、今月はその中でも上位に位置する “料金” をわかりやすく読み解きました。料金はやはり、インフラストラクチャーを設計するときの選択条件として重要な部分ですよね。でも、実際のところ複雑で、まさに雲をつかむ（クラウドにかけて、冗談ですが）ようによくわかりません。それを Amazon Web Services と GCP を比べながら、実際に料金はどれくらいかかるのか、その投資で得られることは何なのかを見ていきました。

テクノロジーとその使い方: Dataflow の Big Data パイプライン、MongoDB バックアップの検証、ボトルネックの診断…

訳していないものもありますが、GCP でサービス開発をするときに参考になる情報を 1 月もいくつか紹介できました。

ゲノミクスから Web サイトデザインまで: 事例紹介

急激に進化するクラウドテクノロジーの本当の利点は、皆さんのストーリーがあってこそ意味があります。1 月は、様々な産業や地理をまたいだ事例を紹介しました。

Alacris Theranostics: ベルリンを拠点とした、マックスプランク研究所の分子遺伝学分野のスピンオフです。GCP を使い、がん患者それぞれに最も適した薬を導いています。
Aucor: フィンランドを拠点のデジタルメディアエージェンシーです。顧客の Web サイトを GCP に設置することで、急激なユーザーの拡大によるスケールを Google にまかせ、彼らの本業となる、素晴らしい Web サイトを作るということにフォーカスしています。
Shine Technologies: オーストラリアでデジタルコンサルティングを実施しています。BigQuery を使って、数十億の広告クリック、インプレッション、それにビジネスの意思決定を導くデータから、ビジネスに役立てる発見をしています。
Aerospike: オープンソースの NoSQL データベースを提供し、Google と同じく Mountain View にあります。Aerospike は猛烈なパフォーマンスを提供するために、Local SSD の限界を突破します: Local SSD の少なくとも 95% の読み込み完了を 1ms 以下で。実際にベンチマークが示しているのは、ストレージコストを RAM と比較して Local SSD なら、価格面で 15 倍の優位性を持てることを伝えています。

こういった面白い内容は、日本語でもどんどん伝えていきます。国内の事例もいくつか取材にお伺いしています。準備が整ったら順次伝えていくので、こちらもお楽しみに。それから、皆さんでも GCP を使って何をしてるか Twitter や Google+ で教えてください。#gcpja

新しい年、新しい連載: Learn with Google Cloud Platform Webiner シリーズが始まりました

月刊の Webiner シリーズでユースケースを取り上げながら、クラウドでの複雑なビジネス上の問題の解決や、ビジネスの成長を促進することを、リアルタイムで Twitter や Google+ で Q&A セッションを行います。今月は、急速に成長しているオンライン小売業の zulily がどうやって Big data を使い、ユニークなテーラード製品や顧客体験を絶え間なくマスマーケットに提供しているのかを話しました。

GCPUG (Google Cloud Platform ユーザーグループ)

昨年紹介した GCPUG、第一回 GCPUG in Tokyo が開催されました。gcp ja night と違い、GCP を知らない皆さんにも参加しやすい内容で、ハンズオンも行われました（とはいえ、マニアックな面白い内容も潜んでます）。そして BigQuery の本といえば、Google BigQuery Analytics、近々日本語訳がでるかもしれない、という楽しみな話を聞けました。
皆さんもどんどん参加して、あるいは支部を作ってください！皆さんと話ができるのを楽しみにしています。
2 月も、期間は短いものの内容の濃い GCP 情報とクラウドインフラストラクチャーを使う本当の利点をお伝えします。

[GCP] Google Cloud Logging を使い、ログからビジネスやオペレーションのインサイトを

2015年2月6日金曜日

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

少し前に Google Cloud Monitoring のベータリリースが行われ、皆さんが利用できるようになったことをお伝えしました。Cloud Monitoring は Stackdriver をベースに、アプリケーションのパフォーマンス、キャパシティ、アップタイムについてのインサイトを把握できるサービスです。そこに Google Cloud Logging が組み合わさることで、Google Cloud Platform は、オペレーションしていくためのさらに強力なツールセットを提供できるようになりました。私たちの本質的な目標の 1 つは、運用オペレーションを簡単にし、そこからインサイトを得られるようにすることです。Google Cloud Logging は、皆さんにとって、とても重要となる 3 つのチャレンジをターゲットにしています。

ログデータをリアルタイムで解析

先を見越したイシュー管理ができるように、エラーとエラー率のモニタリング

費用対効果の高い方法で、長期間ログをアーカイブ

今回、ベータとして利用できると同時に、新しいエクスポート機能を追加しています。Google App Engine のログを、Google Cloud Storage バケットだけでなく、Google BigQuery のデータセットとしてエクスポートできるようになりました。これでログデータの保管から解析までが容易に行えるようになります。エクスポートの設定は、Cloud Logs Viewer の画面から、フィルターのドロップダウンメニューの横にあるギアアイコンをクリックして設定ページにアクセスします。

主要機能 BigQuery へのエクスポート – エクスポートの設定ページでは、ログのエクスポート用に BigQuery に事前に定義しておいたデータセット（または新しくデータセットを追加）に対し、ログをストリームするかを選べます。

“Stream App Engine Logs to BigQuery（App Engine のログを BigQuery にストリーミングする）” チェックボックスをチェックして、”Done（完了）” ボタンを押すとすぐにエクスポートがはじまります。Developers Console の左側のメニュー “Big Data” から、BigQuery にアクセスすると、BigQuery でログを見て、操作して解析できるようになっています。

これで、トラフィックにエラー、レイテンシー、それにコストなども含めて、様々なログデータから　BigQuery の全ての力を使いインサイトを得ることができます。例として、syslog のファイルから、クラスターのゾーン、あるいはエラーが一定期間にログされている数を数えるためにクエリーを実行します。

Google Cloud Storage へのエクスポート - エクスポートの設定ページでは、Cloud Storage にログを保存するために定義しておいたストレージバケット（または、新しいバケットに）を使い、ログをエクスポートするかを選べます。

“Stream App Engine Logs to Cloud Storag（ログを Cloud Storage に保存）” チェックボックスをチェックして、”Done（完了）” ボタンを押すとすぐにエクスポートがはじまります。ログのアーカイブを使うには Developers Console の左側のメニュー “Storage” から、Cloud Storage にアクセスしてください。

Cloud Storage は、ビジネスやコンプライアンスでの要求から、独自アーカイブの必要性を基に、ログのアーカイブを可能にします。そして、さらなるデータ解析のために、BigQuery や Cloud Dataflow、あるいは何らかの Hadoop ソリューションにログを転送できる柔軟性もあります。皆さんの多くが、ログ解析に BigQuery を使って成果をあげています。その 1 つが Wix です。 Wix では、オートスケールでデプロイされている Compute Engine のログを解析するために BigQuery に大量の syslog データを送り、システムの状態やエラー率に関するインサイトを得ています。また、時系列のデータを生成し、Google Cloud Monitoring とインテグレートすることで、システムパフォーマンスとビジネスメトリクスをモニターすることが可能となり、そこからオペレーションを行っていく上で必要なインサイトを得ています。
- Dmitry Shestak, Engineer@Infrastructure team, Wix
始めてみよう現在 Google Cloud Platform を使っているなら、Cloud Logging のエクスポート機能はすぐに利用できます。追加料金はかかりません（Google Cloud Platform のその他のサービスでは、従来通り課金されます）。もっと情報が必要なら、Cloud Logging のドキュメントを読んでください。そしてフィードバックが聞けることを楽しみにしています。 -Posted by Deepak Tiwari, Product Manager

[GCP] Elasticsearch を Click to Deploy を使って Google Compute Engine にデプロイ

2015年2月5日木曜日

Elasticsearchのダウンロード数は、ここ数年で 1,000 万件を超えているそうです。それだけ大量データの検索や分析のニーズが増えているというわけですね。GitHub は、20 億の文書のインデックスを作成し（文章は絶えず編集されています）、サイト検索に利用しています。SoundCloud の 4,000 万ユーザーは、テキスト検索を主にナビゲーションとして使っています。

国内でも、kuromoji を形態素解析に使うといった、日本語全文検索を向上するための情報が数多くあり、導入が容易になってきましたし、実際にサービスで使われている話も耳にするようになってきました。昨年末の Qiita の Elasticsearch Advent Calendar もまだ記憶に新しいところです。

その Advent Calendar の中で、Elasticsearch クラスタを Google Compute Engine を使い 10 分で立ち上げる、という投稿がありましたが（GCE の入門として書かれたものです）、今日紹介する Click to Deploy for Elasticsearch は、もっと速く、デプロイ先のゾーン、ノード数やマシンタイプ、インストールオプションだとかの設定を済ませてクリックすればデプロイ完了です。

elasticsearch-analysis-kuromojiなどは含まれていないので、必要なときは、デプロイ完了後に、Google Developers Console、または gcloud コマンドで SSH アクセスして足りないものを導入してください。

さて、Elasticsearch の情報は数多くあるので、ここでは Click to deploy for Elasticsearch について、デプロイ処理の中心となる Google Cloud Deployment Manager を中心に見ていきます。

Google Cloud Deployment Manager は、デプロイ時に必要な全てのリソースが記載されたテンプレートと、Elasticsearch のデプロイに必要な固有の処理が書かれたシェルスクリプトを使ってデプロイを行います。これらの設定は、YAML ファイルに記載され、一部の定型的な、再利用可能なリソースの一覧は Jinja か Python で書かれたテンプレートファイルとして作成し、設定ファイルからインクルードする形で利用します。テンプレートでは、パラメーターが利用できるというメリットがあり、例えば Click to deploy のデプロイ前の設定のような場面なら、動的に値を設定したいときに利用できます。できた設定は、Google Cloud Deployment Manager でデプロイできます。

Google Cloud Deployment Manager は、まだアルファであるため、一部の方にしか利用できません。今後ベータ段階に進んだとき、あらためてお伝えできると思います。実際に Click to deploy for Elasticsearch のデプロイ処理は、以下のステップで行われています（OS は Debian 7 Linux です）：

事前に必要なソフトウェアとして、OpenJDK 1.7 をダウンロードし、インストール

Elasticsearch をダウンロード、そしてインストール

このとき利用したソースコードは、/usr/src に移動

データディスクを作成し、/elasticsearch にマウント

事前に設定した、あるいはデフォルトのクラスター名と、そのノードが動くインスタンスの IP アドレスで各 Elasticsearch ノードを設定

Elasticsearch のパフォーマンスのために、決められたパラメータに値を設定

Marvel をダウンロードし、インストール後に設定変更（デプロイ前の設定で、Marvel のインストールが true であるなら）

このように Elasticsearch がデプロイされ、テキスト検索、Logstash を使ったログの処理と分析、Kibana を使ったデータビジュアライゼーションがすぐに利用可能になります。この 3 つのオープンソースプロジェクト、Elasticsearch、Logstash、Kibana は、Elasticsearch 社のサポートもあって、密接にインテグレーションされていることから、ELK スタックと呼ばれています。

Click to Deploy for Elasticsearch の、Elasticsearch からの発表は、Elasticsearch on Google Compute Engine（英）の中で行われています。サポート、トレーニング、商用プラグインが必要なときは、ここから Elasticsearch にお問い合わください。

[GCP] コンテナクラスターを構成するものとは？

2015年2月4日水曜日

* この投稿は、米国時間 1 月 22 日、Senior Staff Engineer and Kubernetes Cofounder の Joe Beda によって投稿されたものの抄訳です。
先週は、Miles Ward、Google Cloud Platform ソリューションのグローバルヘッドに、コンテナに関する連載のキックオフとして、コンテナに Docker、それに Kubernetes、これらの全体コンセプトをポストしてもらいました。まだ読んでいなければ、まずはそこから読んでおきましょう。今回のポストに必要な知識を得られますよ！今週は、Joe Beda、シニアスタッフエンジニアで Kubernetes プロジェクトを立ち上げたメンバーの 1 人です。Google のコンテナ運用を支える中心となっているテクニカルコンセプトについて、さらに深く、詳細に話してくれます。それが Kubernetes の開発を告げることになり、また今後の連載の基礎にもなってきます。コンテナクラスターを構成するものは何か？ Docker のようなコンテナシステムが最近盛り上がってきたことは (当然ですが) 興奮しますよね。アプリケーションコードをパッケージ化して転送し、異なるいろいろな環境で動かすことができる、まさにアプリケーションの運用が新しいレベルに至っているという状況です。でも、プロダクションレベルにまででコンテナ利用を広げていこうとすると、どこでどのコンテナを動かすのかや、膨大なコンテナの扱いであったり、ホストをまたいだコンテナ間をうまくコミュニケーションさせる方法であるとか、新たに運用面の問題が持ち上がってきます。そこで Kubernetes の登場です。Kubernetesは、こういった問題を解決できる Google 発のオープンソースツールキットです。先週のポストを思い出してください、私たちは、Kubernetes を “コンテナクラスターマネージャー” である、としています。この分野では、多くの皆さんが “オーケストレーションシステム” と呼んでいますが、それは違うかな、と思っています。オーケストラの音楽は綿密に計画されていて、決められた楽譜があらかじめ演奏家に配られますが、Kubernetes クラスターの制御はむしろ、即興のジャズ演奏。リアルタイムに、今の状況や入っていくるデータに反応するダイナミックなシステムなのですから。そこで、コンテナクラスターの構成するものは何か？という疑問です。複数のコンテナと、コンテナ間のコネクションを配備して統制するダイナミックなシステム？そうですね、それにノード（物理サーバーであっても、仮想マシンであっても）も含めて。このポストの残りは、3 つのことを見ていきます: コンテナクラスターを構成している要素は何かと、それらを動作させる方法、それから相互に接続させた要素を協調させて動かす方法。それに、これまでの Google での経験的から、コンテナクラスターには運用のためのレイヤーが含まれるべきで、それがどういうことなのかも掘り下げていきます。なぜコンテナクラスターが必要なのか？ Googleでの、コンテナクラスター構築の要件となっているのは、常時使用可能であること、パッチ当てやアップデートが可能であること、必要なときにスケールできること、簡単に計測できてモニター可能であることなど、ごく一般的なものです。コンテナは、アプリケーションを簡単に速くデプロイできるようにし、細かいレベルでの制御を可能にしてくれますが、このような目標を達成するには、コンテナ自体を制御するソリューションがまだ足りません。この 10 年の経験から、Google ではコンテナクラスターマネージャーを置くことで、こういった要件を満たせると同時に、多くの利点があることがわかりました:

変動するパーツを制御可能にするマイクロサービス。クラスターマネージャーが、アプリケーションを小さなパーツに分解し、個別に制御、スケールできるようにします。それが、小人数のエンジニアチームの間に明確な境界を持たせることになり、Google の組織的なスケールアップに繋がりました。

障害時に自己修復するシステム。クラスタマネージャーは障害が起きたマシンの受け持っていた処理を、別のマシン上で自動的に再開します。

簡単な水平スケール。コンテナクラスターには水平スケール用に、設定 (レプリケーション数) を変更するくらい簡単に、処理能力を加えていけるツールがあります。

高い利用効率。Google では、コンテナへの移行後から、リソース利用の効率が劇的に改善されています。

クラスターとアプリケーションのオペレーションチームの特殊な役割。開発者はサービスを動かすインフラストラクチャーよりも、サービスの構築にフォーカスできるようになります。たとえば、GMail の開発とオペレーションをしているチームはクラスターオペレーションのチームと直接話すことはほとんどありません。このように関心が別れることで（強制的にではなく）、オペレーションチームをより広い範囲で活用できるようになります。

このいくつかは私たちに固有のことだろうと理解しつつ、さて、すばらしいコンテナクラスターマネージャーに必要な要素と、クラスターの中でコンテナを動かす理由を知るために、皆さんがフォーカスすべきことを見て行きましょう。
要素 1：コンテナのダイナミックな配置クラスターの構築を成功させるには、ジャズの即興のような感じがちょっとだけ必要です。ワークロードをコンテナイメージにパッケージ化したら、それをどこでどう動かしていくのか、その意図を宣言的に指定にしていきます。そして、実際にどこで実行するのかは、クラスター制御システムが判断します。これを私たちは “クラスタースケジューリング” と呼んでいます。これは勝手に配置されるということではありません。それどころか、コンピューターサイエンスの観点から見て、クラスタスケジューリングに興味深くも難しい課題を生じさせるいろいろな制約があります。スケジューリングの際、スケジューラは、VMまたは十分に余裕のある（CPU、RAM、I/O、ストレージなどに）物理マシンにワークロードを配置していきます。しかし、信頼性という観点から見ていくと、連鎖的な障害を避けるために複数のマシンやラックにジョブを分散する必要も出てきます。あるいは、マシンのいくつかには特殊なハードウェア (たとえば、GPU、Local SSDなど) を持たせることもあるでしょう。スケジューラーは、このように変化する状況に対応しながら、障害、クラスタの増大/縮小、処理効率の向上に対処するために、スケジュールし直すことも求められます。そのため、コンテナを特定のマシンに固定しないように推奨しています。”このコンテナはこのマシンに” としなければならないこともありますが、滅多にありません。次の問いは、何をスケジューリングするのか？ということです。簡単な答は、それぞれのコンテナです。でも、同一ホストで複数のコンテナを実行させたいこともありますよね。データサーバーとデータローダーであったり、ログの圧縮/保存プロセスをサーバーとペアにするようなときであるとか。そういったコンテナはいっしょに配置されるべきもので、ダイナミックに配置される中でも分断されないようにしたいわけです。このために、Kubernetes ではポッド (pod) というコンセプトを導入しました。ワーカーコンピューター（Kubernetes ノードとも呼びます）上で複数のコンテナをポッドという単位としてまとめ、いっしょに配置してスケジューリングします。そして、ポッドをグループ化して配置することで、Kubernetes はノード上に多くの処理を、信頼できる方法でまとめることができるのです。

要素 2：セットで考える 1 つの物理ノードで作業をしているなら、ツールでコンテナの一括操作はあまり行いませんが、コンテナクラスターを使い始めたら、ノード間で簡単にスケールアウトできないかと思うでしょう。そのためには、単体ではなくモノのセットという単位で動かす必要があります。そのときそのセットは同じように構成しておきたいです。そこで Kubernetes では、さらに 2 つのコンセプト、ラベルとレプリケーションコントローラーをポッドのセットの処理に使います。 Kubernetes のすべてのポッドには、1 組のキー/バリューペアが設定されています。それをラベルと呼びます。このラベルをクエリーに使い、ポッドのセットを選択します。Kubernetes にはポッドを構成する ”正しい” 方法というものはないので、目的にによってどうポッドを構成するのかは皆さん次第です。例えば、アプリケーションの階層や、地理的な場所、開発環境で構成するのもいいかもしれないですね。実際のところ、ラベルは階層化されたものではないので、同時に複数の方法でポッドを構成することもできます。例：たとえば、フロントエンドとバックエンドからなるシンプルなサービスがあるとします。そのサービスのテスト環境、ステージング環境、プロダクション環境とある中で、プロダクション環境のフロントエンドで使うポッドに env=prod tier=fe、バックエンドには env=prod tier=be というラベルを付け、テスト環境やステージング環境にも同様にラベルを付けるとしてます。そうすると、クラスタを運用したり調査するとき、フロントエンドとバックエンドの両方を見るには env=prod のポッドに絞ればよく、同じようにテスト、ステージング、プロダクションの全体にわたって、すべてのフロントエンドを調べることもできるわけです。さらに多くの階層や環境が増えていったとしても、どう適応したらいいのかは想像できますよね。

図 1 - ラベルを使ポッドをフィルタリングスケールさて、同じように構成されたマシンのプールを特定し維持管理していけるやり方を手にしたところで、今度は、この機能を水平スケール（つまり、スケールアウト）させるために使っていきます。Kubernetes には、それを簡単にするレプリケーションコントローラー（Replication Controller）と呼ぶヘルパーオブジェクトがあります。これは、希望するレプリケーション数、ポッドテンプレート、ラベルのセレクタ / クエリに応じてポッドのプールを維持管理します。これを理解するのはとても簡単です。次の擬似コードを見てください。object replication_controller { property num_replicas property template property label_selector runReplicationController(num_desired_pods, template, label_selector) { loop forever { num_pods = length(query(label_selector)) if num_pods > num_desired_pods { kill_pods(num_pods - num_desired_pods) } else if num_pods < num_desired_pods { create_pods(template, num_desired_pods - num_pods) } } } } たとえば、php のフロントエンド層を 3 つのポッドで動かそうとするなら、それに適したポッドテンプレート（php のコンテナイメージを指している）と、num_replicas を 3 に設定し、レプリケーションコントローラーを作成します。作成したレプリケーションコントローラーは、ラベル env=prod tier=fe を使ってクエリーを行い、どのポッドのセットを処理するのかを特定します。そしてレプリケーションコントローラーは、望まれている状態（num_desired_pods) であるかを見て、その状態になるように作業し続けます。また、スケールイン/アウトしたいなら、レプリケーションカウントを変更するだけでレプリケーションコントローラが残りをやってくれます。システムの望まれている状態、ここにフォーカスすることで、その判断が容易になるわけです。

図 2 – レプリケーションコントローラによる望ましい状態の維持要素 3：クラスター内への接続これまでに取り上げた要素で、たくさんの興味深いことができるようになります。高度な並列処理が可能なレベルに処理を分散できること（継続的インテグレーションシステム、ビデオエンコーディングであるとか) では、個々のポッド間での大量のコミュニケーションがなくても動作します。ですが、最近の優れたアプリケーションはむしろ、お互いにコミュニケーションする小さなサービス (マイクロサービス) のネットワークであることが多いのです。従来のアプリケーションアーキテクチャにおける階層は、実際にはグラフの中のノードです。クラスター管理システムには、これまでに出てきた要素と動作する名前解決システムが必要です。DNS がドメイン名を IP アドレスに名前解決するように、このネーミングサービスは、いくつかの追加要件も込で、サービス名からターゲットへの名前解決を行います。特に、何かが起動したり移動されたりすると、直後にそれが伝わって ”サービス名” は、ターゲットへと解決されます。そのときターゲットに関する追加のメタデータ（たとえば、シャードへのアサイン情報）が含まれることもあります。Kubernetes の API では、ラベルセレクタとウオッチ API パターンの組み合わせで行われ、とても軽量なサービスディスカバリーを提供しています。新しいネーミング API にはこういったアドバンテージがあるものの、それにあわせて書き直されるクライアントプログラムは、すぐには (あるいはずっと) 出てこないでしょう。大抵のプログラムは別の階層とコミュニケーションするために、通信先のアドレスとポートを求めます。このギャップを埋めるするために、Kubernetes ではサービスプロキシの考え方を導入しています。これはシンプルなネットワークロードバランサー/プロキシで、代わりに名前を問い合わせ、ネットワーク上の単一の IP アドレスとポート（DNSを使用して）として見えるようにします。今のところ、このプロキシはラベルセレクタで特定されるすべてのバックエンドに、単純にラウンドロビンで振り分けているだけですが、今後ドメインに応じて的確な決定ができる、カスタムプロキシ/アンバサダーとなることを見越して計画しています（Kubernetes のロードマップにコミュニティが詳細を定義しているので、引き続き注目していてください)。私が個人的にも期待している 1 つの例は、MySQL を使っているときに、write のトラフィックならマスターへ、read のトラフィックならスレーブへと、トラフィックに応じて判断してくれるアンバサダーです。 Voila!（できあがり）これでクラスタ管理システムの主要な 3 つの要素（コンテナのダイナミックな配置、コンテナをセットで考える、クラスター内への接続）がどう組み合わさるのかわかってきたのではないかと思います。冒頭で ”コンテナクラスタは何からできているのか？” と問いました。これまでに説明した内容から、今なら回答できると期待しています。とても単純に言ってしまうと、コンテナクラスタは、システムのあらゆる接続方法や通信方式にあわせて、コンテナの配置と管理をし、ポッドの中にコンテナをグループ化、そしてノード上で動作させるダイミックなシステムです。最初に Google でコンテナを運用してきた経験を形にしていく、という目標で Kubernetes をはじめたとき、最初はただスケジューリングと動的な配置にフォーカスしていました。しかし、リアルなアプリケーションを構築するために絶対に必要なこと、それを様々なシステムから考えて、考えぬいた結果、それが今までに見てきた、ポッド、ラベル、レプリケーションコントローラといった、追加の要素を必要なことが直ぐにわかりました。ですが、私の考えとして、これらも使用できるレベルのコンテナクラスターマネージャーを構築するために最低限必要なものに過ぎません。 Kubernetes はまだオーブンで焼かれているような状態ですが、うまくいっています。最近 v0.8 をリリースし、ここからダウンロード可能です。引き続き機能を追加したり、改良している中、v1.0 へのロードマップも発表しました。プロジェクトは、コントリビュートしてくれるパートナー（Red Hat、VMware、Microsoft、IBM、CoreOSなど）や、Kubernetes を使用している皆さんの参加で、直ぐに大きなコミュニティーとなり、さらに成長しています。私たちは、この分野で多くの経験があるものの、Google がすべての答を持っているわけではありません。Google の中にはない必要条件であったり、検討事項があります。それをふまえて、私たちが構築しているものを確かめて、そしてプロジェクトに参加してください！まずは試して、バグがあればレポート、わからないことは聞いて、あるいはプルリクエスト(PR) を送ってください。 -Posted by Joe Beda, Senior Staff Engineer and Kubernetes Cofounder

[GCP] クラウドの料金体系を理解する

2015年2月3日火曜日

Miles Ward によって投稿第 1 部　仮想コンピュータインフラストラクチャーを設計していくには、新規のアプリケーションを構築であっても、今あるソフトウェアを展開していくにも、コスト面は重要な要素です。コストといっても様々で、インフラストラクチャー提供するにあたり、どういうアプローチをしていても、そこには固有のトレードオフと複雑な側面があります。クラウドのインフラストラクチャーは、こういった複雑な方程式に、まったく新しい変数を作り出しました。加えて、クラウドには二つとして同じものはないのです！あるところでは、いくつかのコンポーネントを組み合わせて提供し、またあるところではより細かいレベルでの料金設定で提供しています。従量課金も様々で、様々な料金体系があり、それぞれコスト面で違った影響があります。そのとき、それぞれのコストを算出し、最適なものを選択するにはどうすればいいでしょう？まずは一例をみてみましょう。普通に一般的なシナリオとして、クラウドをバックエンドにしたモバイルアプリケーションを見ていきます。いろいろな方法で画像共有ができるアプリケーションで、月 500 万のアクティブユーザーがいるとします。このアプリケーションが、ユーザーがワークロードを満たすのに必要なインスタンスのタイプを調べ、Google Cloud Platform で月平均コストを算出し、それをAmazon Web Service と比較します。
このアプリケーションには4つのコンポーネントがあります。

モバイルデバイスが接続し、リクエストを送りアクションを行う API フロントエンド。この部分が処理サイクルの中で大きな部分を占めます。

静的なマーケティングやブログのためのフロントエンド。

画像をアップロードしたりアクセスするときに、処理や保存を行うアプリケーションレイヤー。

バックエンドには、オペレーションに必要なメタデータを保存する Cassandra クラスター。

必要量を見積もるために、以下のように想定しました。

API フロントエンドの 1 つのインスタンスで、だいたい毎秒 80 リクエストに対応。ユーザー数がこれくらいの状況では毎秒約 350 リクエストと予想されるので、このレイヤーでは常に必要なインスタンスは4つだけになります。

マーケティング用のフロントエンドは、冗長化のためにインスタンスを 2 つ用意しておけば、他に必要ないでしょう。

アプリケーションレイヤでは、画像処理とストレージ制御のために 4 インスタンス必要になります。

Cassandra クラスタではメモリーフットプリントの高いインスタンスが 5 つ必要です。ここでは、ワークロードは決まっていて、オートスケールされないと仮定します（大丈夫です、後で補足します）。

この例のアプリケーションの論理アーキテクチャを図 1 に示します。

図 1
クラウドの料金の違いを説明するために、クラウドインフラストラクチャーを提供している Google Cloud Platform と Amazon Web Services を例に、最もシンプルなオンデマンドモデルから見ていきます。それぞれのプロバイダが提供している見積用のツールを使えば、すぐに正確がわかります: ここでの料金計算は、2015 年 1 月 12 日に実施したもので、その結果を掲載したものです。このポストの公開後の料金変更や計算方法の変更により、結果が異なる可能性があります。また、リージョンとしてアメリカを想定しています。日本含む別のリージョンを指定したときには料金が異なることがあります。掲載している料金は US ドルです 料金計算の結果、以下のようになりました: Google Cloud Platform 見積もり: 月額: $2610.90
Amazon Web Services 見積もり: 月額: $4201.68 すぐに気がつくのは、料金の違いです。Google の料金のほうが 38% も安くなっています。どうしてでしょう？Google には継続利用でディスカウントする Sustained Usage Discount という継続利用割引があり、長い期間稼働させるインスタンスのコストを削減できるからです。オートスケールや、一ヶ月の間にシステムの変更が行われない想定なので、30% の割引が満額適用されています。その割引がないとしても、割引前の料金は $3729.86 で、Amazon のオンデマンド料金より 11% も安くなっています。1 年間を通してみれば、Google なら実に $19,000 の節約になります！リザーブドインスタンス Amazon Web Services には長期間（1 年または 3 年のどちらか）の契約が可能で、一部のコストの前払いを選択できる、リザーブドインスタンスという別の料金モデルがあります。Amazon のリザーブドインスタンスで算出すると、このようになります: Amazon Web Services、前払いなし、1 年分の見積料金: 月額: $2993.00 Amazon での 1 年契約では、その期間 ”前払いなし（no-upfront）” オプションで契約したとしても、Google に比べて 13% 割高になります。 Amazon Web Services、一部前払い、1 年分の見積料金: 前払い額: $18164.00 月額: $1093.54 実質月額: $2607.21 “一部前払い（partial upfront）” で $18k 以上を事前に支払うなら、料金は安くなり一年で $44（単位は千でなく）節約できます。 Amazon Web Services、全額前払い、1 年分の見積料金: 前払い額: $30,649.00 月額: $0.00 実質月額: $2554.08 全額前払いとするなら、$681 接続できて、Google Cloud Platform と比較しても 2.3% 安くなります。ですが、見てわかるように、前払いの額は $30,000 です！同じように、一部または全額前払で、Amazon には 3 年のオプションもあります: 一部前払い、3 年分の見積料金: 前払い額: $27,585.00 月額: $897.90 実質月額: $1664.15 全額前払い、3 年分の見積料金: 前払い額: $56,303.00 月額: $0.00 実質月額: $1563.97 3 年契約、全額前払いのリザーブドインスタンスに $56,000 以上も支払うなら、Google の料金よりも 40% 安くなり、予想差額の総額は $37k 以上になります。しかし、想像したかと思いますが、多額の前払い契約を結ぶことにはリスクを伴います。つまり、長期契約にしばられることで、節約できるかなりの額を逃すことにもなるのです。その理由は次のとおりです。

インフラストラクチャーの価格は低下します。Google（ムーアの法則をクラウドに最適用するかのように、過去 12 ケ月間に 3 度）でも Amazon（過去 12 ケ月間に 2 度）でも値下げが行われています。2014年、Google Cloud Platform において月平均にして 4.85% の値下げされました。オンデマンドの料金体系なので、GCP での値下げは自動的に行われます。

もう一つ、忘れないでください、資本は高額なのです！ほとんどの業種では毎年〜7% の資本コストがかかり、これらの前払い購入の価値を大きく下げてしまいます。この例では、Amazon の 3 年間全額前払い契約に対しては実質的に$11,823.63 の加算となります。

そこで、$37,689.40 の差額について再考してみましょう。資本コストを加算し、予想されるインスタンス料金低下を差し引くと、AWS が提供する最もアグレッシブな割引でも、AWS のコストは $60,244.21、Google Cloud Platform のコストは $57,959.57 となり、3.9% のコストアドバンテージがあります。パブリッククラウドの動静を控えめに予測しても（毎月 3% の値下げ、7% の資本コスト）、AWS の3 年間全前払いリザーブドインスタンスでさえ、Google Cloud Platform のオンデマンドな継続利用割引と比較してコスト効果は高くありません。
柔軟性特定の利用方法で契約することもコスト的なリスクがあります。

新しいインスタンスタイプの登場によって古いタイプは非効率になることがあります（たとえば、AWS の c3 インスタンスは、ある種のワークロードにとって古い m3 インスタンスよりも大幅にコスト効果が高くなっています）。

ソフトウェアは変化します。たとえば、ソフトウェアの効率を向上させてインフラストラクチャーへの要件を 50% 削減したとしたらどうでしょう？あるいは、プラットフォームを Windows から Linux へ移行したとしたら（リザーブドインスタンスでは OSタイプの指定が必要です）？あるいは、メモリを増やす必要が生じ、インスタンスを標準型から大容量メモリ型へ変更する必要があるとしたら？

ニーズは変化します。たとえば、新しい競合相手が現れて、顧客の半分を奪っていき、インフラへの負荷が 50% 低下したとしたらどうでしょう？。

全てがうまくいっていたとしても、地理的に、アプリケーションが突然アジアや欧州で人気を得たとしたら？

クラウドコンピューティングの「オンデマンド」による迅速性や柔軟性は巨額の経済的利点となりますが、特に要件が変化したときに顕著です。2 ケ月目に上記リスクのいくつかが実際に起きたとしましょう。アジアマーケットへ移行し、実際のワークロードに適合するようにいくつかのインスタンスをリサイズし、ライブマイグレーションでのインスタンスの信頼度に応じて Cassandra クラスタの冗長度を若干下げるとします。これは図 2 のようになります。

Google Compute Engine 見積料金: 月額: $909.72 Amazon Web Services、一部前払い、1 年間見積料金: 前払い額: $6350.00 月額: $331.42 実質月額: $860.59 このシステムのコストは元のシステムの半分以下になり、しかもまったく異なる大陸に移行しますが、プランの変更に関わるコストにはどのようなものがあるでしょうか？この変更のコストは Google ではごく僅かです。インフラ設計の変更に対して直接的なペナルティはありません。ダウンタイムゼロをなくすために、 2 つのシステムを同時に稼働させる時間によるコストのみです。
これとは対照的に Amazon システムでの変更は、割引を適用するためのなんらかの契約コスト、プラス、先述のデュアルシステム使用（毎時のコスト増）のうえに、新しい構成に見合った価格効率を得るために新しく必要となる前払い額（そして再契約！）の総額となります。
これをキャッシュフローの観点から見てみましょう。最悪のケースを想定するわけではありません。Googleに支払う金額をAmazonのそれに釣り合わせるため、1 年間の一部前払いリザーブドインスタンスを選択したと仮定してみるだけです。 Google: 第1月使用料 : 2610.90 USドル + 第 2-13 月使用料: 909.72 USドル x 12 = 13,527.54 USドル Amazon: 第1月契約料: 18,164.00 USドル + 第1月使用料: 1093.54 USドル + 第 2 月契約料: 6350.00 USドル + 第 2-12 月使用料: 331.42*12 = 29,584.58 USドル 資本コストを考慮しなくともこれは大きな差です！これらの契約がどれほどリスキーかがわかります。AWS にはこのリスクを幾分緩和する RI マーケットプレイスというサービスがあり、リザーブドインスタンス（RI）のユニットを他の AWS の顧客に売り戻す仕組みが用意されています。しかし、ご想像どおり、この手段は次のようないくつかのリスクを抱えています。

たとえば、売却しようとする RI のタイプが、現在多くのワークロードにとって明らかに非効率であるものを他の顧客が必要とするでしょうか？

RI は正規の価格で売却できるでしょうか、それともいくらか割引が必要でしょうか？

そのマーケットプレイスにはどれだけのバイヤーがいるでしょうか。たとえいるとしても RI はすぐに売却できるでしょうか？

米国でスタートしていなかったとしたら？ RI マーケットプレイスは米国銀行の口座を持つ顧客のみが利用可能です。

確実な損失というリスクがあります。RI マーケットプレイスでの 1 取引ごとに 12% の手数料がかかります（Amazon への支払い）。仮に、幸運にも元の 12 ケ月の RIのうちの 10ケ月分（月単位、端数切捨てで売却しなければならない）を元の価格そのままで売却でき、手数料を差し引いた後で 13,320.27 USドルが戻ったとしましょう。この場合、13ケ月分のトータルは 16,083.19 USドルとなり、Google の場合に比べて 2,555.65 USドルのみの損失となります。しかし、なんと面倒で、大きなリスクを負わなければならないでしょうか。数ケ月間 RI が売れなかったとしたら？ 1 月ごとに 1,332 USドルを失うことになります。これは痛い！オートスケールしかしこれは時代遅れの例だとおっしゃるでしょう。クラウドはこのような静的なサイジングを意図しているのではなく、負荷の増減に合わせて機敏にオートスケールすることを期待されていると思います。その通りです。そこで、上記に定常的な負荷要求を反映させ、さらに 1 日に小さなピークが 4 回あるとしましょう。朝のラッシュ、昼のピーク、仕事の後、深夜の狂騒で、それぞれが上記ワークロードの10倍跳ね上がるとします。（我々のアプリケーションは toothbrush test をパスしています！）。バックエンドはこれらのスパイクを十分に処理しますが、Web と API 層は大幅にオートスケールする必要があります。これらのピークのそれぞれが急激に、たとえば 5 分のうちにやってきて、それぞれが15 分続くとしましょう。断っておきますが、100 倍以上のスパイクを持つシステムがあるので、このシナリオは極端ではありません。このようなシステムを効率的に構築することは Google では容易です。インスタンスはおよそ 1 分で立ち上がるので、オートスケールして容易に負荷に対応することができます。また、10 分間以上からしか課金せず、分単位の増分でしか請求しないので、1 ケ月に 110.77 USドルしか加算されません。10倍のピークでです！ Google Compute Engine 見積料金: 月額追加料金: $110.77 これを AWS で構築するのはそれほど効率的ではありません。なぜなら、インスタンスの立ち上げには平均 5 分以上かかるため、インスタンスブート（読出し、ロジックのタイミングまたはマニュアルでのメンテナンス）を前もって実行しておかなければならないからです。また、AWS では 1 時間単位で課金されるので、4 回のピークそれぞれが20 分以下でも 60 分が課金されます。トータルの追加コストは 341.60 USドルとなり、リザーブドインスタンスで適切な割引がなければ、これは現在のAWS顧客が見逃せない数値です。 Amazon Web Services 見積料金: 月額追加料金: $341.60
+ インスタンス起動管理ロジックのマニュアル運用または開発このスパイクの例はよく見られる利用状況ですが、基本的な毎日の変動（1 日に 2 回、つまり昼/夜）もあり、ほとんどすべての顧客では 2 ～ 5倍の範囲で利用状況が変動します。そのような必然的な変動がAutoscaler や他の自動的なリソース管理で追従されなければ、お金を捨てるはめになります！まとめ考察すべき点はさらに数多くありますが、本記事が Google と Amazon の課金体系の違いを分析する助けになることを願っています。我々はここで立ち止まることはありません。さらに多くのクラウドプロバイダや多くのワークロードとで比較し、出費に見合うサービスを正確に理解する助けになることを期待しています。我々はクラウドサービスにおけるコストの削減に最大限注力しており、継続利用割引や分単位課金などの革新技術を先導しています。顧客の一人で、 StarMaker InteractiveのVP of Engineering である Christian F. Howes 氏は、「アプリエンジンの分単位のスケーリングと課金によって月あたり $3,000 もの節約になる」と述べています。インフラシステム設計について最良の決定をしようとしているユーザーにとって価格は非常に重要である、と我々は考えています。クラウド料金で何が重要か、などのご意見をお聞きかせください。どの部分が分かりにくいのか、分析が困難なのは何か、予測が困難なのは何か、など。どんなアイディアをお持ちですか？ご連絡ください！
-Posted by Miles Ward, Global Head of Solutions, Google Cloud Platform

[GCP] Local SSD がどなたでも利用できるようになりました。

2015年2月2日月曜日

* この投稿は、米国時間 1 月 21 日、Product Manager の Kirill Tropin によって投稿されたものの抄訳です。
Local SSD は、ベータ期間中にもすばらしいコストパフォーマンスを示してきました。そしてベータ期間が終了し、世界中の全てのリージョンで利用できるようになったことをお伝えします。
Local SSD では、 1 ～ 4 つの 375 GB の SSD のパーティションを VM にアタッチし、専用で使用できます。また、極めて優れた IOPS も確保されます（4K のランダムリード時: 680k IOPS）。用途としては、膨大な計算を行うアプリケーションで利用する一時スペースとしての用途、また、永続化ディスクと違い、Local SSD には冗長性が組み込まれていないので、独自のレプリケーションを持つ（最近のデータベースの多くや、Hadoop など）高い需要の見込まれる用途に理想的です。さらに Local SSD は高 IOPS で、かつ GB 当たりのコストも低く、メモリーの補完としても機能します。 Local SSD は月額 $0.218/GB で利用できます。 1 時間当たり $0.0003/GB、IOPS あたりのコストとして算出するなら、月額 $0.00048/リード IOPS 、このように、非常にローコストでの利用が可能です。 Local SSD のベータ版期間中、素晴らしい反応をいただきました。 Cloud Harmony ではテストした全てのVM とストレージの組み合わせの中で、Google Compute Engine の Local SSD が、最高値の 4K ランダム IOPS を実現したと発表しました。これを価格あたりにしたとしたら、さらに良い結果になるでしょう！さらに、利用している皆さんからも肯定的なフィードバックをもらいました。 Aerospike では RAM を利用しているかのようなパフォーマンスと、15 倍のコストアドバンテージを、ローカル SSD を NoSQL データベースの RAM を補完するものとして使用することで実現しています。Gyazo.com では, MongoDB の RAM を補完するものとして利用され、Local SSD の低コストと高パフォーマンスによって、完璧とも言える成果を出しています。 Gyazo の洛西一周氏は次のように述べています。「Google Compute Engine の Local SSD は本当に高速です。RAM の使用量を減らすことができ、コスト効率の改善に繋がりました。」ローカル SSD の詳細は、ベータがリリースされたときの発表や、またはドキュメントをご覧ください。VM に最高の IOPS を皆さんに。 - Posted by Kirill Tropin, Product Manager

Japan 公式ブログ