こんにちは。スクエニのイギリス支社、ロンドンオフィスで働くヨシダタツオです。アナリティクス&インサイト部署のデータサイエンス部を担当しています。データとAIでスクエニのファンとゲームの関係性を深めるしくみを作っています。 スクエニ欧州拠点ではGoogle Cloudを活用してカスタマーデータプラットフォーム(CDP)の開発・運用を行っています。先日、この取り組みについてGoogle Cloud主催のGoogle Cloud Next London 2023にて発表しました。今回は、そこでの発表内容を日本語でも共有するために、このITエンジニアブログに寄稿することにしました。 カスタマーデータプラットフォーム(CDP)とは CDPはビジネス全体のデータを収集し活用していくシステムです。一般的には、お客様一人ひとりのデータを収集し、管理し、分析するだけでなく、マーケティングやプロモーションに活用します。 スクエニ欧州拠点のCDP開発の経緯 ロンドンのアナリティクス&インサイト部署は、2009年にスクエニに買収されたアイドスというゲーム開発会社のデータ分析チームのルーツを持ちます。アイドスは2007年にゲームプレイデータの収集、分析、機械学習の適用をゲーム業界においていち早く導入し、スクエニに統合後もその活動を継続しています。 2007年当時、データ分析基盤としてMicrosoft SQL Serverを利用していましたが、2013年頃にゲームのオンライン化に伴うデータ量の増加に伴いPlutoというAWSベースの内製システムに移行しました。 CDP開発の直接のきっかけの一つは2018年に導入された新しいプライバシー法(GDPR)でした。それ以前に主流であったマーケティング手法は、ユーザーデータを提供する会社やそれを活用するデータ連動型の既成ソリューション(例えば、Data Management Platformなど)に依存していました。しかし、GDPRの導入によりこれらの手法が制限され、自社でデータを集める必要性に直面しました。その結果、既存のゲームデータ分析システムであるPlutoを置き換える形で、Google CloudをベースとしたSingle Gamer View(SGV)というシステムが開発され、マーケティングデータ、ユーザーデータ、ゲームデータが一元化されました。 CDPの分析活用・アクティベーション データを統合することで、ユーザーの行動のすべて、つまりメールや広告へのクリック、購入、ゲームプレイからリテンションまでを分析できるようになりました。さらに、ゲームは多くの人にとって生涯にわたる情熱であることも踏まえ、5～10年単位でのユーザーエンゲージメントの分析も行っています。 また、このシステムはマーケティングオートメーションとファンとの関係構築を提供するeCRM CDP機能を実現しています。一方、ソーシャルチャネルやメディアのアクティベーションへは既成のCDPをコネクターとして活用することで対応しています。 AIドリブン・マーケティング CDPの本当の価値は、単にデータを分析するだけでなく、ユーザーエンゲージメントの向上に役立てることにあります。データサイエンスチームでは「旧作ゲームの体験版のレコメンド」、「プレイ中のゲームの継続促進」、「プレイスタイルの理解と適切なメッセージング」などを行っています。 マーケティングオートメーションとフィードバックループ ユーザーデータに各種行動データが紐づくことで、実際のユーザーの行動をトリガーとしたコミュニケーションが自動で行えるようになり、マーケティングオートメーションが実現しました。さらに、メッセージを受け取った人のエンゲージメントが向上したかどうか、例えばプレイを止めたゲームを再度起動したかどうかがフィードバックされ、自動でメッセージが最適化されていきます。 体験版のレコメンド スクエニの旧作のカタログは豊富にありますが、その数はあまりにも多く、ユーザーが遊びたいゲームと巡り合えないということを課題と感じています。その課題の解決のため、今遊んでいるゲームのストーリーをクリアしたことをゲームデータから検知したタイミングで個人に合わせたタイトルの体験版のレコメンデーションを行う仕組みを運用しています。モデルは、レコメンドした体験版が実際にプレイされたかどうかや、プレイ時間をフィードバックとして受け取り、学習し、最適化します。 プレーヤーの継続・復帰の向上 ゲームを購入してもらって終わりではなく、実際にプレイしてもらい、その魅力を体感してもらうことが、ファンとの長期的な関係構築につながると考えています。 そこでプレイスタイルや好みのキャラクター、興味を持つコンテンツを特定し、プレイヤーのニーズに合わせた個別のコミュニケーションを行っています。例えば、PvPを好むプレイヤーにPvPコンテンツの最新情報を提供することで、プレーヤーのエンゲージメントや継続率を高めることができます。実際、このデータドリブンなアプローチを導入した後、特定のゲームにおいて継続・復帰するプレイヤーが大幅に増加しました。 2024年のマーケティングROI測定：Cookie規制とMMM活用 デジタル広告のプライバシー規制が厳しくなり、特にサードパーティCookieの段階的廃止が進む中、マーケティング費用対効果の測定が難しくなっています。その結果、マーケティングミックスモデリング（MMM）が再注目されています。MMMは、様々なマーケティング施策が売上に与える影響を推定し、それぞれの施策の貢献度を評価するために使用される古典的な統計手法です。 社内でデータが一元化されていない場合は、MMMプロジェクトは必要なデータの定義、データ保管場所の特定・手配、データクリーニングや整形など、モデリングの準備段階だけで数か月を要するものでした。 現在はCDP上にデータが統合管理されているため、必要なデータに即座にアクセスし、素早くモデルのPoC作業に着手することができるようになりました。また、Google Cloudを採用していることで、Supermetricsといったデータの一元化ツールや、Google Trendのトレンドデータへのアクセスが容易になり、モデルの精度を高めています。 Single Gamer ViewのCDP機能の技術的なセットアップ 基本的にはGoogle Cloudのサービス、特にサーバーレスと呼ばれるサーバー管理が不要なサービスを選んで構築することで、少人数での運用を実現しています。 データソース: ゲーム、 GA360、メンバーシップ、メール、セールス、ウェブ広告(Supermetrics) パイプライン: Pub/Sub、 Dataflow、 BigQuery ユーザーアクティベーション: Vertex AI (もしくはCI/CD Docker->GKE)からメールやウェブ広告にユーザーリストを共有 チーム間の連携とAIシステムのアジャイルリリース ブランドマネジャー、コミュニティマネジャー、データアナリスト、データサイエンティスト、データエンジニア、データプロテクションまで、異なる部署間の連携体制を作り、組織としてAI活用に挑戦しています。プロジェクトは通常、データアナリストがプロジェクトの提案書を作成しプロジェクトの価値を試算することから始まります。その後、コミュニティマネージャーやブランドチームがレビューし、プレイヤーやコミュニティのニーズに合っているか確認します。

こんにちは、ホシイです。 近年、“オンプレ回帰” という言葉がよく聞かれるようになりました。 人々 (とシステム) は、クラウドからオンプレに帰ってきているのでしょうか? オンプレ回帰という話題において、場合によって話題の中心が必ずしも合致していないこともあるように感じています。大きくは、実際にクラウドからオンプレに移行を実施する・した人の観点と、それを大きな現象として観察している人の観点の差でもあるように思います。 今日は、これをじぶんの考えとしてまとめるべく書き出してみます。 (見聞きした情報の影響が多分に含まれます。いくつか末尾に参考にさせていただいた情報への参照を置いておきます) “オンプレ回帰” は増加している まずここで言うオンプレについて、自前で管理するインフラのことを指しているとします。会社のフロアやサーバールーム、借用して専有管理するデータセンターの一角なども含まれるでしょう。 そのオンプレへ “回帰” ということですから、オンプレに帰ってきているということです。帰ってきた (くる) ということは、その前にどこかに行っていた (いる) ということです。その多くは、クラウド、より正確にはパブリッククラウドからの回帰でしょう。 現在のパブリッククラウド市場は年々成長し、利用者・利用量はまだまだ増加している途上です。数年も逆上ると、パブリッククラウドに行くシステムも今ほど多くはありませんでしたし、戻るにしてもまだ判断が早すぎるタイミングでした。 必然的に、クラウド移行が進行してある程度期間がたった今だからこそ回帰の数もまた増えているという見方もできるでしょう。それが目立って、オンプレ回帰が過剰に・想像以上に増加しているととらえられている面もあるのではないでしょうか。 ここで言うクラウドとは? さてここで、回帰の元である、クラウドについて考えてみましょう。 それらの多くは、上に書いたようにパブリッククラウドだったと思われます。要するに、AWS や Google Cloud、Azure などです。他にもたくさんあります。 それとは別に、プライベートクラウドという区分もあります。これはパブリッククラウド同様に他所で間借りをするものもありますが、オンプレ (に区分される設備) に構築する場合も多く、区分的にはオンプレ側 (もしくはそのもの) と考えるべきでしょう。 ところで、最近はクラウドネイティブという言葉も多く用いられるようになりました。これはシステムの置き場所に関係なくクラウドらしい設計・運用をすることを指す言葉であり、インフラを指しての “クラウドからの移行” のような文脈で使われるものとは違います。後でも触れますが、オンプレ回帰するにあたってもクラウドネイティブは共存できるものです。 回帰の理由 多くがパブリッククラウドからの回帰を指しているとして、その理由は何でしょうか。 以下が多いと考えられます。(また、世間で言われているようです) 費用 セキュリティ・ガバナンス 性能・品質 これらがクラウドへ移行する以前のほうが優れていた、またはクラウドで思ったような改善・効果が得られなかったから回帰するということでしょう。 ここで出てくる問題は、かなり複雑です。 上記はいずれも、クラウドへの移行を試みる際に試算したりプランニングしたりするものですが、移行元での利用方法とおなじような想定をしていなかったかというのがひとつ、重要な確認ポイントです。 たとえば、費用で言うと。オンプレ設備は減価償却期間を定めて、一定の期間で使用する前提の計算をします。その場合、使う量にかかわらず費用がかかっていますので、毎日 100% 使うような使い方がおトクです。しかしクラウドでこれをおなじように見積もってしまうと、数年間そのリソースを専有で使いっぱなしという想定になり、それではクラウドサービスでは非常に高額になってしまいます。 必要なときに必要なだけ使えるのがクラウドのよさなので、本来はそのように想定をつくって計算する必要があります。(とはいえそれが難しいのですが) セキュリティについても同様で、元々が安全な場所からスタートしているオンプレとは違った安全確保の設計が必要になります。ゼロトラストのような考え方はそういったところから生まれたものでしょう。 回帰の結果 さて、どういった理由にせよ、オンプレに帰ってきたとします。 その結果は、クラウド移行の失敗、金銭・資源の喪失、時間の無駄だったのでしょうか? それでは悲しすぎます。 クラウド移行により、得られたものに目を向けてみましょう。それは、たとえば次のようなものでしょう。 アプリケーションの柔軟な構成 すばやいデプロイ 動的スケーリング対応 ままならないインフラへの耐性と運用知見 使用するフレームワーク等のアップデートへの追従 すべてではなくても、クラウド移行のためにこういったことの対応を迫られたのではないでしょうか。そして、これらはパブリッククラウドでしか有効なものというわけではなく、モダンなアプリケーションには必須な機能であり、特徴です。 クラウドでこれらに対応できていれば、オンプレ回帰するときに、これらを持って帰ることができるのです。

※本記事の画像は「 https://logmi.jp/tech/articles/327868 」から引用しています。 睡眠不足のdskです。 いきなりですが、クラウドプロバイダーと聞いて思い浮かぶのって AWS , Azure , GCP が多いと思います。 わたしもそうです。いまはおもいっきり GCP に携わることが多いので、まっさきに viva GCP! と答えてしまうと思います。 そんな中、egressがめちゃくちゃ安い！ が謳い文句(他にもいいとこあるけど)の Linode を使ってみました！ Linode とは Linode はAkamai社が提供する IaaS プラットフォームプロバイダサービスです。「リノード」と読みます。 なぜ名称に「IaaS」がわざわざ付いてるのかというと、マネージドサービスが「現在はほとんどない」んですよね。 なので、「Linode だけでフロントエンドからバックエンドまで構成する」のはちょっと時期尚早感は否めません。 じゃあどういうユースケースがあるのかというと、 (ちょっとした)データ加工と分析 他企業や他チームとのコラボレーション時のワークロード実行環境 負荷試験実行環境 脆弱性診断やセキュリティテスト実施環境 と言った、ロケーションを問わない小規模環境から使ってみるのがいいとおもいます。 メリット まず浮かぶのはコストが安いってことですね。 と言っても ↑ に記載した通り、小規模環境での利用がいいと思っているので、そもそもコストそんなにかかってなさそうやん！という声が聞こえてきそうです。 わたしも Linode が使えそうかという観点でミニマム環境で使ってみたので、コストが安いという実感はまだ得られていません。 よくある「共有/専有CPU」の選択をし、次に「プラン(マシンタイプ)」の選択をするわけですが、プランの中にストレージ(SSD)と転送(egress)が含まれてるんです。 主要クラウドプロバイダーとの価格比較ですが、「4vCPU/8GB」プランにもともと付帯されているストレージと転送量を加味したコストシミュレーションです。 細かい部分は置いておいて、これだけ見ると確かにコストメリットを感じることができますね！ ちなみに今回ベンチマークは取っていません。「どのくらいの性能出るの？」と気になるひともいるとおもうので、その辺は次回にでも。 デメリット やっぱりサービスラインナップの少なさでしょうね。 そもそも主要クラウドプロバイダーとは交わらない層をターゲットにしているのであれば狙い通りなのかもしれませんが。 オンプレや他クラウドからのマイグレーション先として利用する選択肢にはまだ入ってこないとおもいます。 その他 Terraform 使えます。 Terraform サンプルコードも公開されております。

こんにちは! 半年ぶりの執筆となります。nose です。 昨年、とあるゲームタイトルで Web ブラウザ上でプレイできる クラウド体験版 をリリースしました。今回はそのクラウド体験版リリースに纏わる話をしていきたいと思います。 本記事の内容 概要 システム構成 バーチャルパッドについて クラウド体験版をリリースした結果 まとめ ※「バーチャルパッドについて」は オバカム が執筆しています。1 概要 今回ストリーミングで出したゲームは STAR OCEAN THE SECOND STORY R です。 より広く遊んでもらうきっかけづくりとして Web ブラウザでもプレイできるよう他プラットフォームと同時にクラウド体験版を 2023年9月15日 にリリースしました。こちらのクラウド体験版は 2024年3月 にクローズし現在は遊ぶことができません。 システム構成 システム構成としては二つの枠組みに分けられます。 web サイト ゲームストリーミングサービス 1 の部分では主に S3 と CloudFront を使っており、 2 の部分では Ubitus の GameCloud サービスを利用しています。 参考:Ubitusはスクウェア・エニックス『STAR OCEAN THE SECOND STORY R』体験版のクラウド配信をサポート 1 に来たユーザからのアクセスを 2 のストリーミングサービスに受け渡すといった割とシンプルな作りになっています。今回はクラウド体験版ということもありユーザの識別などもしておらずセーブも出来ない作りにしています。構成図としては以下のようになります。

yotaです。 私のチームではCI/CDツールConcourse上でMavenを使ったJavaプロジェクトのビルド環境を構築中です。 この記事はこちらの記事で言及した、 実は後にConnection timed outの根本的な原因が判明したのですが、それは別途投稿します。 にあたるものです。 今回の問題は、MavenによるJavaプロジェクトのビルドが時折Connection timed outでエラーになることでした。 以下のようなエラーですが、対象となるプラグイン、ライブラリは常に同じというわけではありませんでした。 [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M8:test (default-test) on project <プロジェクト名>: Execution default-test of goal org.apache.maven. plugins:maven-surefire-plugin:3.0.0-M8:test failed: Plugin org.apache.maven. plugins:maven-surefire-plugin:3.0.0-M8 or one of its dependencies could not be resolved: Failed to collect dependencies at org.apache.maven.plugins:maven-surefire-plugin:jar:3.0.0-M8 -> org.apache.maven. surefire:maven-surefire-common:jar:3.0.0-M8: Failed to read artifact descriptor for org.apache.maven. surefire:maven-surefire-common:jar:3.0.0-M8: Could not transfer artifact org.apache.maven. surefire:maven-surefire-common:pom:3.0.0-M8 from/to (https://<社内ミラーリポジトリ>): transfer failed for https://<社内ミラーリポジトリ>/org/apache/maven/surefire/maven-surefire-common/3.

はじめに この記事を見つけたけど、後で見ようと思ったそこのあなた！ ぜひ下のボタンから、ハッシュタグ #ハマグリ式 でポストしておきましょう！ こんにちハマグリ。貝藤らんまだぞ。 今回は、ハマグリ式！ 運用しやすい GitHub と Terraform Cloud の設定例 ～Terraform コード付き～ をお届けします！ 番外編って？ ハマグリ式では、下記のようにレベルを設定しています。 初級者：初めてクラウドサービスを利用する人で、基本的な操作（例：ファイルの保存や、サーバーの起動）をインターフェースを通じて行うことができます。また、シンプルなセキュリティルールの設定や、一部の問題のトラブルシューティングに対応できます。 中級者：より深い知識を持ち、コードを用いて操作を自動化したり、より複雑なタスク（例：自動でサーバーの数を増減させる）を行います。また、より高度な監視や、全体のシステム設計と実装について理解があります。 上級者：幅広く深い知識を持ち、大規模で複雑なシステムを設計、実装、維持する能力があります。最先端のテクノロジーを活用し、安全性、耐障害性、効率性を最大化するためのソリューションを提供します。 今回は上記と関係の薄い GitHub、Terraform Cloud についての記事であるため、番外編に分類しています。 ハマグリ式って？ 貝藤らんまが作成するブログ記事のブランド名です。あまり気にせず読み飛ばしてください。 何を書くの？ 以下の通りです。 この記事で書くこと Terraform Cloud 連携のための運用しやすい Terraform HCL 基本コード Terraform Cloud 連携のための運用しやすい GitHub 基本設定 Terraform Cloud の運用しやすい基本設定 それらを実現する HCL コード この記事で書かないこと GitHub と Terraform Cloud の OAuth app 連携 Terraform HCL コードの応用、解説、正しいベストプラクティス GitHub 設定の応用、解説、正しいベストプラクティス Terraform Cloud 設定の応用、解説、正しいベストプラクティス 免責事項 この記事に書かれていることは弊社の意見を代表するものではありません。 この記事に書かれていることには一定の調査と検証を実施しておりますが、間違いが存在しうることはご承知おき下さい。 筆者の専門外の内容については断定を避けておりますが、あらかじめ間違いが存在しうることはご承知おきください。 記事の内容は、記事執筆時点 (2024/2) での情報です。ご承知おきください。 GitHub と Terraform Cloud 連携の基本 クラウドインフラの IaC 管理が一般的になりつつある昨今、コード管理・plan・レビュー・apply という一連の流れはクラウド上で実施したいですよね。

yotaです。 私のチームではCI/CDツールConcourse上でMavenを使ったJavaプロジェクトのビルド環境を構築中です。 （Concourseについては本ブログの別記事を参照ください） その中で、Mavenによる依存ライブラリや各種プラグインのダウンロードがConnection timed outとなり、ビルド全体がエラーになるという事象が発生するようになりました。 以下のようなエラーですが、対象となるライブラリ、プラグインは常に同じというわけではありませんでした。 [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M8:test (default-test) on project <プロジェクト名>: Execution default-test of goal org.apache.maven. plugins:maven-surefire-plugin:3.0.0-M8:test failed: Plugin org.apache.maven. plugins:maven-surefire-plugin:3.0.0-M8 or one of its dependencies could not be resolved: Failed to collect dependencies at org.apache.maven.plugins:maven-surefire-plugin:jar:3.0.0-M8 -> org.apache.maven. surefire:maven-surefire-common:jar:3.0.0-M8: Failed to read artifact descriptor for org.apache.maven. surefire:maven-surefire-common:jar:3.0.0-M8: Could not transfer artifact org.apache.maven. surefire:maven-surefire-common:pom:3.0.0-M8 from/to opd (https://<社内ミラーリポジトリ>): transfer failed for https://<社内ミラーリポジトリ>/org/apache/maven/surefire/maven-surefire-common/3.0.0-M8/maven-surefire-common-3.0.0-M8.pom: Connect to <社内ミラーリポジトリ>:443 failed: Connection timed out (Connection timed out) -> [Help 1] この Connection timed outの原因はすぐに解明できなかったのですが、このときMavenの実行ごとに常にすべてのライブラリをダウンロードする構成になっていました。そこで、都度ダウンロードしないように変更してConnection timed outが起きる機会を減らすこととしました。

みなさん、こんにちは！初投稿の hamachan です。 私は、クラウドの技術で、一例として 急増するユーザアクセスも良い感じで捌く(CM等のプロモーション打つよ～ → どのくらいサーバ増強しておきましょうか？…みたいな議論から不毛だと思ってます。そんな見積もり、とても難しいですよね？) 各種メンテナンスも不要(セキュリティパッチ適用から、バージョンアップ対応などなど面倒くさいのです。) といった、「何もしなくて良い状態」に極力したい人、憧れる人です！ さてさて、今や弊社の複数のオンラインゲームタイトルで、GCPのCloud Runが採用されていますが、今回はそれを初めて導入したときのお話です。 背景など とあるオンラインゲームタイトルで、国産クラウドから、GCPへ移設するお仕事がありました。この際、ユーザ様からのアクセスを受けるフロント部分に関し、別プロダクト(流行りもあってGKE)にしようという流れがあったのですが、結果Cloud Runにしました。これが初めての導入でした。 Cloud Runは冒頭自己紹介部分にも書いた 急増するユーザアクセスも良い感じで捌く 各種メンテナンスも不要 を叶えてくれる可能性があり、私の推しプロダクトでした。 この初導入を実現させたく、ずっとこのCloud Runを触っていた時期があります。プロデューサー, 開発担当, チームメンバらにその良さを説明し、共感してもらい、初導入を実現するには自分で手を動かさないとですよね。 そんなこんなで今回は、 推しプロダクト(今回だとCloud Run)があって、本番環境に導入してみたい その推しプロダクトの良さを関連メンバに伝えたい 開発担当など、自分以外の人が指定したプロダクトを言われたとおり準備するのではなく、一石を投じたい みたいなことを考えている人には刺さるかもしれない内容となっています。 なお、本記事では、TCO（Total Cost of Ownership）の試算や、Cloud Runの説明、構築/導入手順といったものは割愛させていただきます。 ただ、移設前の国産クラウドで稼働していたことあり、アクセス規模とか正確に分かったので、費用見積もりはやり易かったですね。 本題「推しプロダクト(Cloud Run)を関連メンバに伝える手順」 以下のステップで、関連メンバ(プロデューサー,開発担当,チームメンバら)に説明等を行い、口説き落としていきました。 ここから、この「関連メンバ」を『みんなー！』とか『皆』で呼びます。 みんなー！デプロイとか体験してみてー！ まず長いサービス運用の中で生じる、デプロイ作業を皆に体験して貰いました。 体験用のプログラムなどは私の方で準備し、上からコマンドを叩けば、ひととおりの流れが掴める…という体験環境を整備し、以下のように案内しました。 体験用プログラムなど(java,Dockerfileといったもの)は適切な位置に設置済であり、 皆さんに利用の流れを体験してもらうための手順になっています。 最後まで進めれば、ネイティブイメージのビルド→GCRへの格納 →Cloud Runへのデプロイの流れがつかめます。 1. ↓作業ディレクトリに移動します $ cd ~/getting-started.spring/spring-graal-native/spring-graal-native-samples/webflux-netty 2. ↓ネイティブイメージをビルドします $ ./build.sh →以下のような文字列が出ます === Building webflux-netty sample === Packaging webflux-netty with Maven Unpacking webflux-netty-0.

こんにちは、疑り深いホシイです。 複数の機能を組み合わせてシステムを構築するとき、それぞれの機能同士の通信は必要だがその他の通信は禁止したいということはよくあります。たとえば… 開発中のプログラムで、想定している以外の通信が無いことを確認したい 公開されているソフトウェア (OSS や container image 等) をちょっと試してみたいが、その素性が完全には確認できていないので、外部との通信を遮断した環境で実行してみたい 特に後者のような用途では、実行環境ごと隔離できると何かと便利です。今回は Docker を使ってやってみたいと思います。 Docker の実行 option を使用する docker run するときに、--net=none をつけるだけで、container は network から隔離されます。 参考: None network driver ❯ docker run -it --rm --entrypoint=ash --net=none alpine / # ip link show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN qlen 1000 link/ipip 0.

はじめに この記事を見つけたけど、後で見ようと思ったそこのあなた！ ぜひ下のボタンから、ハッシュタグ #ハマグリ式 でポストしておきましょう！ こんにちハマグリ。貝藤らんまだぞ。 今回は、ハマグリ式！ Jira issue 作成君を Python で書いてみた をお届けします！ 初級って？ ハマグリ式では、下記のようにレベルを設定しています。 初級者：初めてクラウドサービスを利用する人で、基本的な操作（例：ファイルの保存や、サーバーの起動）をインターフェースを通じて行うことができます。また、シンプルなセキュリティルールの設定や、一部の問題のトラブルシューティングに対応できます。 中級者：より深い知識を持ち、コードを用いて操作を自動化したり、より複雑なタスク（例：自動でサーバーの数を増減させる）を行います。また、より高度な監視や、全体のシステム設計と実装について理解があります。 上級者：幅広く深い知識を持ち、大規模で複雑なシステムを設計、実装、維持する能力があります。最先端のテクノロジーを活用し、安全性、耐障害性、効率性を最大化するためのソリューションを提供します。 今回は上記と関係の薄い生成系 AI についての記事であるため、番外編に分類しています。 ハマグリ式って？ 貝藤らんまが作成するブログ記事のブランド名です。あまり気にせず読み飛ばしてください。 何を書くの？ 以下の通りです。 この記事で書くこと GPT-4 API を使った Jira issue を作成するプログラム プログラムの拡張案 この記事で書かないこと GPT-4 の解説 python コードの解説 AI やプログラムの精度の検討 プログラムの拡張案の比較検討 免責事項 この記事に書かれていることは弊社の意見を代表するものではありません。 この記事に書かれていることには一定の調査と検証を実施しておりますが、間違いが存在しうることはご承知おき下さい。 筆者の専門外の内容については断定を避けておりますが、あらかじめ間違いが存在しうることはご承知おきください。 記事の内容は、記事執筆時点 (2024/1) での情報です。ご承知おきください。 GPT-4 API を使った Jira issue 作成君を Python で書いてみる 巷で話題の GPT-4 、せっかくなら業務に組み込みたいですよね。

みなさん、こんにちわ！初投稿のドリアです。 2011年にAWSの東京リージョン、2016年にGCPの東京リージョンが開設されてから クラウド環境を利用する機会も増えたのではないでしょうか。 柔軟なインフラリソースの活用に加えて様々なマネージドソリューションが発表される中で クラウドのセキュリティはどうしているの？と気になる方もいると思いますので 本日はクラウドのセキュリティ製品を触ってみたことについて書いてみようと思います。 クラウドのセキュリティといってもどういったものがあるの？ クラウドセキュリティといっても各クラウドが提供している製品や 3rdベンダーが提供している製品、防御範囲も多種多様にあるかと思います。 今回はクラウドプラットフォームが提供している GCPのSCC(Security Command Center)についてポストしようと思います。 ※AWSの類似製品はGuard Dutyというものがあります。 SCCってなーに？ Google Cloud Platform向けのセキュリティとリスク管理製品です。 Security Command Center 検知項目は300超あり、不正なDNSへのアクセスやFWの脆弱性情報、アカウントの異常利用など 様々なセキュリティ情報を検知してくれます。 有効化してみた なんとなく製品は聞いたことある、なんとなく知ってるけど、、、って人も多いと思うので 特定のorg配下で、試しに有効化した際の画面を貼っています。 桁数は伏せますが、大量に検知されることが分かりました。 それもそのはずで、GoogleがGCPプロジェクト作成時に デフォルトで作ってくれるDefalutのネットワークやDefaultのFirewallなど 利用していなくてもSCCが検知してくれるケースも多数ありました。 ※組織ポリシーでdefault類の作成を抑止している場合、その限りではない。 この数を検知し続けると運用が成り立たない 色々と検知してくれるのは良いことではありますが Googleのセキュリティ基準と自分たちのセキュリティ基準は各社異なると思いますので 自分たちが検知したいルールを定めて、各パラメータごとにレベル分けをすることをお勧めします。 参考までに我々がSCCの検出結果をどういったプロダクトでフィルタリングや 検知をしているか、構成を載せておきます。 SCCではいくつかの機能が提供されておりますので、SCC上で各機能の有効/無効 および各プロジェクトで検知する/しないのミュートルールを定義し Cloud Function上で、通知優先度を定めています。 まとめ クラウドセキュリティといった広範囲な単語ではありますが こういったプロダクトを利用することで、ガードレールを敷くことができます。 もちろん当該製品を導入すればセキュリティが完璧というわけではないですが 一つの選択肢として利用することを検討してみてもいいかもしれません。 こんな人におすすめ クラウドセキュリティに大して漠然とした不安がある人 GCPプロジェクト横断でお墨付きを欲してる人 多少なり、クラウドセキュリティとして投資が出来る企業 こんな人はもう少し考えてもいいかも SCCを有効化したら、簡単に何でもしてくれる魔法の杖を探してる人 有効化してから幾多のパラメータと殴り合いが始まる。(もちろん事前設計大事) IPSなどの防御製品を探している人 SCCが担当しているのは不正侵入検知やリスク管理であることから、検知後のアクションはマニュアル対応が必要である。 ミドルウェアの脆弱性まで検知してほしい人 今後スキャンツールとの連携が出てくるかもしれませんが、SCC単体では現時点で対応していない。(と思う)

こんにちは、ホシイです。 機械学習が業務に入り込んで、GPU つきの PC やサーバーを共有機として使用することが増えました。以前から自動テスト等の用途で需要はあったかと思いますが、急速に進んでいるように感じます。 今日は、こうやって増えてきたホストの GPU のみなさんが、元気よく働いている様子を確認しやすくする仕組みを用意してみたいと思います。 Observability に関しては以前、JMX MBean metrics の可視化を試す を書きました。また、Cloud Monitoring で custom metrics を活用する という記事で、CLI output を parse して custom metrics 化についても書いています。 今回もこのあたりの仕組みを使い、custom metrics をつくればできそうだな… と思っていました。nvidia-smi も、よく見る人間に読みやすい形式だけではなく monitoring ぽい出力にも対応しているようですし。 しかし！web 検索していると、やはりみんなホシイと思っているものはすでにつくられているものです。今回はそちらをありがたく利用させていただくことにしましょう。 NVIDIA DCGM Exporter を使用して GPU の monitoring をしてみるサンプル NVIDIA 社が DCGM Exporter という、Prometheus 等に metrics を収集させるためのソフトウェアを提供しています。GitHub 上の repo を確認すると、license は Apache License 2.0 とありました。 冒頭にも書きました 以前の記事 の内容も流用し、Docker compose を使って Prometheus + Grafana とともに この exporter を使い、情報の可視化をしてみましょう。

はじめに この記事を見つけたけど、後で見ようと思ったそこのあなた！ ぜひ下のボタンから、ハッシュタグ #ハマグリ式 でポストしておきましょう！ こんにちハマグリ。貝藤らんまだぞ。 今回は、ハマグリ式！ AWS Linux ログイン RTA をお届けします！ 初級って？ ハマグリ式では、下記のようにレベルを設定しています。 初級者：初めてクラウドサービスを利用する人で、基本的な操作（例：ファイルの保存や、サーバーの起動）をインターフェースを通じて行うことができます。また、シンプルなセキュリティルールの設定や、一部の問題のトラブルシューティングに対応できます。 中級者：より深い知識を持ち、コードを用いて操作を自動化したり、より複雑なタスク（例：自動でサーバーの数を増減させる）を行います。また、より高度な監視や、全体のシステム設計と実装について理解があります。 上級者：幅広く深い知識を持ち、大規模で複雑なシステムを設計、実装、維持する能力があります。最先端のテクノロジーを活用し、安全性、耐障害性、効率性を最大化するためのソリューションを提供します。 ハマグリ式って？ 貝藤らんまが作成するブログ記事のブランド名です。あまり気にせず読み飛ばしてください。 何を書くの？ 以下の通りです。 この記事で書くこと AWS で Linux にログインするための最短手順 この記事で書かないこと AWS VPC のベストプラクティス AWS EC2 のベストプラクティス AWS で Linux にログインするための真の最短手順 免責事項 この記事に書かれていることは弊社の意見を代表するものではありません。 この記事に書かれていることには一定の調査と検証を実施しておりますが、間違いが存在しうることはご承知おき下さい。 筆者の専門外の内容については断定を避けておりますが、あらかじめ間違いが存在しうることはご承知おき下さい。 記事の内容は、記事執筆時点 (2023/12) での情報です。ご承知おき下さい。 Linux ログイン RTA IT インフラで最もスタンダードなリソース、それは Linux であると言ってもよいでしょう。 検証してみたいとき、まずは Linux を起動してログインするところから始まります。

こんにちは、ホシイです。 貧乏性なので、仕事中はたいてい費用のことを考えています。 今回は、機械学習インフラにも関連する記事です。AI に関しては SQUARE ENIX AI 技術ブログ もありますので、ご興味がありましたらぜひご覧ください！ GPU をお安く、好きなときに好きなだけ利用したい AI の話題花盛りの昨今、アプリケーションで GPU を利用する機会も増えてきました。GPU の用途もいろいろとありますが、最近でわたし周辺の需要として特に多いのは、機械学習です。ざっくり言うとタスクに対してパラメーターやデータを与えてある程度の時間、計算処理をするものです (なんでもそうと言えばそうですが)。ここでの問題は、GPU は基本的に高価で購入することに敷居があるうえに、それをホストに組み込んでかつ共有リソースとして利用するというのはなかなか難しいというものです。 今回の記事ではこれをスマートに解決する例をつくってみたいと思います。GKE Autopilot で。 最初は Cloud Run を調べたのですが、通常の Cloud Run では GPU が使えないようでした (GKE node を使えばできそう)。GPU が使える選択肢として考えられる GCE や GKE Standard では、ゼロから scale させる仕組みをつくりたいとなると、追加の工夫が必要そうです。GKE Autopilot では cluster を常時維持する必要はありますが、GPU 含めてリソース管理するシステム費用と考えるとじゅうぶん妥当な費用と感じます。 ※ Vertex AI を使え… という声が聞こえてきますが、ここでは聞こえないこととします。GCP 以外でもいろいろと便利なサービスはあるぞ！というかたは、どこかでお会いしたときに教えてください 🙏 ちなみに今回の記事、かなり類似した内容がこちら → GKE で GPU 使うのめっちゃ簡単 (Google Cloud Uchimaさんの記事) にあるのを観測しております。Autopilot などについてはそちらで詳しく説明されていますので、あわせてご参照ください。 想定アプリケーションシナリオ 今回は、以下の仮想要件向けにソリューションをつくってみましょう。 エンドユーザーには web UI を提供し、その操作に応じて機械学習の処理を実行するアプリケーションとします。このとき、リクエストを受け付けるために web アプリケーションの Pod は常時起動しておく必要がありますが、機械学習の処理は GPU を使用するため、それと同居するとクラウド費用が高額になってしまいます。ということで、機械学習処理は web からは分割して、使うときだけ起動するようにします。

はじめに こんにちは、情報システム部 SRE 橋本です。 今回はQiitaのNew Relic Advent Calendar 2023の14日めの記事として書きました。 担当しているシステムでサービス監視やSLI/SLOを用いて、どのようにしてサービスの健全性を知るのか？というのを考えていく中でNew Relicが課題解決に繋がるかもしれないと思い、直近でチームで評価を行いました。 この記事では、どのような課題感を持っていたのかというのと、その課題感に対して当該プロダクトがどう刺さったのかを簡単にお話したいと思います。 サービスとその信頼性 BtoBやBtoCなどで違いはあると思いますが、サービスがあり（中央）、サービスの提供者（下）、サービスを利用するお客様などの利用者（上）という3つの関係性で整理できます。 この関係性の中で、我々は利用者が正常にサービスを利用できているかを知りたいという欲求があります。 伝統的な監視 そこで自分たちのシステムに対して監視を行うことになります。PrometheusやZabbix、Sensu、Munin、Cacti、Nagios、MRTG、etc…といろんなツールがありますが、メトリクスを取得してグラフ化したりゲージやカウンターの値をもとに監視やパフォーマンス計測をしたりします。また、ログもどこかに集約したり、もしくはサーバに直接入ってエラーが発生したら確認したりします。 しかし、これら伝統的な監視だけで正しくサービス適用が出来ているかを判断することは実は難しいのです。CPU使用率が高ければ、エラーが少し出たらお客様が本当に困るのでしょうか？ 困っているかもしれないし、困っていないかもしれません。これだけでは分からないのです。 夜中にアラートで起こされたエンジニアにとって、「誰も困っていないかもしれないからアラート対応しません」 とは言い切れないのです。 スパイクして落ち着いた形跡が分かるメトリクスのグラフを貼ってログをチャットでシェアして 「静観します」 とだけ書いて再び眠りについた経験があるのではないでしょうか。 また、大きな障害が万が一発生した場合、エラーが出ているがどれだけの深刻度合いなのかが即時に判断できず、エスカレーションをどこまで行うべきか迷ったことがあるかもしれません。 Site Reliability Engineering そこで細かなメトリクスやログを用いた監視ではなく、SLI/SLOを用いたプラクティスでサービスの正常性を測ろうという話が出てきます。 SLI/SLOと、利用者がどのようにサービスを利用しているかを現す ユーザー・ジャーニー（User Journey） を関連付けて考えることでサービスの正常性を計測することが、SRE（Site Reliability Engineering）のプラクティスの一つであると捉えています。 しかし、このSLI/SLOの仕組みを作る取り組みは一筋縄ではいきません。大変なのです。 監視の仕組みを作り、グラフを作り、新しい仕組みができれば追加し、メトリクスを集計するエージェントを入れ、ログのフォワーダーを仕込んで、集約する仕組み（アグリゲーター）の設定をして、サービスの負荷が高まると監視やログを集約する仕組みが詰まり、スケールさせて負荷対策をして、ダッシュボードを作っていたら一週間の時間がいつの間にか溶けており、気がついたらコストの問題や、そもそも活用されていないという根本課題が出てきて最初の仕組みづくりに戻る… そして、これらの監視の仕組みをもとにSLIをUJ（User Journey）を分析して定め集計し、それもダッシュボードにして運用しながら妥当性を見極めつつBizと会話をしてSLOを決めて、それに従って運用をする… 最後の運用までたどり着けるイメージが湧きません。 システムが初期段階から徐々に成長していくのであれば徐々に成長させていけるかもしれません。また、すでに大きなSLI/SLOを取り扱う仕組みがあり、それらに乗っかる形であればもちろん問題ないかと思います。 しかしながら、まったく白紙の状態から、比較的大きなシステムに対してSREのプラクティスを適用するのは上記の大変さを乗り越える必要があり、とてもコストがかかってしまうものであると考えています。作れたとしても維持するコストや継続的・組織的に担保するのも多くの場合困難を伴うものと思われます。 大事なのはサービスが正常かを知ることであり、知るための仕組みを作り・維持することではないのですが、 “知るための仕組み"そのものが重量級 なものになりがちであるが故に目的と手段が交叉してしまいがちであろうと思います。自身の過去の苦い経験でもありますし、今現在も進行形の課題でもあります。 “運用のための運用"にならないために 我々の環境ではシステムに対する 可観測性（オブザーバビリティ） を確保するためにGoogle Cloudのプロダクトや独自に開発された集計の仕組みを利用しています。 Google Cloudのこれらは、比較的簡単に使い始めることが出来て、且つ、安価でもあるので（一部工夫が必要ですが）とても使いやすいプロダクトが揃っていると思います。 しかし、先に述べた仕組みづくりや維持の負担がシステム規模に比して大きくなってきており、 “運用のための運用” になってきてしまっている状況が見えつつありました。 また、最後の “SLI/SLOの運用"というゴールまでが長くなりそう に思われました。 少し前置きが長くなりましたが、以上までを背景としてNew RelicをPoCしてみました。 導入ポイント 我々の環境はGKE/コンテナ環境のフロントエンドと、VMで構成されるデータストアサーバがあります。

みなさん、こんにちは！ そろそろ新卒と名乗るのもおこがましい気がするオバカムです。 オバカムがいるチームでは、インフラの管理にTerraform Cloudを使っています。 Terraform Cloudから管理対象のリソースへのアクセスには(当然ながら)認証情報が必要になります。 昨今、永続的な認証情報はセキュリティリスクとして受け取られるようになってきているため、例えばOIDCを利用して一時認証を使うなど、永続的な認証情報を避ける方法が重要視され始めています。 というわけで今回はTerraform CloudとOIDCにまつわる小ネタをいくつか紹介します！ 今回は管理リソースはAWSとGoogle Cloudにあることを前提とします。1 OIDCを利用したTerraform Cloudでのリソース管理の概略図は以下を想定します。 以下のような流れで一時的な認証情報を取得します。 Terraform CloudのWorkspaceでPlan/Applyをする際に各クラウドのIAMサービス2にアクセスキーを要求 各クラウドのIAMサービスはTerraform CloudのOpenID ProviderにWorkspaceの情報を問い合わせ OpenID ProviderはWorkspaceの情報をIDトークンとして各クラウドのIAMサービスに提供 各クラウドのIAMサービスは提供されたIDトークンをもとにアクセス権限を設定し、期限付きのアクセスキーを生成し提供 OIDCを利用してTerraform Cloudからリソースに一時認証でアクセス OIDCを介してTerraform Cloudが動的認証情報を得るにはいくつかのステップを踏む必要があります。 各クラウドにTerraform CloudのOIDC Providerを認識してもらう 各クラウドでのアクセス権限設定 Terraform CloudのWorkspaceの環境変数設定 順を追って説明していきます。 管理クラウド側に利用するOIDC Providerを設定 まずは管理対象のクラウドに利用するOIDC Providerを認識してもらいましょう。 OIDC Providerの認識部分でどちらも抑えておくべきポイントは以下です。 Issuer(OIDC ProviderのURL)を指定 Terraform Cloudではhttps://app.terraform.io Audience(OIDC Providerが認証情報を発行する対象)の指定 AWSではaws.workload.identity Google Cloudではhttps://iam.googleapis.com/projects/{Project ID}/locations/global/workloadIdentityPools/{Workload Identity Pool Name}/providers/{Provider Name} 各クラウドでの設定を設定画面のスクリーンショットを出しながら説明します。 今回はすべてコンソールから設定します。 AWS コンソールからIAM>ID プロバイダと進み、プロバイダを追加ボタンをクリック プロバイダの各種設定を行う プロバイダのタイプはOpenID Connectを選択 プロバイダのURLにhttps://app.

はじめに この記事を見つけたけど、後で見ようと思ったそこのあなた！ ぜひ下のボタンから、ハッシュタグ #ハマグリ式 でツイートしておきましょう！ こんにちハマグリ。貝藤らんまだぞ。 今回は、ハマグリ式！ VPC 「など」の設定項目をわかりやすくざっくり解説する ～AWS SDK for Python (Boto3) コードもあるよ～ をお届けします！ 初級って？ ハマグリ式では、下記のようにレベルを設定しています。 初級者：初めてクラウドサービスを利用する人で、基本的な操作（例：ファイルの保存や、サーバーの起動）をインターフェースを通じて行うことができます。また、シンプルなセキュリティルールの設定や、一部の問題のトラブルシューティングに対応できます。 中級者：より深い知識を持ち、コードを用いて操作を自動化したり、より複雑なタスク（例：自動でサーバーの数を増減させる）を行います。また、より高度な監視や、全体のシステム設計と実装について理解があります。 上級者：幅広く深い知識を持ち、大規模で複雑なシステムを設計、実装、維持する能力があります。最先端のテクノロジーを活用し、安全性、耐障害性、効率性を最大化するためのソリューションを提供します。 ハマグリ式って？ 貝藤らんまが作成するブログ記事のブランド名です。あまり気にせず読み飛ばしてください。 何を書くの？ 以下の通りです。 この記事で書くこと AWS VPC 「など」の基本的な設定項目がどういうものか AWS VPC 「など」の設定項目をとりあえずどうすればいいか AWS VPC を作成する AWS SDK for Python (Boto3) コード この記事で書かないこと AWS VPC 「など」のすべての設定項目がどういうものか AWS VPC 「など」の設定項目の選び方 AWS VPC 「など」の設定項目の応用 AWS VPC 「など」のベストプラクティス AWS VPC 「など」と AWS 他サービスとの連携 Python コードの解説 免責事項 この記事に書かれていることは弊社の意見を代表するものではありません。 この記事に書かれていることには一定の調査と検証を実施しておりますが、間違いが存在しうることはご承知おき下さい。 筆者の専門外の内容については断定を避けておりますが、あらかじめ間違いが存在しうることはご承知おき下さい。 記事の内容は、記事執筆時点 (2023/11) での情報です。ご承知おき下さい。 AWS VPC 「など」の設定項目をざっくり解説する AWS で最も初めに触るサービスといえば VPC や、サブネット、ルートテーブルだと思います。

こんにちは、ホシイです。 みなさんは、どのように Kubernetes を活用されていますか。 そもそも Windows container とは 以前に、Docker でやってみる Windows container という記事を書きましたが、ここにいらしたあなたはもしかして、ご覧いただけたりしていますでしょうか。 ふだん Docker を使って container を利用しているというと、たいていは Linux application の利用ではないでしょうか。実は Windows container も同様に Docker (for Windows) で利用ができます。というのが前回の記事の内容でした。 今回は、Kubernetes から Windows container を利用してみましょう。 何のために? 応用・用途としては Windows でしか提供されていないソフトウェアを使用して CI job・batch 処理のようなものを実行したい、Windows application の build がしたいなどが考えられます。 具体的には Visual Studio であるとか、… いろいろありそうですね。 やってみよう GKE + Terraform でやってみます。 cluster の部分は特別なことはないので node pool の部分のみ抜粋します。ひとつの cluster に、Linux と Windows の node pool を混在させることができます。 設定内容は一通り確認して、service account などの部分は用途・必要に応じて調整してください。

はじめに この記事を見つけたけど、後で見ようと思ったそこのあなた！ ぜひ下のボタンから、ハッシュタグ #ハマグリ式 でツイートしておきましょう！ こんにちハマグリ。貝藤らんまだぞ。 今回は、ハマグリ式！ EC2 の設定項目をわかりやすくざっくり解説する ～AWS SDK for Python (Boto3) コードもあるよ～ をお届けします！ 初級って？ ハマグリ式では、下記のようにレベルを設定しています。 初級者：初めてクラウドサービスを利用する人で、基本的な操作（例：ファイルの保存や、サーバーの起動）をインターフェースを通じて行うことができます。また、シンプルなセキュリティルールの設定や、一部の問題のトラブルシューティングに対応できます。 中級者：より深い知識を持ち、コードを用いて操作を自動化したり、より複雑なタスク（例：自動でサーバーの数を増減させる）を行います。また、より高度な監視や、全体のシステム設計と実装について理解があります。 上級者：幅広く深い知識を持ち、大規模で複雑なシステムを設計、実装、維持する能力があります。最先端のテクノロジーを活用し、安全性、耐障害性、効率性を最大化するためのソリューションを提供します。 ハマグリ式って？ 貝藤らんまが作成するブログ記事のブランド名です。あまり気にせず読み飛ばしてください。 何を書くの？ 以下の通りです。 この記事で書くこと AWS EC2 の基本的な設定項目がどういうものか AWS EC2 を作成する AWS SDK for Python (Boto3) コード この記事で書かないこと AWS EC2 のすべての設定項目がどういうものか AWS EC2 設定項目の選び方 AWS EC2 設定項目の応用 AWS EC2 と AWS 他サービスとの連携 python コードの解説 免責事項 この記事に書かれていることは弊社の意見を代表するものではありません。 この記事に書かれていることには一定の調査と検証を実施しておりますが、間違いが存在しうることはご承知おき下さい。 筆者の専門外の内容については断定を避けておりますが、あらかじめ間違いが存在しうることはご承知おきください。 記事の内容は、記事執筆時点 (2023/10) での情報です。ご承知おきください。 AWS EC2 の設定項目をざっくり解説する AWS で最も基本的なサービスといえば EC2 だと思います。

はじめに こんにちは、クラウドエンジニアの査です。最近はGCP関連のインフラ、特にGKEやKafkaの構築、メンテナンスと監視周りの業務を担当しています。 本日は、以下の構成図のように、Kafkaから収集したメトリクスを利用して、KubernetesのHPAを制御し、アプリケーションのパフォーマンスを自動的に調整する方法を解説したいと思います。 Kubernetesを使用してコンテナ化されたアプリケーションをデプロイする際、アプリケーションの負荷やトラフィックの変動に柔軟に対応できることが重要です。そのために、Kubernetesクラスター内のアプリケーションを自動的にスケーリングできるHorizontal Pod Autoscaler（HPA）というKubernetesの強力な機能があります。 Kafkaは、分散メッセージングシステムとしての優れた性能と信頼性を提供する一方、トラフィックの変動に適応できるスケーリングメカニズムが求められます。 利用した技術の一覧 Kafka_exporter kafkaクラスターのメトリクスを収集するためのexporter Custom-prometheus GKE用prometheusエンジン、デプロイされたexporterからメトリクスを定期的に取得し、Monarchに保存することが可能 Monarch Monarch は、すべての Prometheus データを 24 か月間、追加費用なしで保存するデータベース Stackdriver-adapter カスタム指標をHPAに利用させられるようにするアダプター HPA 管理対象となるPodの数を、指定したメトリクス（例えばCPU使用率）に基づいて自動的にスケールさせる 実装例と注意点 Kafka_exporter SystemサービスとしてKafkaクラスターに実装されます。 注意点 GKEのPodのcidrからのTCPアクセスをFirewallで許可する必要があります(デフォルトのポート: 9308)。 Custom-prometheus gkeでprometheus-engineを実装し、prometheusのscrape_configsに下記の例のように設定します。 apiVersion:v1kind:ConfigMapmetadata:namespace:gmp-publicname:custom-prometheusdata:config.yaml:|global: scrape_interval: 30s scrape_configs: - job_name: kafka-exporter static_configs: - targets: ['kafka:9308']custom-prometheusのGUIのstatus → targetで、kafka-exporterのステータスがUPであればOK。 Stackdriver-adapter 注意点 カスタムAPIサービスを作成するには、Control Planeからstackdriver-adapterからのアクセスが必要なので、Firewall RuleにControl PlaneのcidrからnodeへのTCPアクセス(ポート:443)を許可する必要があります stackdriver-adapterはサービスアカウントcustom-metrics-stackdriver-adapterを作成し、利用するが、デフォルトでは権限がないため、403エラーが発生する。解決方法として、 custom-metrics-stackdriver-adapterにGCPのサービスアカウント（例えば stackdriver-adapter-wi@<project_id>.iam.gserviceaccount.com）とバインドし、roles/monitoring.viewerの権限を付与します 実装が上手くいけば、以下のとおりにK8sにカスタムAPIサービスが３つ作成されます。 custom.metrics.k8s.io/v1beta1 custom.metrics.k8s.io/v1beta2 external.metrics.k8s.io/v1beta1 下記のコマンドでカスタムメトリクスのAPIを確認できます。