アーキテクチャ図だけ描いてTerraformはGoogle Cloud Developer Cheat Sheetに書いてもらおう
初めての方は、初めまして。そうでない方も、初めまして。クラウドエース SRE 部で Professional Cooking Architect をしている zeta です。私はドンドコ島の充実度をオンライン1位(多分)にしましたが皆さんいかがお過ごしでしょうか。 はじめに クラウドエースの SRE 部は Google Cloud のインフラの面倒を見ることが主な業務です。世の中の多くの企業の似たような役割を持つ部署でもそうだと思いますが、インフラの設計・構築・運用といったフェーズを行っていきます。こういったインフラエンジニア的なことをやっていると、みなさんも一度ぐらいは「設計だけやったら勝手にインフラ構築されねーかな〜」なんて思ったことはあるのではないでしょうか。技術の力でコンピュータに働かせてサボるというのは IT エンジニア開闢以来ずっと存在し続けた悲願であり、エンジニアリングのモチ
Cloud Run 上のページが一部の Chrome 環境で文字化けする謎を探るべく我々は Google Cloud の奥地へと向かった
この記事は 2024 年 2 月 28 日に執筆されました．今後この問題が Cloud Run 側で修正された場合，再現しない可能性がありますのでご留意ください． TL; DR Cloud Run は執筆時現在 zstd による圧縮に対応していない ヘッダの Content-Encoding: zstd のみが削除され，ボディは圧縮されたまま応答される ブラウザはこの応答を正しく解釈できないため文字化けのような表示となる zstd による圧縮は，執筆時現在 Chrome に実装されているもののデフォルトでは無効だが近い将来に有効化される 悲劇は突然訪れる 弊社では，コーポレートエンジニアリングチーム [1] [2] において，社内向けにいくつかのサービスを提供しています． これらのサービスはもともと AWS でホストされていましたが，アクセス制限に Identity-Aware Proxy
Cloud Run のための実践 Cloud Deploy
はじめに 本記事では実践的な Cloud Run のデプロイパイプライン実装を通して Cloud Deploy の理解を試みます。Cloud Deploy は元々 Kubernetes 用のプロダクトとしてリリースされたこともあり、Cloud Run に限って利用するには学習コストが高すぎるところもあります。本記事では Cloud Run のデプロイの本番環境構築・運用に必要な部分のみをピックアップして次のようなことを説明します。 Cloud Deploy の仕組み Cloud Deploy を使ったデプロイパイプラインの設計・実装方法 Service Account、IAM 設計 おすすめの Infra as Code の方法 おすすめの skaffold.yaml の書き方 Automation、デプロイフック、カナリアデプロイなどの高度なパイプライン、監視などは上記のような基本をおさ
Cloud Run から内向きが「内部」なCloud Run にアクセスしたい
はじめに Cloud Run から 別の Cloud Run へアクセスするときに、その Cloud Run って「すべてのインターネットからアクセスさせる」必要ってあるのかな？という疑問がありました🤔 公式ドキュメント[1]を読むと Cloud Run からのアクセスをInternal (内部)として扱う方法について記載がありました。 3つの方法があるようですが、どうも理解が進まないので実際に検証してみたいと思います。 やりたいこと 検証プロセスの概観 Cloud Run を2つ作成します。以下はそれぞれのコードです。 client-node : server-node に対して、HTTPリクエストを投げる Cloud Run。この Cloud Run は常に 内向きは「すべて」とする。 リクエスト先 Cloud Run の公開URLを環境変数として設定している server-node
Cloud Run + Litestream で RDB を使いつつ費用を格安に抑える
前から気になっていた Litestream を Cloud Run で使ってみたので、そのメモです。 Litestream とは？ サンプルコード 手順 動作確認してみる 制限事項 おまけ まとめ 参考 Litestream とは？ Litestream は、 SQLite のデータベースファイルを Amazon S3 や Google Cloud Storage などのオブジェクトストレージにリアルタイムでレプリケートすることができるオープンソースのツールです。 例えば通常 Cloud Run で DB エンジンとして SQLite を使用しようとしても、コンテナが破棄されると同時に毎回 SQLite のデータベースファイルも消えてしまうため、データを永続化することができません。 しかし Litestream を使用すれば、 SQLite のデータベースファイルをオブジェクトストレージに
AWSエンジニアがGCPでハマりがちなポイント - Qiita
Japan Digital Design（以下JDD）でインフラエンジニアをしている渡邉です。 Japan Digital Design Advent Calendar 2023 もついに19日目までやってまいりました。 後半だしまだ全然余裕～、とのんびりしていたら、あっと言う間にやってきました...。 さて、今回は Google Cloud Platform（以下GCP）に関するお話です。 JDDでは各プロジェクトそれぞれでインフラ選定が異なりますが、基本的にはAWSをメインで利用しています。 GCPはPoCや内部的なアプリケーションに利用が限られていたわけですが、ついにProductionサービスでの利用が決まり、GCPを本格的に使うことになりました。 AWSにどっぷり浸かったインフラエンジニアがGCPを使い始めるにあたって、きっとハマるであろうポイントをいくつか挙げてみようと思います
GCPのバッチ処理サービス「Batch」を試してみる
それぞれ微妙にできることや制限に違いがあり、ここを捉えた上で選択する必要があります。 Batchの強みはおそらくタイムアウトがないことによって長時間実行ができ、かつシンプルに実装できることだと思います。 （タイムアウト最大値に関して、Batchにおいては存在しないと公式動画の方で説明していますが、Cloud Composerについては不明でした。） Batch単体でもジョブ定義ファイル内で各タスクの依存関係（順次実行、並列実行）はできますが、Cloud ComposerやWorkflowsのように複雑なジョブネットを書くことは難しそうです。 ジョブネットのように動かしたい場合には公式ドキュメントにもあるようにWorkflowsなどからBatchジョブを実行するのが良さそうです。 動かしてみよう 実際にジョブを作って動かすまで試してみたいと思います。 GCP公式がBatchのサンプルコードを
Cloud Runで開発用環境を沢山作る - 一休.com Developers Blog
概要 この記事は 一休.com Advent Calendar 2023 16日目の記事です。 RESZAIKO開発チームの松村です。 一休では各サービス毎に、開発中のサービスの動作を社内で確認できる環境があります。 それぞれmain(master)ブランチと自動的に同期している環境と、特定のブランチを指定して利用できる環境の2種類があります。 今回、RESZAIKOの新規サービス(予約画面)に対してブランチを指定してデプロイできる環境を作成したので、その方針と反省点と今後について記述していきます。 現在運用中の予約画面 開発環境を作る理由 一休では長らく、EKS上に複数の環境を用意して、ブランチを指定すると開発環境にデプロイするシステムが利用されてきました。 一般的にこのような環境を構築するのは以下のような理由が挙げられます。 動作確認 マイクロサービスで、異なるブランチ同士の組み合わせ
事例から学ぶクラウドへのOpenTelemetry導入のハマりどころ - ヘンリー - 株式会社ヘンリー エンジニアブログ
ヘンリーでSRE / SDETをしているsumirenです。 この記事は株式会社ヘンリーAdvent Calendar 2023の9日目の記事です。昨日は id:nabeop の カジュアルな社内勉強会 : ギベンの紹介 という記事でした。 背景 ヘンリーでは分散トレーシングにOpenTelemetryを用いています。元々、ログはCloud Runの標準出力をCloud Loggingが拾ってくれるものを見ており、メトリクスもCloud Runがマネージドで取得してくれるものを見ていました。しかし、オブザーバビリティを高め、また民主化するためには、トレースを起点にメトリクスやログなど全てのシグナルを追えるべきだと考え、OpenTelemetryを導入しました。 ローカルでいくつかのマイクロサービスとOpenTelemetry Collectorを立ち上げ、Jaegerで分散トレースを追える
Google、AWS Nitro対抗の独自開発したクラウド基盤システム「Google Titanium」投入を発表
Google、AWS Nitro対抗の独自開発したクラウド基盤システム「Google Titanium」投入を発表 Google Cloudは、同社専用に開発したカスタムチップやソフトウェアなどにより構成されるクラウド基盤システム「Titanium」の投入を、先日開催されたGoogle Cloud Next '23で発表しています。 Titaniumは、Googleが独自に開発したカスタムチップとソフトウェアから構成されたシステムです。 クラウドの基盤を構成するホスト上では、セキュリティを保証する処理、仮想化ハイパーバイザの処理、ネットワークやストレージへのアクセスや暗号化などを含むI/Oの処理などが行われます。 Titaniumを用いてクラウド基盤を構成するホストからこれらの処理をオフロードすることで、サーバの能力をより多くユーザーインスタンスに振り分けることが可能になり、全体としてクラ
WINTICKET Web の GKE 脱却と Cloud Run の採用 | CyberAgent Developers Blog
WINTICKET の Web 版（以降 WINTICKET Web）のテックリードを担当している @dora1998 です。 サービス開始以来、WINTICKET Web は Google Kubernetes Engine（以下 GKE）へデプロイして稼働していました。2022 年 10 月に Cloud Run を採用した構成へリアーキテクチャを行ったので、この記事ではその背景や具体的な構成、付随して行った改善について紹介します。 抱えていた課題 WINTICKET Web ではリアーキテクチャ前のバックエンド構成について、大きく 3 つの課題を抱えていました。 リリースの安定性 これまでのリリースフローでは段階的なリリース手段がなく、リリース内容に不具合が含まれていた場合にほぼ全てのユーザーが影響を受ける問題がありました。 加えて、WINTICKET はレース情報を提供する競輪シス
Cloud Run に ko と skaffold を使ってデプロイまでやってみる | フューチャー技術ブログ
はじめにこんにちは！ TIG コアテクチームの川口です。本記事は、CNCF連載 の5回目の記事になります。 本記事では、CNCF の Knative を基盤として利用している Cloud Run と CNCF の各種ビルドツール ko, skaffold、Cloud Deploy を用いたうえで、アプリケーションのビルドからデプロイまでを行います。 扱う技術要素今回は、合計5つの技術要素を扱います。 全体感を掴むため、それぞれの技術とそれらの関連について図示します。 Cloud Run （Knative）Cloud Run は、Google Cloud におけるコンテナベースのサーバーレスコンピューティングサービスとしてよく知られているものかと思います。こちらは、基盤として Knative を採用しています。 この Knative は 2022年の3月に CNCF の Incupating
Cloud RunのDirect VPC Egressを解説 - G-gen Tech Blog
G-gen の佐々木です。当記事では、Google Cloud (旧称 GCP) のサーバーレスコンテナサービスである Cloud Run の Direct VPC Egress 機能について解説します。 前提知識 Cloud Run とは サーバーレス VPC アクセスコネクタとは 概要 Direct VPC Egress とは 使用方法 サーバーレス VPC アクセスコネクタと Direct VPC Egress の比較 コスト パフォーマンス 構成図 比較表 ユースケース 制限事項 スケーリングの上限 サポートされているリージョン サブネットに十分な IP アドレスが必要 その他の制限事項 ロギング・モニタリングに関する制限事項 セキュリティに関する制限事項 Cloud Run jobs の実行時間に関する制限事項 Cloud Run 前提知識 Cloud Run とは Cloud
【社内勉強会】AKIBA.GCP でZennのCI/CDを紹介し、Google Cloud Japan の皆さまに改善アドバイスをいただきました | DevelopersIO
【社内勉強会】AKIBA.GCP でZennのCI/CDを紹介し、Google Cloud Japan の皆さまに改善アドバイスをいただきました こんにちは。Zennチームの和田です。2023年3月1日、Google Cloud に関する社内勉強会が開催され、そこでZennのCI/CDの話をしたのでレポートを書きます。 Zenn の CI/CD Zennは、バックエンドにGoogle Cloudを採用しています。少人数のチームで運営しており、できるだけ運用負荷を減らす観点でCI/CDは重視しているポイントです。いまは、以下のような概略図で動いています。 勉強会の目的 おおきくふたつありました。 Google Cloud で動いているアプリのCI/CDとして、Zennを例にとって共有すること Google Cloud Japan の方々に改善点をアドバイスしてもらうこと この勉強会のために、
Container Registryから脱却してコスト削減した話 - 生涯未熟
一人でインフラ周りなど色々と見て毎日を過ごしているのですが、ある日「そういえば全然Billing情報確認してないぞ」となり確認してみるとえらいことが。 なんか一部のSKUで料金が爆上がりしてる！！！ サービス全体からするとそこまで大きなインパクトではない額だったのですが、それでも見過ごせない不穏な上がり方です。 10/1を契機に上がっていたので、GCPのお知らせを確認してみると・・・ cloud.google.com これや〜〜〜 GKEでContainer Registryを利用していたので、Podを生やす際にContainer Registryからイメージをダウンロードしてくるタイミングで新たにお金がかかるように😇 えらいこっちゃとすぐさまダウンロード時の料金がかからないArtifact Registryへの移行を準備しました。 Artifact Registryへの移行 まずはCD
dbt Core を GCPのCloud Run JobsやBatchで実行する方法
はじめに dbtを用いたデータ基盤運用がお盛んになったなと個人的に感じます。 よく記事で見かけるのが、DWH製品としてSnowFlake, そしてデータ変換にdbt Cloudでしょうか。 そして DWH製品としてSnowFlake, そしてデータ変換にdbt core を ECS Fargateに乗せてサーバレスにやる方法も最近記事で見ました。 あとは dbt core を AirFlow(Cloud ComposerやMWAA含む)で実行する方法もしばしばみかけます。 しかしどれも自分には、あまりFitしませんでした。なぜならば求めている要件としては以下だからです BigQueryの案件が多いのでBigQueryにクエリ投げれればOK 1日1回のバッチ回せれば良い スケジュール設定できればOK dbtドキュメントもみたい 無課金or微課金(ストレージ料やクエリスキャン料除く)ですませた
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - GoogleCloudPlatform/jit-access: Just-In-Time Access is a self-service web application that lets you manage just-in-time privileged access to Google Cloud projects. JIT Access runs on App Engine and Cloud Run.
GCPの権限管理に関する自動化について
【GCP🐳】まだArtifact Registryに移行してないアナタへ
Cloud Run Casual Talk! #2 を開催しました！