※この投稿は米国時間 2019 年 11 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。 高度なスケーラビリティと構成の柔軟性を提供するコンテナ オーケストレーション プラットフォームを求めているお客様にとって、マネージド Kubernetes サービスである Google Kubernetes Engine（GKE）は優れた選択肢になります。GKE は、ステートフル アプリケーションのサポートに加えて、ネットワーキング、ストレージ、オブザーバビリティ（可観測性）のセットアップなど、コンテナ オーケストレーションのあらゆる側面を完全に制御できます。 しかしながら、お使いのアプリケーションがそうしたレベルのクラスタ構成やモニタリングを必要としない場合は、フルマネージドの Cloud Run が最適なソリューションになるかもしれません。フルマネージド Clou

デジタル トランスフォーメーションを加速 お客様がデジタル トランスフォーメーションに乗り出したばかりでも、あるいはすでに進めている場合でも、Google Cloud は困難な課題の解決を支援します。

Google Cloud Storage は、ほとんどの（すべてではないとしても）開発ニーズに対応できる、Google Cloud Platform の強力な統合型オブジェクト ストレージです。ユーザーに近いエッジでのサービス提供や、CDN（コンテンツ配信ネットワーク）、自動冗長化といった機能をすぐに利用できますし、もちろん、このストレージを使うことによる自社の二酸化炭素排出量はゼロです！ それでも、個々の開発者ごとに Cloud Storage に関して固有のユース ケースや要件があります。Cloud Storage をそのまま使用しても得られるパフォーマンスは素晴らしいですが、この投稿では、特定のユース ケースへの最適化に役立つ高度なコツ、工夫、アドバイスを紹介します。 パフォーマンス基準の確立 まず念頭に置かなければならないのは、測定できないものは改善できないということです。したがっ

フィードバックを送信 gzip 圧縮ファイルのトランス コーディング コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 このページでは、gzip ファイルの圧縮時と解凍時の変換について説明します。このページには、Cloud Storage でのトランス コーディングの概要、関連するメタデータの操作に関するベスト プラクティス、圧縮ファイルの動作が記載されています。 トランス コーディングと gzip gzip は、データ圧縮の 1 つの形式で、主にファイルのサイズを縮小します。圧縮されていない場合よりも高速でファイルを転送でき、より小さいスペースでの保存が可能です。ファイルを圧縮するとコストと転送時間の両方を減らすことが可能です。Cloud Storage の「トランス コーディング」は、ファイルをリクエスト元に提供する前にファイルの圧縮を自動的に変更します

クラウドベースのビジネス向けストレージ サービス。すべて Google Cloud のインフラストラクチャで動作します。ファイル共有サービスをお探しの場合は、Google ドライブをご利用ください。写真ストレージをお探しの場合は、Google フォトをご利用ください。

フィードバックを送信 Compute Engine の継続利用割引 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 Google Cloud では、請求月の 25% 以上で使用され、他の割引が適用されていない Compute Engine リソースに対して継続利用割引（SUD）が適用されます。Compute Engine では、該当するリソースを請求月の 4 分の 1 以上で使用すると、そのリソースの継続使用に対して 1 時間ごとに継続利用割引が自動的に適用されます。割引率は使用量に応じて徐々に高くなります。1 か月間連続稼働している仮想マシン（VM）インスタンスでは、リソース料金に実質最大 30% の割引が適用されます。 継続利用割引は、以下のリソースに適用されます。 汎用のカスタム マシンタイプまたは事前定義されたマシンタイプの vCPU とメモリ コ

Stackdriver Logging は Google Cloud Platform（GCP）と広くインテグレーションされており、GCP サービスとその使用状況に関する豊富なログ情報を提供します。Stackdriver Logging のエクスポート機能を使用すると、ログをエクスポートし、その情報をニーズに合わせて利用できます。 ログをエクスポートする理由はたくさんあります。たとえば、コンプライアンス要件に準拠する目的で長期保存（月単位または年単位）用にログを保持することや、ログから抽出した指標に対してデータ分析を行うこと、他のシステムにログを取り込むことなどです。Stackdriver Logging は、Cloud Storage、BigQuery、Cloud Pub/Sub にログをエクスポートできます。 GCP で Logging のエクスポート機能をセットアップする方法は、お客

※この投稿は米国時間 2019 年 1 月 26 日に Google Cloud blog に投稿されたものの抄訳です。 このたび、『The Site Reliability Workbook』がウェブサイトで閲覧できるようになりました。Google で生まれ、他の企業にも広まりつつある Site Reliability Engineering（SRE）は、運用上の問題をソフトウェア的に解決するためのエンジニアリングであり、Google におけるエンジニアリングの本質的な部分を占めています。 SRE は考え方であり、一連のプラクティスやメトリクスであり、システムの信頼性を保証するための処方箋でもあります。SRE モデルを構築すれば、サービスの信頼性が向上し、運用コストが下がり、人間が行う作業の価値が高くなって、サービスとチームの双方で大きなメリットが得られます。上述の新しいワークブックは、

※この投稿は米国時間 2019 年 1 月 26 日に Google Cloud blog に投稿されたものの抄訳です。 このたび、『The Site Reliability Workbook』がウェブサイトで閲覧できるようになりました。Google で生まれ、他の企業にも広まりつつある Site Reliability Engineering（SRE）は、運用上の問題をソフトウェア的に解決するためのエンジニアリングであり、Google におけるエンジニアリングの本質的な部分を占めています。 SRE は考え方であり、一連のプラクティスやメトリクスであり、システムの信頼性を保証するための処方箋でもあります。SRE モデルを構築すれば、サービスの信頼性が向上し、運用コストが下がり、人間が行う作業の価値が高くなって、サービスとチームの双方で大きなメリットが得られます。上述の新しいワークブックは、

前回の『CRE が現場で学んだこと』シリーズでは、システムの可用性を担保するにあたってターゲットとする正確な数値をいかにして割り出すか、ということについてお話ししました。このターゲットをシステムのサービス レベル目標（SLO）と呼びます。 今後、システムが十分な信頼性を保って稼働しているか、またシステムにどんな設計やアーキテクチャの変更が必要かについて議論する際は、システムが継続的に SLO を満たしているという枠の中で語る必要があります。 SLO の適合性は直接測定することが可能です。システムにおいて精査が成功した頻度で計るのです。これをサービス レベル指標（SLI）といいます。システムが過去 1 週間 SLO を満たしつつ稼働していたかどうかを評価する場合に、SLI からサービスの可用率を把握するのです。定められた SLO を下回っているとなれば問題があるということですから、他の場所に

Google Cloud デベロッパーアドボケイト 佐藤一憲 3 月 20、21 日に NHK ホールで開催された Perfume のライブ ステージ「Reframe」。このステージは、NHK が東京オリンピック・パラリンピックに向けて文化面においても機運を高めていくイベント「This is NIPPON プレミアムシアター」の一環として開催したもので、NHK と Perfume がこれまで生み出してきたパフォーマンスの最新テクノロジーによる「再構築」をテーマに、インタラクション デザインを担当したライゾマティクスによるドローンや AR 技術をふんだんに投入した演出が話題となりました。 今回のイベントでのライゾマティクスによる新しい試みのひとつが、Google の機械学習技術を応用したステージ演出です。同社を率いる真鍋大度氏は次のように説明します。「Perfume のミュージックビデオや歌

Fully managed in-memory Redis and Memcached service that offers sub millisecond data access, scalability, and high availability for a wide range of applications. Redis is a trademark of Redis Ltd. Memorystore is based on open-source Redis versions 7.2 and earlier.*

アカウント管理、承認、パスワード管理をうまくこなすにはコツが必要です。多くの開発者にとってアカウント管理は、十分な注意が払われていない “ダーク コーナー” になっています。製品マネジャーやお客様の中には、期待を裏切られるようなアカウント管理の経験がある方も少なくないでしょう。 幸い、Google Cloud Platform（GCP）には、ユーザー アカウント（本稿では、お客様であれ社内ユーザーであれ、システムに対して自分の身元を証明したうえでアクセスする人々を指します）の作成、セキュアな処理、そして適切な認証に役立つツールが用意されています。 この投稿記事では、Google Kubernetes Engine にホストされているウェブ サイト、Apigee の API、Firebase を使うアプリケーションなど、認証されたユーザーを扱うサービスを開発している人々のために、アカウント認

日本国内で圧倒的なシェアを誇り、今や知らない人はいないというほど認知度を増した「メルカリ」。その勢いは国内だけに留まらず、2014 年 9 月には米国に、2017 年 3 月には英国でのサービスを開始しています（世界累計 1 億ダウンロード。2017 年 12 月 16 日時点）。海外展開に消極的と言われる国内サービス事業者ですが、同社に関してはその常識は通用しないようです。今回は、そんなメルカリの米国における最新の取り組みについて、今春 CTO に就任した名村 卓さんと、SRE 中島 大一さんにお話をお伺いしました。 ■ 写真左から 執行役員 CTO 名村 卓氏 SRE 中島 大一氏 ■ 利用している Google Cloud Platform サービス Google Kubernetes Engine、Cloud Dataflowなど ■ 株式会社メルカリ 2013 年 2 月 1 日

Fastly の導入事例 : 履歴統計 DB を MySQL から Cloud Bigtable にダウンタイムなしで移行 （この記事では、米 Fastly から許可をいただき、先日同社が公開したブログ記事 How we moved our Historical Stats from MySQL to Bigtable with zero downtime の日本語訳を掲載します） - By Toru Maesaka, Senior Software Engineer at Fastly 過去から学ぶことは意思決定に不可欠なステップの 1 つです。私たち Fastly は、お客様が過去のイベントに基づいて迅速かつ的確に決定を行えるよう支援するため、Historical Stats API を提供しています。この API を使用すれば、分や時間、日単位でキャッシュに関するあらゆる統計情報を取

* この投稿は米国時間 5 月 12 日に投稿されたもの（投稿はこちら）の抄訳です。 Posted by 佐藤一憲, Staff Developer Advocate, Google Cloud Cliff Young, Software Engineer, Google Brain David Patterson, Distinguished Engineer, Google Brain Google 検索、ストリートビュー、Google フォト、そしてGoogle 翻訳。これらのサービスに共通するのは、いずれもニューラルネットワーク（NN）の計算処理の高速化のために Google の第一世代の Tensor Processing Unit (TPU) が用いられている点です。 Google の Tensor Processing Unit (TPU) が搭載された回路基板（左）と、 G

マルチクラウド戦略は、異なるクラウド プロバイダーの長所を使い分けたり、きわめて重要なワークロードを分散させたりすることを可能にします。たとえば、既存のアプリケーションには Amazon Web Services（AWS）を使っているものの、その一方で Google の Cloud Vision や Cloud Video Intelligence、Data Loss Prevention といった強力な API を使いたいとか、Google のビッグデータと機械学習の機能によってデータを分析し知見を引き出したいときに役立ちます。 今回は、Google Cloud Platform（GCP）と AWS のワークロードを統合するパターンの 1 つ（他にもたくさんあります）として、Google Cloud Endpoints と AWS Lambdaを使用する方法を紹介します。アーキテクチャを

Google で何かおかしなことが起こったらどうなるか、考えたことはありますか？ この業界は面白い比喩を使うのが好きで、何か起こった際に対処することを「火消し」と呼んだりします。 上の写真に写っている実際の消防士の場合とは異なり、Google で起こった事故で生命の危険にさらされることは通常はありません。つまり完璧な比喩にはなっていないのですが、Google の Site Reliability Engineer（SRE : サイト信頼性エンジニア）の 1 次対応は、他の分野での 1 次対応と共通点が多いのです。 他分野での 1 次対応と同様、Google の SRE は定期的に緊急時対応の訓練を行い、迅速かつ効率的に目の前の問題が解決できるよう、スキルやツール、テクニック、態度に磨きをかけます。 緊急時のサービス対応チームおよび Google では、何かが起こったときのことを「インシデン