この記事は Google Cloud Japan Customer Engineer Advent Calendar 2020 の 20 日目の記事です。 皆さん、こんにちは。Google Cloud の内間(@kuchima)です。本日も前日の Kozzy さん(Kozzy Hasebe)に引き続きみんな大好きサービスメッシュネタです。 この記事では、Google Cloud が提供している Traffic Director というサービスを利用したプロキシレス サービスメッシュ（以降、プロキシレス gRPC と記載します) の概要について説明していきたいと思います。 サービスメッシュとは？という話についてはこちらの記事では触れないので、Kozzy さんの記事「Anthos Service Mesh を導入、移行、そして使いこなしてみよう」をご参照ください。 Traffic Direct

※この投稿は米国時間 2020 年 12 月 18 日に、Google Cloud blog に投稿されたものの抄訳です。 Cloud Run に対する Google のビジョンはシンプルです。デベロッパーのソースコードを、HTTPS で保護されたドメイン名を使用したフルマネージドの自動スケーリング インフラストラクチャ上で実行できるようにすることです。しかし、従来は、Cloud Run へのデプロイには少なくとも次のような 2 段階のステップが必要でした。 コードをコンテナ イメージへとパッケージ化する このコンテナ イメージを Cloud Run にデプロイする コンテナ イメージはソフトウェアのパッケージ化、デプロイ、スケーリングの業界基準となったものの、すべてのデベロッパーがコンテナの仕組みや、（それぞれの好みの言語で書かれた）アプリをコンテナ イメージへとビルドする方法を知りたい

はじめに以前 Yuki Furuyama さんが「NEG とはなにか」という哲学的な(?)記事を書かれていましたが、このたび「Serverless NEG」(Serverless Network Endpoint Group)という新しいタイプの NEG が追加されました。(まずは Beta でのご提供です → EDIT(2020–10–14): 2020年10月14日に GA になりました。) これで NEG は Zonal NEG、Internet NEG、Serverless NEG の三種類になりました。 Furuyama さんの Zonal NEG に関する記事には「NEG は Kubernetes の Service に相当するもの、Network Endpoint は Pod に相当するものです」とありましたが、Serverless NEG では「Network Endpoi

Cloud Run CPU 0.08 ~ 8 Core (2nd gen は最小 0.5~) Memory 128 MiB ~ 32 GiB (2nd gen は最小 512MiB~) Deploy App Engine は Deploy (gcloud app deploy) を実行すると Cloud Build が暗黙的に動いて Deploy が行われるが、これがなかなか時間がかかる。 開発環境だと CI でとりあえず main branch に merge されたら、Deploy したりするけど、Deploy を Skip してもよいような時でも CI 回してると Deploy を待つことになって、ちょっとめんどうに感じる。 更にこの仕組みは成果物は Deploy しないと生まれないので、CI と CDを分離しづらい。 Cloud Run は Container Registry a

新しい Google Cloud ホワイトペーパー: Cloud Key Management Service の有効な活用方法 ※この投稿は米国時間 2020 年 9 月 15 日に、Google Cloud blog に投稿されたものの抄訳です。 「暗号化は簡単だが、鍵の管理は難しい」という法則は今も変わっていません。多くの大規模な組織にとって、暗号鍵の管理は依然として難しい課題です。多くのプライベートなワークロードには暗号化が不可欠であり、それらをクラウドに移行することも考えれば、この課題はさらに深刻なものになります。 しかし一方で、クラウドによって暗号鍵の管理がより効率的で、安全で、規制に準拠したものとなり、管理が簡単になる可能性もあります。クラウドベースでの鍵の管理を正しく行えば、クラウド コンピューティングをさらに信頼性の高いものにできます。 ただし、このような目標を達成するに

GoogleがBigQueryを安価に提供できる理由は、Borgによる大規模分散コンテナ環境があるから いまから6年前の2014年、当時ようやくDockerコンテナが世の中に知られるようになってきた頃、Googleはすでに社内のすべてのソフトウェアをコンテナ化しており、毎週20億個ものコンテナをクラウド上で起動していると発表し、多くのエンジニアを驚かせました。 この大規模なコンテナの制御、すなわちオーケストレーションを行っていたのが同社内で「Borg」と呼ばれるソフトウェアです。 そしてKubernetesはこのBorgを基に、Googleがオープンソース化したコンテナオーケストレーションソフトウェアだとされています。 Borgの大規模分散コンテナ基盤でBigQueryが成立する このBorgによる大規模分散コンテナ基盤があるからこそ、BigQueryが安価に提供できるのだと、Google

※この投稿は米国時間 2020 年 10 月 29 日に、Google Cloud blog に投稿されたものの抄訳です。 昨今の変化するビジネス環境では、クラウド ストレージのコストを管理し、過剰な支出のリスクを軽減することが非常に重要です。今回 Google は、Google Cloud Storage 内のデータを保護し、総所有コスト（TCO）を削減することを目的とした、新しい 2 つのオブジェクトのライフサイクル管理（OLM）ルールの提供を開始します。バージョニングされたオブジェクトがいつ最新でなくなったか（期限切れ）、またはオブジェクトに設定したカスタム タイムスタンプに基づき、ストレージ クラス間でオブジェクトを移行したり、オブジェクトを完全に削除したりできるようになりました。これにより、きめ細かな管理が可能となり、TCO の削減と、ストレージ効率の改善が実現します。 アーカイ

※この投稿は米国時間 2020 年 8 月 13 日に、Google Cloud blog に投稿されたものの抄訳です。 Google Cloud で確実にアプリケーションを運用してインフラストラクチャを実行することがどれほど重要であるかについて、お客様からさまざまな声が寄せられています。とりわけ、オブザーバビリティは信頼性のある運用のために欠かせない要素です。Google Cloud 環境の分析情報をすばやく得られるよう、今年に入ってリリースしたオブザーバビリティ スイートである Cloud Operations に 21 の新機能を追加しました。これにより、Google Cloud Console からすべてのオペレーション機能に直接アクセスできます。今日ご案内する新機能では、お使いの環境が Google Cloud、その他のクラウド、オンプレミス、またはその組み合わせのいずれであって

※この投稿は米国時間 2020 年 7 月 31 日に、Google Cloud blog に投稿されたものの抄訳です。 Google Cloud に移行する組織のセキュリティ運用チームから次のような質問を受けることがよくあります。「デプロイメントへの不正な侵入を防ぎ、ラテラル ムーブメントに対する防御力を高めるにはどうすればよいですか？」ラテラル ムーブメントでは、攻撃者がシステムに侵入した後にシステム内部を動き回り、機密性の高いデータへのアクセス権を奪います。 ラテラル ムーブメントを防ぎ、組織のセキュリティを維持するには、「多層防御」のアプローチをとることをおすすめします。そうすれば、互いに補強し合うように構築された複数のセキュリティ レイヤによってユーザーやデータを保護できます。あるレイヤが回避または突破された場合でも、他に多くのセキュリティ レイヤが控えており、攻撃者の目的遂行を

App Engine を利用していると、時たま何かに引っかかったように処理が詰まることがあります。こんな時にはもちろん StackDirver Trace を使ってボトルネックを探ったりするわけです。 しかしながら時に、何の RPC を呼び出しているわけでもないのに、何故か処理の開始が遅い場合や、レスポンスを返すのが遅いということがあります。 よくありがちな理由が、リクエストが殺到して新規インスタンスがスピンアップするときに処理が遅れることです。私の周りでは良く「スピンアップに引っかかる」と言っています。しかし、具体的に何が起こっているのか、本当にスピンアップが起因しているのかは曖昧のままでした。そのため、今回、真面目に調べてみることにしました。 Request Queue を理解する App Engine がスケールする仕組みを詳しく知るには Pending Request Queue

GCP Datastoreを扱うコードをGitHub Actions上でテストする方法をまとめた。 TL;DR GCP Datastoreはエミュレータが用意されており、コンテナを提供している人もいる https://cloud.google.com/datastore/docs/tools/datastore-emulator https://hub.docker.com/r/singularities/datastore-emulator/ GitHub ActionsでDBや外部ストレージを模した環境を用意するときはjobs.<job_id>.servicesを使う https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idservices GCPのGoクライアン

In my previous story, Gabriel Flores asked me about cost comparison. Indeed, choosing a solution from a technical point of view is important, but the cost of a service isn’t to forget because, in auto scaling environment, it can blow up without warning. The comparison performed in only based on the pricing and Quotas & limits of each product. The performance of processing are supposed equals in bo

If you’re a mobile app developer, I imagine there’s a good chance that you know something about Firebase, Google’s mobile application development platform. Or, if you’re an enterprise systems developer, you might know something about Google Cloud Platform (GCP), a broad suite of products and services that host your data and code at planetary scale, and more. While both platforms can be used withou

界隈でちょくちょく質問されているのを見るので調べたことをまとめてみました。 結論だけで言うと、「よい」です。 Firebase apiKey? なに? Firebase project を作成すると projectId はもちろん apiKey や databaseURL などが作成され、これを使うことで機能が使えるようになります。Firebase console でいうと Project 設定などから [アプリを追加] すると取得できます。 詳しい手順はこちら。https://support.google.com/firebase/answer/7015592?authuser=0 var config = { apiKey: "CcN0p0MAIzavPCNkmXSyAy4xhKwCF6CqbX5TcvL", authDomain: "example.firebaseapp.com",

EDIT: This article may contain technical issues. Read with a grain of salt. Google Cloud Functions come in 2 flavors: HTTP & background functions. You use background functions when you want to have your Cloud Function invoked indirectly in response to an event, such as: ✉️ A message on a Pub/Sub topic📦 A change in a Cloud Storage bucket🔥 A Firebase eventIn this blogpost, we’ll talk about Pub/Sub

この記事は Google Cloud Japan Customer Engineer Advent Calendar 2019 の 14日目の記事です。 以前にこちらの記事で VPC-native クラスタの説明と、ルートベースのクラスタについても簡単に触れましたが、今回はもっと具体的な違いと、両者のメリットデメリットについて解説していきたいと思います。 今回解説する内容は次の点です。 ・実際に GCP の VPC ネットワークのどの設定がこの両者の違いを実現しているのか？ ・クラスタ内の Pod と外部の通信の仕組みついてなにか違いはあるのか？ ・両者のメリット、デメリットとそれぞれのユースケースについて 実際に GKE のクラスタを作りながらみていきましょう。 ルートベースのクラスタまずはルートベースのクラスタを gcloud コマンドで作成します。ルートベースを指定するオプションは

この記事は Google Cloud Japan Customer Engineer Advent Calendar 2019 の 16日目の記事です。 tl;dr「Google アカウントを使ったログイン機能を簡単に実装したい！」 Identity-Aware Proxy を使えば、ログイン画面すら作ることなく Google アカウントによるログイン機能を実装できます。ログイン可能なユーザを制限した社内向けアプリ等にも最適です。 「Google アカウント以外のソーシャル ログインもサポートしたい！」 Identity Platform で簡単に実現することができます。Firebase Authentication と共通の SDK が提供されており、ログイン画面も FirebaseUI により簡単に作ることができます。メールアドレスによるユーザリンク機能、マルチテナント対応、SLA も

この記事は Google Cloud Japan Customer Engineer Advent Calendar 2019 の 3 日目の記事です。 本記事では、GKE を対象に、マスター、ノードのアップグレード戦略について紹介します。11/5 には Surge Upgrade がベータ版としてリリースされましたので、そちらも合わせて紹介します。 GKE のアップグレード戦略Kubernetes は、約 3 ヶ月ごとにマイナーバージョンがリリースされます。また、3 つのマイナーリリースをサポートするというポリシーになっています（ v1.3 がリリースされたタイミングで、 v1.0 はサポートされなくなります）。そのため、Kubernetes を運用するに当たって、Kubernetes を適切にアップグレードしていくことは、必須の作業といえるでしょう。 では、GKE のアップグレードを考