Google Cloud Platform Japan 公式ブログ: API

Apigee が 3 年連続でフルライフサイクル API 管理分野のリーダーに ―― 2018 年版 Gartner Magic Quadrant

2018年6月20日水曜日

こちらApigee のウェブサイト本図表は、Gartner リサーチの発行物の一部であり、発行物全体のコンテクストにおいてご覧いただく必要があります。この Gartner の発行物は、リクエストにより Apigee からご提供することが可能です。

Gartner は、Gartner リサーチの発行物に掲載された特定のベンダー、製品またはサービスを推奨するものではありません。また、最高のレーティングまたはその他の評価を得たベンダーのみを選択するようテクノロジーの利用者に助言するものではありません。Gartner リサーチの発行物は、Gartner リサーチの見解を表したものであり、事実を表現したものではありません。Gartner は、明示または黙示を問わず、本リサーチの商品性や特定目的への適合性を含め、一切の保証を行うものではありません。* この投稿は米国時間 5 月 2 日、Google Cloud の Director of Product Management である Ed Anuff によって投稿されたもの（投稿はこちら）の抄訳です。- By Ed Anuff, Director of Product Management, Google Cloud

API デザイン : URL には名前と識別子のどちらを使うべきか

2017年11月10日金曜日

https://ebank.com/accounts/a49a9762-3790-4b4f-adbf-4577a35b1df7https://library.com/shelves/american-literature/books/moby-dickGoogle Cloud Platform API Design Guide 識別子の長所論文階層構造の名前自然の分類法両方の長所を取り入れるにはGoogle Cloud Platform 識別子はルックアップ用、名前は検索用https://ebank.com/accounts/a49a9762-3790-4b4f-adbf-4577a35b1df7https://library.com/shelves/american-literature/books/moby-dickhttps://library.com/search?kind=book&name=moby-dick&shelf=(name=american-literature) 名前と識別子の併用https://ebank.com/accountshttps://ebank.com/accounts/a49a9762-3790-4b4f-adbf-4577a35b1df7https://library.com/locations{"kind": "Shelf", "name": "American-Literature", }https://library.com/shelf/20211fcf-0116-4217-9816-be11a4954344https://library.com/inventory{"kind": "Book", "name": "Moby-Dick", "location": "/shelf/20211fcf-0116-4217-9816-be11a4954344" }https://library.com/book/745ba01d-51a1-4615-9571-ee14d15bb4afhttps://library.com/shelf/american-literatature/book/moby-dickhttps://library.com/search?kind=book&name=moby-dick&shelf=(name=american-literature)https://library.com/book/745ba01d-51a1-4615-9571-ee14d15bb4af 2 種類の URL を持つ方法の欠点パーマリンクと検索 URL の “いいとこ取り”Web API Design : The Missing Link投稿記事* この投稿は米国時間 10 月 17 日、software developer および API designer である Martin Nally によって投稿されたもの（投稿はこちら）の抄訳です。- By Martin Nally, software developer and API designer

Grafeas 登場 : ソフトウェアサプライチェーンの監査、統制のためのオープンソース API

2017年10月25日水曜日

「私たち Shopify は、本番環境に送り込むすべてのコンテナを監視、統制する包括的な方法を探していました。私たちは毎営業日に 6,000 ものビルドを出荷し、33 万種以上のコンテナイメージを含むレジストリを保守しています。弊社の Kubernetes パイプラインに Grafeas と Kritis を導入すれば、弊社で作るすべてのコンテナイメージの脆弱性とビルドの情報を自動的に保存し、Shopify ビルドコンテナのポリシーを徹底させることができます。弊社の Kubernetes クラスタは、ビルダーが署名したイメージしか実行しません。Grafeas と Kritis は、デベロッパーをコード開発に専念させつつ、今まで以上のセキュリティ保護に本当に役に立ちます。より多くの企業が Grafeas と Kritis をプロジェクトに組み込むことを期待しています。」
— Jonathan Pulsifer 氏、Shopify のシニアセキュリティエンジニア（Shopify のブログもご覧ください）
大規模なガバナンスが抱える課題

拡大し、細分化されるツールセット : 組織の規模や業務内容が拡大していくと開発言語やツールの使用が増え、その開発ライフサイクルを把握してコントロールし続けることが難しくなります。

オープンソースソフトウェアの採用 : オープンソースソフトウェアはデベロッパーの生産性を高めますが、同時に監査や統制も複雑にします。

管理の分散化と継続的デリバリ : 技術部門に自律性を与え、ソフトウェアを継続的に出荷するようになると（“push on green”）、開発のスピードは上がりますが、ベストプラクティスや標準の遵守は難しくなります。

ハイブリッドクラウドへのデプロイ : オンプレミス、プライベートおよびパブリッククラウドのクラスタを併用してそれぞれの長所を手に入れようとする企業が増えていますが、そうした多様な環境の運用状況を 360 度の視点で把握することは容易ではありません。

マイクロサービスアーキテクチャ : 大規模なシステムをコンテナベースのマイクロサービスに分割すると、すべての部品を追跡することが難しくなります。

Grafeas のアプローチ

止むことのない高度な脅威に対する予防的なセキュリティ体制を確立するため、コンテナなどのイミュータブルなインフラストラクチャを使うこと

本番デプロイを保護するため、包括的なコンポーネントのメタデータとセキュリティアテステーションに基づいて、ソフトウェアサプライチェーンにセキュリティコントロールを組み込むこと

共通仕様とオープンソースソフトウェアを基軸としてシステムの柔軟性を保ち、開発ツールの相互運用性を確保すること

包括性 : Grafeas は、ソフトウェアコンポーネントのユニークな識別情報（たとえばコンテナのイメージダイジェスト）に対応させた形で構造化メタデータを格納するため、コンポーネントのレジストリを並置する必要がなく、コンポーネントに関するメタデータをさまざまなリポジトリから格納できます。

ハイブリッドクラウドとの相性の良さ : ハイブリッドクラウドデプロイの一元的かつ汎用のコンポーネントリポジトリとして JFrog Artifactory を使用できるのと同様に、Grafeas API は一元的で汎用的なメタデータストアとして使用できます。

プラガブル : Grafeas を使用すると、メタデータの新しいプロデューサ、コンシューマを簡単に追加できます（たとえば、脆弱性スキャナを追加または変更する場合や、新しいビルドシステムを追加する場合）。

構造化 : 一般的なメタデータタイプ（脆弱性、ビルド、アテステーション、パッケージインデックスメタデータなど）に対するメタデータスキーマが構造化されているので、新しいメタデータタイプとプロバイダを追加でき、Grafeas 対応ツールはすぐにそれらの新ソースに対応できます。

強力なアクセス制御 : Grafeas のもとでは、メタデータの複数のプロデューサやコンシューマのアクセスを慎重に制御できます。

豊かなクエリ能力 : Grafeas を使用すると、すべてのコンポーネントのあらゆるメタデータを簡単に照会できるため、各コンポーネントのモノリシックなレポートを読み取る必要はありません。

細分化されたメタデータの統合と一元管理

JFrog は、JFrog Xray API に Grafeas を組み込もうとしており、一方の環境（たとえば Xray のオンプレミス環境）のメタデータをもう一方の環境（たとえば Google Cloud Platform）で使えるようなハイブリッドクラウドワークフローをサポートします。詳細は JFrog のブログをご覧ください。

Red Hat は、OpenShift における Red Hat Enterprise Linux コンテナのセキュリティ機能と自動化を Grafeas で拡張することを予定しています。詳細は Red Hat のブログをご覧ください。

IBM は、IBM Cloud の IBM Container Service の一部として Grafeas と Kritis を提供することと、Google の Vulnerability Advisor と DevOps ツールを Grafeas API に統合することを計画しています。詳細は IBM のブログをご覧ください。

Black Duck は、Google Container Registry と Google Container Engine にエンタープライズレベルの改良されたオープンソースセキュリティを導入するため、Grafeas の Google アーティファクトメタデータ API 実装を組み込む作業を Google と共同で進めています。詳細は Black Duck のブログをご覧ください。

Twistlock は、Grafeas と統合され、詳細な脆弱性およびコンプライアンスデータをオーケストレーションツールに直接パブリッシュし、コンテナ操作に関する洞察と信頼性を顧客に提供します。詳細は Twistlock のブログをご覧ください。

Aqua Security は、Grafeas と統合され、脆弱性や違反情報をパブリッシュし、コンポーネントメタデータ情報に基づいてランタイムセキュリティポリシーを徹底させます。詳細は Aqua Security のブログをご覧ください。

CoreOS は、企業向け Kubernetes プラットフォームである Tectonic のイメージセキュリティスキャニングとアプリケーションライフサイクルガバナンスを拡張するため、Grafeas と Tectonic の統合を検討しています。

JFrog による Grafeas API の Xray 実装

Grafeas の Google アーティファクトメタデータ API 実装と、Google Container Registry の脆弱性スキャニング

JFrog Xray と Googleアーティファクトメタデータ API の双方向メタデータ同期

Black Duck の Grafeas および Google アーティファクトメタデータ API の組み込み

さあ、あなたもこの世界へ

JFrog-Google ウェビナーへの登録

Grafeas の試用と GitHub プロジェクト : https://github.com/grafeas への参加

10 月 17 日に開催された Google Cloud Summit in Toronto での Shopify の講演、12 月に開催予定の KubeCon in December のチェック

今後のリリースや統合に関する講演などの予定を受け取れるこちらのフォームの送信

Grafeas ディスカッショングループ : grafeas-users@googlegroups.comへのサインアップ

grafeas.io のドキュメントとサンプルの参照

* この投稿は米国時間 10 月 12 日、Developer Platforms の Product Manager である Stephen Elliott と、Container Security の Product Manager である Jianing Guo によって投稿されたもの（投稿はこちら）の抄訳です。- By Stephen Elliott, Product Manager, Developer Platforms and Jianing Guo, Product Manager, Container Security

Cloud Machine Learning API を使った会話アプリの作成 - Part 3

2017年9月11日月曜日

Part 1Part 2 Actions on Google 用の新しいインテントPart 1

where

hours-no-contextticket-no-contextmap-no-context

Actions on Google の統合を有効にする

API.AI コンソールを開き、Integrations（統合）タブで Actions on Google の統合をオンにします。

Additional triggering intents（追加するトリガーインテント）の下のポップアップダイアログで、Google Assistant でサポートしたいすべてのインテントを追加します。なお、Welcome Intent はシステムによって自動的に Default Welcome Intent に設定されます。後で Actions on Google で SETTINGS（設定）をクリックすると、この設定ダイアログを表示できます。

inquiry.where インテントは画像のアップロードを要求しますので、Google Assistant ではサポートされないことに注意してください。そのため、このインテントをトリガーインテントリストに追加してはなりません。また、サポートする新しいインテントを追加作成する方法については、上述の『Actions on Google 用の新しいインテント』で説明しています。

Actions on Google でサポートしたいすべてのインテント（hours-no-context インテントなど）を Additional triggering intents のリストに追加したら、最下部の UPDATE（更新）および TEST（テスト）ボタンをクリックします。すると、緑色のボックスが生成されるので、VIEW（表示）ボタンをクリックし、Actions on Google Web Simulator に移動します。

Actions on Google コンソールに初めてアクセスする場合はプロンプトが表示され、Activity controls センターにおいて Device Information（端末情報）と Voice & Audio Activity（音声アクティビティ）をオンにするよう促されます。

デフォルトでは、これらの設定はオフになっています。これらをすでにオンにしている場合は、このプロンプトは表示されません。

この 2 つの設定をオンにすると、Actions on Google Web Simulator に移動します。いよいよシミュレータで統合のテストに入ります。

まず、“Talk to my test app”（テストアプリと会話）とタイプするか、話しかけます。すると、シミュレータは Default Welcome Intent に基づいてこの文に応答します。続いて、API.AI テストコンソールにアクセスしているかのように、アプリをテストできます。

tell() API と ask() API の違いtell()ask() 次のステップ

Cloud Speech API Quickstart

Cloud Vision API Quickstart

Cloud Translation API Quickstart

API.AI Quickstart

ソースコード* この投稿は米国時間 8 月 28 日、Software Engineer である Chang Luo と Bob Liu によって投稿されたもの（投稿はこちら）の抄訳です。- By Chang Luo and Bob Liu, Software Engineers

Google における API のバージョニング

2017年7月6日木曜日

セマンティックバージョニングcoolcloudapi.googleapis.com/v1/coolthings/12301221312132coolcloudapi.googleapis.com/v1/coolthings/12301221312132Cloud Endpoints10-minute-quickstartin-depth tutorials* この投稿は米国時間 6 月 26 日、Product Manager である Dan Ciruli によって投稿されたもの（投稿はこちら）の抄訳です。- By Dan Ciruli, Product Manager

API 管理サービスの Apigee を買収

2016年9月21日水曜日

予測* この投稿は米国時間 9 月 8 日、Senior Vice President である Diane Greene によって投稿されたもの（投稿はこちら）の抄訳です。
- Posted by Diane Greene, Senior Vice President

This blog post includes forward-looking statements within the meaning of Section 27A of the Securities Act of 1933 and Section 21E of the Securities Exchange Act of 1934. These forward-looking statements generally can be identified by phrases such as Google or management “believes,” “expects,” “anticipates,” “foresees,” “forecasts,” “estimates” or other words or phrases of similar import. Similarly, statements herein that describe the proposed transaction, including its financial impact, and other statements of management’s beliefs, intentions or goals also are forward-looking statements. It is uncertain whether any of the events anticipated by the forward-looking statements will transpire or occur, or if any of them do, what impact they will have on the results of operations and financial condition of the combined companies or the price of Alphabet or Apigee stock. These forward-looking statements involve certain risks and uncertainties that could cause actual results to differ materially from those indicated in such forward-looking statements, including but not limited to the ability of the parties to consummate the proposed transaction and the satisfaction of the conditions precedent to consummation of the proposed transaction, including the ability to secure regulatory approvals at all or in a timely manner; the ability of Google to successfully integrate Apigee’s operations, product lines and technology; the ability of Google to implement its plans, forecasts and other expectations with respect to Apigee’s business after the completion of the transaction and realize additional opportunities for growth and innovation; and the other risks and important factors contained and identified in Alphabet’s filings with the Securities and Exchange Commission (the "SEC"), any of which could cause actual results to differ materially from the forward-looking statements. The forward-looking statements included in this blog post are made only as of the date hereof. Google and Alphabet undertake no obligation to update the forward-looking statements to reflect subsequent events or circumstances.

GCP でスケーラブルなウェブプロトタイプを構築する

2016年9月14日水曜日

* この投稿は米国時間 8 月 31 日、Google Web Engineer である Jason Mayes によって投稿されたもの（投稿はこちら）の抄訳です。
Google のウェブエンジニアとして、私は過去 5 年間、社内チームやお客様向けのスケールドシステムを開発してきました。システムの中には、ウェブのフロントやバックエンドのコンポーネントが含まれていることもよくあります。
この投稿では、Google Cloud Platform（GCP）を使って開発したカスタムメイドの機械学習システムの話をしたいと思います。このブログを読んで、自分でも何かクールなウェブアプリを構築したいと思ってもらえれば幸いです。
この話は、私がコンピュータのビジョンに関心を持ったところから始まります。私は長年、この分野に興味を持っていました。読者の皆さんの中には、望みどおりの結果を得るために最もシンプルなソリューションを探そうと努力していた私の個人的な実験に関する公開ポストを目にした方がいらっしゃるかもしれません。
私はシンプルであることが大好きなのですが、自分の手がけるプロジェクトが年を追うごとに複雑になるにつれ、特にその気持ちが大きくなりました。仲のいい友人が昔、私に「シンプルであることは複雑な芸術だ」と言ったのですが、この業界に 10 年在籍して本当にそのとおりだと感じています。

コンピュータビジョンに関する私の初期の実験において、動きを分離させようとしているところ

私のウェブエンジニア兼コンピュータサイエンティストとしての経歴は、2004 年に当時人気だった LAMP などを手がけたことから始まりました。その後 2011 年に Google に入社し、Google Cloud スタックに出会いました。つまり Google App Engine のことです。私は、スケーリングとディストリビューションを扱うシステムによって時間が大きく節約できることを知り、以来 App Engine に夢中になっています。
しかし、2011 年から時は流れ、最近私は TensorFlow を使ってウェブベースの機械学習システムを開発するプロジェクトに関わりました。ここで、私が開発に使った Google Cloud の新技術を一部紹介しましょう。

課題 : 長期間稼働しているタスクと短時間でクリティカルなタスクの両方に対し、ジョブの実行を保証するには？

TensorFlow を使って Google Compute Engine によるカスタムオブジェクトを認識しているところ

今年の初め頃、私は Google が開発したマシンインテリジェンス向けのオープンソースソフトウェアである TensorFlow の使い方を学んでいました（試す価値のあるものですよ）。
Google Compute Engine 上で TensorFlow を動かす方法がわかると、私は TensorFlow が単体ではスケールできないものであることにすぐに気づきました。負荷分散するために、いくつかのコンポーネントをそれぞれのサーバーに分割しなくてはならなかったのです。

初期デザインと課題

私のアプリケーションでディープニューラルネットワークの一部を再トレーニングするには、平均 30 分程度かかっていました。長時間かかるジョブがある可能性を考えると、ユーザーに進捗状況を知らせるために、リアルタイムのステータスアップデートを提供したいと思いました。
また、すでにトレーニングが済んだクラシファイヤーを使って画像分析をする必要もありました。これにかかる時間は、1 つのジョブにつき 100 ミリ秒以下です。こうした短時間のジョブが、30 分かかるような長時間のジョブにさえぎられるようなことがあってはなりません。
最初の実装は次のようになりました。

この段階で、次のような問題が発生しました。

Google Compute Engine サーバー上でさまざまなタイプのジョブを処理したため、非常に大きな負荷がかかってしまった。

Compute Engine のオートスケーリングプールを需要に合わせて 10 インスタンスまで作ることができたものの、時間のかかるトレーニングタスクが 10 個リクエストされると、分類やファイルのアップロードといったタスクのためのインスタンスが残らない。

プロジェクトの予算が限られていたため、一度に起動できるインスタンスは 10 個までだった。

データベースの選択肢このアプリケーションでは、さまざまな種類のワークロードをサポートする必要があったことに加え、永続的データが保管できなくてはなりませんでした。それができるデータベースは数多く、当然のことながら Google Cloud SQL もその 1 つです。ただ、この方法にはいくつか問題がありました。

時間がかかる : Cloud SQL を使うには、SQL データベースと統合できるようにすべての DB コードを自分で書き直さなくてはなりません。また、稼働するプロトタイプをできるだけ早く提供する必要がありました。

セキュリティ : Cloud SQL の統合には、Google Compute Engine のインスタンスがコアデータベースに直接アクセスする必要がありましたが、私はコアデータベースを見せたくありませんでした。

さまざまな種類のジョブ : 今は 2016 年ですから、きっとこんな問題を解決する何かがあるはずで、さまざまなジョブの種類に対応できるはずですよね？

その解決策として私は、モバイルアプリケーションやウェブアプリケーションの開発に向けた Google の Backend as a Service（BaaS）である Firebase を使うことにしました。
Firebase によって既存の API を使うことができ、（私の Node.js ベースのサーバーに最適な）JSON オブジェクトを使って永続的データを保管できるようになりました。これにより、クライアントが DB の変更をリッスンできるようになり（ジョブの進捗状況を伝えるのに最適です）、私の Cloud SQL のコアデータベースと密接に統合する必要もなくなりました。

私が利用した GCP サービス

最終的に私はサーバーを 3 つのプールに分けました。それぞれのプールは特定のタスクに対して高度に特化させており、1 つは分類用、1 つはトレーニング用、そしてもう 1 つはファイルのアップロード用としました。各タスクで利用したクラウド技術は以下のとおりです。
Firebase James Tamplin および彼のチームと話して以来、私はずっと Firebase をプロジェクトに使う機会をうかがっていました。
Firebase の主な機能の 1 つに、リアルタイムデータベースを数分で作れるというものがあります。そう、リアルタイムです。しかも、JavaScript を使うだけで、更新のすべてをリッスンできるのです。Firebase を使えば、動くチャットアプリケーションが 5 分以内に作れます。
これは、リアルタイムでジョブの進捗状況を確認するのに最適です。というのも、私はフロントエンドに問題のあるジョブへの変更をリッスンさせ、GUI をリフレッシュできるためです。
また、すべてのウェブソケットや DB fun も処理されるので、私はすごく使いやすい API を使って JSON オブジェクトを渡すだけでいいのです。Firebase はオフラインにも対応しており、オンライン状態になった時点で同期されます。
Cloud Pub/Sub 同僚の Robert Kubis と Mete Atamel が、Google のマネージドリアルタイムメッセージングサービスである Google Cloud Pub/Sub を私に紹介してくれました。
Cloud Pub/Sub は、セントラルトピックにメッセージを送ることを可能にするもので、そこから Compute Engine インスタンスがサブスクリプションを作ることもできるし、セントラルトピックに対して非同期的に緩くつながった状態でプルやプッシュすることもできます。これにより、容量に空きが出ると、すべてのジョブが最終的に稼働することが保証されます。
また、これはすべて水面下で行われるため、自分でジョブをリトライする必要もありません。時間が大幅に節約できます。

Cloud Pub/Sub のパブリッシャとなるエンドポイントの数に制限はなく、どこからでもサブスクリプションが可能

App Engine 私は App Engine でフロントエンドウェブアプリケーションをホストし、配信しました。HTML や CSS、JavaScript、テーマなどの資産はすべてここに保管されており、必要に応じて自動的にスケールされます。
さらにいい点は、App Engine がマネージドプラットフォームであることです。セキュリティ機能が搭載されているほか、App Engine の API に対して自分の好みの言語（Java、Python、PHP など）でコーディングした際に自動でスケーリングする機能も搭載されています。
API は Memcache や Cloud SQL などの高度な機能にもアクセスできるようになっており、負荷が増してもスケールする方法で頭を悩ませる必要はありません。
オートスケーリング機能の付いた Compute Engine Compute Engine は、きっとほとんどのウェブ開発者になじみのあるものでしょう。これは、自分の選択した OS をインストールできるサーバーで、そのインスタンスに対して完全にルートアクセスすることが可能です。
インスタンスは完全にカスタマイズでき（仮想 CPU の数や、RAM、ストレージの容量も設定できます）、課金は分単位のため、要求に応じてスケールアップやスケールダウンする際にさらなるコスト削減が可能です。
もちろん、ルートアクセスができるということは、これらのマシンでやりたいと思っていたことがほぼ何でもできるということなので、私も TensorFlow を稼働させる環境としてこれを選びました。
また Compute Engine は、オートスケーリングのメリットも享受できます。要求に応じて、また設定した数値に応じて、利用できる Compute Engine インスタンスの数を増やしたり減らしたりすることが可能です。私のユースケースでは、CPU の平均利用率に応じてオートスケーラはいつも 2 から 10 のインスタンスとなっていました。
Cloud Storage Google Cloud Storage は、（サイズ的にも数的にも）大量のファイルを安価に保管できるサービスです。世界中のエッジサーバーロケーションにレプリケーションされており、その場所は要求しているユーザーに近いロケーションとなっています。
私が自分の機械学習システムでクラシファイヤーをトレーニングするために使ったファイルをアップロードし、必要になるまで保管していたのもここです。
Network Load Balancer 私の JavaScript アプリケーションはウェブカメラを利用していたので、安全な HTTPS 接続にてアクセスする必要がありました。Google の Network Load Balancer は、自分で定義した異なる Compute Engine クラスタにトラフィックを送ることができるものです。
私の場合、画像分類クラスタと、新しいクラシファイヤーをトレーニングするためのクラスタがあったので、何がリクエストされたかによって、そのリクエストを適切なバックエンドに HTTPS 経由ですべて安全に送ることができました。

すべてを組み合わせた結果

これらのコンポーネントをすべて組み合わせてみると、私のシステムアーキテクチャは、だいたい次のようなものになりました。

これでちゃんと動いてはいましたが、一部無駄な部分もありました。Google Compute Engine Upload Pool のコードは、単に App Engine 上で稼働するように Java で書き直せることに気づいたのです。こうすることで直接 Cloud Storage にプッシュできるため、Compute Engine インスタンスの余分なプールが必要なくなります。やった！
また、App Engine を使うことになったため、カスタムメイドの SSL ロードバランサも必要なくなりました。App Engine 単体で新しいジョブを Pub/Sub へと簡単に内部でプッシュでき、すべてのフロントエンドのアセットをそのまま appspot.com 経由で HTTPS にて送ることができるためです。
つまり、Google の appspot.com 上でデプロイした場合、最終的なアーキテクチャは次のようになるでしょう。

アーキテクチャの複雑さが軽減されるとメンテナンスも楽になり、コスト削減にもつながります。

まとめ

Pub/Sub と Firebase を使うことで、私は 1 週間以上の開発時間を削減できたと見ています。これで私は目の前の問題にすぐに取りかかり、短時間で解決できるようになりました。さらには、プロトタイプが要求に応じてスケールしていき、予算に余裕がまったくないときでもすべてのジョブを最終的に片付けられることを保証できるようになったのです。
Google Cloud Platform サービス群の組み合わせは、ウェブ開発者が完全なエンドツーエンドシステムのプロトタイプを短時間で作るうえで素晴らしいツールキットであり、セキュリティと今後のスケーラビリティに対する支援も同時に得られるものです。ぜひ皆さんも試してみることをお勧めします。
- Posted by Jason Mayes, Google Web Engineer

API 管理スイートの Cloud Endpoints がベータリリース

2016年9月14日水曜日

* この投稿は米国時間 9 月 1 日、Google Cloud Platform の Product Manager である Dan Ciruli によって投稿されたもの（投稿はこちら）の抄訳です。
私たち Google は先ごろ、Google Cloud Endpoints の最新機能セットとオープンソースコンポーネントをベータリリースしました。Cloud Endpoints は、Google Cloud Platform（GCP）で実行される、任意の言語で書かれた API のデプロイ、保護、モニタリング、管理を行う分散 API 管理スイートです。
また、レイテンシを低減し、カスタムドメインをサポートしてデバッグの機能を強化した Java と Python 用の Cloud Endpoints Frameworks の新バージョンもリリースしました。
私たちにとって、Google のウェブ API の規模に対応しつつ、マイクロサービスのサージも処理できるパフォーマンスを備えた API プラットフォームを構築することは、大きな課題でした。
この難題を解決するため、私たちは伝統的な API 管理機能を自分で処理するサーバーサイドプロキシを開発しました。この方法ならネットワークホップを避けられます。社内テストではレイテンシがミリ秒未満になりましたが、これは従来のスタンドアロンプロキシの数十、数百ミリ秒とは大きな違いです。
そしてこのたび、このアーキテクチャを広く皆さんに公開することになりました。Extensible Service Proxy（ESP）は、サーバーローカルアーキテクチャで実行されるように設計された NGINXf ベースのプロキシです。コンテナ化された環境あるいは単独でデプロイされるように設計され、Google Service Control との統合により、極端に低いレイテンシでのモニタリング、権限チェック、API キーチェックなど、Google が自社 API 管理で使っている多くの機能を提供します。
加えて、私たちは OpenAPI Specification のサポートも発表しました。Google は Open API Initiative（OAI）の設立時からのメンバーで、REST API の記述方法を標準化することの意味を理解しています。
Open API Specification を採用する企業は、それぞれが選んだ言語とフレームワークを使ってアプリケーションを開発しつつ、OAI のツールセットから得られるメリットを享受できます。

Google Cloud Endpoints の機能

Cloud Endpoints のベータリリースには、モバイルアプリ、ウェブアプリ、他サービスのいずれからアクセスされるかにかかわらず、独自 API の管理に必要とされる広範な機能が含まれています。
Cloud Endpoint では、利用度、エラー、消費のグラフとともに基幹 API の状態をモニタリングできます。また、API 呼び出しのログを Google Cloud Logging に、トレース情報を Google Cloud Trace に送り、Google Big Query との統合を通じて強力なアナリティクスを実現します。
さらに、組み込みの Google 認証と、Auth0、Firebase Authentication との統合を通じてエンドユーザー認証をサポートし、API キーを作成、チェックしてクライアントごとの利用を追跡します。

Cloud Endpoints は、バックエンドとして使いたい言語とフレームワークをデベロッパーが簡単に選べるように設計されています。OpenAPI Specification（以前は Swagger と呼ばれていたもの）に基づき、Google App Engine standard / flexible environment、Google Compute Engine、Google Container Engine で実行されるバックエンドをサポートします。
たとえば App Engine standard / flexible environment では、1 行の構成変更で透過的にプロキシ機能を追加することも、Kubernetes や Container Engine 上のコンテナ化バージョンのプロキシをデプロイすることも可能です。
GCP ユーザーはすでに Cloud Endpoints で開発を大幅に強化しています。Vendasta のテクニカルリーダー、Braden Bassingthwaite 氏は、「Cloud Endpoints のおかげで、私たちは今までになくスピーディかつ着実に API を構築、リリースできています。認証やパフォーマンス、状態のモニタリングを気にせずに済むようになり、優れた API を構築するために必要な時間と労力を削減できました」と述べています。

Java、Python 用の Endpoints Frameworks

上述したように、私たちは新しい API 管理機能とともに、App Engine standard environment で実行される Java、Python のための Google Cloud Endpoints API Frameworks の新バージョンも発表しました。
新バージョンのフレームワークは、レイテンシを低減し、デベロッパーエクスペリエンスを向上させ、カスタムドメインをサポートしました。また、新しい API 管理機能をオプトインできるようになっています。
Endpoints Frameworks の詳細は、Java と Python 用のドキュメントを参照してください。

ぜひお試しを！

ベータテストの最初の一部期間は Cloud Endpoints の API 管理機能が無償で提供されます。最終的な価格体系についてはベータ期間中に発表される予定です。
API は、GCP が重点を起き、力を注いできた分野です。Endpoints チームは今後、サポートするユースケースを増やし、Identity and Access Management（IAM）との統合、レートリミットとクォータ、デベロッパーポータルなどの機能を追加した新リリースを提供する予定です。どうぞご期待ください。
Cloud Endpoints の詳細はドキュメントをご覧ください。また、App Engine standard / flexible environment、Container Engine、Compute Engine のそれぞれについてクイックスタートガイドが用意されていますので、試してみてください。そして、Google Cloud Endpoints Google Group に参加し、フィードバックを送っていただければ幸いです。
- Posted by Dan Ciruli, Product Manager, Google Cloud Platform

Google Cloud Platform Japan Blog

Apigee が 3 年連続でフルライフサイクル API 管理分野のリーダーに ―― 2018 年版 Gartner Magic Quadrant

API デザイン : URL には名前と識別子のどちらを使うべきか

Grafeas 登場 : ソフトウェアサプライチェーンの監査、統制のためのオープンソース API

Cloud Machine Learning API を使った会話アプリの作成 - Part 3

Google における API のバージョニング

API 管理サービスの Apigee を買収

GCP でスケーラブルなウェブプロトタイプを構築する

API 管理スイートの Cloud Endpoints がベータリリース

12 か月間のトライアル

Labels

Archive

Feed

Company-wide

製品・サービス

デベロッパー