Google Cloud のマネージド Terraform、 Infrastructure Manager 登場！
こんにちは。クラウドエースの阿部です。 今回はひっそりと一般提供されていた Infrastructure Manager について紹介したいと思います。 Infrastructure Manager とは Infrastructure Manager (以降、Infra Manager と表記) は、 Google Cloud におけるリソースのデプロイや管理を IaC で自動化するためのマネージドサービスです。 内部では Terraform と Cloud Build を使用してリソースの管理を行っています。 Infra Manager の特徴 特徴としては以下の通りです。 GitHub 等と連携した CD (継続的デリバリ) の構築を簡単に実装できます。Cloud Build で同じ事をやる場合は、 cloudbuild.yaml で CI/CD パイプライン設定が必要です。また、ロー
Cloud Run (Grafana) + BigQuery + IAPでデータの見える化を実現した - 株式会社ヘンリー エンジニアブログ
こんにちは、ヘンリーでSREをしているTODA（＠Kengo_TODA）です。 弊社ではデータの共有は主にNotionを用いています。ただ各システムからデータをかき集めて動的に共有するには、Notionはちょっと向いていないなと思うところがあります。データを通じてシステムや顧客、チームの課題を掴むことはスタートアップの生命線とも言え、SLOやKPIを動的に図示してスタンドアップミーティングなどで共有できる仕組みが必要だと感じていました。 このため、Grafanaを用いた仕組みをGCP上に構築しました。ウェブページを自動生成できるツールからの情報は以前Noteでご紹介したサーバーレス社内サイトで展開していますが、Grafanaであれば動的にコンテンツを構築して提供できると期待しています。 この記事ではGCPないしGrafanaの設定をどのようにしたか、その背景とともに説明していきます。 どの
GitHub ActionsからBigQueryのリモート関数をデプロイする - BOOK☆WALKER inside
こんにちは、メディアサービス開発部サービス分析課の佐藤です。ブックウォーカー社で全社横断のデータ基盤を構築しています。 前回SlackからGitHub Actionsを実行する記事を投稿しましたが、今回はそのGitHub Actionsを使ってデプロイしていたBigQueryのリモート関数の利用ケースについて説明していきます。 背景 「外部のAPIから得たデータをBigQueryへ投入するやり方」の検討 Terraformでデプロイ用のServiceAccountを作成 BigQueryに外部接続とデータセット作成 GitHub Actionsにデプロイ用ワークフローを作る ランタイム判定 エントリポイント判定 全体の流れをまとめて提供する 終わりに 背景 現在、BigQueryのデータを加工する集計バッチについてはスケジュールクエリを各自に好き勝手に作成してもらう運用にしています。 スケ
データ基盤のアラートにNew Relicを導入しました - TVer Tech Blog
はじめまして、エンジニアの黒瀬と申します。 弊社では、これまでバックエンドの監視にNew Relicを利用してきましたが、今回データ基盤にも導入を開始しました。 この記事では、その経緯についてご紹介したいと思います。 背景と課題 弊社ではTVerのサービス利用状況を日々収集し、それをBigQueryを中心としたデータ基盤に集約・可視化することで、日々のサービス改善に活用しています。 このプロセスは、おおむね次のような役割分担となっています。 収集処理：バックエンドを担当するバックエンドチームがAWSに構築 集約処理：データ基盤を担当するデータチームがGCPに構築 これらのうちデータチームでは、集約処理を構成するバッチごとにアラートを実装していましたが、下記のような問題がありました。 バッチごとに異なった方法でアラートを実装していたため、保守がしにくい アラートの通知先が散らばっており、毎回
秘密情報をGitLabに格納することなくGoogle Cloud / AWSに対して認証する - エムスリーテックブログ
エムスリーエンジニアリンググループ AI・機械学習チームの笹川です。 趣味はバスケと筋トレで、このところはNBAはオフシーズンですが、代わりにユーロバスケが盛り上がっていて、NBAに来ていない良いプレーヤーがたくさんいるんだなーと思いながら見ています。 夜ご飯を催促するためデスク横で待機する犬氏（かわいい） 今回は、パブリッククラウドへの認証に必要な秘密情報をGitLab自体に格納することなく、安全に認証する方法について紹介します。 CI/CDの実行時のパブリッククラウドに対する認証 ナイーブな手法とその問題点 OpenID Connectを用いた認証 Terraformでパブリッククラウド側の設定を記述する Google Cloudの場合 AWSの場合 GitLab CI/CDで認証する Google Cloudの場合 AWSの場合 認証ステップの共通化 まとめ We are hirin
一週間で構築できる！ お手軽データウェアハウス
Legalscape (リーガルスケープ) アドベントカレンダー 2021 の 12/16 (木) のエントリです。 本日のエントリは、突貫工事的に一週間程度1で構築したデータウェアハウスについてお送りいたします。 データウェアハウス構築前夜 2021 年 6 月に予定をしている Legalscape 正式版リリースが刻々と迫り、みなが慌ただしく仕事をしている 5 月下旬、ビジネス上の様々な理由からユーザのアクティビティログを保持して分析・集計するデータ基盤、すなわちデータウェアハウスが必要になりました。 Legalscape ではそれまで、プロダクト上でのユーザの行動に伴って発生するアクティビティログはすべて (書籍の全文検索に用いているものと同じ) Elasticsearch クラスタにインデックスしていました。アクティビティログを利用する際は、このインデックスに対して Kibana
CI/CDのボトルネックを把握できていますか？BigQueryでビルド情報ダッシュボードを構築した話
https://event.cloudnativedays.jp/cicd2021/talks/1152 開発人数が多く、規模の大きいプロダクトでは最終的な成果物をビルドするだけで1時間以上かかってしまうことも珍しくありません。ですが最初からそれほど時間がかかっていたわけではなく、時間とともに巨大化するコードベース、追加されたステップなどによりいつの間にかどこかの処理がボトルネックとなっていることが多いでしょう。 CIサービスの多くは成功/失敗の情報、全体としてのビルド時間の情報は見やすく提供していますが、各ステップの時間やステップのエラー率などの細かい粒度の情報を時系列で確認する機能までは提供されていないことが多いです。そのため、ボトルネック箇所を特定するためには過去の生ビルドログを自分の目で確認するコストが高い作業が必要でした。 そこで、Jenkins, CircleCI, Githu
SQLを使った監視でデータ基盤の品質を向上させる - MonotaRO Tech Blog
こんにちは、データ基盤グループの吉田(id:syou6162)です。データ基盤グループでは安定してデータを利用できるように様々な取り組みを行なっています。本エントリでは、データ品質に問題がある場合にすぐに気付けるようにしたSQLによる監視の仕組みを紹介します。 背景 SQLを使った監視基盤の構築 実際の監視項目例 他チームがdailyで転送しているデータがバッチの失敗により遅れていないか BigQueryのエラーレートが急激に増加していないか 承認済みビューの設定が意図せず消えていないか 今後の展望 背景 データ基盤の運用をしていると、日々様々なトラブルと向き合う必要があります。例えば、以下のようなものがあります。 他チームがdailyで転送しているデータがバッチの失敗により遅れている TerraformなどのIaCで承認済みビューの権限管理を行なっているが、コードの設定ミスで意図せぬ状態
Streamlit on Cloud Run with Identity-Aware Proxy (IAP) - public note
タイトルのとおり、Cloud Run で Streamlit を動かしてみました。また、特定の人のみがアクセスできるように、Identity-Aware Proxy(IAP) での保護を試しましたので、その設定やコードを紹介します。 Cloud Run で動かすのはすぐにできたのですが、複数の Streamlit コードを認証付きでいい感じにホストする手段を探すのにかなり苦戦しました... Streamlit 構成図 ソースコード リクエストから Streamlit が起動するまで よいところ 設定のポイント ユーザ認証方法 Cloud Run の Ingress 設定 IAP で必要な権限 パスルール設定 リクエストURL に Streamlit の起動URLを合わせる サーバーレス NEG と Cloud Run の設置リージョン 参考にしたページ Streamlit Streamli
最近の砂場活動その23: Cloud MonitoringでKubernetesのバッチ処理を監視する - yasuhisa's blog
Kubernetes上で動かしているバッチ処理の監視をCloud Monitoringで行なおうと思ったのですが、素朴にやるとちょっと困りました。一工夫したので、メモを残しておきます。 背景 Cloud Monitoringで素朴にバッチ監視を行なう これだと困る...! 次のバッチが成功するまでインシデントが閉じないようにする 背景 Webサービスの監視と同様にバッチ処理についても監視は必要です MackerelなどのSaaSを使うと、バッチ処理についても簡単に監視できます 最近の砂場活動その10: songmu/horensoを使ってバッチの処理時間をMackerelのサービスメトリックに記録する - yasuhisa's blog ただ、仕事のチームではMackerelを今は使っていません。GCPを使っているので、Cloud Monitoringでやるかなーという感じ メトリックやダ
【2019年4月版】Terraform + GKE でのいろいろ小技メモ - Qiita
Terraform にだいぶ馴染んでまいりました。 前回の記事(【2019 年 4 月版】Terraform+Spinnakerがよくね!? → 闇が深い。)で Spinnaker のインストールを Terraform でやってみましたが、Spinnaker 以上に Terraform でアレコレやりましたのでむしろ Terraform + GCP の闇を垣間見てしまいました。 前回の説明の流れではご紹介していない小技というか注意点をアラカルトでメモっておきます。 でもやっぱり、敵はロール。 GKE から Cloud SQL Proxy を通して SQL にアクセスする 基本的には以下の公式ページの手順でOKです。 Google Kubernetes Engineから接続する ただし、以下のコマンドを Terraform でどうやるか、が問題です。 $ kubectl create sec
Stackdriver を触ってみた - えいのうにっき
Mackerel に始まり、先日の Datadog を経て、今日は Stackdriver を触ってみる。 Stackdriver も、モニタリング系の SaaS。当初は AWS 向けのモニタリングサービスとして始まったようだけど、Google に買収され GCP ファミリーに加わり、今ではむしろ GCP 寄りのサービスになっているようす。 Stackdriver も同じくエージェントインストール型。とはいえ、GCP 上のリソースであればある程度のことはエージェントなしで取得できるみたい。現在ベータで、無料で利用できる。 〜 利用開始まで 前回の Datadog でも監視対象にした home.a-know.me は GCE でホストしているということもあり、せっかくなんで、エージェントをインストールしない状態でどこまでのことができるのか、確認してみる。 Stackdriver は Goog
Terraformを使って GCP Pub/Sub から AWS Lambda へのPush通知の仕組みを作成した - Qiita
先日作ったのでその覚書的なものです。 簡単に言うとこんな感じのものを作りました。 GKE上のDockerアプリ -> Stackdriver logging -> Pub/Sub -> Lambda -> Slack 作成の動機 概ね以下の背景です。 GCPをメインに、AWSも多少織り交ぜつつな感じのアプリケーションを作っている。 Stackdriverでアプリの監視を行っているがエラーログを検知したらSlackに通知する仕組みが欲しかった。 Stackdriver単体だとログ内容をSlackに通知できなさそうだった。 StackdriverはフィルタリングしたログをPub/Subへ流すことができるらしい。 Pub/Subはキューにデータが流れてきたときに指定したエンドポイントにPush通知できるらしい。 と、こんなかんじの前提があり Pub/Sub から lambda に流して、そこから
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - GoogleCloudPlatform/terraformer: CLI tool to generate terraform files from existing infrastructure (reverse Terraform). Infrastructure to Code