「+ Joy」 初めは熱々だったはずなのに だんだん硬くて冷たくなっていく目標に 血を通わせる工夫_2024年度下期アップデート版
「+ Joy」 初めは熱々だったはずなのに だんだん硬くて冷たくなっていく目標に 血を通わせる工夫_2024年度下期アップデート版
いやー高い技術を持ってそうだけどいまいち地味なのと料金表が表に出てないから敬遠してた謎のネットワークサービスFastlyを友人が転職してたので試してみました。そしたらいままでCloud Runで抱えてた悩みが解決してしかも値段も結構大丈夫そうだったので記事にまとめることにしました。 追記：Host Overrideについて書いた 俺たちは安くてhttpsで独自ドメインでCloud Runを使いたい そう、それだけなんですよ。それだけなのに苦労するのがCloud Runなんですよ。詳しくはこちらをお読みください。いままでは安くで済まそうとすると、プレビュー版のカスタムマッピングか、Cloudflareを前段にかますことが多かったのですが、それだと遅いのですよ。 Cloudflare Workersを組むとそこそこ速いのですが、キャッシュ含めちゃんと組むとなるちょっとコードの手間がかかるんです
はじめに 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
Google Cloud のログ管理サービスである Cloud Logging は JSON で出力されたログを構造化ログとして認識します。その際に特別な JSON フィールドを使うとログに特別な属性を与える事ができます。本記事ではそれらの特別な JSON フィールドを用途ごとにまとめて紹介します。 本記事の技術的な内容はほぼすべてこのドキュメント 1 ページに書いてありますが、「実際に UI でどう表示されるのか」と「その特別な JSON フィールドにどんな価値があるのか」はドキュメントにないので参考にしていただけると思います。 Cloud Logging へのログ書き込み Cloud Logging へログを書き込むには大きく 2 つの方法があります。API で LogEntry を直接書き込むか、それ以外かです。 API で直接書き込む方法の場合、メジャーな言語であれば各言語のライブ
G-gen 又吉です。Google Cloud (旧称 GCP) の生成 AI (Generative AI) である PaLM 2 を用いて、Cloud Run 上に社内 LLM Web アプリを構築してみました。 はじめに 前提知識 Vertex AI PaLM API Gradio Cloud Runサービスへのアクセス制御 準備 ディレクトリ構成 app.py requirements.txt Dockerfile デプロイ 動作検証 はじめに 今回は、Google Cloud の生成 AI である Vertex AI PaLM API を用いて、社内向け LLM Web アプリを Cloud Run 上にデプロイします。 また、Cloud Run サービスの認証には Identity-Aware Proxy (IAP) を用いることで、社内ユーザーのみがアクセスできる状態を構成で
[GCP]Log AnalyticsとLooker StudioでBigQueryのクエリコストをユーザー別に見える化するBigQueryLogAnalyticsGoogleCloudLookerStudio 先々月～先月（2022年9, 10月）頃、Cloud LoggingシリーズにLog Analyticsの公開プレビュー版が利用可能になったので、使ってみつつ、Looker Studio（旧Google Data Portal）でBigQueryのクエリコストをユーザー別に見える化するところまで実施してみたので、覚書きを残しておきます。 ※本記事は、2022年11月1日に執筆しました。 用語解説 Log AnalyticsとLooker Studioについて、簡単に解説しておきます。 Log Analytics Cloud Loggingシリーズの機能セットのひとつで、BigQuer
![[GCP]Log AnalyticsとLooker StudioでBigQueryのクエリコストをユーザー別に見える化する - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/26429e0f4e6506e9a138dfca3fb1b625e59fa545/height=288;version=1;width=512/https%3A%2F%2Ffanyv88.com%3A443%2Fhttps%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCR0NQJTVETG9nJTIwQW5hbHl0aWNzJUUzJTgxJUE4TG9va2VyJTIwU3R1ZGlvJUUzJTgxJUE3QmlnUXVlcnklRTMlODElQUUlRTMlODIlQUYlRTMlODIlQTglRTMlODMlQUElRTMlODIlQjMlRTMlODIlQjklRTMlODMlODglRTMlODIlOTIlRTMlODMlQTYlRTMlODMlQkMlRTMlODIlQjYlRTMlODMlQkMlRTUlODglQTUlRTMlODElQUIlRTglQTYlOEIlRTMlODElODglRTMlODIlOEIlRTUlOEMlOTYlRTMlODElOTklRTMlODIlOEImdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZ0eHQtY2xpcD1lbGxpcHNpcyZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTA3YzhmMWM0ODdkOTI5MGRhMzcyYWEyMGYzZmZiZGY3%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTcxNiZ0eHQ9JTQwQ19IRVJPJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzImdHh0LWFsaWduPWxlZnQlMkN0b3Amcz01M2I4YzAxNWZhODNkYjA1ZjA0NTA1ZjYyM2MyMGZlNQ%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D8ed796666e6a007091ac599b347f8e23)
こんにちは、インフラ部の id:sue445 です。 前回に引き続きGitLabのGCP移行について紹介します。 前編の記事はこちらになります inside.pixiv.blog 今回の目次 今回の目次 やったこと2: 実際にGCPに構築した GitLab構築に関係するリポジトリの構成 gcp-gitlab-terraform gcp-gitlab-playbook gcp-gitlab-helm 備考 全体の構成図 webservice (GitLab本体) GitLab CI 3rd party製のDockerイメージから公式のDockerイメージに移行した Docker Swarmは継続利用 GitLabを複数ゾーンで動かすための準備だけした やりたかった構成 現在の構成 Cloud IAPとTunneling SSH Connectionsを利用したgitアクセス Tunnelin
データシステム担当の黒瀬です。 こちらは、TVer Advent Calendar 2022の9日目の記事です。 この記事では、TVerで運用しているデータシステムの基本的な権限管理ポリシーについてご紹介します。 大まかな内容 GCP上に構築しているデータシステムをメンテナンスする際の権限を、従来は管理者が手動管理していたが、この運用にはリスクがありました。 そこで、権限を付与するためのサービスアカウントを経由する仕組みおよびその趣旨を明確にするルールを導入しました。 結果、管理者に依存せずにメンテナンスができる運用が可能になりました。 背景 TVerでは、主にBigQueryに視聴ログなどのデータを集約し、その上で集計や分析をするという方針をとっています。 ログを収集するシステムはAWSやGCPなど要件に合わせて各所に構築されていますが、これらからBigQueryへデータを収集・集約する
こんにちは、インフラ部の id:sue445 です。 先日ピクシブ社内で利用しているGitLabをオンプレミス環境からGCPに移行しました。 とても長いので全3回にわけて紹介したいと思います。 全体の構成 前編：前置きとアーキテクチャ検討 中編：環境構築 後編：実際の移行作業とその前後の対応。移行後の所感など 今回の目次 全体の構成 今回の目次 tl;dr; 移行の理由 筆者略歴 GitLab移行の時系列 やったこと1: アーキテクチャ検討 構成図 GitLabをクラウドに移行するための障壁をまとめた URLをどうするか Cloud IAP利用時の通信のオーバーヘッドをなくしたい 実際にGCP移行した後の構成 AWSでPoC環境を作った時の構成 LDAPからの依存をやめたい＆複数のログイン方法を統一したい ssh接続時にあるLDAP依存を不要にしたい 余談 AWS移行案 GCP移行案 Gi
本記事は、2021年9月15日に開催された Google の公式イベント「オープンクラウドサミット」において、 Google Cloud のアプリケーションモダナイゼーションスペシャリストである塚越啓介氏が講演された「 Cloud Run と Eventarc による Event Driven Architecture 入門」のレポート記事となります。 今回は Google Cloud （GCP）の Cloud Run と Eventarc を活用した Event Driven Architecture の構築方法についてご説明します。各サービスの概要説明に加えて、 Eventarc のデモンストレーションも紹介していますので、ぜひ最後までご覧ください。 なお、本記事内で使用している画像に関しては、オープンクラウドサミット「 Cloud Run と Eventarc による Event D
MAD事業部@大阪の岩田です。 本エントリは クラスメソッド Google Cloud Advent Calendar 2021 の 24日目 の記事です。 最近色んな環境でrm -rf /*を実行するのが流行っているようですね。 このビッグウェーブに乗るべくGoogle CloudのCloud Functions実行環境でrm -rf /*を試してみたいと思います。 やってみる 早速やっていこうと思うのですが、OSコマンドの実行を試すためにいちいちCloud Functionsにデプロイするソースコードを書き換えてデプロイして...を繰り返すのは効率が悪そうです。理想としてはCloud Functions実行環境にシェルアクセスして各種コマンドで環境を自由に分析し、最後にrm -rf /*を実行できると嬉しいです。 ということで、以前紹介したserverless-preyを利用してClo
はじめに 先日、JakartaOne Live Japan 2022というイベントで登壇させていただく機会を頂きました。 QuarkusやHelidonのような新しめのEEフレームワークがこれまでのPayaraやWebLogicとどう違うのか？ CloudRunのようなサーバレス環境でMicroProfileのどの機能が効果的に働くのか？ という点を最近のWeb開発周りのトレンドと絡めながら話ました。上記のようにアーカイブ動画も公開されていますが、せっかくなのでQuarkusがサーバレス環境で実行に最適化されるまでの周辺事情等をまとめたいと思います。Javaだけに留まらず最近の環境事情の整理にも役立つかと思います。 TL;DR Quarkus/Helidonは軽量で高速な新しいEEフレームワーク コンテナや、サーバレス、クラウドネイティブなど最新のトレンドに基づいた設計 GCPのCloud
現時点では実装できていない機能もある為詳しく記述できない箇所や実際の仕様と異なる、変更される箇所も出てきます。その点を考慮して閲覧していただけると嬉しいです。 サービスの仕様 以下の特徴を持つようなサービスを設計します。 ユーザーがmp4形式の動画をアップロード アップロードされた動画をHLSにトランスコードし閲覧時に配信 配信されている動画はユーザー単位のアクセス制限をかける事が可能 今回は動画をメインに取り扱っていますが、動画以外にも画像や音声、テキストデータなどを扱う事が可能だと思います。 配信基盤の設計 配信にはCloudStorageを利用します。加えてCloudStorageのrulesでは表現の難しいユーザー単位でのアクセスコントロールを予定しているのでHttpLoadBalancer, CloudCDNを利用する予定です。 以下は署名付きCookieを使用した場合のシークエ
G-gen の佐々木です。当記事では Google Cloud (旧称 GCP) のサーバーレスなコンテナサービスである Cloud Run を解説します。 Cloud Run とは Cloud Run の基本 2 つの利用方法 Cloud Run サービス (services) Cloud Run ジョブ (jobs) 動的スケーリング サービスの冗長性 デプロイ デプロイ元のコンテナイメージ コンテナの要件 トラフィック移行とロールバック 構成 エンドポイント コンテナインスタンスの最大・最小数 Startup CPU boost CPU・メモリ リクエストのタイムアウト コンテナインスタンスあたりの同時リクエスト最大数 CPU を常に割り当てる Cloud Run サービス コンテナ実行環境 (世代) サービス連携 (トリガー) ネットワークアクセスの制限 Cloud Run サービ
Professional Data Engineerに合格しました。受験体験記を共有したいと思います。 Professional Data Engineerとは 2022年の最も高収入につながる IT 認定資格ランキングで1位の資格です。平均年収2200万円($171,749) 合格するためにやったこと 模擬問題集で70%あれば合格できます。1セット1時間合計8時間で終わります。試験開始前に間違えた問題を再度確認しておきましょう。Udemyのセール時に購入するのがおすすめです 【最短攻略】Google Cloud 認定 Professional Data Engineer 模擬問題集 Google Cloud Professional Data Engineer - GCP - Exams - 2022 テストは英語ですが、右クリックで日本語にできます。 Udemy自動化 Tampermo
はじめに 私の仕事は、新規サービスをまるっといい感じに開発するのを委託されることがほとんどです。最近はネイティブアプリを作ることよりもブラウザで動くWebサービスを開発することが多いのですが、案件の規模感や要求によって技術選定を少し変えるようにしています。「こういうときはこう」みたいに一概には言えないのですが、普段使う構成を紹介します。誰かの参考になれば幸いです。 2022/02/10 現在での内容です。 前提 開発を委託される場合の運用費をどうするの問題があります。クライアントにクレカ登録をしてもらうか、こちらで支払って毎月請求するかになります。僕は毎月やるのがめんどくさいのでできるだけ前者に倒している関係上、あまりいろいろなSaaSを組み合わせて作ることをなるべく避けています。 規模感によらず使っているもの 私の場合、以下が使えるとめちゃくちゃ効率よく開発できます。 GCP 好きだから
prep-container-engine-for-prod.md https://cloud.google.com/solutions/prep-container-engine-for-prod プロジェクト・ネットワーク・クラスタの構成 プロジェクト GCP のすべてのリソースは プロジェクト の下に作成される プロジェクトごとに請求や IAM の管理が可能 本番やステージングといった複数環境のリソースを分離するためにもプロジェクトで分けよう ネットワークとサブネットワーク ネットワークはサブネットワーク・外部 IP アドレス・ファイアウォールルール・ルートなどをもつ GCP ではパフォーマンスやシンプルさを追求し、リージョンを跨げるネットワークになっている ファイアウォールはネットワークに対して設定できる ファイアウォールはデフォルトで GKE ノードへの流入トラフィックは禁止して
※この投稿は米国時間 2021 年 11 月 4 日に、Google Cloud blog に投稿されたものの抄訳です。 Google Kubernetes Engine（GKE）の新機能であるイメージ ストリーミングが一般提供されることを発表いたします。この革新的な GKE 機能には、アプリケーション スケールアップ時間を劇的に改善させる可能性があり、これを利用するとユーザーからの要求の増加に対してより迅速に応答し、予備容量のプロビジョニングを減らして費用を削減できます。これを可能にするのは、コンテナのイメージ pull 時間を数分（大きなイメージの場合）から（コンテナサイズを問わず）わずか 2～3 秒に削減する能力です。こうしてアプリケーションは直ちに起動でき、その間、GKE がコンテナデータを並行してストリーミングします。 アプリケーションをスケールアップする際、従来の Kubern
インフラの駒崎です。 Google Kubernetes Engine (GKE) の 1.20+ で有効な kubelet graceful node shutdown と、それを活用した preemptible VM の利用について書かせていただきます。 GCP の Preemptible VM とは Preemptible VM は、いくつかの制限があるかわりに通常のインスタンスよりも安く利用できるインスタンスです。制限はいくつかありますが、最も留意すべきは 「いつでも停止される可能性があり、最長でも起動から 24 時間で停止される」点でしょうか。 ※ Preemptible VM の新バージョンとして Spot VM もアナウンスされました (2021/10/13 現在 preview) 。 Graceful node shutdown GKE 1.20 以降のバージョンでは ku
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
