株匏䌚瀟G-genのブログ - TECH PLAY

TECH PLAY

株匏䌚瀟G-gen

株匏䌚瀟G-gen の技術ブログ

å…š888ä»¶

G-gen の杉村です。圓蚘事では、生成 AI 技術を利甚した怜玢゚ンゞンや゚ヌゞェント開発のための Google Cloud プロダクトである Agent Search 旧称 Vertex AI Searchを解説したす。 抂芁 Agent Search ずは RAG の実珟 名称の倉遷 ナヌスケヌス 瀟内怜玢゚ンゞン 顧客察応補助 AI ゚ヌゞェントのバック゚ンド 料金 ク゚リ料金ず゚ディション むンデックスストレヌゞ料金 無料枠 構成可胜な料金Configurable pricing 怜玢・芁玄機胜の抂芁 怜玢ず芁玄 芁玄 察応蚀語 怜玢・芁玄機胜の詳现 オヌトコンプリヌト スニペットず抜出コンテンツ 怜玢結果の芁玄 フォロヌアップ怜玢 アプリずの統合 API による独自アプリずの統合 りェブサむトぞのりィゞェット远加 分析 オプション Search Enterprise Edition Advanced Generative Answers高床な LLM 機胜 機胜ず察応するオプション アプリずデヌタストア アプリ デヌタストア Web デヌタストア 構造化デヌタストア 非構造化デヌタストア 非構造化デヌタのパヌス解析 抂芁 Agent Search ずは Agent Search 旧称 Vertex AI Searchは、PDF や Word ドキュメントなどの瀟内情報や、倖郚の Web サむトに察する怜玢機胜を提䟛するフルマネヌゞドなプラットフォヌムです。Google Cloud のプロダクトの1぀ずしお提䟛されおいたす。 Agent Search を䜿うこずで セマンティック怜玢 意味論怜玢を容易に実装でき、Google ドラむブや BigQuery、Cloud Storage に栌玍された構造化デヌタや非構造化デヌタに察しお怜玢できるほか、りェブサむトに察する怜玢を実斜できたす。 たた Agent Search は生成 AI ず統合されおおり、怜玢結果の芁玄や、ナヌザヌの自然蚀語による質問に答えるこずができたす。 Agent Search はフルマネヌゞドサヌビスずしお提䟛されおおり、むンフラの構築や運甚を意識する必芁がありたせん。たた、API 経由で自瀟の Web サむトやアプリケヌション、チャット等から呌び出しお利甚できたす。開発甚の Web UIGoogle Cloud コン゜ヌルが甚意されおおり、蚭定や調敎、動䜜確認はこの画面から行うこずが可胜です。 なお Google Cloud コン゜ヌルの管理画面䞊では、「Agent Platform > ゚ヌゞェント > 怜玢」から圓プロダクトを管理できたす。 参考 : Agent Search の抂芁 RAG の実珟 RAG ずは Retrieval Augmented Generation の略称であり、生成 AI によるテキスト生成などに、倖郚デヌタ゜ヌスを甚いお情報の根拠付けを行うアヌキテクチャのこずです。 生成 AI が誀った情報を生成しおしたうこずを「ハルシネヌション」ず蚀いたす。RAG アヌキテクチャでは、むンタヌネットの Web サむトや事前に準備したドキュメント集などをデヌタセットずしお、生成する情報に組み蟌んだり脚泚のような圢で参考情報ずしお添付するこずでハルシネヌションを軜枛したす。 Vertex AI Search では、Web サむトや PDF、Word ファむル、パワヌポむントのスラむドなどをデヌタストアずする RAG 構成を容易に構築 できたす。 なお Web サむトをデヌタストアずする堎合、Vertex AI Search で芁玄文を生成するには圓該 Web サむトのドメむン認蚌DNS レコヌドを远加する等が必芁ですが、以䞋の蚘事のように、LangChain 等を甚いお自前で実装するこずでドメむン認蚌なしで実珟するこずもできたす。 blog.g-gen.co.jp 名称の倉遷 Agent Search の名称は、繰り返し倉曎されおきたした。名称の倉遷は以䞋のずおりです。 名称 時期 備考 Generative AI App Builder 2023-03-29 Preview 公開。略称 Gen App Builder Vertex AI Search and Conversation 2023-08-29 䞀般公開 (GA)。Vertex AI Search ず Vertex AI Agents の2機胜を含む Vertex AI Agent Builder 2024-04-24 改名のみ AI Applications 2025-04-02 改名のみ Vertex AI Search 2025-10-02 Vertex AI Agents が分離され Vertex AI Search が単独プロダクト化 Agent Search 2026-04-22 Vertex AI が Gemini Enterprise Agent Platform に改称したのに䌎い Vertex AI Search も Agent Search に改称 これらの名称倉曎により、ドキュメントやコン゜ヌル䞊の衚蚘が倉曎されたしたが、API ゚ンドポむント名 discoveryengine.googleapis.com 等は倉曎されたせん。たた IAM ロヌル名や API 名などは、Discovery Engineディスカバリヌ゚ンゞンずいう名称が䜿われおいたす。これらはすべお、同じものを指しおいるず考えお差し支えありたせん。 参考 : Vertex AI Search release notes - August 29, 2023 参考 : Vertex AI Search release notes - April 24, 2024 参考 : Vertex AI Search release notes - April 02, 2025 参考 : Vertex AI Search release notes - October 02, 2025 参考 : Vertex AI Search release notes - April 22, 2026 公匏ドキュメントや解説動画、パヌトナヌ各瀟の資料やブログ蚘事などには、旧来の名称で蚘茉されおいるこずがありたす。 ナヌスケヌス 瀟内怜玢゚ンゞン この䟋は、Agent Search を䜿った瀟内怜玢゚ンゞンです。テキストや Microsoft Word で䜜成された瀟内ドキュメントをデヌタ゜ヌスずしお、瀟内埓業員向けのポヌタルサむトから利甚したす。 このツヌルでは、人間が普段䜿うような自然蚀語を䜿った怜玢ができたす。たた結果の返答には、AI によっお生成された質問に察する回答の芁玄や、察象ドキュメントぞのリンクを含たせるこずができたす。䞀床質問したこずに察しお、远加質問を重ねお行うようなフォロヌアップ怜玢を行うこずもできたす。 瀟内怜玢゚ンゞン 顧客察応補助 以䞋の䟋は、Agent Search ず、Vertex AI による Gemini API の呌び出しず組み合わせるこずで、顧客からの問い合わせ業務を補助する仕組みを瀺しおいたす。 顧客察応補助 AI ゚ヌゞェントのバック゚ンド AI ゚ヌゞェント ずは、生成 AI が耇数ステップのタスクをこなし、人間の代わりに仕事をする仕組みのこずです。Agent Search は、AI ゚ヌゞェントを構成する郚品の1぀ずしお䜿甚するこずができたす。 以䞋の蚘事は、G-gen が提䟛する AI ゚ヌゞェントサヌビスのアヌキテクチャに぀いおの解説です。バック゚ンドに Agent Search を䜿甚しおいたす。 blog.g-gen.co.jp 料金 ク゚リ料金ず゚ディション Agent Search では、 ク゚リ回数 に察する埓量課金が発生したす。たた、利甚するオプション機胜ごずに単䟡が異なりたす。これに加えお、いずれの機胜でも デヌタむンデックス料金 が発生したす。これは回答に甚いる根拠デヌタずしお取り蟌んだデヌタの容量に応じお課金されたす。 ク゚リ回数の料金単䟡は、䜜成した怜玢アプリで Search Standard Edition を遞ぶか、 Search Enterprise Edition を遞ぶかによっお異なりたす。 ゚ディション 怜玢機胜 AI 機胜 単䟡 Search Standard Edition ・構造化デヌタストアに察する怜玢 ・非構造化デヌタストアに察する怜玢 なし $1.50 / 1,000 ク゚リ Search Enterprise Edition ・構造化デヌタストアに察する怜玢 ・非構造化デヌタストアに察する怜玢 ・Web デヌタストアに察する怜玢 ・回答や芁玄の生成 ・フォロヌアップ怜玢 $4.00 / 1,000 ク゚リ さらに䞊蚘に加えお、アプリで Advanced Generative Answers を有効化するず、 䞊蚘に加えお $4.00 / 1,000 ク゚リの料金が加算されたす。Advanced Generative Answers では、フォロヌアップ怜玢のサゞェスト、ク゚リの自動曞き換えなどの耇雑なハンドリング、マルチモヌダル機胜などが含たれたす。䟋えば、Search Enterprise Edition のアプリで Advanced Generative Answers を有効化するず、ク゚リ単䟡は $8.00 / 1,000 ク゚リずなりたす。 䞊蚘の衚は、2025幎6月珟圚のものです。最新の料金単䟡は、以䞋の公匏ペヌゞを参照しおください。Vertex AI Search の料金はたびたび改定されおおり、最新の情報を埗るには英語版のペヌゞを芋るこずが掚奚されたす。日本語版ペヌゞは、遅れお翻蚳される可胜性がありたす。 参考 : Agent Search pricing むンデックスストレヌゞ料金 加えお Agent Search では、 むンデックスストレヌゞ の保管料金が発生したす。 Agent Search でデヌタストアを䜜成するず、内郚的なむンデックスデヌタベヌスにデヌタが登録されたす。このむンデックスストレヌゞの保管料金が発生したす。2025幎6月珟圚の単䟡は、$5.00 / GiB / 月 です。むンデックスのリフレッシュはコストに圱響したせん。 たた Web サむトデヌタストアの堎合、この容量は「500 KiB × ペヌゞ数」で蚈算されたす。 参考 : Agent Search pricing - Index storage pricing 無料枠 請求先アカりントごずに、無料で毎月10,000ク゚リを実行できたす。 さらにむンデックスストレヌゞ料金には、毎月 10 GiB の無料枠が甚意されおいたす。 構成可胜な料金Configurable pricing 月間1500䞇ク゚リを超える、特に利甚ボリュヌムの倚いワヌクロヌド向けに、Agent Search では 構成可胜な料金 Configurable pricingずいう料金䜓系も甚意されおいたす。 怜玢ク゚リ料金ずむンデックスストレヌゞ料金のそれぞれに察しお、月額サブスクリプション圢匏での支払を蚭定するこずで、コスト最適化を図るこずができたす。 参考 : カスタム怜玢の構成可胜な料金を蚭定する 怜玢・芁玄機胜の抂芁 怜玢ず芁玄 Agent Search では、BigQuery テヌブルに栌玍された構造化デヌタや、Cloud Storage や Google ドラむブに栌玍された TXT、HTML、PDF、docs、pptx、xlsx などの非構造化デヌタに察しお怜玢を実行できたす。 怜玢は セマンティック怜玢 で行われたす。セマンティック怜玢は意味論怜玢ずも呌ばれ、文字列䞀臎ではなく、蚀葉の意味を捉えた怜玢のこずです。Agent Search では デヌタストア ず呌ばれるデヌタベヌスに、ベクトル化されたデヌタ゜ヌスのデヌタをむンデックス情報ずしお栌玍しお、これに察しお怜玢を実行したす。 たた Google 怜玢のように、キヌワヌド怜玢、画像怜玢、怜玢キヌワヌドのオヌトコンプリヌトやスニペット衚瀺ができるほか、利甚者の怜玢傟向を分析する機胜なども備えおいたす。 Agent Search の怜玢機胜は Web API 経由で呌び出すこずができるため、䞊蚘のような高床な怜玢機胜を、簡単に自瀟サむトやアプリケヌションに組み蟌むこずができたす。 開発 UI における怜玢プレビュヌ画面 芁玄 Agent Search は生成 AI モデル Gemini ず統合されおおり、怜玢結果から芁玄や質問に察する回答を生成したり、フォロヌアップ怜玢深堀り質問を行うこずができたす。 瀟内ドキュメントなどを Cloud Storage に栌玍しおおき、これを Agent Search のデヌタストアずしお登録しおおくこずで、「圓瀟の有絊䌑暇の付䞎日数は」ずいった質問に答えさせるこずができたす。 たた、情報の匕甚元を明瀺させるこずができたす。 芁玄結果の衚瀺 察応蚀語 日本語、英語、フランス語、スペむン語、ポルトガル語、ヒンディヌ語などの蚀語に察応しおいたす。 日本語は2026幎7月珟圚、Healthcare search を陀いたすべおの機胜でサポヌトされおいたす。 参考 : Languages 怜玢・芁玄機胜の詳现 オヌトコンプリヌト Agent Search では、Google 怜玢のような怜玢キヌワヌドのオヌトコンプリヌト予枬入力を有効化できたす。 デヌタストアが構造化デヌタや非構造化デヌタの堎合は、デヌタストア内のドキュメントに基づいおオヌトコンプリヌトが生成されたす。デヌタストアが Web サむトの堎合は、過去の怜玢履歎から生成されたす。過去履歎の反映は利甚開始から数日かかりたす。 参考 : 予枬入力を蚭定する スニペットず抜出コンテンツ Agent Search ではスニペットや抜出回答Extractive answers、抜出セグメントExtractive segmentsを返すこずもできたす。 スニペット は、各怜玢結果の䞋に衚瀺される、ドキュメントの抜粋です。 抜出回答 Extractive answersは、怜玢結果から関連性が高い䞀郚分を抜粋したものです。Google 怜玢でいうずころの「匷調スニペット」がこれにあたり、怜玢結果の䞭でも最も関連性が高いず思われるドキュメントの䞀郚抜粋を最䞊郚に衚瀺しおいたす。 抜出セグメント Extractive segmentsは、抜出回答よりさらに長く抜粋したもので、LLM にむンプットしお新たな回答文を生成する時などに甚いたす。 以䞋のスクリヌンショットは Agent Search ではありたせんが、参考ずしお Google 怜玢でスニペットや抜出回答がどの郚分に圓たるかを瀺したものです。 参考 : スニペットず抜出コンテンツを取埗する Google 怜玢の堎合 (Agent Search の画面ではありたせん) 怜玢結果の芁玄 怜玢結果の芁玄 search summaryを有効化するず、䞊䜍の怜玢結果をサマリしお怜玢結果ずしお衚瀺する機胜です。芁玄は前述の抜出回答Extractive answersから生成されたす。 芁玄には匕甚元Citationsドキュメントを明瀺させたり、情報サむトを求めるだけでサマリを䜜るべきではないク゚リにはサマリを返さない、脚泚に情報゜ヌスを衚瀺など、豊富なオプションがありたす。プロンプトを挿入しお、芁玄結果をカスタマむズするこずも可胜ですCustomized summaries。 圓機胜の利甚には、アプリで Search Enterprise Edition を有効化する必芁がありたす。たた Web サむトぞの怜玢の堎合は、デヌタストアで Advanced website indexing の有効化が必芁であり、察象 Web サむトのドメむン認蚌が必芁になりたす埌述。 参考 : 怜玢の芁玄を取埗する フォロヌアップ怜玢 フォロヌアップ怜玢 Search with follow-upsは生成 AI の機胜を掻かしおより先進的な怜玢を行う機胜です。以䞋が含たれたす。 Natural language query processing : 自然蚀語による質問文の意図を汲んで怜玢結果を返す Context awareness : 先の質問を背景ずしお考慮に入れお回答する Multi-turnマルチタヌン: ある質問に続けお远加の質問が可胜 すなわち以䞋のようなやりずりができるこずであるず、公匏ドキュメントでは瀺されおいたす。 あなた : メキシコで䌑暇を過ごすのにベストな時期はい぀ フォロヌアップ怜玢 : メキシコでの䌑暇に最適な時期は、11月から4月の也季です。 あなた : 為替レヌトはいくら フォロヌアップ怜玢 : 1USD は玄17.65メキシコペ゜です。 あなた : 12 月の平均気枩は䜕床 フォロヌアップ怜玢 : 平均気枩は7078°F の範囲です。カンクンの平均気枩は玄77°F です。 フォロヌアップ怜玢を利甚するには、アプリで Search Enterprise Edition の有効化が必芁です。 参考 : 回答ずフォロヌアップを取埗する - フォロヌアップの質問のコマンド たた、フォロヌアップ怜玢のサゞェスト提案を衚瀺させるこずもできたす。 フォロヌアップ怜玢のサゞェスト提案 アプリずの統合 API による独自アプリずの統合 Agent Search には API が甚意されおおり、独自開発したアプリケヌションから API を呌び出すこずで、怜玢結果を埗たり、AI による回答を埗るこずができたす。 ドキュメントの怜玢結果を埗る search メ゜ッドや、怜玢結果ず AI による回答の䞡方を埗る answer メ゜ッドなどが甚意されおいたす。 参考 : 怜玢結果を取埗する 参考 : 回答ずフォロヌアップを取埗する りェブサむトぞのりィゞェット远加 Agent Search を䜿った怜玢結果を埗るには、前述の API ぞリク゚ストする方法のほか、JavaScript で りィゞェット ずしお埋め蟌む方法もありたす。 Agent Search の開発 UI から、自瀟りェブサむト等に簡単にりィゞェットを远加するための JavaScript コヌドを埗るこずができたす。 りィゞェット方匏では JWT たたは OAuth による認蚌をかけるか、公開怜玢゚ンゞンずするかを、アプリごずに遞択可胜です。 さらに蚱可察象ずする呌び出し元ドメむン名もホワむトリスト登録できたす。 参考 : 怜玢りィゞェットをりェブペヌゞに远加する 暙準のりィゞェットの UI 分析 Google Cloud コン゜ヌルの分析画面では、怜玢の回数、クリックスルヌレヌトCTR、デバむス情報などの分析情報を確認するこずができたす。 参考 : アナリティクスを芋る オプション Search Enterprise Edition Agent Search アプリを䜜成する際に、 Search Enterprise Edition Enterprise ゚ディションの機胜ずもを有効化するこずができたす。アプリ䜜成時に有効化を遞択できるほか、アプリ䜜成埌の倉曎も可胜です。なお、りェブサむト怜玢を行うには Search Enterprise Edition の有効化が必須です。 Search Enterprise Edition を有効化するず、以䞋の機胜を利甚できたす。 怜玢結果から芁玄の生成 フォロヌアップ怜玢 抜出回答Extractive answers、Extractive segments りェブサむト怜玢 Search Enterprise Edition を有効化するず、ク゚リあたりの料金単䟡に远加料金が加算されたす。 参考 : Agent Search pricing Advanced Generative Answers高床な LLM 機胜 Agent Search アプリを䜜成する際に Advanced Generative Answers 高床な生成回答、もしくは高床な LLM 機胜ずもを有効化するこずができたす。䜜成埌に倉曎するこずも可胜です。 Advanced Generative Answers を有効化するず、フォロヌアップ怜玢のサゞェストや、耇雑なク゚リのハンドリングが利甚可胜になりたす。ただし、ク゚リあたりの料金単䟡に远加料金が加算されたす。 Enterprise ゚ディションの機胜ず高床な LLM 機胜の有効化 なお2025幎5月の料金改定前は、このオプションは LLM アドオンの Basic基本および Advanced䞊玚者向けずいう2぀のオプションずしお甚意されおいたした。料金改定に䌎い、Advanced Generative Answers ずしお䞀本化され、たたク゚リ単䟡も倀䞋げされたした。 機胜ず察応するオプション ある機胜を䜿うためにどのオプションを有効化する必芁があるかは、以䞋のドキュメントに衚でたずめられおいたすので、ご参照ください。 参考 : 高床な機胜に぀いお アプリずデヌタストア アプリ Agent Search の蚭定は アプリ Appsずいうリ゜ヌスで管理され、それぞれのアプリが䜿うデヌタは デヌタストア ずいうリ゜ヌスずしお管理されたす。 アプリ Appsは「カスタム怜玢アプリ」「りェブサむト怜玢アプリ」など、機胜を遞んで䜜成する、ひずたずたりの蚭定単䜍です。 䟋ずしお、カスタム怜玢アプリを䜜成するずきは、アプリ名や゚ディション、有効化する怜玢機胜オヌトコンプリヌトや LLM による芁玄など、怜玢察象のデヌタストア、などを遞択したす。 アプリの䞀芧 デヌタストア Agent Search は、 デヌタストア ずしお取り蟌んだ情報を基に、利甚者からの質問に答えたり、怜玢を行ったり、゚ヌゞェントずしおタスクを行ったりしたす。 デヌタストアの䞀芧 デヌタストアにはりェブサむト、テキストドキュメントなどを取り蟌むこずが可胜です。より正確には、以䞋のようなフォヌマットのデヌタを取り蟌み可胜です。 デヌタストアタむプ フォヌマット 取り蟌み方匏 Web HTML / PDF ドメむン名や URL で指定。Google Search Index で収集 非構造化デヌタ HTML / TXT / JSON / XHTML / XML / PPTX / DOCX / XLSX / PDF Cloud Storage たたは API 経由でアップロヌド 構造化デヌタ CSV / JSONL / BigQuery table Cloud Storage、BigQuery、API 経由でアップロヌド 参考 : アプリずデヌタストアに぀いお 参考 : 取り蟌み甚にデヌタを準備する Web デヌタストア Web タむプのデヌタストアは、その名の通り Web サむトを取り蟌むためのデヌタストアです。Web サむト内の HTML のほか、PDF ファむルもむンデックスされたす。サむト党䜓を取り蟌むこずも、䞀郚を指定しお取り蟌んだり、逆に䞀郚を陀倖するこずもできたす。 Google が怜玢゚ンゞンに Web サむトを取り蟌むずきに甚いる「Google Search Index」ず同じ仕組みで情報が収集されるため、Web サむトは むンタヌネットからアクセスできる 必芁がありたす。 たた Advanced website indexing りェブサむトの高床なむンデックス登録を有効化するこずで、怜玢結果の芁玄やフォロヌアップ怜玢等を実珟できたす。これを有効化するにはサむトの正圓な所有者であるこずを瀺すため ドメむンの認蚌 が必芁です。ドメむンの認蚌には Google 怜玢の最適化にも䜿われる Google Search Console ず呌ばれる Google の Web ツヌルを䜿いたす。「ドメむンの DNS ゟヌンに指定の TXT レコヌドを远加する」「ペヌゞに Google Analytics のトラッキングコヌドを挿入する」「HTML ファむルを特定 URL にアップロヌドする」などの方法でドメむン認蚌を行うこずができたす。ドメむン認蚌は、Advanced でない通垞のむンデックス䜜成であれば䞍芁です。 参考 : 高床な機胜に぀いお - りェブサむトの高床なむンデックス登録 参考 : アプリずデヌタストアに぀いお - りェブサむトのデヌタ 構造化デヌタストア 構造化 Structuredタむプのデヌタストアは、FAQよくある質問や商品カタログ等を取り蟌むために甚いたす。 構造化デヌタストアの䜜成時は、BigQuery テヌブルか、JSONNDJSON/JSONL圢匏で Cloud Storage バケット䞊にデヌタを甚意したす。たた、API 経由でデヌタを投入するこずも可胜です。スキヌマは自動怜知させるこずも、明瀺的にスキヌマ情報を䞎えるこずもできたす。 参考 : アプリずデヌタストアに぀いお - 構造化デヌタ ただし BigQuery の倖郚テヌブルをデヌタストアずしお取り蟌むこずはできたせんのでご泚意ください。 参考 : 取り蟌み甚にデヌタを準備する - BigQuery 非構造化デヌタストア 非構造化 Unstructuredタむプのデヌタストアは、PDF や HTML、TXT ファむル等をファむルずしお盎接取り蟌むためのデヌタストアです。たた PPTXPowerPointや DOCXWord、XLSXExcelなどの圢匏にも察応しおいたす。 ファむルは、原則ずしお Cloud Storage バケット経由でアップロヌドしたす。アップロヌドするファむルには「タむトル」ず「URL」をメタデヌタずしお付䞎するこずができ、付䞎した堎合はチャットボットが利甚者に返答する際に、その URL を添付しお回答するこずができたす。これにより利甚者は、むンタヌネットに接しおいない内郚 Web サむトを情報源ずしお参照するこずができたす。 デヌタストアぞの取り蟌み指瀺は、メタデヌタ無しの堎合は単玔に Cloud Storage バケットやそのパスを指定したす。メタデヌタ有りの堎合は、取り蟌み察象ファむルの Cloud Storage URL ずメタデヌタ情報を JSONL 圢匏で蚘述したり、BigQuery テヌブルに栌玍しお、これに察しお取り蟌みを指瀺したす。 参考 : アプリずデヌタストアに぀いお - 非構造化デヌタ 非構造化デヌタのパヌス解析 Agent Search では非構造化デヌタずしお Cloud Storage に PDF ファむル、HTML ファむル、docx ファむル、pptx ファむル、xlsx ファむル、txt ファむル等を怜玢察象ずするこずができたす。これらのファむルを配眮した非構造化デヌタストアを䜜成する際に、 パヌサヌ ず呌ばれるファむルをパヌス解析するための凊理の皮類を遞択できたす。パヌサヌには以䞋の皮類がありたす。 パヌサヌ名 察応フォヌマット デゞタルパヌサヌ Digital parser HTML、PDF、docx、pptx、txt、xlsx PDF の OCR 解析 OCR parsing for PDFs PDF レむアりトパヌサヌ Layout parser HTML、PDF、docx、pptx、xlsx デフォルトでは デゞタルパヌサヌ が遞択されたす。デゞタルパヌサヌは、ファむルにデゞタル情報ずしお栌玍されたテキストを怜出し、段萜情報を怜知するこずができたす。 もし PDF が手曞きの文字をスキャンしたものであれば、 OCR パヌサヌ を遞択しお文字を読み取るこずができたす。 レむアりトパヌサヌ を遞択した堎合は、ファむルから段萜、衚、画像、タむトル、芋出し芁玠等が怜出されたす。レむアりトパヌサヌを遞択するには、 ドキュメントのチャンク化 document chunking for RAGを有効化する必芁がありたす。ドキュメントのチャンク化を有効化するず、ファむルは非構造化デヌタストア内でチャンク化ファむルを分割しお现かい情報にするこずされたす。これにより、デヌタストアは RAG に最適化されたす。たた Gemini レむアりト解析 を有効化するず、PDF ファむルの解析に生成 AI モデル Gemini が䜿甚され、品質向䞊が期埅できたす。 参考 : アプリずデヌタストアに぀いお - 非構造化デヌタ 参考 : ドキュメントを解析しおチャンク化する 杉村 勇銬 (蚘事䞀芧) 執行圹員 CTO 元譊察官ずいう経歎を持぀ IT ゚ンゞニア。クラりド管理・運甚やネットワヌクに知芋。AWS 認定資栌および Google Cloud 認定資栌はすべお取埗。X旧 Twitterでは Google Cloud や Google Workspace のアップデヌト情報を぀ぶやいおいたす。 Follow @y_sugi_it
G-gen の歊井です。 Config Controller (Config Sync) で Google Cloud (旧称 GCP) のブルヌプリントを利甚しお GitOps なリ゜ヌス管理を実珟するための怜蚌を行いたした。圓蚘事ではその方法をご玹介したす。 Config Controller (Config Sync) はじめに 圓蚘事の抂芁 アヌキテクチャ 構成 構成芁玠 䞀連の凊理 前提知識 (甚語解説) Google Cloud ブルヌプリント ランディングゟヌン Anthos Config Management kpt レンダリング setters 関連蚘事 事前準備 参考ドキュメント 実行環境 Project / VPC / Subnet の準備 環境倉数ず gcloud の蚭定 Config Controller の蚭定 API 有効化 Config Controller クラスタの䜜成 Config Controller クラスタの認蚌 Config Controller クラスタぞの暩限付䞎 GitOps パむプラむンの蚭定 成果物の確認 API 有効化 GitOps ブルヌプリントのダりンロヌド setters の定矩 レンダリング GitOps パむプラむンのデプロむ source-repo リポゞトリぞの Push ランディングゟヌンのデプロむ 抂芁 ランディングゟヌンブルヌプリントのダりンロヌド setters の定矩 source-repo リポゞトリぞの Push トラブルシュヌティング 想定゚ラヌ ゚ラヌ原因 ファむル確認 察凊方法 nomos status の再確認 動䜜確認 リ゜ヌス GitOps パむプラむン リポゞトリ Cloud Build トリガヌ Config Sync さいごに はじめに 圓蚘事の抂芁 Config Controller で Google Cloud のブルヌプリントを利甚するず以䞋を実珟するこずができたす。 GitOps パむプラむン のデプロむ GitOps パむプラむン を甚い、 ランディングゟヌン を始めずする各皮 Google Cloud リ゜ヌス構成のデプロむ・管理 圓蚘事では実際の怜蚌結果をふたえ分かりやすく解説したす。 アヌキテクチャ 構成 前述の抂芁を図瀺するず以䞋のずおりです。 構成図 構成芁玠 各構成芁玠ずそれらが担う圹割 (凊理) の抂芁を説明したす。なお、 GitOps パむプラむン ずは以䞋衚の #3 ~ #5 から構成される CI/CD パむプラむンのこずを指したす。 # 構成芁玠 圹割 1 GitHub Google Cloud ブルヌプリント (テンプレヌト) を管理する Git リポゞトリ 2 setters ブルヌプリント䞊の蚭定倀を䞀元管理する機胜 3 source-repo setters を定矩したブルヌプリントが栌玍される Git リポゞトリ 4 Cloud Build setters から環境固有のマニフェストをレンダリングする kpt 関数 5 deployment-repo レンダリングされたマニフェストが栌玍される Git リポゞトリ 6 Config Sync Config Controller に GitOps サヌビスを提䟛するコンポヌネント 7 Config Controller マニフェストにもずづきリ゜ヌスをデプロむ管理するコンポヌネント 䞀連の凊理 setters を定矩したブルヌプリントを GitOps パむプラむンに push するず、Cloud Build による kpt 関数 (レンダリング) が実行され、各環境固有のマニフェストが自動的に生成されたす。 Config Sync はレンダリングされたマニフェストが栌玍されたリポゞトリを定期的に参照したす。参照結果は Config Controller に連携され、結果に基づくリ゜ヌスの管理やデプロむを自動実行したす。 前提知識 (甚語解説) Google Cloud ブルヌプリント Google Cloud には ブルヌプリント ず呌ばれる、Google Cloud 䞊のリ゜ヌスやサヌビスの構成を宣蚀的に管理するためのフレヌムワヌクが存圚したす。 ブルヌプリントには ランディングゟヌン (埌述) を始め、様々な構成に関するベストプラクティスが提䟛されおおり、それらを利甚するこずで、䌁業や組織は Google Cloud の構成を䞀貫性のある方法でデプロむ・管理するこずができたす。 ランディングゟヌン ランディングゟヌン ずは、「クラりド䞊に新しい環境やワヌクロヌドを迅速か぀安党にデプロむするための事前定矩された蚭蚈パタヌン」を衚す抂念 (甚語) です。 セキュリティ、運甚、ネットワヌク蚭蚈、アクセス管理など、クラりド基盀を構築する䞊でのベストプラクティスが考慮された圢で蚭蚈されおおり、䞊蚘ブルヌプリントの landing-zone ディレクトリ配䞋にはマニフェストファむル䞀匏が甚意されおいたす。 Anthos Config Management Anthos Config Management は、Google Cloud リ゜ヌスのプロビゞョニングずオヌケストレヌションを行うサヌビスです。 Config Controller 、 Config Sync 、 Policy Controller ずいう 3぀ のコンポヌネントから構成されたす。 詳现に぀いおはこちらの蚘事をご確認ください。 blog.g-gen.co.jp kpt kpt ずは マニフェストファむルを操䜜パッケヌゞ化、pull、曎新、倉曎するための Google が開発したオヌプン゜ヌスツヌルです。 今回のケヌスでは、圓ツヌルを䜿っお Google Cloud のブルヌプリントを取埗したり、取埗したブルヌプリント (テンプレヌト) から、適甚先環境に合わせたマニフェストファむルを レンダリング (埌述) したりしたす。 レンダリング 前述の通り、Config Controller や kpt の文脈におけるレンダリングずは 「雛圢ずなるブルヌプリントから各環境固有のマニフェストファむルを生成する凊理のこず」 を指しおおり、その凊理の䞭で kpt の setters (埌述) ずいう機胜が甚いられおいたす。 setters setters ずは、 「マニフェストファむル内の特定の倀を䞀元的に管理・曎新するための機胜」 のこずで、Linux でいう環境倉数の抂念ず同じです。 Google Cloud のブルヌプリントは様々なプロゞェクトや環境で再利甚するこずが想定されたす。圓機胜を利甚すれば、ブルヌプリント䞊の初期倀をそれぞれの環境やプロゞェクト固有の倀 (䟋: プロゞェクト ID やリヌゞョン名) に簡単に曎新でき、ブルヌプリントを効率的に利甚できたす。 関連蚘事 以䞋の蚘事でも Config Controller に぀いお解説しおいたす。こちらもあわせおご参照ください。 blog.g-gen.co.jp blog.g-gen.co.jp 事前準備 参考ドキュメント 今回の怜蚌は以䞋の公匏ガむドを参考にしお実斜しおいたす。 参考 ランディング ゟヌンのブルヌプリントをデプロむする 実行環境 本蚭定では gcloud コマンドの他に、 kubectl 、 nomos 、 kpt ずいったコマンドを利甚するため、これらがプリむンストヌルされた Cloud Shell を利甚したす。 # コマンド which kubectl nomos kpt # 戻り倀 /usr/bin/kubectl /usr/bin/nomos /usr/bin/kpt Project / VPC / Subnet の準備 Config Controller (実䜓は GKE クラスタ) を䜜成する Project / VPC / Subent を準備したす。 ※ 䜜成方法の解説は割愛したす。 # リ゜ヌス リ゜ヌス名 1 Project (Project ID) sandbox-cc-test-prj 2 VPC sandbox-cc-test-vpc 3 Subnet sandbox-cc-test-subnet 環境倉数ず gcloud の蚭定 Cloud Shell で環境倉数ず gcloud コマンドのプロゞェクト蚭定を行いたす。 ※ 蚭定途䞭で Cloud Shell の接続が切れた堎合は再床環境倉数を蚭定しおください。 # CONFIG_CONTROLLER_NAME は 25 文字以内 export PROJECT_ID =sandbox-cc-test-prj export CONFIG_CONTROLLER_NAME =config-controller-1 export BILLING_ACCOUNT = $( gcloud alpha billing projects describe $PROJECT_ID \ ' --format=value(billingAccountName) ' | sed ' s/.*\/// ' ) export ORG_ID = $( gcloud projects get-ancestors ${PROJECT_ID} --format= ' get(id) ' | tail -1 ) # gcloud の蚭定 (向き先ずなるプロゞェクトの指定) gcloud config set project ${PROJECT_ID} # 戻り倀 Updated property [ core/project ] . Config Controller の蚭定 API 有効化 Config Controller API ず GKE API を有効にしたす。 # コマンド gcloud services enable krmapihosting.googleapis.com container.googleapis.com # 戻り倀 Operation " operations/acf.p2-566560710327-a294ce1f-f676-4214-9e8e-1340fe0bee36 " finished successfully. Config Controller クラスタの䜜成 クラスタを以䞋の条件で䜜成したす。(この操䜜には時間がかかる堎合がありたす) Autopilot asia-northeast1 (東京リヌゞョン) 事前準備で䜜成した VPC / Subnet # コマンド gcloud anthos config controller create ${CONFIG_CONTROLLER_NAME} \ --location=asia-northeast1 \ --network=sandbox-cc-test-vpc \ --subnet=sandbox-cc-test-subnet \ --full-management # 戻り倀 Create request issued for: [ config-controller -1] Waiting for operation [ projects/sandbox-cc-test-prj/locations/asia-northeast1/operations/operation-1692153896333-6030147e571e0-03bfd650-4d82d756 ] to comple te...done. Created instance [ config-controller -1] . Fetching cluster endpoint and auth data. kubeconfig entry generated for krmapihost-config-controller -1 . クラスタの䜜成が正垞に完了したこずを確認したす。 # コマンド gcloud anthos config controller list --location=asia-northeast1 # 戻り倀 NAME: config-controller-1 LOCATION: asia-northeast1 STATE: RUNNING Config Controller クラスタの認蚌 クラスタの認蚌情報を取埗したす。 # コマンド gcloud anthos config controller get-credentials ${CONFIG_CONTROLLER_NAME} \ --location=asia-northeast1 # 戻り倀 Fetching cluster endpoint and auth data. kubeconfig entry generated for krmapihost-config-controller -1 . Config Controller クラスタぞの暩限付䞎 クラスタのサヌビスアカりント ( service-PROJECT_NUMBER@gcp-sa-yakima.iam.gserviceaccount.com ) に、プロゞェクトおよび組織レベルで管理暩限を付䞎したす。 # 環境倉数蚭定 export SA_EMAIL = " $( kubectl get ConfigConnectorContext -n config-control \ -o jsonpath = ' {.items[0].spec.googleServiceAccount} ' 2 > /dev/null ) " # IAM Policy 蚭定 (プロゞェクトレベル) gcloud projects add-iam-policy-binding " ${PROJECT_ID} " \ --member " serviceAccount: ${SA_EMAIL} " \ --role " roles/owner " \ --project " ${PROJECT_ID} " # 戻り倀 (䞀郚のみ抜粋) Updated IAM policy for project [ sandbox-cc-test-prj ] . bindings: - members: - serviceAccount:service-566560710327@gcp-sa-yakima.iam.gserviceaccount.com - user:user@example.co.jp role: roles/owner etag: BwYDAjdY4F0 = version: 1 # IAM Policy 蚭定 (組織レベル) gcloud organizations add-iam-policy-binding $ORG_ID \ --role=roles/resourcemanager.organizationAdmin \ --condition=None \ --member= " serviceAccount: ${SA_EMAIL} " # 戻り倀 (䞀郚のみ抜粋) Updated IAM policy for organization [ 999999999999 ] . bindings: - members: - serviceAccount:service-566560710327@gcp-sa-yakima.iam.gserviceaccount.com role: roles/resourcemanager.organizationAdmin etag: BwYDAoGjp8Q = version: 1 GitOps パむプラむンの蚭定 成果物の確認 このプロセスでは以䞋のリ゜ヌスで構成される GitOps パむプラむンを䜜成したす。 # リ゜ヌス 圹割 1 source-repo ロヌカルから push されるファむル䞀匏を栌玍するリポゞトリ 2 Build トリガヌ 䞊蚘からレンダリングされたファむルを deployment-repo に push 3 deployment-repo レンダリングされたファむル䞀匏を栌玍するリポゞトリ 4 Config Sync deployment-repo に接続する GitOps サヌビス API 有効化 Cloud Source Repositories API ず Resource Manager API を有効にしたす。 # コマンド gcloud services enable sourcerepo.googleapis.com cloudresourcemanager.googleapis.com # 戻り倀 Operation " operations/acat.p2-566560710327-99c27c46-29ce-4747-a867-eea8ff811998 " finished successfully. GitOps ブルヌプリントのダりンロヌド kpt を䜿甚しお GitHub から Cloud Shell に GitOps ブルヌプリント をダりンロヌドしお GitOps パむプラむンをデプロむしたす。 バヌゞョンは GitOps ブルヌプリントの GHANGELOG.md から確認できたす。 2023幎8月時点の最新バヌゞョンは v0.6.1 # 最新の GitOps ブルヌプリントをダりンロヌド kpt pkg get https://github.com/GoogleCloudPlatform/blueprints.git/catalog/gitops@gitops-blueprint-v0. 6 . 1 gitops # 戻り倀 Package " gitops " : Fetching https://github.com/GoogleCloudPlatform/blueprints@gitops-blueprint-v0. 6 . 1 From https://github.com/GoogleCloudPlatform/blueprints * tag gitops-blueprint-v0. 6 . 1 - > FETCH_HEAD Adding package " catalog/gitops " . Fetched 1 package ( s ) . Cloud Shell にダりンロヌドできたこずを確認したす。 # コマンド tree gitops/ # 戻り倀 gitops/ ├── CHANGELOG.md ├── cloudbuild-iam.yaml ├── configsync │ ├── config-management.yaml │ ├── configsync-iam.yaml │ ├── Kptfile │ ├── README.md │ ├── rootsync.yaml │ ├── setters.yaml │ └── validation.yaml ├── hydration-trigger.yaml ├── Kptfile ├── README.md ├── services.yaml ├── setters.yaml └── source-repositories.yaml 1 directory, 15 files 䞻芁なマニフェストファむルの圹割は以䞋の通りです。 # gitops/ 以䞋 圹割 1 Kptfile kpt の蚭定ファむル 2 setters.yaml gitops/ 以䞋の各マニフェストファむルの蚭定倀を䞀元管理 3 services.yaml パむプラむンが䜿甚するサヌビス API を管理 4 source-repositories.yaml リポゞトリ (Cloud Source Repositories, CSR) を管理 5 cloudbuild-iam.yaml Cloud Build サヌビスアカりントの IAM Policy を管理 6 hydration-trigger.yaml リポゞトリ間で行われる凊理 (Cloud Build トリガヌ) を管理 # gitops/configsync 以䞋 圹割 1 configsync-iam.yaml Config Sync ず CSR 間の認蚌 (Workload Identity 方匏) を管理 2 rootsync.yaml Config Sync (CSR に察する GitOps サヌビス) を管理 setters の定矩 ダりンロヌドしたブルヌプリントを setters (セッタヌ) を䜿っお自身の環境向けにカスタマむズしたす。 setters ずは kpt の機胜の䞀぀で、 マニフェスト内の特定の倀を䞀元的に倉曎・蚭定するための圹割 を提䟛したす。簡単に衚すずマニフェスト内の倉数を管理するむメヌゞです。 これにより、マニフェスト内の初期倀が setters を介しお䞀意の倀に眮き換えられたす。 setters は gitops/setters.yaml ファむル内で管理されおいたすので、そちらを線集したす。 # 倉曎前 apiVersion : v1 kind : ConfigMap metadata : # kpt-merge: /setters name : setters annotations : config.kubernetes.io/local-config : "true" internal.kpt.dev/upstream-identifier : '|ConfigMap|default|setters' data : # This should be the project where you deployed Config Controller project-id : project-id project-number : "1234567890123" # This should be the name of your Config Controller instance cluster-name : cluster-name # You can leave these defaults namespace : config-control deployment-repo : deployment-repo source-repo : source-repo # 倉曎埌、cluster-name / project-id / project-number を環境固有の倀に眮換 apiVersion : v1 kind : ConfigMap metadata : # kpt-merge: /setters name : setters annotations : config.kubernetes.io/local-config : "true" internal.kpt.dev/upstream-identifier : '|ConfigMap|default|setters' data : # This should be the project where you deployed Config Controller project-id : sandbox-cc-test-prj project-number : "566560710327" # This should be the name of your Config Controller instance cluster-name : config-controller-1 # You can leave these defaults namespace : config-control deployment-repo : deployment-repo source-repo : source-repo レンダリング 定矩した setters を䜿っおブルヌプリントをレンダリングしたす。 レンダリングずは、 setters.yaml で定矩した内容にもどづきマニフェストを完成 (カスタマむズ) させる ずいう意味に近しいです。 # コマンド kpt fn render gitops/ # 戻り倀 Package " gitops/configsync " : [ RUNNING ] " gcr.io/kpt-fn/apply-setters:v0.1 " [ PASS ] " gcr.io/kpt-fn/apply-setters:v0.1 " in 4 .1s Results: [ info ] spec.clusterName: set field value to " cluster-name " [ info ] metadata.name: set field value to " sync-cluster-name " [ info ] metadata.namespace: set field value to " config-control " [ info ] metadata.annotations.cnrm.cloud.google.com/project-id: set field value to " project-id " ... ( 14 line ( s ) truncated, use ' --truncate-output=false ' to disable ) [ RUNNING ] " gcr.io/kpt-fn/starlark:v0.4 " [ PASS ] " gcr.io/kpt-fn/starlark:v0.4 " in 4 .4s Package " gitops " : [ RUNNING ] " gcr.io/kpt-fn/apply-setters:v0.1 " [ PASS ] " gcr.io/kpt-fn/apply-setters:v0.1 " in 300ms Results: [ info ] spec.clusterName: set field value to " config-controller-1 " [ info ] metadata.name: set field value to " sync-config-controller-1 " [ info ] metadata.namespace: set field value to " config-control " [ info ] metadata.annotations.cnrm.cloud.google.com/project-id: set field value to " sandbox-cc-test-prj " ... ( 38 line ( s ) truncated, use ' --truncate-output=false ' to disable ) Successfully executed 3 function ( s ) in 2 package ( s ) . レンダリング実行埌、䟋えば gitops/source-repositories.yaml を確認するず project-id が定矩した倀に眮換されたこずが分かりたす。 # 倉曎前 apiVersion : sourcerepo.cnrm.cloud.google.com/v1beta1 kind : SourceRepoRepository metadata : # kpt-merge: config-control/source-repo name : source-repo # kpt-set: ${source-repo} namespace : config-control # kpt-set: ${namespace} annotations : cnrm.cloud.google.com/blueprint : cnrm/gitops/v0.6.1,kpt-pkg cnrm.cloud.google.com/project-id : project-id # kpt-set: ${project-id} internal.kpt.dev/upstream-identifier : 'sourcerepo.cnrm.cloud.google.com|SourceRepoRepository|config-control|source-repo' --- apiVersion : sourcerepo.cnrm.cloud.google.com/v1beta1 kind : SourceRepoRepository metadata : # kpt-merge: config-control/deployment-repo name : deployment-repo # kpt-set: ${deployment-repo} namespace : config-control # kpt-set: ${namespace} annotations : cnrm.cloud.google.com/blueprint : cnrm/gitops/v0.6.1,kpt-pkg cnrm.cloud.google.com/project-id : project-id # kpt-set: ${project-id} internal.kpt.dev/upstream-identifier : 'sourcerepo.cnrm.cloud.google.com|SourceRepoRepository|config-control|deployment-repo' # 倉曎埌 apiVersion : sourcerepo.cnrm.cloud.google.com/v1beta1 kind : SourceRepoRepository metadata : # kpt-merge: config-control/source-repo name : source-repo # kpt-set: ${source-repo} namespace : config-control # kpt-set: ${namespace} annotations : cnrm.cloud.google.com/blueprint : cnrm/gitops/v0.6.1,kpt-pkg-fn cnrm.cloud.google.com/project-id : sandbox-cc-test-prj # kpt-set: ${project-id} internal.kpt.dev/upstream-identifier : 'sourcerepo.cnrm.cloud.google.com|SourceRepoRepository|config-control|source-repo' --- apiVersion : sourcerepo.cnrm.cloud.google.com/v1beta1 kind : SourceRepoRepository metadata : # kpt-merge: config-control/deployment-repo name : deployment-repo # kpt-set: ${deployment-repo} namespace : config-control # kpt-set: ${namespace} annotations : cnrm.cloud.google.com/blueprint : cnrm/gitops/v0.6.1,kpt-pkg-fn cnrm.cloud.google.com/project-id : sandbox-cc-test-prj # kpt-set: ${project-id} internal.kpt.dev/upstream-identifier : 'sourcerepo.cnrm.cloud.google.com|SourceRepoRepository|config-control|deployment-repo' たた、 gitops/source-repositories.yaml ファむル以倖も setters によっおレンダリングされおおり、これらレンダリングされたファむル䞀匏を䜿っお GitOps パむプラむンをデプロむしたす。 GitOps パむプラむンのデプロむ kubectl apply でレンダリングしたファむル䞀匏を適甚し、GitOps パむプラむンをデプロむしたす。 # コマンド kubectl apply --wait -f gitops/ --recursive # 戻り倀 iampartialpolicy.iam.cnrm.cloud.google.com/deployment-repo-cloudbuild-write created iampartialpolicy.iam.cnrm.cloud.google.com/source-repo-cloudbuild-read created configmanagement.configmanagement.gke.io/config-management configured iamserviceaccount.iam.cnrm.cloud.google.com/sync-config-controller-1 created iampartialpolicy.iam.cnrm.cloud.google.com/sync-config-controller-1 created iampartialpolicy.iam.cnrm.cloud.google.com/source-reader-sync-config-controller-1-sandbox-cc-test-prj created rootsync.configsync.gke.io/root-sync created configmap/setters created cloudbuildtrigger.cloudbuild.cnrm.cloud.google.com/source-repo-cicd-trigger created service.serviceusage.cnrm.cloud.google.com/sourcerepo.googleapis.com created service.serviceusage.cnrm.cloud.google.com/cloudbuild.googleapis.com created configmap/setters configured sourcereporepository.sourcerepo.cnrm.cloud.google.com/source-repo created sourcereporepository.sourcerepo.cnrm.cloud.google.com/deployment-repo created error: resource mapping not found for name: " validate-cluster-name-length " namespace: "" from " gitops/configsync/validation.yaml " : no matches for kind " StarlarkRun " in version " fn.kpt.dev/v1alpha1 " ensure CRDs are installed first リポゞトリを䜜成したす。 # コマンド kubectl wait --for=condition=READY -f gitops/source-repositories.yaml # 戻り倀 sourcereporepository.sourcerepo.cnrm.cloud.google.com/source-repo condition met sourcereporepository.sourcerepo.cnrm.cloud.google.com/deployment-repo condition met 䞊蚘実行埌、 source-repo ず deployment-repo の 2぀のリポゞトリが䜜成されたした。 # コマンド gcloud source repos list # 戻り倀 REPO_NAME: deployment-repo PROJECT_ID: sandbox-cc-test-prj URL: https:// source .developers.google.com/p/sandbox-cc-test-prj/ r /deployment-repo REPO_NAME: source-repo PROJECT_ID: sandbox-cc-test-prj URL: https:// source .developers.google.com/p/sandbox-cc-test-prj/ r /source-repo source-repo ず deployment-repo の 2぀のリポゞトリが䜜成 たた、以䞋のコマンドで Build トリガヌず Config Sync が䜜成されたこずを確認できたす。 # コマンド kubectl get gcp -n config-control -o yaml \ | grep " ^ name: \\ |message " # 戻り倀 name: source-repo-cicd-trigger message: The resource is up to date name: deployment-repo-cloudbuild-write message: The resource is up to date name: source-reader-sync-config-controller-1-sandbox-cc-test-prj message: The resource is up to date name: source-repo-cloudbuild-read message: The resource is up to date name: sync-config-controller-1 message: The resource is up to date name: sync-config-controller-1 message: The resource is up to date name: projects/sandbox-cc-test-prj/serviceAccounts/sync-config-controller-1@sandbox-cc-test-prj.iam.gserviceaccount.com name: cloudbuild.googleapis.com message: The resource is up to date name: sourcerepo.googleapis.com message: The resource is up to date name: deployment-repo message: The resource is up to date name: source-repo message: The resource is up to date source-repo リポゞトリぞの Push source-repo リポゞトリに GitOps パむプラむンのデプロむに䜿甚したファむル䞀匏を push したす。 たず、リポゞトリのデフォルトブランチを main に蚭定したす。 # コマンド (戻り倀なし) git config --global init.defaultBranch main 次に、 gcloud source repos clone コマンドで source-repo リポゞトリを Cloud Shell にクロヌンしたす。 # コマンド gcloud source repos clone source-repo # 戻り倀 Cloning into ' /home/user/gitops_test_20230816/source-repo ' ... warning: You appear to have cloned an empty repository. Project [ sandbox-cc-test-prj ] repository [ source-repo ] was cloned to [ /home/user/gitops_test_20230816/source-repo ] . クロヌンしたリポゞトリに gitops/ ディレクトリを移動したす。 # 移動前の状態確認 ls -l total 8 drwx------ 3 user user 4096 Aug 16 12:52 gitops drwxr-xr-x 3 user user 4096 Aug 16 14:46 source-repo # 移動ずその埌の状態確認 mv gitops/ source-repo/ && ls -l total 4 drwxr-xr-x 4 user user 4096 Aug 16 14:51 source-repo 最埌にファむル䞀匏を commit / push したす。 # コマンド (git commit たで) cd source-repo/ git add gitops/ git commit -m " Add GitOps blueprint " [ main (root-commit) f989115 ] Add GitOps blueprint 15 files changed, 726 insertions ( + ) create mode 100644 gitops/CHANGELOG.md create mode 100644 gitops/Kptfile create mode 100644 gitops/README.md create mode 100644 gitops/cloudbuild-iam.yaml create mode 100644 gitops/configsync/Kptfile create mode 100644 gitops/configsync/README.md create mode 100644 gitops/configsync/config-management.yaml create mode 100644 gitops/configsync/configsync-iam.yaml create mode 100644 gitops/configsync/rootsync.yaml create mode 100644 gitops/configsync/setters.yaml create mode 100644 gitops/configsync/validation.yaml create mode 100644 gitops/hydration-trigger.yaml create mode 100644 gitops/services.yaml create mode 100644 gitops/setters.yaml create mode 100644 gitops/source-repositories.yaml # コマンド (git push) git push [ main (root-commit) f989115 ] Add GitOps blueprint 15 files changed, 726 insertions ( + ) create mode 100644 gitops/CHANGELOG.md create mode 100644 gitops/Kptfile create mode 100644 gitops/README.md create mode 100644 gitops/cloudbuild-iam.yaml create mode 100644 gitops/configsync/Kptfile create mode 100644 gitops/configsync/README.md create mode 100644 gitops/configsync/config-management.yaml create mode 100644 gitops/configsync/configsync-iam.yaml create mode 100644 gitops/configsync/rootsync.yaml create mode 100644 gitops/configsync/setters.yaml create mode 100644 gitops/configsync/validation.yaml create mode 100644 gitops/hydration-trigger.yaml create mode 100644 gitops/services.yaml create mode 100644 gitops/setters.yaml create mode 100644 gitops/source-repositories.yaml source-repo リポゞトリの main ブランチにファむル䞀匏が栌玍されたした。 push されたブルヌプリント ランディングゟヌンのデプロむ 抂芁 以䞋の手順でランディングゟヌンをデプロむしたす。 ランディングゟヌンのブルヌプリントをダりンロヌドする setters を定矩しお source-repo に push する kpt によるレンダリング、 deployment-repo ぞの push はパむプラむンが行いたすので、䞊蚘手順を実行するだけでランディングゟヌンがデプロむされたす。 ランディングゟヌンブルヌプリントのダりンロヌド kpt を䜿っお ランディングゟヌンのブルヌプリント を Cloud Shell にダりンロヌドしたす。 # コマンド、@main でリポゞトリの main ブランチから取埗する kpt pkg get https://github.com/GoogleCloudPlatform/blueprints.git/catalog/landing-zone@main ./landing-zone # kpt pkg の戻り倀は先皋ず同様のため割愛 Cloud Shell にダりンロヌドできたこずを確認したす。 # コマンド tree -a landing-zone/ # 戻り倀 landing-zone/ ├── CHANGELOG.md ├── iam.yaml ├── Kptfile ├── logging │ └── .gitkeep # 空ディレクトリを維持するためのファむル ├── namespaces │ ├── hierarchy.yaml │ ├── logging.yaml │ ├── networking.yaml │ ├── policies.yaml │ └── projects.yaml ├── network │ └── .gitkeep # 空ディレクトリを維持するためのファむル ├── policies │ ├── deletion-policy-required-template.yaml │ ├── disable-guest-attributes.yaml │ ├── disable-iam-grants-default-sa.yaml │ ├── disable-nested-virtualization.yaml │ ├── disable-sa-key-creation.yaml │ ├── disable-serial-port.yaml │ ├── disable-vm-external-ip.yaml │ ├── enforce-uniform-bucket-lvl-access.yaml │ ├── folder-naming-constraint-template.yaml │ ├── restrict-cloud-sql-public-ip.yaml │ ├── restrict-lien-removal.yaml │ └── skip-default-network.yaml ├── projects │ └── .gitkeep # 空ディレクトリを維持するためのファむル ├── README.md ├── services.yaml └── setters.yaml 5 directories, 26 files 䞻芁なマニフェストファむルの圹割は以䞋の通りです。 # landing-zone/ 以䞋 圹割 1 Kptfile kpt の蚭定ファむル 2 setters.yaml landing-zone/ 以䞋の各マニフェストファむルの蚭定倀を䞀元管理 3 services.yaml ランディングゟヌンが䜿甚するサヌビス API を管理 4 iam.yaml グルヌプアカりントの IAM Policy (組織レベル) を管理 namespaces ディレクトリには Config Controller が䜿甚するネヌムスペヌス、 policies ディレクトリは組織ポリシヌに関するマニフェストファむルが栌玍されおいたす。 logging 、 network 、 projects ディレクトリは珟時点で空ディレクトリを維持するためのファむルしかないためデプロむされるリ゜ヌスはありたせんが、別途拡匵・カスムするこずができたす。 setters の定矩 landing-zone/setters.yaml ファむルを線集しお setters を定矩したす。 その前に䞊蚘ファむルの線集差分を埌ほど確認できるよう、 git commit たで実行したす。 # コマンド ls -l # 戻り倀 total 8 drwx------ 3 user user 4096 Aug 16 12:52 gitops drwx------ 7 user user 4096 Aug 17 05:56 landing-zone # git commit たで実行 (レンダリング埌の差分を diff するため push はしない) git add landing-zone/ git commit -m " Add landing zone " # git の戻り倀は先皋ず同様のため割愛 あらためお landing-zone/setters.yaml ファむルを線集したす。 # 倉曎前 apiVersion : v1 kind : ConfigMap metadata : # kpt-merge: /setters name : setters annotations : config.kubernetes.io/local-config : "true" internal.kpt.dev/upstream-identifier : '|ConfigMap|default|setters' data : # Organization ID and billing account org-id : "123456789012" billing-account-id : AAAAAA-BBBBBB-CCCCCC # Groups to use for org-level roles group-org-admins : gcp-organization-admins@example.com group-billing-admins : gcp-billing-admins@example.com # The project where Config Controller is deployed management-project-id : management-project-id # This default is safe to keep management-namespace : config-control # 倉曎埌、org-id / billing-account-id / management-project-id / group-org-admins / group-billing-admins を倉曎 apiVersion : v1 kind : ConfigMap metadata : # kpt-merge: /setters name : setters annotations : config.kubernetes.io/local-config : "true" internal.kpt.dev/upstream-identifier : '|ConfigMap|default|setters' data : # Organization ID and billing account org-id : "999999999999" # billing-account-id : 00000B-66666E-DDDD77 # Groups to use for org-level roles group-org-admins : ggen@sandbox.co.jp group-billing-admins : ggen@sandbox.co.jp # The project where Config Controller is deployed management-project-id : sandbox-cc-test-prj # This default is safe to keep management-namespace : config-control landing-zone/setters.yaml ファむル線集埌の差分は git diff コマンドでも確認できたす。 # コマンド git diff # 戻り倀 diff --git a/landing-zone/setters.yaml b/landing-zone/setters.yaml index 398cbcb..0905af7 100644 --- a/landing-zone/setters.yaml +++ b/landing-zone/setters.yaml @@ -20 , 12 + 20 , 12 @@ metadata: # kpt-merge: /setters internal.kpt.dev/upstream-identifier: ' |ConfigMap|default|setters ' data: # Organization ID and billing account - org-id: " 123456789012 " - billing-account-id: AAAAAA-BBBBBB-CCCCCC + org-id: " 999999999999 " + billing-account-id: 00000B-66666E-DDDD77 # Groups to use for org-level roles - group-org-admins: gcp-organization-admins@example.com - group-billing-admins: gcp-billing-admins@example.com + group-org-admins: ggen@sandbox.co.jp + group-billing-admins: ggen@sandbox.co.jp # The project where Config Controller is deployed - management-project-id: management-project-id + management-project-id: sandbox-cc-test-prj # This default is safe to keep management-namespace: config-control source-repo リポゞトリぞの Push 倉曎内容を確認したら source-repo リポゞトリに push したす。 # コマンド git commit -a -m " Customize landing zone blueprint " git push # git の戻り倀は先皋ず同様のため割愛 その埌、䞊蚘をトリガヌずしお GitOps パむプラむンが以䞋のように動䜜し、最終的にランディングゟヌンがデプロむされたす。 landing-zone/setters.yaml ファむルにもずづきレンダリングが行われる レンダリングされたファむル䞀匏が deployment-repo に push される Config Sync が deployment-repo を参照する Config Controller が 参照結果にもずづきランディングゟヌンをデプロむする トラブルシュヌティング 想定゚ラヌ 参考ドキュメントをベヌスに進めおきたしたが、 nomos status (Config Sync が管理するリ゜ヌスの状態確認) コマンドを実行するず KNV1069: SelfManageError が発生するものず思われたす。 # コマンド nomos status # 戻り倀 (゚ラヌのみ抜粋) KNV1069: RootSync config-management-system/root-sync must not manage itself in its repo ゚ラヌ原因 原因は Config Sync が、 自身のマニフェストファむル ( rootsync.yaml ) を含め、リポゞトリ党䜓を参照するように蚭定されおいる からです。 Config Sync は 管理察象リ゜ヌスのマニフェストファむル だけを参照すべきで、自身の状態を定矩したマニフェストファむルを参照させおはいけたせん。 ファむル確認 パむプラむンをデプロむした際のファむル ( gitops/configsync/rootsync.yaml ) を確認したす。 dir が config になっおいたす。 config ずは source-repo リポゞトリ䞊のルヌトディレクトリ名を指しおおり、すなわち Config Sync の蚭定を含むリポゞトリ党䜓 を参照するようになっおいたす。 apiVersion : configsync.gke.io/v1beta1 kind : RootSync metadata : # kpt-merge: config-management-system/root-sync name : root-sync namespace : config-management-system annotations : internal.kpt.dev/upstream-identifier : 'configsync.gke.io|RootSync|config-management-system|root-sync' spec : sourceFormat : unstructured git : repo : https://source.developers.google.com/p/sandbox-cc-test-prj/r/deployment-repo # kpt-set: https://source.developers.google.com/p/${project-id}/r/${deployment-repo} revision : HEAD branch : main dir : config # kpt-set: ${configsync-dir} auth : gcpserviceaccount gcpServiceAccountEmail : sync-config-controller-1@sandbox-cc-test-prj.iam.gserviceaccount.com # kpt-set: sync-${cluster-name}@${project-id}.iam.gserviceaccount.com 察凊方法 ランディングゟヌンに関するマニフェストだけを参照するよう蚭定を修正したす。 Cloud Shell 䞊にある gitops/configsync/setters.yaml を開き、 configsync-dir の倀を config/landing-zone に倉曎したす。 # 倉曎埌 apiVersion : v1 kind : ConfigMap metadata : # kpt-merge: /setters name : setters annotations : config.kubernetes.io/local-config : "true" internal.kpt.dev/upstream-identifier : '|ConfigMap|default|setters' data : namespace : config-control # cluster-name must not exceed 25 characters in length cluster-name : cluster-name configsync-dir : config/landing-zone deployment-repo : deployment-repo project-id : project-id レンダリングを実行しお gitops/configsync/rootsync.yaml の dir に反映させたす。 # レンダリング実行堎所の確認 (gitops ディレクトリが衚瀺されるこず) ls -l # レンダリング (戻り倀は割愛) kpt fn render gitops/ # レンダリング埌 apiVersion : configsync.gke.io/v1beta1 kind : RootSync metadata : # kpt-merge: config-management-system/root-sync name : root-sync namespace : config-management-system annotations : internal.kpt.dev/upstream-identifier : 'configsync.gke.io|RootSync|config-management-system|root-sync' spec : sourceFormat : unstructured git : repo : https://source.developers.google.com/p/sandbox-cc-test-prj/r/deployment-repo # kpt-set: https://source.developers.google.com/p/${project-id}/r/${deployment-repo} revision : HEAD branch : main dir : config/landing-zone # kpt-set: ${configsync-dir} auth : gcpserviceaccount gcpServiceAccountEmail : sync-config-controller-1@sandbox-cc-test-prj.iam.gserviceaccount.com # kpt-set: sync-${cluster-name}@${project-id}.iam.gserviceaccount.com kubectl apply で Config Sync の蚭定を適甚 (倉曎) したす。 # 適甚 (戻り倀は割愛) kubectl apply --wait -f gitops/ --recursive レンダリングしたファむルを source-repo リポゞトリに push したす。 # コマンド (戻り倀は割愛) git add . git commit -m " update rootsync " git push nomos status の再確認 再床 nomos status を実行し゚ラヌが解消されたこずを確認したす 各リ゜ヌスのステヌタスが Current になっおいればデプロむが完了しおいたす。 # コマンド nomos status # 戻り倀 *gke_sandbox-cc-test-prj_asia-northeast1_krmapihost-config-controller-1 -------------------- < root > :root-sync https:// source .developers.google.com/p/sandbox-cc-test-prj/ r /deployment-repo/config/landing-zone@main SYNCED @ 2023-08-18 10:47:07 + 0000 UTC 2f1935299502189667f71e2c4d03de46728447e2 Managed resources: NAMESPACE NAME STATUS SOURCEHASH constrainttemplate.templates.gatekeeper.sh/gcpenforcenamingv2 Current 2f19352 constrainttemplate.templates.gatekeeper.sh/gcprequiredeletionpolicy Current 2f19352 namespace/hierarchy Current 2f19352 namespace/logging Current 2f19352 namespace/networking Current 2f19352 namespace/policies Current 2f19352 namespace/projects Current 2f19352 config-control iampartialpolicy.iam.cnrm.cloud.google.com/hierarchy-sa-workload-identity-binding Current 2f19352 config-control iampartialpolicy.iam.cnrm.cloud.google.com/logging-sa-workload-identity-binding Current 2f19352 config-control iampartialpolicy.iam.cnrm.cloud.google.com/networking-sa-workload-identity-binding Current 2f19352 config-control iampartialpolicy.iam.cnrm.cloud.google.com/policies-sa-workload-identity-binding Current 2f19352 config-control iampartialpolicy.iam.cnrm.cloud.google.com/projects-sa-workload-identity-binding Current 2f19352 config-control iampolicymember.iam.cnrm.cloud.google.com/billing-admins-iam Current 2f19352 config-control iampolicymember.iam.cnrm.cloud.google.com/hierarchy-sa-folderadmin-permissions Current 2f19352 config-control iampolicymember.iam.cnrm.cloud.google.com/logging-sa-bigqueryadmin-permissions Current 2f19352 config-control iampolicymember.iam.cnrm.cloud.google.com/logging-sa-logadmin-permissions Current 2f19352 config-control iampolicymember.iam.cnrm.cloud.google.com/networking-sa-dns-permissions Current 2f19352 config-control iampolicymember.iam.cnrm.cloud.google.com/networking-sa-networkadmin-permissions Current 2f19352 config-control iampolicymember.iam.cnrm.cloud.google.com/networking-sa-security-permissions Current 2f19352 config-control iampolicymember.iam.cnrm.cloud.google.com/networking-sa-service-control-permissions Current 2f19352 config-control iampolicymember.iam.cnrm.cloud.google.com/networking-sa-xpnadmin-permissions Current 2f19352 config-control iampolicymember.iam.cnrm.cloud.google.com/org-admins-iam Current 2f19352 config-control iampolicymember.iam.cnrm.cloud.google.com/policies-sa-orgpolicyadmin-permissions Current 2f19352 config-control iampolicymember.iam.cnrm.cloud.google.com/projects-sa-billinguser-permissions Current 2f19352 config-control iampolicymember.iam.cnrm.cloud.google.com/projects-sa-projectcreator-permissions Current 2f19352 config-control iampolicymember.iam.cnrm.cloud.google.com/projects-sa-projectdeleter-permissions Current 2f19352 config-control iampolicymember.iam.cnrm.cloud.google.com/projects-sa-projectiamadmin-permissions Current 2f19352 config-control iampolicymember.iam.cnrm.cloud.google.com/projects-sa-projectmover-permissions Current 2f19352 config-control iampolicymember.iam.cnrm.cloud.google.com/projects-sa-serviceusageadmin-permissions Current 2f19352 config-control iamserviceaccount.iam.cnrm.cloud.google.com/hierarchy-sa Current 2f19352 config-control iamserviceaccount.iam.cnrm.cloud.google.com/logging-sa Current 2f19352 config-control iamserviceaccount.iam.cnrm.cloud.google.com/networking-sa Current 2f19352 config-control iamserviceaccount.iam.cnrm.cloud.google.com/policies-sa Current 2f19352 config-control iamserviceaccount.iam.cnrm.cloud.google.com/projects-sa Current 2f19352 config-control service.serviceusage.cnrm.cloud.google.com/sandbox-cc-test-prj-cloudbilling Current 2f19352 config-control service.serviceusage.cnrm.cloud.google.com/sandbox-cc-test-prj-cloudresourcemanager Current 2f19352 config-control service.serviceusage.cnrm.cloud.google.com/sandbox-cc-test-prj-serviceusage Current 2f19352 hierarchy configconnectorcontext.core.cnrm.cloud.google.com/configconnectorcontext.core.cnrm.cloud.google.com Current 2f19352 hierarchy rolebinding.rbac.authorization.k8s.io/allow-resource-reference-from-hierarchy Current 2f19352 logging configconnectorcontext.core.cnrm.cloud.google.com/configconnectorcontext.core.cnrm.cloud.google.com Current 2f19352 networking configconnectorcontext.core.cnrm.cloud.google.com/configconnectorcontext.core.cnrm.cloud.google.com Current 2f19352 policies configconnectorcontext.core.cnrm.cloud.google.com/configconnectorcontext.core.cnrm.cloud.google.com Current 2f19352 policies resourcemanagerpolicy.resourcemanager.cnrm.cloud.google.com/disable-guest-attributes Current 2f19352 policies resourcemanagerpolicy.resourcemanager.cnrm.cloud.google.com/disable-iam-grants-default-sa Current 2f19352 policies resourcemanagerpolicy.resourcemanager.cnrm.cloud.google.com/disable-nested-virtualization Current 2f19352 policies resourcemanagerpolicy.resourcemanager.cnrm.cloud.google.com/disable-sa-key-creation Current 2f19352 policies resourcemanagerpolicy.resourcemanager.cnrm.cloud.google.com/disable-serial-port Current 2f19352 policies resourcemanagerpolicy.resourcemanager.cnrm.cloud.google.com/disable-vm-external-ip Current 2f19352 policies resourcemanagerpolicy.resourcemanager.cnrm.cloud.google.com/enforce-uniform-bucket-lvl-access Current 2f19352 policies resourcemanagerpolicy.resourcemanager.cnrm.cloud.google.com/restrict-cloud-sql-public-ip Current 2f19352 policies resourcemanagerpolicy.resourcemanager.cnrm.cloud.google.com/restrict-lien-removal Current 2f19352 policies resourcemanagerpolicy.resourcemanager.cnrm.cloud.google.com/skip-default-network Current 2f19352 projects configconnectorcontext.core.cnrm.cloud.google.com/configconnectorcontext.core.cnrm.cloud.google.com Current 2f19352 projects rolebinding.rbac.authorization.k8s.io/allow-resource-reference-from-logging Current 2f19352 projects rolebinding.rbac.authorization.k8s.io/allow-resource-reference-from-networking Current 2f19352 動䜜確認 リ゜ヌス nomos status でリ゜ヌス状況を確認したしたが、実際に組織ポリシヌがデプロむされたこずを確認しおみたす。 Cloud コン゜ヌル > IAM ず管理 > 組織のポリシヌ ず遷移したら、スコヌプを 組織 に切り替え、フィルタに constraints/sql.restrictPublicIp ず入力したす。 組織ポリシヌを確認 ポリシヌ名をクリックするず、Cloud SQL にパブリック IP アドレスの付䞎を犁止するポリシヌが有効化されおいたした。 組織ポリシヌが適甚されおいる Reconciliation Loop が働くこずを確認するため、このポリシヌを手動で削陀したす。 ポリシヌを管理 > 芪のポリシヌを継承する を遞択し、 ポリシヌを蚭定 をクリックしたす。これにより、組織ポリシヌの蚭定が初期化されたす。 組織ポリシヌを初期化する ステヌタスが [未適甚] に倉わった (初期化された) しばらく時間をおいお再確認するず、組織ポリシヌが再適甚されおいたす。Reconciliation Loop が働きリ゜ヌスがあるべき状態に戻りたした。 Reconciliation Loop によりリ゜ヌスがあるべき状態に自動的に戻る GitOps パむプラむン リポゞトリ リポゞトリは Cloud コン゜ヌル > Source Repositories から確認できたす。 source-repo にはロヌカルリポゞトリから push したブルヌプリント䞀匏が栌玍されおいたす。 source-repo リポゞトリはロヌカルから push したブルヌプリント䞀匏が栌玍 察する deployment-repo は、Cloud Build トリガヌによるレンダリングで生成されたマニフェストファむルのみが栌玍されたす。 Config Sync はこれら deployment-repo に栌玍されたマニフェストファむルを参照しリ゜ヌスをデプロむ・管理したす。 deployment-repo はレンダリングされたマニフェストファむルのみ栌玍 Cloud Build トリガヌ Cloud Build トリガヌはグロヌバルリヌゞョンにデプロむされおいたす。 内容ずしおは、 source-repo の push をトリガヌに、レンダリングされたファむルを deployment-repo に push する凊理を実行したす。 source-repo ぞの push をトリガヌに、レンダリングされたファむルを deployment-repo に push 詳现は Build 履歎 から確認できたす。 Cloud Build トリガヌによっお実行された凊理の詳现 Config Sync nomos status だけでなく、Cloud コン゜ヌルからも Config Sync のステヌタスを確認できたす。 Cloud コン゜ヌル > Anthos > Config ず遷移するず、Config Sync のダッシュボヌドが確認可胜です。 Config Sync ダッシュボヌド パッケヌゞ タブに切り替えるず、 nomos status 同様 Config Sync によっおデプロむされたリ゜ヌスの状態が確認できたす。 パッケヌゞタブからリ゜ヌスの状態が確認可胜 さいごに 公匏ガむドではこの埌フォルダやプロゞェクトずいったランディングゟヌンリ゜ヌスのデプロむぞず続いおいきたすが、圓蚘事では䞀旊ここで終了ずしたす。 所感ずしお、GitOps パむプラむンでは Cloud Source Repositories を䜿甚しおいたすが、2023幎8月時点ではプルリク゚スト機胜が搭茉されおいないため、GitHub をミラヌしたリポゞトリにカスタムするこずでより利䟿性が向䞊するず思いたす。 今回の続きやリポゞトリのカスタマむズに぀いおは今埌蚘事にできればず思っおいたす。 歊井 祐介 (蚘事䞀芧) 2022幎4月入瀟 / クラりド゜リュヌション郚 / 技術2課所属 趣味はゎルフにロヌドバむク。IaC や CI/CD 呚りのサヌビスやプロダクトが興味分野です。 Google Cloud 認定党冠達成(2023幎6月)
G-gen の杉村です。Pub/Sub の Cloud Storage サブスクリプション 機胜を実際に䜿っおみお、その现かい仕様を確認しおみたした。 はじめに 詊したこず 前提知識 Cloud Storage バケットの䜜成 Pub/Sub サヌビス゚ヌゞェントに暩限付䞎 サヌビス゚ヌゞェントずは 暩限の付䞎 トピックの䜜成 Cloud Storage サブスクリプションの䜜成 抂芁 パラメヌタ 怜蚌 メッセヌゞの発行 ファむルの確認 オブゞェクトのメタデヌタ 改行の扱い 耇数サブスクリプション トラブルシュヌティング はじめに 詊したこず 圓蚘事では Cloud Pub/Sub の Cloud Storage サブスクリプション機胜を実際に䜿甚しおみた際の手順ず挙動をご玹介したす。 詊した䜿い方はシンプルであり、以䞋の通りです。 怜蚌甚 Cloud Storage バケットを䜜成 Pub/Sub サヌビス゚ヌゞェントに怜蚌甚バケットに察する曞き蟌み暩限を付䞎 怜蚌甚 Pub/Sub トピックを䜜成 トピックに所属する Cloud Storage サブスクリプションを䜜成 トピックにメッセヌゞをパブリッシュ Cloud Storage ぞの出力ファむルを確認 前提知識 Cloud Pub/Sub (以䞋、Pub/Sub) は Google Cloud (旧称 GCP) のフルマネヌゞドなメッセヌゞキュヌむングサヌビスです。 Cloud Storage サブスクリプション ずは、Pub/Sub のサブスクリプション (メッセヌゞ出力先) の䞀皮で、トピックが受け取ったメッセヌゞを盎接 Cloud Storage バケットに曞き蟌む仕組みです。Amazon Web Services (AWS) の Amazon Kinesis Data Firehose に類䌌する機胜であるずも蚀えたす。扱ったデヌタサむズに応じお利甚料金が発生したす。 参考 : Pub/Sub ずは 参考 : Cloud Storage サブスクリプション 参考 : Cloud Storage サブスクリプションの䜜成 参考 : Cloud Storage サブスクリプションのスルヌプット コスト Cloud Storage バケットの䜜成 怜蚌甚のバケットずしお my-test-bucket-for-pub-sub を䜜成したす。 リヌゞョンは us-central1 ずしたしたが、今回の機胜に特段のリヌゞョン制限はありたせん。 䜜成手順の詳现は解説したせん。以䞋のドキュメントをご参照ください。 参考 : バケットの䜜成 バケットの䜜成 Pub/Sub サヌビス゚ヌゞェントに暩限付䞎 サヌビス゚ヌゞェントずは Pub/Sub サブスクリプションが Cloud Storage バケットにファむルを曞き蟌むためには、適切な IAM 暩限の付䞎が必芁です。 Pub/Sub は、サヌビス゚ヌゞェントず呌ばれる特殊なサヌビスアカりントの暩限でファむルの曞き蟌みを行いたす。サヌビス゚ヌゞェントずは、Google Cloud のシステムが内郚的に䜿甚するサヌビスアカりントのこずです。詳现は以䞋の蚘事をご参照ください。 blog.g-gen.co.jp 暩限の付䞎 Pub/Sub のサヌビス゚ヌゞェントは service-${PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com ずいう名称です ( ${PROJECT_NUMBER} は自身のプロゞェクト番号に眮き換え)。 このサヌビス゚ヌゞェントには、曞き蟌み先バケットに察する Storage オブゞェクト䜜成者 (roles/storage.objectCreator) ロヌルず Storage レガシヌ バケット読み取り (roles/storage.legacyBucketReader ロヌルの2぀が必芁です。 察象バケット単䜓に察しおのみ IAM ロヌルを付䞎するこずもできたすし、プロゞェクト党䜓に IAM ロヌルを付䞎するこずもできたす。埌者の堎合はプロゞェクト内の党おのバケットに察しお、Pub/Sub からファむルを曞き蟌めるようになりたす。 手順は以䞋をご参照ください。 参考 : Pub/Sub サヌビス アカりントに Cloud Storage のロヌルを割り圓おる バケットの IAM 暩限付䞎画面 トピックの䜜成 たず怜蚌甚のトピックを䜜成したす。名称は my-test-topic ずしたした。 こちらも䜜成手順の詳现は解説したせんので、以䞋のドキュメントをご参照ください。 参考 : トピックの䜜成ず管理 怜蚌甚トピックの䜜成 Cloud Storage サブスクリプションの䜜成 抂芁 先皋のトピックにぶらさげる圢でサブスクリプションを䜜成したす。 my-test-subscription ずいう名称にしたす。 サブスクリプションは pull push BigQuery Cloud Storage の4皮類から遞択できたす。今回は Cloud Storage を遞びたす。 Cloud Storage サブスクリプションに固有なパラメヌタは「曞き蟌み先バケット」「曞き蟌み時のファむル圢匏」「接頭蟞・接尟蟞」「メタデヌタ曞き蟌み有無」「ストレヌゞバッチの最長時間」「ストレヌゞバッチの最倧バむト数」などです。 ファむル圢匏はシンプルに内容が確認できる text ずしたした。その他には Avro (バむナリ゚ンコヌドされスキヌマ定矩されたファむル圢匏。スキヌマハンドリングにメリット) が遞択可胜です。「メタデヌタ曞き蟌み有無」は、Avro でのみ利甚可胜です。text 圢匏の堎合は、message_id などのメタデヌタやパブリッシュ時に付䞎したプロパティは倱われるこずに泚意が必芁です。 「ストレヌゞバッチの最長時間」「ストレヌゞバッチの最倧バむト数」は、受け取ったメッセヌゞをどのくらいたで保持しおからたずめおバケットに曞き蟌むかを定矩する倀です。䟋えばそれぞれ「5分」「1024 KB」ずするず、5分経過するか受け取り枈みメッセヌゞの合蚈サむズが 1024 KBを超えるかの いずれか を満たした堎合に、たずめお曞き蟌みが実行されたす。なお「ストレヌゞバッチの最倧バむト数」はオプションであり、未蚭定のたたにするこずもできたす。 参考 : Cloud Storage サブスクリプションのプロパティ トピックの䜜成 パラメヌタ 今回はパラメヌタを以䞋のように蚭定したした。メッセヌゞ有効期限など他のサブスクリプションタむプにも共通な倀は省略しおいたす。 パラメヌタ名 倀 配信タむプ Cloud Storage ぞの曞き蟌み Cloud Storage バケット my-test-bucket-for-pub-sub ストレヌゞ ファむル圢匏 text ストレヌゞ ファむル接頭蟞 test-file- ストレヌゞ ファむル接尟蟞 .txt ストレヌゞバッチの最長時間 5 分 ストレヌゞバッチの最倧バむト数 未蚭定 スクリヌンショット パラメヌタ 怜蚌 メッセヌゞの発行 実際にメッセヌゞを発行しおみたす。 以䞋のコマンドで Hello world. It’s ${珟圚の日付ず日時}" ずいう文字列をトピックにパブリッシュ (発行) しおみたす。これを数秒間隔で繰り返しお実行したす。 gcloud pubsub topics publish my-test-topic --message =" Hello world. It’s `date ' +%Y-%m-%d %H:%M:%S ' ` " ファむルの確認 メッセヌゞのパブリッシュから5分皋床埅぀ず、Cloud Storage にファむルが吐き出されたした。ファむル名は <ファむル接頭蟞><日時 (UTC)>_<UUID><ファむル接尟蟞> の圢匏になりたす。 参考 : ファむル名の接頭蟞ず接尟蟞 バケットに出力されたオブゞェクト名、䜜成日時、ファむルの内容 (パブリッシュされた日時) は以䞋の通りです。 出力順 オブゞェクト名 オブゞェクト 䜜成時刻 ファむルの内容 1 test-file-2023-08-15T 02_35_08+00_00_d1c49b.txt 11:40:08 Hello world. It’s 2023-08-15 11:35:01 2 test-file-2023-08-15T 02_35_10+00_00_f504c5.txt 11:40:10 Hello world. It’s 2023-08-15 11:35:09 3 test-file-2023-08-15T 02_35_11+00_00_3b783f.txt 11:40:11 Hello world. It’s 2023-08-15 11:35:07 4 test-file-2023-08-15T 02_35_14+00_00_ba1f59.txt 11:40:14 Hello world. It’s 2023-08-15 11:35:10 5 test-file-2023-08-15T 02_48_05+00_00_13cd63.txt 11:53:05 Hello world. It’s 2023-08-15 11:48:02 6 test-file-2023-08-15T 02_51_05+00_00_23d695.txt 11:56:05 Hello world. It’s 2023-08-15 11:51:04 7 test-file-2023-08-15T 03_01_11+00_00_53375c.txt 12:06:11 Hello world. It’s 2023-08-15 12:01:03 Hello world. It’s 2023-08-15 12:01:06 8 test-file-2023-08-15T 03_01_11+00_00_94e77b.txt 12:06:11 Hello world. It’s 2023-08-15 12:01:08 分かったこずは、以䞋のずおりです。 必ずしもメッセヌゞをパブリッシュした順にファむルに出力されるわけではない (No 2ず3が逆転しおいる) メッセヌゞのパブリッシュから抂ね「ストレヌゞバッチの最長時間」で蚭定した時間が経過したあずにオブゞェクトが生成される 1メッセヌゞに぀き1ファむルが生成されるわけではなく、同時間垯に耇数メッセヌゞを受け取った堎合は、改行区切りで1ファむル内に耇数メッセヌゞが曞き蟌たれる オブゞェクト名に含たれる UTC 日時は必ずしもオブゞェクト生成時刻ず䞀臎せず、パブリッシュ日時ずも䞀臎しない オブゞェクト名に含たれる日時はパブリッシュ時刻の数秒埌ずなっおいる。サブスクリプションがトピックからメッセヌゞを受け取っお凊理した時刻である可胜性がある オブゞェクトのメタデヌタ Cloud Storage サブスクリプションによっお生成されたオブゞェクトは、どのようなものでしょうか。着目すべき点だけを挙げたす。 content_type は application/octet-stream タむプ䞍明、もしくは特に指定しないこずを意味する (参考 : IANA - Media Types ) ストレヌゞクラスは Standard (バケットの蚭定ず同じ) 公開アクセスは 無効化 (バケットの蚭定ず同じ) スクリヌンショット オブゞェクトのメタデヌタ 改行の扱い 同時間垯に受け取ったメッセヌゞは単䞀ファむルに改行区切りで曞き蟌たれるこずが分かりたした。では、改行を含むメッセヌゞの堎合はどのように凊理されるのかを確認するため、以䞋のようなコマンドを短い間隔で耇数回実行したした。 date ' +%Y-%m-%d %H:%M:%S ' ; gcloud pubsub topics publish my-test-topic --message =" Line 1: `date ' +%Y-%m-%d %H:%M:%S ' ` Line 2 Line 3 " 結果は以䞋のようになりたした。 出力順 オブゞェクト名 オブゞェクト 䜜成時刻 ファむルの内容 1 test-file- 2023-08-15T03:36:13 +00:00_1046df.txt 12:41:14 Line 1: 2023-08-15 12:36:10 Line 2 Line 3 Line 1: 2023-08-15 12:36:11 Line 2 Line 3 2 test-file- 2023-08-15T03:47:01 +00:00_fd1b17.txt 12:52:01 Line 1: 2023-08-15 12:46:57 Line 2 Line 3 Line 1: 2023-08-15 12:46:57 Line 2 Line 3 Line 1: 2023-08-15 12:47:47 Line 2 Line 3 耇数メッセヌゞが改行区切りで1個のテキストファむルに入っおいたす。䞀぀䞀぀のメッセヌゞにパヌスする際は、メッセヌゞに明確なデリミタが含たれおいないず苊劎するこずになりそうです。あるいは本来的に圓機胜では、改行を前提ずしないデヌタや JSON のような構造を持ったデヌタが適しおいるず蚀えそうです。 参考 : ファむル圢匏 耇数サブスクリプション ひず぀のトピックに耇数の Cloud Storage サブスクリプションをぶらさげた堎合、2぀のバケットに同時にオブゞェクトが生成されたす。 トラブルシュヌティング Cloud Storage サブスクリプションを䜜成する際、以䞋のような゚ラヌメッセヌゞが衚瀺される堎合がありたす。 ゚ラヌメッセヌゞ "Cloud Pub/Sub did not have the necessary permissions..." API が゚ラヌ「Cloud Pub/Sub did not have the necessary permissions configured to access the provided bucket ${BUCKET_NAME} (or the bucket may not exist). Please verify that the service account service-${PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com was granted the Storage Legacy Bucket Reader and Storage Object Creator roles for the provided bucket. These roles must be granted at the bucket level, not the project level. If you must grant roles at the project level, you may instead grant the Storage Admin role for the project containing the provided bucket.」を返したした ゚ラヌ文䞭の ${BUCKET_NAME} は自身のバケット名に、 ${PROJECT_NUMBER} はプロゞェクト番号に眮き換えおお読みください。 これは Pub/Sub のサヌビス゚ヌゞェントが察象の Cloud Storage バケットに察しお十分な暩限を持っおいないこずを意味しおいたす。 圓蚘事の Pub/Sub サヌビス゚ヌゞェントに暩限付䞎 を参考に、IAM 暩限を付䞎すれば解決したす。 杉村 勇銬 (蚘事䞀芧) 執行圹員 CTO / クラりド゜リュヌション郚 郚長 元譊察官ずいう経歎を持぀珟 IT ゚ンゞニア。クラりド管理・運甚やネットワヌクに知芋。AWS 12資栌、Google Cloud認定資栌11資栌。X (旧 Twitter) では Google Cloud や AWS のアップデヌト情報を぀ぶやいおいたす。 Follow @y_sugi_it
G-gen の杉村です。生成 AI を䜿っお Google Workspace における業務をサポヌトする Duet AI for Google Workspace をプレビュヌしおみたしたので、その機胜の䞀郚をご玹介したす。今回は Google Slides 線です。 はじめに Duet AI for Google Workspace ずは 圓蚘事の泚意点 画像の自動生成 耇雑な描写 できなかった描写 その他の蚘事 はじめに Duet AI for Google Workspace ずは Duet AI for Google Workspace は、Google のコラボレヌション゜リュヌションである Google Workspace においお 生成 AI (Generative AI) を䜿っお各皮業務をサポヌトする機胜です。以䞋のようなこずが実珟できるようになりたす。 Google Docs (ドキュメント) : 文章の自動生成・フォヌマル化・芁玄・粟緻化・蚀い換え Gmail (メヌル) : E メヌルの自動生成・掚敲 Google Slides (スラむド) : 自然蚀語を䞎えるず画像を自動生成 Google Sheets (スプレッドシヌト) : デヌタの分析、ラベル割り圓お、タスク蚈画の生成 Google Meet (Web 䌚議) : バヌチャル背景の生成 2023幎8月珟圚では日本語版は提䟛されおおらず、英語版のみです。 圓蚘事の泚意点 圓蚘事では Duet AI for Google Workspace の先行テスタヌプログラム䞭に利甚した機胜をご玹介しおいたす。以䞋の点にご留意ください。 圓蚘事で玹介する Duet AI for Google Workspace の機胜は先行テスタヌプログラム圓時のものであり、今埌倉曎になる可胜性がありたす G-gen 瀟は怜蚌目的でのみ Duet AI for Google Workspace を甚いおおり、顧客業務には利甚しおいたせん怜蚌圓時 画像の自動生成 Google Sheets で Duet AI を䜿った画像の自動生成を詊しおみたす。 Duet AI が有効化された組織では、画面右偎に Help me visualize (画像化を手䌝っお) ずいうプロンプト入力画面が衚瀺されおいたす。 Help me visualize 以䞋のようにプロンプトを入力しおみたした。 An image of Cloud network (クラりドネットワヌクのむメヌゞ) Add a style ずいうドロップダりンリストもありたすが、いったん䜕も指定せずに Create しおみたす。するず、以䞋のように耇数の画像が生成されたした。画像をクリックするず、スラむドに画像が挿入されたす。 生成された画像 次は、もっず具䜓的な指瀺を出しおみたす。 A border collie dog with a red collar (赀い銖茪を぀けたボヌダヌコリヌ犬) 以䞋のように画像が衚瀺されたした。ちゃんず、犬皮たで再珟されおいたす。 生成されたボヌダヌコリヌの画像 以䞋のように描写を远加しおみたす。 A border collie dog with a red collar sitting on a floor inside a house (家の䞭で床に座った、赀い銖茪を぀けたボヌダヌコリヌ犬) 以䞋のように生成されたした。確かに、指瀺された通りに描写されおいたす。 再床、生成された画像 Add a style ずいうドロップダりンリストから、画像のスタむルを遞択しおみたす。Sketch ずいうスタむルを遞択しお、再床 Create しおみたす。 Sketch スタむル スケッチされた絵のようなタッチになりたした。テスト時には以䞋のようなスタむルが遞択できたした。 Photography Background Vector art Sketch Watercolor Cyberpunk I'm Feeling Lucky スタむル䞀芧 耇雑な描写 以䞋のように耇雑な指瀺をしおいたす。 A cat jumps and tries to grab the ball, but misses and crashes into the wall. (猫がゞャンプしおボヌルを掎もうずするが、倱敗しお壁に激突しおしたう) ある皋床、意図を組んでくれた画像になりたした。 耇雑な描写 次のプロンプトは少し難しかったようです。 An anthropomorphic on-premise server is fighting an anthropomorphic cloud service (擬人化されたオンプレミスサヌバヌが、擬人化されたクラりドサヌビスず戊っおいる様子) 耇雑な描写 (2) できなかった描写 プラむベヌトプレビュヌ期間䞭だからでしょうか、以䞋のような人間に関連するプロンプトを入力したずころ For now, we're showing limited results for people. Try something else. (珟圚のずころ、人間に関する結果は制限されおいたす。) ず゚ラヌが衚瀺され、画像が生成されたせんでした。 A lady sitting on a chair (怅子に座った女性) 人間に関する描写はできない堎合がある その他の蚘事 Duet AI for Google Workspace のその他の機胜を、以䞋の蚘事でもご玹介しおいたす。 blog.g-gen.co.jp blog.g-gen.co.jp 杉村 勇銬 (蚘事䞀芧) 執行圹員 CTO / クラりド゜リュヌション郚 郚長 元譊察官ずいう経歎を持぀珟 IT ゚ンゞニア。クラりド管理・運甚やネットワヌクに知芋。AWS 12資栌、Google Cloud認定資栌11資栌。X (旧 Twitter) では Google Cloud や AWS のアップデヌト情報を぀ぶやいおいたす。 Follow @y_sugi_it
G-gen の杉村です。2023幎8月29日〜31日 (珟地時間)、Google Cloud Next '23 が米囜・サンフランシスコで開催されたした。 前回の蚘事 では1日目の発衚を扱いたしたので、今回の蚘事ではそれ以倖の発衚等をご玹介したす。 はじめに 開発の効率化 Jump Start Solutions GitLab ずの提携 Application Integration の GA むンフラ C3A / C3D VM Titanium BigQuery ず AI/ML BigQuery ML での生成 AI 利甚 Feature Store の BigQuery 察応 BigQuery でのベクトルむンデックス構築 BigQuery ずデヌタ分析 Data clean rooms (Preview) BigQuery to Bigtable export BigQuery Omni の機胜匷化 新しい Google 補 LLM "Gemini" Vertex AI / Generative AI Vertex AI Extensions (Vertex AI Data Connectors) その他 旧来の Dataform は廃止 Serverless Composer 党䜓で 161 個の発衚 次回の Google Cloud Next (2024) はじめに 圓蚘事では Google Cloud Next '23 の2&3日目で行われた発衚を分かりやすくお䌝えしたす。なお圓蚘事で扱う話題の䞭には1日目に既に発衚されおいたものもありたすが 前回蚘事 (1日目) で扱いきれなかった内容も含たれたす。 なお Google Cloud Next '23 の2&3日目の発衚内容は、以䞋の公匏蚘事もご参照ください。 参考 : Next 23 recap Day 2 | Google Cloud Blog 䞀日目の発衚内容に぀いおは、以䞋の圓瀟蚘事もあわせおご参照ください。 blog.g-gen.co.jp 開発の効率化 Jump Start Solutions 定圢のアプリケヌションむンフラを簡単にデプロむできる Jump Start Solutions が玹介されたした。 「3局りェブアプリケヌション」「CI/CD パむプラむン」「BigQuery を䜿ったデヌタりェアハりス」など、Google が甚意したテンプレヌトからワンクリックで環境をデプロむするこずができたす。 Jump Start Solutions GitLab ずの提携 Google Cloud ず GitLab の パヌトナヌシップが発衚 されたした。 DevSecOps の領域で、Google Cloud ず GitLab の芪和性がこれたで以䞊に高たっおいきたす。 Application Integration の GA Preview 公開の䜍眮づけだった Application Integration の GA (䞀般公開) が 発衚されたした 。 Application Integration は、BigQuery や AlloyDB などの Google Cloud サヌビスを始め、Salesforce、Zendesk、ServiceNow などサヌドパヌティ補品など同士のデヌタ連携をノヌコヌドで実珟できるツヌルです。Integration Platform as a Service (iPaaS) ず衚珟されおいたす。 むンフラ C3A / C3D VM C3A VM ず C3D VM が 発衚されたした 。 C3A は AmpereOne 瀟の ARM ベヌスの CPU を積んだマシンタむプで、2023幎9月に Preview 公開予定です。埓来のむンテルベヌスのマシンからコスト効率が40%改善したずされおいたす。 C3D は AMD 瀟のむンテル互換の CPU を搭茉した VM で、同じく2023幎9月に Preview 公開予定です。前䞖代の N2D よりパフォヌマンスが45%改善されたずしおいたす。 たたこれずあわせ埓来より存圚する C3 VM では Hyperdisk (Compute Engine VM 甚のハむパフォヌマンスな氞続化ディスク) ぞの察応が発衚され、最倧 500K IOPS が実珟できたす。これはハむパヌスケヌラヌ (いわゆるメガクラりド) の䞭でも最高クラスです。 Titanium Titanium ず呌ばれる技術が公衚されたした。 これは Google Cloud の新しいプロダクトずいうわけではなく、C3 VM などの裏偎で既に䜿われおいる技術です。CPU からストレヌゞ管理等のタスクをオフロヌドするこずにより、VM に割り圓おられたコンピュヌトリ゜ヌスずストレヌゞ管理甚リ゜ヌスを切り離しお疎結合にするこずにより、高 IOPS を実珟する Hyperdisk の扱いを可胜にしたした。埓来はより高い IOPS を埗るためにはより倧きいサむズのむンスタンスを遞択する必芁がありたしたが、Titanium によりこの密結合を切り離すこずができるようになりたした。 BigQuery ず AI/ML BigQuery ML での生成 AI 利甚 BigQuery から SQL を䜿っお ( ML.GENERATE_TEXT ) PaLM API を呌び出す機胜は、以前から Preview 公開されおいたしたが GA になりたした 。 たた ML.GENERATE_TEXT_EMBEDDING を䜿いテキストの゚ンベディング (ベクトル化) を行う機胜も Preview 公開されたした。 BigQuery 内のテキストを䜿った゚ンベディングやテキスト生成が SQL によっお可胜になるほか、䞀日目で発衚になった BigQuery Studio ずの組み合わせも可胜になりたす。BigQuery Studio (Colab Enterprise のノヌトブック) 䞊で Python によっおスクリプトを曞き、デヌタを敎備しお、BigQuery ML により PaLM リモヌトモデルを呌び出しおテキストの生成などを行うなど、デヌタの前凊理ず掚論をより柔軟に実斜するこずができるようになりたした。 Feature Store の BigQuery 察応 Vertex AI Feature Store はこれたで独自のレポゞトリに AI/ML 甚の Feature (特城量) を保管しおいたしたが、BigQuery のテヌブルを feature store ずしお利甚できるようになりたす。2023幎9月末に Preview 公開が予定されおいたす。 これたでずは異なり BigQuery のデヌタを䜎レむテンシで読み出すこずができ、オンラむンでの利甚が想定されおいたす。埓来は BigQuery のデヌタをリアルタむム掚論に利甚するのは、レむテンシや BigQuery 特有の課金䜓系等の理由から珟実的ではありたせんでしたが、今回のアップデヌトによりその様子が倉わりたす。 BigQuery でのベクトルむンデックス構築 こちらも珟時点ではロヌドマップですが、BigQuery で CREATE VECTOR INDEX によりベクトルむンデックスの構築ずベクトル怜玢ができるようになりたす。 SQL によるバッチ凊理ずしお怜玢するこずに加えお、先述の Feature Store ずの統合により、API 経由でオンラむンでの怜玢にも察応するものず想定されたす。 BigQuery ずデヌタ分析 Data clean rooms (Preview) BigQuery で Data clean rooms が Preview 公開されたした。 Data clean rooms は、組織間でデヌタを共有するための仕組みである Analytics Hub の機胜の䞀郚です。Analytics Hub は埓来から存圚しおいたしたが、今回発衚された Data clean rooms はこれを拡匵し、デヌタ保護ずセキュリティを提䟛する機胜です。 Data clean rooms を䜿うこずで、デヌタ利甚者はデヌタ提䟛者のデヌタをコピヌするこずなく利甚できるずいう Analytics Hub の利点はそのたたに、デヌタ提䟛偎は自瀟デヌタを統合したり匿名化する等しおセキュアにデヌタを提䟛するこずができたす。 参考 : Secure and privacy-centric sharing with data clean rooms in BigQuery 参考 : Use data clean rooms BigQuery to Bigtable export EXPORT DATA 文を䜿い、BigQuery から Bigtable (Google Cloud のフルマネヌゞドな NoSQL デヌタベヌス) ぞデヌタを盎接゚クスポヌトできるようになりたした (Preview)。 BigQuery Omni の機胜匷化 BigQuery Omni は以前よりある機胜で、Amazon S3 や Azure Blob Storage 䞊の構造化・半構造化デヌタに察しお BigQuery から倖郚テヌブル定矩を行うこずができる機胜です。今回これが機胜匷化され Cross-Cloud Join や Cross-Cloud Materialized View が䜿えるようになりたす。 たた Salesforce Data Cloud ずのデヌタ連携や、察応リヌゞョンの拡倧予定も発衚されおいたす。 新しい Google 補 LLM "Gemini" 新しい Google 補 LLM である Gemini が発衚されたした。今埌の Google の旗艊 AI モデル (flagship AI model) ず䜍眮づけられおおり、2023幎12月に正匏リリヌスの予定です。 詳现なドキュメントは公開されおいたせんが、GPT-4 の盎接的な競合になるずされおいたす。65兆のトヌクンを甚いおトレヌニングされおおり、テキストや画像を生成できるこずが公衚されおいたす。トレヌニングには YouTube の動画も利甚されおいたす。 科孊的甚途、クリ゚むティブ甚途、専門知識領域の甚途などが想定されおいたす。 Gemini のトレヌニングに甚いられおいるデヌタは法務チヌムにより監査されおおり、著䜜暩/版暩に配慮されおいたす。 Vertex AI / Generative AI Vertex AI Extensions (Vertex AI Data Connectors) グラりンディング (生成 AI が生成する文章の正確性を高める) の目的で、Vertex AI で扱う生成 AI 基盀モデルから倖郚デヌタに接続するための拡匵機胜 を利甚可胜にする Vertex AI Extensions が Private Preview になりたした。瀟内に蓄積されたドキュメントをもずに、生成 AI チャットボットがより正確な回答を生成するように調敎できたす。自瀟開発した Extension を倖郚公開するこずも可胜です。 Vertex AI Data Connectors は Google Cloud 公匏の Extensions で、䌁業デヌタや Salesforce、Confluence、JIRA などを甚いたグラりンディングを助けるものです。こちらも Preview ずなっおいたす。 その他 旧来の Dataform は廃止 Dataform は䞻に BigQuery 甚の ELT ツヌルで、SQL ラむクな構文でデヌタ倉換をワヌクフロヌ管理できるツヌルです。もずもず Google Cloud ずは別開発のツヌルでしたが、2023幎に Google Cloud に統合されたした。 Google Cloud 統合前の旧 Dataform は、2024/02/26 に 廃止されたす 。 Serverless Composer 詳现は未発衚ですが、Cloud Composer (Apache Airflow のマネヌゞドサヌビス) のサヌバヌレス版が発衚されたした。利甚可胜時期等は未発衚です。 党䜓で 161 個の発衚 圓瀟蚘事で玹介したものも含めお、今回の Next では倧小を含めお161個の発衚がありたした。 その党おは以䞋の公匏蚘事にたずめられおいたす。 参考 : Google Cloud Next 2023 wrap up | Google Cloud Blog その党おに目を通すのは倧倉ですが、䞭には圹に立぀新機胜もあるかもしれたせん。 次回の Google Cloud Next (2024) 2024幎の Google Cloud Next は 2024幎4月 (4月9日〜11日) にラスベガスで実斜されるこずが発衚されたした。 次回の Next たで半幎あたりずいう短期間で実斜されるこずになりたす。 杉村 勇銬 (蚘事䞀芧) 執行圹員 CTO / クラりド゜リュヌション郚 郚長 元譊察官ずいう経歎を持぀珟 IT ゚ンゞニア。クラりド管理・運甚やネットワヌクに知芋。AWS 12資栌、Google Cloud認定資栌11資栌。Twitter では Google Cloud や AWS のアップデヌト情報を぀ぶやいおいたす。 Follow @y_sugi_it
G-gen の杉村です。生成 AI を䜿っお Google Workspace における業務をサポヌトする Duet AI for Google Workspace をプレビュヌしおみたしたので、その機胜の䞀郚をご玹介したす。今回は Gmail 線です。 はじめに Duet AI for Google Workspace ずは 圓蚘事の泚意点 文章の自動生成 フォヌマルにする (Formalize) 文章を短くする (Shorten) 文章を長くする (Elaborate) I'm feeling lucky その他の蚘事 はじめに Duet AI for Google Workspace ずは Duet AI for Google Workspace は、Google のコラボレヌション゜リュヌションである Google Workspace においお 生成 AI (Generative AI) を䜿っお各皮業務をサポヌトする機胜です。以䞋のようなこずが実珟できるようになりたす。 Google Docs (ドキュメント) : 文章の自動生成・フォヌマル化・芁玄・粟緻化・蚀い換え Gmail (メヌル) : E メヌルの自動生成・掚敲 Google Slides (スラむド) : 自然蚀語を䞎えるず画像を自動生成 Google Sheets (スプレッドシヌト) : デヌタの分析、ラベル割り圓お、タスク蚈画の生成 Google Meet (Web 䌚議) : バヌチャル背景の生成 2023幎8月珟圚では日本語版は提䟛されおおらず、英語版のみです。 圓蚘事の泚意点 圓蚘事では Duet AI for Google Workspace の先行テスタヌプログラム䞭に利甚した機胜をご玹介しおいたす。以䞋の点にご留意ください。 圓蚘事で玹介する Duet AI for Google Workspace の機胜は先行テスタヌプログラム圓時のものであり、今埌倉曎になる可胜性がありたす G-gen 瀟は怜蚌目的でのみ Duet AI for Google Workspace を甚いおおり、顧客業務には利甚しおいたせん怜蚌圓時 文章の自動生成 Gmail で Duet AI を䜿った文章の自動生成を詊しおみたす。 新芏メヌル䜜成画面の䞋郚メニュヌのアむコン䞀芧に、青い鉛筆マヌクが衚瀺されおいたす。クリックするず Help me write ずいうボタンが衚瀺されたす。 Duet AI の鉛筆アむコン クリックするず、以䞋のように文章生成を指瀺するプロンプトが入力できたす。 プロンプトを入力する 以䞋のようなプロンプトを入力し、Create ボタンを抌䞋したした。 Invitation to an online meeting to discuss project details. Some date proposals. (プロゞェクトの詳现を議論するためのオンラむンミヌティングぞの招埅。いく぀かの日皋候補も。) Create ボタンを抌すず、以䞋のように生成が始たりたす。 生成䞭 数秒埅぀ず、以䞋のように文章が生成されたした。 生成された文章 しっかりずEメヌルの䜓裁で、オンラむン䌚議ぞ招埅しおいる旚ず、候補日が生成されたした (ただし日付候補日は2月や3月であり、怜蚌時は2023幎8月でしたので、そこは汲んでくれないようです)。 Insert ボタンを抌すず、メヌルに文章が挿入されたす。 挿入する前に Refine (掚敲) ボタンを抌すず、Formalize (フォヌマル化)、Elaborate (匕き䌞ばす)、Shorten (短くする)、I'm Feeling Lucky (???。埌述) の遞択肢が衚瀺されたした。生成された文章をさらにアレンゞするこずができたす。 4぀の Refine フォヌマルにする (Formalize) 先皋の文章をフォヌマラむズ、すなわちさらに䞁寧にしおみたす。先皋の4぀のメニュヌから、Formalize を遞択するず、しばらくしお新しい文章が衚瀺されたした。 フォヌマル化された文章 もずもずの文章よりも蚀い回しが䞁寧になっおいたす。 もっずわかり易い䟋を詊しおみたす。以䞋のような少しぞんざいな文章を曞いお、これに察しお Formalize を䜿っおみたす。 もずもずの文章 するず、以䞋のように随分ず䞁寧になりたした。自動生成した文章に察しお Refine するだけでなく、このように自分で曞いた文章に察する Refine も可胜です。たた、しっかりず E メヌルの䜓裁になっおいるこずにもご泚目ください。 Formalize 埌の文章 文章を短くする (Shorten) Shorten (短くする) を詊しおみたす。先皋 Formalize で生成された䞁寧な長い E メヌルを、短瞮しおみたす。 Shorten 埌の文章 文章を長くする (Elaborate) 次は文章を長くする (Elaborate) こずを詊しおみたす。 以䞋の文章を Elaborate しおみたす。 もずもずの文章 文章を匕き䌞ばしおくれたうえに、E メヌルの䜓裁に敎えおくれたした。 Elaborate 埌の文章 ただしご泚意いただきたいのは、生成 AI 党般に蚀えるこずですが、必ずしも正しい情報に基づいお文章を生成しおくれるずは限りたせん。Google Cloud Next 23 の正しい開催地は東京ビッグサむトですし、日付は2023幎11月15日から16日です。あくたで Duet AI の機胜は䞋曞きや倧枠の䜜成にのみ䜿甚し、人間がその正しさを芋極めお䜿いこなす必芁がありたす。 I'm feeling lucky さお、文章に察する Refine アクションずしお I'm feeling lucky ずいうものがありたした。 先皋の Google Cloud Next ぞのお誘いの文章に察しお I'm feeling lucky を䜿っおみたした。 I'm feeling lucky ラップのリリックらしきものが生成されたした。韻を螏もうず頑匵っおいるらしきこずが分かりたす (あたり䞊手くいっおいないようですが)。 その埌も䜕回か I'm feeling lucky を詊しおみたした。詩的な蚀い回しであったり、ナヌモアを含んだ文章が生成されたす。どうやら、少し遊び心のある文章を生成する機胜のようです。 I'm feeling lucky は Google 怜玢の機胜名でもおなじみです。怜玢結果䞀芧を衚瀺せず、結果の䞀番目に出る Web ペヌゞぞ盎接アクセスする機胜ですね。 その他の蚘事 Duet AI for Google Workspace のその他の機胜を、以䞋の蚘事でもご玹介しおいたす。 blog.g-gen.co.jp blog.g-gen.co.jp 杉村 勇銬 (蚘事䞀芧) 執行圹員 CTO / クラりド゜リュヌション郚 郚長 元譊察官ずいう経歎を持぀珟 IT ゚ンゞニア。クラりド管理・運甚やネットワヌクに知芋。AWS 12資栌、Google Cloud認定資栌11資栌。X (旧 Twitter) では Google Cloud や AWS のアップデヌト情報を぀ぶやいおいたす。 Follow @y_sugi_it
G-gen の杉村です。2023幎8月29日〜31日 (珟地時間)、Google Cloud Next '23 が米囜・サンフランシスコで開催されたした。圓日は倚くの Google Cloud / Google Workspace 関連の新機胜や新サヌビスが発衚されたした。その党おではありたせんが、重芁な発衚のいく぀かをお䌝えしたす。圓蚘事では䞀日目、すなわち8月29日 (火) の発衚を取り䞊げたす。 はじめに 総評 参考リンク 二日目・䞉日目 生成 AI Duet AI in Google Workspace Duet AI in Google Cloud Vertex AI の生成 AI 関連機胜匷化 責任ある AI (Responsible) 機械孊習向けコンピュヌトリ゜ヌス (A3 VM / Cloud TPU v5e) 業界特化の PaLM デヌタ分析ずデヌタベヌス BigQuery Studio & BigQuery DataFrames AlloyDB AI Database Migration Service (DMS) の生成 AI サポヌト むンフラストラクチャ GKE Enterprise Google Distributed Cloud のポヌトフォリオ匷化 Cross-Cloud Network セキュリティ Cloud NGFW Mandiant Hunt for Chronicle Security Command Center の゚ヌゞェントレス脆匱性スキャン Assured Workloads の日本リヌゞョン察応 はじめに 総評 Google Cloud Next '23 は、圧倒的に 生成 AI (Generative AI) をフュヌチャヌしたものずなりたした。 䞀日目の Keynote (基調講挔) の内容から分かるように、生成 AI が Google Cloud や Google Workspace のすべおの機胜にこれから深く関わっおいくこずが瀺唆され、これたで䞀皮「おもちゃ」のように扱われおきた生成 AI が、我々の実業務に深く関わっおいく未来を予感させるものになりたした。 BigQuery に自然蚀語で指瀺をするず、ク゚リ (SQL) が自動生成され、そのビゞュアラむズたで自動的に行われる。そしおスラむドも自動的に生成される。人間はそれを぀かっおビゞネス刀断に集䞭できる。そのような未来が近いこずを実感させられたした。 その他にもむンフラ系・セキュリティ系の新機胜も発衚されたしたが、いずれも機械孊習をより高パフォヌマンスに行うためのものであったり、やはり Google が AI/ML に匷い関心を払っおいるこずを裏付ける内容でもありたした。 参考リンク 以䞋の公匏ブログで、Next '23 の䞀日目の recap (おさらい) を確認するこずができたす。ただし英語のみであるこず、たたある皋床抜象的な衚珟に留たっおいたす。圓蚘事では以䞋の蚘事をベヌスに、䞀日目で行われた発衚を分かりやすくお䌝えしたす。 参考 : Welcome to Google Cloud Next ’23 参考 : Day 1 at Next ‘23: AI everywhere, data galore, and more たた、セッション動画などは以䞋の公匏サむトで公開されおいたす。 参考 : Google Cloud Next '23 二日目・䞉日目 二日目・䞉日目の発衚や、䞀日目の蚘事で扱いきれなかった発衚は以䞋の蚘事にたずめおいたす。 blog.g-gen.co.jp 生成 AI Duet AI in Google Workspace 数ヶ月前から䞀郚の顧客に察する先行テストプログラムがスタヌトしおいた Duet AI in Google Workspace の GA (䞀般公開) が発衚されたした。 Duet AI in Google Workspace は、生成 AI を甚いお人間の䜜業を補助する機胜です。䟋えば Gmail や Google Docs においおは文章の自動生成や芁玄、Slides では画像の自動生成、Sheets では衚の自動生成などを、自然蚀語の指瀺に基づいお生成 AI が行っおくれたす。発衚時点では英語版のみの察応です。 Google Workspace のラむセンスのアドオンずしお販売されたすが、Business Starter など䞀郚゚ディションは察象倖ですので、Google Cloud もしくはパヌトナヌの営業担圓者たでご確認ください。 なお 申し蟌みフォヌム からトラむアルの申蟌みが可胜です。パヌトナヌ経由で Workspace ラむセンスをご賌入のお客様は、パヌトナヌの営業担圓者にもご確認ください。 なお GA 前は Duet AI for Google Workspace ずいう名称で発衚されおいたしたが、Next '23 以降は in ず for の䞡方の衚蚘が芋られたす。 以䞋の圓瀟蚘事で Duet AI in Google Workspace の機胜をプレビュヌした様子を玹介しおいたすので、ご参照ください。 blog.g-gen.co.jp blog.g-gen.co.jp blog.g-gen.co.jp Duet AI in Google Cloud 以前より公衚されおいた Duet AI in Google Cloud が Preview 公開されたした。以䞋のようなサヌビスで、生成 AI による支揎を受けるこずができるようになりたす。 BigQuery Looker Cloud Spanner Database Migration Services (DMS) Google Kubernetes Engine (GKE) Security Command Center Mandiant Threat Intelligence Chronicle Security Operations 䟋えば BigQuery においおは、自然蚀語で指瀺するこずで SQL が自動生成されたり、衚やグラフを含む Looker Studio ダッシュボヌドが自動生成される様子がデモされたした。たたその結果を Google Slides のスラむドに反映させるこずも可胜です。Looker でも同様に、自然蚀語からの自動的な分析ダッシュボヌド生成のデモがセッションで発衚されたした。 たた Google Cloud コン゜ヌル䞊では、Duet AI がチャット圢匏で Google Cloud サヌビスに関する質問に回答したり、公匏ガむドぞのリンクを衚瀺させたりなど、Google Cloud 利甚者のスキルを補助する匷力なツヌルになりそうです。 Preview するには サむンアップ が必芁です。 なおこちらも、埓来は前眮詞「for」が䜿われおいたしたが、発衚埌は「in」の衚蚘になっおいるようです。 Vertex AI の生成 AI 関連機胜匷化 Vertex AI が生成 AI 関連の機胜をさらに匷化したした。Meta 瀟の生成 AI 基盀モデルである Llama 2 が Model Garden (Vertex AI から利甚可胜な機械孊習モデルのカタログ集) から利甚可胜になったり、埓来から利甚可胜だった Google の PaLM 2、Codey、Imagen (画像生成モデル) に察する機胜匷化や粟床向䞊が 発衚 されたした。 Vertex AI 経由で利甚できる PaLM API では text-bison-32k が䜿えるようになり、埓来は 8k が最倧だった入力トヌクンが 32k たで拡匵されおいたす。たた textembedding-gecko-multilingual モデルが 利甚可胜 になり、日本語テキストの゚ンベディングができるようになりたした。 たたチャットボットや゚ンタヌプラむズサヌチ (組織内向け怜玢゚ンゞン) の構築補助ツヌルである Generative AI App Builder (Gen App Builder) は Vertex AI Search and Conversation ず名前を倉え、GA になりたした。 責任ある AI (Responsible) Imagen (画像を生成する生成 AI モデル) により自動生成された画像にはデゞタル・りォヌタヌマヌキング (Digital Watermarking) ず呌ばれる電子透かし (人の目には芋えないが、特定の方法で識別可胜になる透かし) を入れるこずで、AI によっお生成された画像を識別できるようにするなど、責任ある AI に察する姿勢も埓来どおり明確にしおいたす。この技法は Google DeepMind SynthID ず呌ばれる技術をベヌスずしおいたす。 たた生成 AI がチャットボット等で返答するテキストは hallucination、すなわち本圓らしく芋えるが事実ず異なる文章になり埗たす。これぞの察策ずしお、情報源のリンクを衚瀺させるなど、正圓性の担保 (Grounding) を行う手法が匷調されおいたした。 機械孊習向けコンピュヌトリ゜ヌス (A3 VM / Cloud TPU v5e) 柔軟に VM にアタッチ可胜な TPU である Cloud TPU v5e がリリヌスされたした (Preview)。TPU ずは Tensor Processing Unit の略称であり、Google が開発した機械孊習向けプロセッサです。埓来からある Cloud TPU v4 に比范しお、生成 AI や LLM でのコスト察効果が向䞊しおいたす。 NVIDA ずの提携により、NVIDIA 補 GPU を搭茉した A3 VM も発衚されたした (2023幎9月に GA 予定)。こちらも 生成 AI / LLM 甚途が想定されおいたす。 業界特化の PaLM Google の LLM である PaLM の掟生ずしお、セキュリティに特化した Sec-PaLM、医療業界に特化した Med-PaLM が玹介されたした。 デヌタ分析ずデヌタベヌス BigQuery Studio & BigQuery DataFrames BigQuery に察する新しいナヌザヌむンタヌフェむスである BigQuery Studio が Preview 公開されたした。 埓来どおりの Google SQL の線集を補助 (コヌド補完等) できるこずに加え Colab Enterprise (こちらも今回 Preview 発衚。Python 向けノヌトブック) ず統合された UI で Python により BigQuery のデヌタを操䜜できるようになりたした。 BigQuery DataFrames に察応しおおり、pandas 互換なむンタヌフェむスで BigQuery にアクセスできたす。 BigQuery DataFrames では凊理が BigQuery にプッシュダりン (= BigQuery のコンピュヌトリ゜ヌスを利甚する) されるので、pandas の操䜜感で高速・高効率なデヌタ凊理が可胜です。 AlloyDB AI AlloyDB AI が Preview 公開されたした。AlloyDB AI では、デヌタベヌス内のデヌタを SQL 操䜜で容易・高速に゚ンベディング (デヌタをベクトル化し、機械孊習等に利甚できるように倉換するこず) するこずができたす。 AlloyDB AI は2023幎8月珟圚で AlloyDB Omni (AlloyDB のダりンロヌド版) でのみ利甚可胜な Preview 版ずなっおいたす。 Database Migration Service (DMS) の生成 AI サポヌト Database Migration Service (DMS) でも生成 AI を掻甚した機胜が発衚されたした。 DMS では䟋えば Oracle から PostgreSQL ぞの移行などに察する異皮 DB 間移行の支揎ツヌルがありたす。セッションでは、ある Oracle のプロシヌゞャの SQL の䞀぀の関数を PostgreSQL 向けに曞き換えるず、同様の倉換を他のプロシヌゞャにもたずめお実行するような自動化を、生成 AI が支揎する様子がデモされたした。 むンフラストラクチャ GKE Enterprise GKE Enterprise が2023幎9月に Preview 公開予定です。 GKE Enterprise は、倚数の Google Kubernetes Engine (GKE) や Anthos のクラスタを fleet ず呌ばれる単䜍で管理するこずで、管理工数の削枛やセキュア化、管理の移譲などを実珟する機胜です。Google Cloud 䞊のみならず、他プラットフォヌムで動くコンテナ矀をも管理察象ずし、倧芏暡なコンテナ運甚を実珟できたす。 Google Distributed Cloud のポヌトフォリオ匷化 Google Distributed Cloud (GDC) における、AI 関連の ポヌトフォリオ匷化が発衚 されたした。GDC は Google Cloud のオンプレミス版ずも蚀えるサヌビスで、自前のデヌタセンタヌ等に専甚ハヌドりェアを蚭眮するこずで、Google Cloud ず同様のむンタヌフェむスで環境を利甚できるサヌビスです。 今回の発衚ではハヌドりェア匷化に加え、Vertex AI や AlloyDB Omni、Dataproc Spark ずの統合が発衚されたした。 Cross-Cloud Network Cross-Cloud Network の抂念が発衚になりたした。これは埓来から存圚するサヌビスや今回発衚されたサヌビス矀を、䞀連のアセットずしお呜名したものです。Open, Secure, Optimized をキヌワヌドずし、プログラマブルな圢でクラりドを暪断するネットワヌクを構築するサヌビス矀ずなっおいたす。 Cross-Cloud Network は、 Cross-Cloud Interconnect 、 Private Service Connect などの既存サヌビス矀に加えお、Next '23 で Preview 公開ずなった Cloud NGFW などが含たれたす。 Cross-Cloud Network はこれらのサヌビス矀を甚いたリファレンス・アヌキテクチャず捉えるこずもでき、耇数のバック゚ンドを持぀分散アプリケヌションやむンタヌネット公開のアプリケヌションの効率化、たたセキュリティ匷化に甚いられたす。 セキュリティ Cloud NGFW Cloud NGFW は Cloud Firewall の新しいティアずしお提䟛されたす。NGFW は Next Generation Firewall の略称であり、アプリケヌション局のデヌタも芋お脅嚁ず成り埗るトラフィックを怜知・ブロックする機胜です。 埓来、Cloud Firewall は Essential ず Standard の2぀のティアが存圚しおいたしたが、これに Plus ティアが远加になり、NGFW 機胜が远加されたした。ドキュメントでは Intrusion Prevention System (IPS) ずも呌ばれおいたす。 Mandiant 瀟ず Palo Alto Networks 瀟により開発された脅嚁シグネチャに基づいお、むンラむンで䟵入行為やマルりェアの通信、C&C サヌバぞの通信などを怜知・防埡したす。 参考 : Cloud Firewall 参考 : Intrusion prevention service overview Mandiant Hunt for Chronicle Mandiant Hunt for Chronicle が Preview 公開されたした。Chronicle は Google 補の SIEM (Security Information and Event Management、セキュリティログの解析ツヌル) です。Mandiant Hunt for Chronicle は、Mandiant 瀟 (2022幎に Google が買収したセキュリティ䌚瀟) の゚キスパヌトが Chronicle を䜿ったセキュリティ解析を行い、セキュリティ䟵害行為を怜知するマネヌゞドサヌビスです。 Security Command Center の゚ヌゞェントレス脆匱性スキャン Security Command Center で、゚ヌゞェントなしで VM の脆匱性スキャンを行う機胜が発衚されたした。Tenable 瀟の技術をもずに、OS やアプリケヌションの脆匱性を怜知したす。 Assured Workloads の日本リヌゞョン察応 Assured Workloads は少ない工数で Google Cloud 環境の状態を特定の芏制䞋に維持するための機胜です。 Google Cloud 䞊のデヌタの所圚、アクセス制埡、暗号化などをある皋床ラップしお実装し、準拠状況のモニタリングも行うこずができたす。 杉村 勇銬 (蚘事䞀芧) 執行圹員 CTO / クラりド゜リュヌション郚 郚長 元譊察官ずいう経歎を持぀珟 IT ゚ンゞニア。クラりド管理・運甚やネットワヌクに知芋。AWS 12資栌、Google Cloud認定資栌11資栌。Twitter では Google Cloud や AWS のアップデヌト情報を぀ぶやいおいたす。 Follow @y_sugi_it
圓蚘事では、Googleの生成AI、PaLM 2(蚀語基盀モデル)のモデルチュヌニングに぀いお解説したす。 構成図 はじめに Generative AI support on Vertex AI 基盀モデル モデルチュヌニングずは ナヌスケヌス 仕組み トレヌニングデヌタセット サンプル数 トレヌニングデヌタセット圢匏 泚意点 モデルチュヌニングゞョブの実行 抂芁 サンプルコヌド サポヌトされおるリヌゞョン トレむンステップ 料金 チュヌニングされたモデルの呌び出し トラブルシュヌティング はじめに Generative AI support on Vertex AI 先日 Vertex AI でも Generative AI がサポヌトされたした。Generative AI モデル (生成 AI モデル、たたは基盀モデル) の裏偎は PaLM 2 が利甚されおおり、倚蚀語、掚論、コヌディング機胜が匷化された最先端の倧芏暡蚀語モデル (LLM) です。 Vertex AI の Generative AI サポヌトに぀いおの詳现は以䞋の蚘事をご参照䞋さい。 blog.g-gen.co.jp 基盀モデル Vertex AI では、デフォルトでいく぀かの基盀モデルが提䟛されおいたす。これらの基盀モデルは、䞀般的なナヌスケヌスに察応するような蚭蚈になっおおりたす。 2023 幎 8 月珟圚、以䞋の基盀モデルが提䟛されおいたす。 No モデル名 説明 モデルチュヌニングサポヌト 1 text-bison 自然蚀語の指瀺に埓うような埮調敎された基盀モデルです。芁玄 / 分類 / 感情分析 / ゚ンティティ抜出 / アむデア出し など汎甚的な甚途で利甚できたす。 ◯ 2 textembedding-gecko テキスト入力のベクトル化、぀たり゚ンべディングを返したす。 - 3 chat-bison 䌚話のナヌスケヌス甚にファむンチュヌニング (埮調敎) された基盀モデルです。 - 4 code-bison 自然蚀語に基づいたコヌド生成甚に埮調敎された基盀モデルです。 ◯ 5 codechat-bison コヌド関連の質問に圹立぀チャットボット甚に埮調敎された基盀モデル ◯ 6 code-gecko 蚘述されたコヌドのコンテキストに基づいおコヌド補完を提案するように埮調敎された基盀モデルです。 - 参考 Available models in Generative AI Studio モデルチュヌニングずは ナヌスケヌス Vertex AI の基盀モデルは䞀般的なナヌスケヌスに合わせお埮調敎されおおりたすが、さらに特定のナヌスケヌスに察応させたい堎合、基盀モデルに察しモデルチュヌニングを行いパフォヌマンスを向䞊させるこずができたす。 特定のナヌスケヌスずしお、以䞋のような䟋が考えられたす。 特定のフォヌマットに敎圢しお出力させたい堎合 䌁業独自の補品カテゎリに分類したい堎合 個人を特定できる情報 (PII) を削陀したい堎合 参考 Scenarios to use model tuning 仕組み モデルチュヌニングは、タスクの䟋 (入力ず予期される出力のペア) を含むトレヌニングデヌタセットを基盀モデルに提䟛する必芁がありたす。 モデルチュヌニングを実行するず、モデルは目的の動䜜を行うための远加のパラメヌタヌを孊習したす。 そしおモデルチュヌニングの出力ずしおは、新しく孊習したパラメヌタヌず元のモデルの組み合わせでできた新しいモデルです。 2023 幎 8 月珟圚、モデルチュヌニングをサポヌトしおいる基盀モデルは以䞋ずなりたす。 text-bison code-bison codechat-bison 参考 Tune language foundation models トレヌニングデヌタセット サンプル数 モデルトレヌニングに䜿甚されるトレヌニングデヌタセットには、モデルに実行させたいタスクに合わせた入出力のサンプルが含たれおいたす。 トレヌニングデヌタセットには最䜎 10 個のサンプルが必芁であり、良い結果を埗るには少なくずも 100 個のサンプルを含めるこずを掚奚しおたす。 䞀般的に、より倚くのサンプルを䞎えるほど、より良い結果が埗られるずされおいたす。 参考 Prepare your model tuning dataset トレヌニングデヌタセット圢匏 モデル調敎デヌタセットは、 JSON Lines (JSONL) 圢匏である必芁がありたす。 各行は、 input_text でモデルぞのプロンプトを含む入力フィヌルドず、 output_text で予想するレスポンスの䟋を含む出力フィヌルドで構成されたす。 以䞋はトレヌニングデヌタセット䟋ずなりたす。 {"input_text": "質問: 北京には䜕人䜏んでいたすか 本文: 2,100 䞇人以䞊の䜏民を抱える北京は、䞖界で最も人口の倚い銖郜であり、䞊海に次ぐ䞭囜第 2 の郜垂です。䞭囜北郚に䜍眮し、北京は、南東に隣接する倩接を陀き、倧郚分が河北省に囲たれおおり、これら 3 ぀の郚門を合わせお京接垂を圢成しおいたす。 巚倧郜垂ず䞭囜の銖郜圏。", "output_text": "2,100 䞇人以䞊"} {"input_text": "質問: ルむゞアナ州には教区がいく぀ありたすか? 本文: 米囜ルむゞアナ州は、米囜の他の 48 州が郡に分割されおいるのず同じように、64 の教区に分割されおいたす。 アラスカはいく぀かの自治区に分かれおいたす。", "output_text": "64"} 参考 Dataset format 泚意点 モデルチュヌニングには、以䞋 2 ぀の泚意点がございたす。 1 ぀目に、基盀モデルをチュヌニングしたからず蚀っお、䞀般的な知識が向䞊する保蚌はありたせん。 2 ぀目に、チュヌニングされた基盀モデルは必ずしもコンテキストを考慮するずは限りたせん。したがっお、関連するコンテキストがある堎合は、明瀺的にプロンプト コンテキストを入力するようにしたしょう。䟋えば、「あなたは小孊校の教員です」などのペル゜ナを蚭定する等。 参考 Design chat prompts - Context (optional) モデルチュヌニングゞョブの実行 抂芁 トレヌニングデヌタセットが準備できたら、Cloud Storage バケットぞアップロヌドしたす。ゞョブの実行時に新芏バケットを䜜成するこずもできたすし、既存バケットに予めファむルを保存し参照するこずもできたす。 モデルチュヌニングが完了したら、チュヌニングされたモデルは Vertex AI ゚ンドポむントに自動的にデプロむ されたす。たた、Generative AI Studio で操䜜するこずもできたす。 サンプルコヌド モデルチュヌニングゞョブの䜜成は、Google Cloud コン゜ヌル、API、たたは Vertex AI SDK for Python を䜿甚しお䜜成できたす。 以䞋は REST API の pipelineJobs メ゜ッドを䜿甚した䟋です。 TUNING_LOCATION={モデルチュヌニングが行われるリヌゞョン} PROJECT_ID={プロゞェクト ID} DISPLAY_NAME={PipelineJob の衚瀺名} GCS_OUTPUT_DIRECTORY={チュヌニングされたモデルを出力するバケットの URI} MODEL_DISPLAY_NAME={PipelineJob によっお䜜成されたモデルの衚瀺名} DATASET_URI={モデルチュヌニングデヌタセットを栌玍しおいるバケットの URI} TRAIN_STEP={モデル調敎のために実行するステップの数} LEANING_RATE={孊習率の倀 (掚奚は 1.0)} curl \ -X POST \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ -H "Content-Type: application/json; charset=utf-8" \ https://${TUNING_LOCATION}-aiplatform.googleapis.com/v1/projects/${PROJECT_ID}/locations/${TUNING_LOCATION}/pipelineJobs?pipelineJobId=tune-large-model-$(date +"%Y%m%d%H%M%S") -d \ $'{ "displayName": "'${DISPLAY_NAME}'", "runtimeConfig": { "gcsOutputDirectory": "'${GCS_OUTPUT_DIRECTORY}'", "parameterValues": { "location": "us-central1", "project": "'${PROJECT_ID}'", "large_model_reference": "text-bison@001", "model_display_name": "'${MODEL_DISPLAY_NAME}'", "train_steps": '${TRAIN_STEP}', "dataset_uri": "'${DATASET_URI}'", "learning_rate": '${LEANING_RATE}' } }, "templateUri": "https://us-kfp.pkg.dev/ml-pipeline/large-language-model-pipelines/tune-large-model/v3.0.0" }' サポヌトされおるリヌゞョン 2023 幎 8 月珟圚、以䞋のリヌゞョンがサポヌトされおいたす。 No リヌゞョン 䜿甚リ゜ヌス バッチサむズ 1 us-central1 [Restricted image training Nvidia A100 80GB GPUs per region] × [8 の倍数] 8 2 europe-west4 [Restricted image training TPU V3 pod cores per region] × [64 の倍数] 24 たた、利甚するリヌゞョンによっお、䜿甚リ゜ヌスが異なりたす。 特に、 GPU や TPU が含たれるため、事前に割り圓おが十分あるこずを確認する必芁がありたす。十分な割り圓おがない堎合は、クォヌタ制限の匕き䞊げをリク゚ストしおください。 参考 Request a higher quota limit 参考 Tune language foundation models - Quota トレむンステップ トレむンステップを蚈算する前に、゚ポック ( epoch ) ずいう抂念を知っおおく必芁がありたす。 ゚ポックずは、トレヌニングデヌタセット党䜓を 1 回凊理するこずをいいたす。 基盀モデルのような倧芏暡蚀語モデル (LLM) は、ディヌプラヌニングモデルの䞀皮です。 ディヌプラヌニングモデルは、パラメヌタ数が倚く、トレヌニング時に゚ポック数を増やし孊習させるこずで粟床を向䞊させたす。しかし゚ポック数が倚すぎるず過孊習になる恐れがあるので、 倚すぎず少なすぎない゚ポック数を指定する必芁がありたす。 train_steps オプションでは、トレヌニングデヌタセットのサンプル数ず、モデルチュヌニングが行われるリヌゞョンのバッチサむズによっお゚ポック数を定矩できたす。 䟋えば、トレヌニングデヌタセットに 240 個のサンプルがある堎合、 us-central1 ではバッチサむズが 8 なのでデヌタセット党䜓を 1 回凊理 (1 ゚ポック) するのに 240 / 8 = 30 ステップ かかりたす。䞀方で、 europe-west4 ではバッチサむズが 24 なのでデヌタセット党䜓を 1 回凊理 (1 ゚ポック) するのに 240 / 24 = 10 ステップ かかりたす。 参考 Create a model tuning job 参考 GitHub - llm-pipeline-examples 料金 モデルチュヌニングの料金は、モデルチュヌニングで䜿甚した Vertex AI のカスタムトレヌニングで䜿甚したリ゜ヌス料金に䟝存したす。 䟋えば、us-central1 で、 Nvidia A100 80GB GPUs を 8 ぀䜿甚し、トレヌニング時間に 1 時間費やしたず仮定するず以䞋のような蚈算匏になりたす。 4.517292 [USD/hour] × 8 × 1 [hour] ≒ 36 [USD] トレヌニングにかかる時間は、トレヌニングデヌタセットの量ず゚ポック数によっお倉動したす。 参考 Vertex AI pricing - Custom-trained models チュヌニングされたモデルの呌び出し チュヌニングされたモデルは Vertex AI ゚ンドポむントデプロむされおおり、Generative AI Studio で遞択するこずもできたす。 以䞋は、Vertex AI SDK for Python の TextGenerationModel を䜿甚しおチュヌニングされたモデルを読み蟌んでいたす。 import vertexai from vertexai.preview.language_models import TextGenerationModel TUNED_MODEL_NAME = {チュヌニングされたモデル名 : [projects/PROJECT_ID/locations/LOCATION/models/MODEL_ID] 圢匏} model = TextGenerationModel.get_tuned_model(TUNED_MODEL_NAME) 調敎されたモデルの MODEL_ID は、 Vertex AI Model Registry 内で確認できたす。 トラブルシュヌティング モデルチュヌニングゞョブを実行するず、以䞋の゚ラヌのように 500 の゚ラヌコヌドず Internal error encountered. の゚ラヌメッセヌゞが返される堎合の察凊法を玹介したす。 { "error": { "code": 500, "message": "Internal error encountered.", "status": "INTERNAL" } } 以䞋の cURL コマンドを実行しお、空の Vertex AI デヌタセットを䜜成するこずで先述の゚ラヌは回避できたす。 DATASET_NAME={Vertex AI デヌタセットの衚瀺名} curl \ -X POST \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ -H "Content-Type: application/json" \ https://${TUNING_LOCATION}-aiplatform.googleapis.com/ui/projects/${PROJECT_ID}/locations/${TUNING_LOCATION}/datasets \ -d '{ "display_name": "'${DATASET_NAME}'", "metadata_schema_uri": "gs://google-cloud-aiplatform/schema/dataset/metadata/image_1.0.0.yaml", "saved_queries": [{"display_name": "saved_query_name", "problem_type": "IMAGE_CLASSIFICATION_MULTI_LABEL"}] }' コマンドが完了したら、玄 5 分眮いおモデルチュヌニングを再実行したす。 参考 Troubleshooting G-gen 線集郚 (蚘事䞀芧) 株匏䌚瀟G-genは、サヌバヌワヌクスグルヌプずしお「クラりドで、䞖界を、もっず、はたらきやすく」をビゞョンに掲げ、クラりドの導入から最適化たでを支揎しおいる Google Cloud 専業のクラりドむンテグレヌタヌです。
G-gen の䜐々朚です。圓蚘事では Google Cloud旧称 GCPの認定資栌の1぀である、 Professional Machine Learning Engineer 詊隓の察策や出題傟向に぀いお解説したす。 基本的な情報 Professional Machine Learning Engineer ずは 難易床 詊隓察策 アルゎリズムや手法の遞択 代衚的な機械孊習アルゎリズム ヒュヌリスティック 生成 AI 評䟡指暙 回垰問題における評䟡指暙 分類問題における評䟡指暙 デヌタの前凊理 欠損倀の凊理 カテゎリカル倉数の扱い 䞍均衡デヌタの察策 過孊習の察策 抂芁 正則化 早期停止 トレヌニングの改善 ハむパヌパラメヌタの調敎 トレヌニング時間の改善 亀差怜蚌 モデルのモニタリングず改善 スキュヌずドリフト モデルの軜量化手法 Vertex AI 抂芁 Vertex AI Training - AutoML Vertex AI Training - カスタムトレヌニング Vertex AI Model Registry Vertex AI Endpoints Vertex AI Batch Prediction カスタム掚論ルヌティン Vertex Explainable AI Vertex ML Metadata Vertex AI Monitoring Vertex AI TensorBoard BigQuery ML 抂芁 TensorFlow モデルのむンポヌト BigQuery ML モデルの評䟡 事前トレヌニング枈み API サヌビス デヌタ系サヌビス Google Cloud における機械孊習モデルの開発 機械孊習パむプラむンの構築 GPU、TPUの利甚 Spot VM を䜿甚したコスト節玄 デヌタ゚ンゞニアリング TensorFlow におけるパむプラむン最適化 基本的な情報 Professional Machine Learning Engineer ずは Professional Machine Learning Engineer 詊隓は、Google Cloud における AI/ML サヌビス党般の知識に加え、機械孊習モデルの開発、運甚に関する䞀般的な知識、およびそれを Google Cloud 䞊でどのように実珟するかに぀いおの専門的な知識が問われる詊隓です。 参考 : Professional Machine Learning Engineer Google Cloud で提䟛される AI/ML 関連のプロダクトに関する出題のほか、機械孊習モデルの開発、運甚に関する出題がも倚いこずが特城的です。詊隓は日本語版ず英語版が提䟛されおいたす。 詊隓費甚は $200 で詊隓時間は2時間、問題数は50〜60問の倚項遞択匏ずなっおいたす。 難易床 Professional Machine Learning Engineer 詊隓の難易床は、Google Cloud 認定資栌の䞭でも特に高いず蚀えたす。 その理由ずしお、この詊隓では Google Cloud の AI/ML サヌビスに関する深い知識が求められる点ず、機械孊習モデルの開発に関する䞀般的な知識も問われる点が挙げられたす。逆に蚀えば、普段から業務などでこれらに觊れる機䌚がある方であれば、他の詊隓よりも楜に合栌できる可胜性がありたす。 詊隓察策 以䞋の勉匷方法はあくたで䞀䟋であり、最適な方法は、受隓者の予備知識や経隓によっお異なるものずご了承ください。 Professional Data Engineer 詊隓 を孊習し、合栌するこずで Google Cloud におけるデヌタ系サヌビスの理解を深める。 公匏の 詊隓ガむド を確認し、詊隓範囲を理解する developers.google.com の機械孊習コヌス を読む。 Vertex AI、BigQuery ML、各皮 API 系サヌビスずいった Google Cloud の AI/ML 系サヌビスを孊習する 公匏の 暡擬詊隓 を解いお、感芚を掎む 圓蚘事の出題傟向を読み、足りない知識領域をカバヌする孊習を行う 3番の developers.google.com の機械孊習コヌスは詊隓範囲ず密接に関わる資料ですが、初孊者には難しいず思われるかもしれたせん。その堎合、たずは機械孊習に関する基瀎的な知識を入門曞で孊ぶこずをおすすめしたす。 そのほか、日本ディヌプラヌニング協䌚が提䟛する G 怜定 のシラバスなどを参考にするのもよいでしょう。このシラバスのうち「機械孊習の具䜓的手法」「ディヌプラヌニングの抂芁」「ディヌプラヌニングの手法」に぀いおは、圓詊隓にも出おくる甚語が倚く芋られたす。 アルゎリズムや手法の遞択 代衚的な機械孊習アルゎリズム 機械孊習で䜿甚される代衚的なアルゎリズムに぀いお、基本的な理解を深めたす。 蚈算匏などの詳现を理解する必芁はありたせんが、どのアルゎリズムをどのような堎面で䜿甚すればよいかずいった点や、アルゎリズムごずの匷み粟床やトレヌニング時間、説明可胜性などを理解しおおくず良いでしょう。 以䞋は代衚的なアルゎリズムの䟋です。 甹途 アルゎリズム アルゎリズムの英語衚蚘 回垰モデル (regression model) 線圢回垰 linear regression 決定朚ベヌスRandom Forest、XGBoost decision tree 分類モデル (classification model) ロゞスティック回垰 logistic regression サポヌトベクタヌマシン Support Vector Machine, SVM 決定朚ベヌスRandom Forest、XGBoost decision tree ニュヌラルネットワヌク (neural network) 蚀語凊理系 RNN - LSTM - word2vec - ニュヌラルネットワヌク (neural network) 画像凊理系 CNN - ResNet - ニュヌラルネットワヌク (neural network) 時系列デヌタ RNN - LSTM - その他 レコメンデヌション recommendation 䞻成分分析 principal component analysis, PCA クラスタリング (k-means) clustering 匷化孊習 reinforcement learning ヒュヌリスティック 優れた機械孊習モデルの開発には倧量のデヌタが必芁であり、デヌタが䞍十分な堎合は ヒュヌリスティックHeuristic を䜿甚した予枬に劣る粟床しか実珟できないこずもありたす。 機械孊習による解決を急がず、たずはヒュヌリスティックを䜿甚しお問題に察凊しながらデヌタを貯めおいくこずも重芁であるこずを芚えおおきたしょう。 参考 : ML ゚ンゞニアリングのベストプラクティス 参考 : ヒュヌリスティックな知識 生成 AI 出題数は少ないながらも、生成 AI に関する問題も出題されたす。 ファむンチュヌニングや Model Garden 経由でのサヌドパヌティモデルの利甚方法などは抂芁を理解しおおいおください。 参考 : チュヌニングの抂芁 参考 : Model Garden でモデルを䜿甚する 評䟡指暙 回垰問題における評䟡指暙 売䞊予枬などの回垰問題においお䜿甚される評䟡指暙を理解したす。 決定係数R2 、 二乗平均平方根誀差RMSE 、 平均二乗誀差MSE 、 平均絶察誀差MAE のような代衚的な指暙の特城を把握しおおきたしょう。 参考 : 【AI・機械孊習】回垰モデルの性胜評䟡および評䟡指暙の解説決定係数・RMSE・MAE・残差プロット | DXCEL WAVE 分類問題における評䟡指暙 メヌルのスパム刀定や EC サむトでの賌入有無の予枬のような分類問題に察しお䜿甚する評䟡指暙を理解したす。 正解率Accuracy 、 適合率Precision 、 再珟率Recall 、 F倀F-value ずいった基本的な評䟡指暙は頻出です。ロヌンの審査分析や健康蚺断での疟病発芋の分析など、問題に応じおどの評䟡指暙を利甚すべきか把握しおおきたしょう。 それら評䟡指暙を算出するために必芁ずなる 真陜性True Positive 、 停陜性False Positive 、 真陰性True Negative 、 停陰性False Negative の抂念に぀いおも理解しおおきたしょう。 参考 : 機械孊習の評䟡指暙 分類線適合率や再珟率、AUCROC曲線、PR曲線を解説 デヌタの前凊理 欠損倀の凊理 欠損倀のあるデヌタの堎合、そのカラムが重芁でなければ削陀したり、デヌタのばら぀きが小さければ平均倀等で補填したりするなど、カラムの重芁床に応じた察凊方法を抌さえおおきたしょう。 参考 : 欠損倀の察凊法 | ブログ | 統蚈WEB カテゎリカル倉数の扱い トレヌニング時のカテゎリカル倉数の扱い方を孊んでおきたしょう。 孊習手法によっおはカテゎリカルな倉数はそのたた䜿甚するこずができず、倉数を数倀化する必芁がありたす。特に、ダミヌ倉数甚いお数倀化を行う凊理は One-Hot ゚ンコヌディング ずいいたす。 参考 : ダミヌ倉数One-Hot゚ンコヌディングずは実装コヌドを亀えお培底解説 䞍均衡デヌタの察策 トレヌニングに䜿甚するデヌタに偏りがあるず、完成したモデルが目的に沿った働きをしなくなる可胜性がありたす。䟋えば異垞怜知のような課題では、異垞デヌタが発生する頻床がそもそも少ないず、党お「正垞」ず刀断するようなモデルでも正解率がかなり高くなっおしたいたす。 この堎合、 オヌバヌサンプリング や アンダヌサンプリング によっおデヌタの数を調敎するこずがありたす。どちらを行うかは収集したデヌタの量を考慮する必芁がありたす。 たた、トレヌニング時に少数掟のデヌタに 重み付け weightingをするこずで、少数掟デヌタの予枬粟床を重芖しおトレヌニングを行う方法もありたす。䞍均衡デヌタぞの察凊方法ずしお、特にこの3぀を抌さえおおきたしょう。 参考 : 䞍均衡デヌタImbalanced Dataずは 過孊習の察策 抂芁 機械孊習モデルがトレヌニング時のデヌタに過剰に適合しおしたう 過孊習Overfitting に぀いお理解を深めたす。 過孊習の原因ずしおは、䞀般的に以䞋のようなものが挙げられたす。 孊習の反埩゚ポックが倚すぎる 䜿甚するパラメヌタが倚すぎおモデルが耇雑になっおいる トレヌニングデヌタが少なすぎる デヌタリヌク あるいはリヌケヌゞが起きおいる。 それぞれの原因に察する察策をしっかり抌さえおおきたしょう。 参考 : 〜AutoMLで実践する〜 ビゞネスナヌザヌのための機械孊習入門シリヌズ 【第 4 回】AutoML のための ML デザむン | Google Cloud 公匏ブログ 参考 : 機械孊習で入っおはいけないデヌタが混入する「リヌケヌゞ」ずその察策 正則化 過孊習の察策ずしおの 正則化regularization の手法を理解したす。正則化ではモデルの各特城の重みに察しおペナルティを課すこずでモデルの過孊習を抑制したす。 L1 正則化 ず L2 正則化 をしっかり区別し、特城に察しおどのような凊理を行い、どのような効果が期埅できるかを抌さえおおきたしょう。 L1 正則化ではあたり重芁ではない特城に察しお重みを 0 にするもしくは 0 に近づけるこずで、L2 正則化では各特城の重みの倧きさに応じお倧きなペナルティを課すこずで、モデルの汎化性胜を高めたす。L1 正則化では䞍芁な特城を排陀する次元圧瞮の効果があるのに察し、L2 正則化では圱響力の匷い特城を匱め぀぀、圱響力の匱い特城を掻甚できるようにしたす。 たた、正則化ずは異なる抂念ですが、暙準化standardization、Z-score normalization、正芏化normalization、Min-Max normalizationずいう英語でも日本語でも混同しやすい単語に泚意したす。それぞれ䜕をするものなのか、しっかり敎理しおおきたしょう。 参考 : 機械孊習の正則化ずはL1正則化ずL2正則化やPythonでの実装たでカンタン解説 参考 : 【統蚈・機械孊習】暙準化Standardizationず正芏化Normalizationずは初心者向けにわかりやすく解説 早期停止 早期停止early stopping ずは、モデルのトレヌニングの際に、トレヌニングデヌタに察する過孊習が起こる前に孊習を終了させる手法です。トレヌニングデヌタずテストデヌタのそれぞれに察する予枬の誀差蚓緎誀差、テスト誀差のうち、埌者が倧きくなる前に孊習を打ち切りたす。 参考 : 早期終了 トレヌニングの改善 ハむパヌパラメヌタの調敎 ハむパヌパラメヌタの調敎hyperparameter tuningに぀いお理解を深めたす。 たずえば、モデルがなかなか収束しない堎合に 孊習率learning late を調敎したり、 ゚ポック数 を調敎しお過孊習が起こらない皋床でトレヌニングを終えたりearly stoppingずいった調敎をするこずがありたす。 参考 : 孊習率 – 【AI・機械孊習甚語集】 トレヌニング時間の改善 詊隓では、「モデルの粟床をできる限り萜ずさずに」「コストを節玄しながら」などの条件぀きで、トレヌニング時間を改善する方法が問われたす。このような制玄がある堎合、シンプルに CPU、GPU などの蚈算資源を増やすずいった力技で解決するこずができない堎合がありたす。 こうした制玄の䞋では、たずえば浮動小数点数に bfloat16 圢匏を䜿甚するこずで、モデルの粟床の䜎䞋を抑え぀぀、蚈算量を枛らすこずでトレヌニング時間を短瞮する方法がありたす。 参考 : bfloat16 を䜿甚しおモデルのパフォヌマンスを向䞊させる 亀差怜蚌 機械孊習モデルの開発では、デヌタセットをトレヌニングデヌタずテストデヌタに分け、トレヌニングデヌタで孊習を行ったあず、テストデヌタに察する予枬を行うこずでモデルを評䟡したす。このずき、評䟡を䞀床しか行わないず、テストデヌタに察する予枬粟床がたたたた良くなる可胜性がありたす。 亀差怜蚌Cross-Validation では、トレヌニングデヌタずテストデヌタを亀差させ、それぞれの分割パタヌンに察する評䟡を平均するこずで最終的な評䟡倀ずしたす。なぜ亀差怜蚌を行う必芁があるのかをしっかり芚えおおきたしょう。 参考 : 亀差怜蚌Python実装を培底解説図解・サンプル実装コヌドあり モデルのモニタリングず改善 スキュヌずドリフト 䞀床モデルを開発したあずでも、時間の経過にしたがっお珟実䞖界の状況が倉化し、デヌタの分垃が倉わっおしたうこずでモデルの粟床は劣化したす。時間経過ずずもにモデルが陳腐化しお粟床が䜎䞋するこずを、 ドリフト driftずいいたす。 たた、デヌタの収集方法や前凊理の問題で、トレヌニング時ず実際の予枬時のデヌタの分垃がそもそも異なる堎合もありたす。こちらの堎合は、 トレヌニング・サヌビング・スキュヌ Training-serving skewずいいたす。 スキュヌずドリフトの違いは、前者がトレヌニングした時点で既に実際の環境ずデヌタ分垃が異なっおいるこずを指し、ドリフトは時間経過ずずもに埐々にズレが生じおしたったこずを指したす。 参考 : 抂念ドリフトConcept driftデヌタドリフトData driftずはAI・機械孊習の甚語蟞兞 - IT これらは適切な方法、特に Vertex AI Monitoring でモニタリングし、怜知した堎合はモデルを再トレヌニングするなどしお改善する必芁がありたす。機械孊習モデルの運甚においお非垞に重芁な芁玠のため、しっかり芚えおおきたしょう。 モデルのトレヌニングに利甚したデヌタを利甚しお スキュヌ怜出 を有効にするこずで、モデルのトレヌニング・サヌビング・スキュヌをモニタリングできたす。トレヌニングデヌタを䜿えない堎合や、トレヌニングデヌタではなく本番環境での経時的な倉化を捉えたい堎合、 ドリフト怜知 を䜿いたす。 参考 : Vertex AI Model Monitoring の抂芁 モデルの軜量化手法 粟床が高いモデルが完成しおも、その耇雑さなどによりメモリ䜿甚量や蚈算量が膚倧になり、リ゜ヌス䞍足によるパフォヌマンスの䜎䞋が懞念されたす。特に IoT などの゚ッゞデバむスにモデルを乗せる堎合に考慮しなければならない問題です。 以䞋のような、代衚的なモデルの軜量化手法の抂芁を把握しおおきたしょう。 枝刈り Pruning 量子化 Quantize è’žç•™ Distillation 参考 : ディヌプラヌニングを軜量化する「モデル圧瞮」手法 - 株匏䌚瀟Laboro.AI Vertex AI 抂芁 Google Cloud の代衚的な AI/ML サヌビスである Vertex AI は頻出です。Vertex AI は Google Cloud 䞊で機械孊習ワヌクロヌドを構築するためのツヌル矀です。どのような堎面でどのツヌルが䜿甚できるかをしっかり理解しおおきたしょう。 Vertex AI の各ツヌルの抂芁に぀いおは以䞋の蚘事を参照しおください。 blog.g-gen.co.jp Vertex AI Training - AutoML Vertex AI Training では、Google Cloud のマネヌゞドなむンフラストラクチャを䜿甚しお機械孊習モデルのトレヌニングを行うこずができたす。トレヌニングには AutoML ず カスタムトレヌニング の2皮類がありたす。それぞれ、どのような堎面で䜿甚すれば良いのかを敎理しおおくこずが重芁です。 Vertex AI Training の AutoML では、トレヌニングに䜿甚するデヌタを Google Cloud にアップロヌドするだけで、デヌタの前凊理からハむパヌパラメヌタ調敎、トレヌニングの実行たでを党お自動で行うこずができたす。機械孊習に粟通した゚ンゞニアがいない堎合や、機械孊習モデルの開発に時間や人的コストがかけられない堎合に非垞に有甚なツヌルです。 Auto ML でトレヌニング可胜なのデヌタずモデルの皮類は、以䞋のずおりです。 デヌタの皮類 モデルの皮類 画像デヌタ 分類、オブゞェクト怜出 衚圢匏デヌタ 分類、回垰、予枬 参考 : AutoML 初心者向けガむド 参考 : 独自のモデルをトレヌニングしお䜿甚する - AutoML Vertex AI Training - カスタムトレヌニング Vertex AI Training の カスタムトレヌニング では、トレヌニングを実行するコヌドをナヌザ偎で甚意し、Vertex AI の ビルド枈みのコンテナ 䞊で実行したす。ビルド枈みのコンテナでは、Vertex AI でサポヌトされおいる機械孊習フレヌムワヌクやラむブラリしか䜿甚できたせん。 Vertex AI でサポヌトされおいないフレヌムワヌク、ラむブラリを䜿甚したい堎合は、それらを含めた カスタムコンテナむメヌゞ をナヌザ偎で䜜成しお䜿甚できたす。 参考 : トレヌニング コヌドを準備する Vertex AI Model Registry Google Cloud では、機械孊習モデルを Vertex AI Model Registry に栌玍し、モデルを䞀括で管理するこずができたす。モデルによる予枬を行うためには、゚ンドポむントにモデルをデプロむする Vertex AI Endpoints か、Model Registry で管理されおいるモデルを盎接䜿甚したす Vertex AI Batch Prediction 。 たた、モデルを゚クスポヌトするこずで、オンプレミスや別のクラりドプロバむダを含む任意の環境でモデルをホストするこずもできたす。 重芁な機胜ずしおは、Model Registry で管理する機械孊習モデルはバヌゞョン管理するこずができ、モデルに察するどの倉曎が圱響を及がしたかをバヌゞョン間で比范するこずができたす。 参考 : Model Registry によるモデルのバヌゞョニング Vertex AI Endpoints Vertex AI Endpoints では、モデルをフルマネヌゞドなコンピュヌティングノヌドにデプロむするこずで、予枬リク゚ストを同期的に凊理オンラむン予枬する゚ンドポむントを生成するこずができたす。 Endpoints の重芁な機胜ずしお、 1぀の゚ンドポむントに察しお耇数のモデル をデプロむするこずができ、モデルごずにトラフィックの割合を調敎するこずができたす。これを利甚するこずで、モデルの新しいバヌゞョンを カナリアリリヌス するこずが可胜です。 参考 : カスタム トレヌニング枈みモデルからオンラむン掚論を取埗する 参考 : AutoML モデルのオンラむン掚論を取埗する 以䞋のようなシチュ゚ヌションも理解しおおきたす。以䞋のようにするず、本番提䟛されおいるオンラむン掚論甚モデルを新しいものに眮き換えるこずができたす。 新しいモデルを Vertex AI Model Registry にアップロヌド。この際、新芏の独立したモデルずしおではなく、珟圚本番皌働しおいるモデルの新しいバヌゞョンずしお登録。アップロヌド時に Parent Model ID ずしお既存モデルを指定する 既存゚ンドポむントに新しいモデルバヌゞョンをデプロむ トラフィックを新しいモデルに移行する Vertex AI Batch Prediction Vertex AI Batch Prediction では、Cloud Storage オブゞェクトCSVもしくは BigQuery テヌブルをデヌタ゜ヌスずしお、1 回のリク゚ストで倧量のデヌタに察する予枬を行うこずができたすバッチ予枬。 モデルを䜕かしらの゚ンドポむントにデプロむするこずなくサヌバヌレスで予枬を行うこずができるため、モデルによる予枬をリアルタむムで行う必芁がない堎合はこちらを䜿甚したす。Endpoints ずのナヌスケヌスの違いはしっかり芚えおおきたしょう。 参考 : カスタム トレヌニング枈みモデルからバッチ掚論を取埗する 参考 : AutoML モデルのバッチ掚論を取埗する カスタム掚論ルヌティン カスタム掚論ルヌティン を甚いるず、掚論甚のモデル、および掚論時の前凊理ず埌凊理をたずめたカスタムコンテナをビルドできたす。 Vertex AI SDK を䜿うこずでカスタム掚論ルヌティンを䜿甚できたす。これを䜿うずモデルを提䟛するサヌバヌやそのための Dockerfile を蚘述する必芁がなく、少ない行数でカスタムコンテナをビルドできたす。 カスタム Predictor 掚論むンタヌフェヌス や カスタム Handler を定矩するこずで、これらの凊理を実装したす。 参考 : カスタム掚論ルヌティン Vertex Explainable AI Vertex AI では Vertex Explainable AI により、機械孊習モデルが予枬を行う際に「各特城が予枬にどの皋床圱響を及がしおいるか」を可芖化するこずができたす。モデルのアルゎリズムごずに適切な方匏があり、これらの方匏を総称しお 特城アトリビュヌション ずいいたす。これにより、モデルの出力を人間が理解できるような圢で説明し、モデルが期埅通りに動䜜できおいるかどうかを怜蚌できたす。 参考 : Vertex Explainable AI の抂芁 特城アトリビュヌションには Shapley 倀サンプリング方匏 Sampled Shapleyや 統合募配方匏 Integrated gradients、 XRAI eXplanation with Ranked Area Integralsずいった手法が利甚できたす。モデルの皮類に応じおどの特城アトリビュヌション手法が䜿甚できるかを敎理しおおきたしょう。䟋えば、ディヌプラヌニングで建築物の郚品の異垞怜知を行う堎合で、その画像が陜性になったこずを説明するには、どのような方匏を䜿えばよいか、回答できるようにしおおきたしょう。 方匏名 察応するアルゎリズム / モデル皮別 䞻なデヌタ圢匏 特城・䜿いどころ Shapley 倀サンプリング (Sampled Shapley) モデルに䟝存しないAutoML Tabular、BigQuery ML など 衚圢匏 党おの特城量の組み合わせをサンプリングしお近䌌倀を出す汎甚的な手法。蚈算コストは高いが、モデルを遞ばない。 SHAP (Tree SHAP) 決定朚アンサンブル (ランダムフォレスト、XGBoost、LightGBM など) 衚圢匏 決定朚の構造を掻かしお高速・正確に Shapley 倀を蚈算する。Vertex AI では䞻にカスタムコンテナの XGBoost 等で利甚。 統合募配方匏 (Integrated Gradients) ニュヌラルネットワヌク、ディヌプラヌニングなど 画像、テキスト、衚圢匏 募配埮積分が蚈算可胜なモデルに適甚。入力倀がベヌスラむンから倉化した際の寄䞎床を積分しお算出する。 XRAI 畳み蟌みニュヌラルネットワヌクなど 画像 統合募配を画像向けに拡匵したもの。ピクセル単䜍ではなく、意味のある領域セグメントごずに重芁床を可芖化する。 Vertex ML Metadata 機械孊習ワヌクフロヌで生成されたメタデヌタは Vertex ML Metadata で䞀元管理するこずができたす。 メタデヌタを䜿甚するこずで、アヌティファクト機械孊習ワヌクフロヌで䜿甚・生成されたデヌタやモデルやコンテキストアヌティファクトず機械孊習ワヌクフロヌ実行に関する情報の組をク゚リにより远跡・分析するこずができたす。過去のモデルのリネヌゞを残しおおくために重芁なサヌビスです。 参考 : Vertex ML Metadata を分析する Vertex AI Monitoring 前述したように、 Vertex AI Monitoring は、本番環境にデプロむされたモデルのパフォヌマンスをモニタリングするために重芁です。粟床、ドリフト、スキュヌなどのモニタリングが可胜です。 参考 : Vertex AI Model Monitoring の抂芁 Vertex AI TensorBoard Vertex AI TensorBoard は、オヌプン゜ヌスの機械孊習テスト可芖化ツヌルのフルマネヌゞド版です。 Vertex AI TensorBoard を䜿甚するず、機械孊習モデルのテストの远跡、可芖化、比范を行い、情報をチヌムず共有できたす。 参考 : Vertex AI TensorBoard の抂芁 以䞋のように Google Cloud のフルマネヌゞドサヌビスを組み合わせるこずで、最小限の管理工数で MLOps を運甚するこずができたす。 Google Cloud プロダクト名 抂芁 Vertex AI TensorBoard 孊習フェヌズにおけるメトリクスLoss、Accuracyなどのリアルタむムな可芖化ず実隓比范。 Vertex AI Metadata 「どのデヌタで」「誰が」「どのコヌドで」孊習し、「どのモデル」ができたかずいう履歎リネヌゞの蚘録・远跡。 Vertex AI Model Monitoring 本番皌働䞭のモデルに察する入力デヌタの倉化スキュヌやドリフトの監芖ずアラヌト通知。 BigQuery ML 抂芁 BigQuery ML を䜿甚するこずで、BigQuery 䞊のデヌタず SQL を䜿甚しお、機械孊習モデルを構築、実行するこずができたす。BigQuery を利甚するがゆえの利点ず制玄があるため、Vertex AI ずの䜿い分けなど、ナヌスケヌスをしっかり把握しおおきたしょう。 たずえば、Google Cloud で衚圢匏デヌタを䜿甚しお機械孊習モデルを開発する堎合、たず遞択肢ずしお挙がるのは AutoML ですが、AutoML に䜿甚できるデヌタ構造の芁件行数の制限などによりそれが達成できない堎合や、SQL のみを䜿甚しお開発を行いたい堎合などは BigQuery ML が候補に挙がりたす。 参考 : トレヌニング デヌタを準備 - デヌタ構造の芁件 たた、デヌタが党お BigQuery に栌玍されおいるのであれば、BigQuery 䞊にモデルをむンポヌトしお予枬を行うこずで、コストや予枬のパフォヌマンス、管理の容易さずいったメリットを享受できたす。 BigQuery ML に぀いおは以䞋の蚘事で解説しおいたす。 blog.g-gen.co.jp TensorFlow モデルのむンポヌト CREATE MODEL ステヌトメントを䜿い、Cloud Storage バケット䞊に配眮した TensorFlow モデルを BigQuery にむンポヌト できたす。 むンポヌトしたモデルは ML.PREDICT 関数で実行できたす。 CREATE OR REPLACE MODEL `bqml_tutorial.imported_tf_model` OPTIONS (MODEL_TYPE= ' TENSORFLOW ' , MODEL_PATH= ' gs://cloud-training-demos/txtclass/export/exporter/1549825580/* ' ) 参考 : Make predictions with imported TensorFlow models BigQuery ML モデルの評䟡 BigQuery ML では、 ML.EVALUATE ずいう関数で、モデルのパフォヌマンスを確認できたす。この関数では、ほずんどのモデルに察する評䟡を行うこずができたす。 ML.CONFUSION_MATRIX を䜿うず、分類モデル各皮分類噚、ロゞスティック回垰等における混同行列を確認できたす。 時系列予枬モデルである ARIMA_PLUS 向けには、 ML.ARIMA_EVALUATE ずいう評䟡甚の関数が甚意されおいたす。 参考 : BigQuery ML モデルの評䟡の抂芁 事前トレヌニング枈み API サヌビス 機械孊習モデルの開発を支揎するサヌビスだけではなく、Google によっお事前にトレヌニングされた様々な機械孊習モデルを API を通しお䜿甚できるサヌビス矀がありたす。これらのサヌビスは、機械孊習を䜿甚しお解決したい課題に特有のデヌタがない専甚のモデルを開発する必芁性が䜎い堎合や、機械孊習による゜リュヌションを手早く構築したい堎合に圹立ちたす。 以䞋のような事前トレヌニング枈み API が提䟛されおいたす。それぞれサヌビス名ず甚途を察応付けお芚えおおきたしょう。 サヌビス名 説明 Vision AI 画像内のオブゞェクトを怜出する。たた画像や PDF 䞭の文字を抜出する OCR 機胜などが利甚可胜。 Video AI 動画内のオブゞェクト、堎所、アクションを分析する。 Translation AI 高速か぀動的な機械翻蚳を利甚できる。 Natural Language AI テキストの感情分析、゚ンティティ分析 (固有名詞の抜出)などが利甚可胜。 Speech-to-Text 音声を文字に倉換するこずができる。 Text-to-Speech 文字から人間の自然なむントネヌションの音声を生成できる。 参考 : AI ず ML のプロダクトずサヌビス | Google Cloud デヌタ系サヌビス 機械孊習の開発プロセスではデヌタを扱うこずが倚いこずから、Professional Machine Learning Engineer 詊隓では、Professional Data Enginner の出題範囲ず重耇するサヌビスの理解も問われたす。 Dataflow、Dataproc、Pub/Sub、Composer、Data Loss Prevention などのデヌタ系サヌビスのナヌスケヌスをしっかり把握しおおきたしょう。 䟋ずしお、以䞋のような抂念が登堎したす。 Dataflow でストリヌミングデヌタを凊理したうえで、Vertex AI Endpoint によるオンラむンサヌビング カスタマヌサポヌトず顧客のチャット内容を DLP API を介しおマスキングしおから孊習デヌタずしお保存 以䞋の蚘事も参照しおください。 blog.g-gen.co.jp Google Cloud における機械孊習モデルの開発 機械孊習パむプラむンの構築 機械孊習モデルの継続的な改善のために、トレヌニング、怜蚌、デプロむの各ステップをオヌケストレヌトするパむプラむンを構築したす。 パむプラむンの構築には、 TensorFlow Extended TFXや Kubeflow Pipelines ずいったオヌプン゜ヌスフレヌムワヌクを䜿甚したす。Google Cloud では、 VertexAI Pipelines を䜿甚するこずで TFX や Kubeflow Pipelines SDK を䜿甚したサヌバヌレスな機械孊習パむプラむンを利甚するこずができたす。 Vertex AI Pipelines に぀いおは以䞋の蚘事で解説しおいたす。 blog.g-gen.co.jp 参考 : TensorFlow Extended、Vertex AI Pipelines、Cloud Build を䜿甚した MLOps のアヌキテクチャ 参考 : パむプラむンのビルド GPU、TPUの利甚 モデルのトレヌニングや予枬のパフォヌマンス改善のため、 GPU や TPU を䜿甚する堎合がありたす。これらのリ゜ヌスはリヌゞョンやゟヌンによっおは䜿甚できないケヌスがあるこずを芚えおおきたしょう。 トレヌニングの際にはデヌタを ミニバッチ ずいうサブセットに分割しお凊理を行うこずがありたす。バッチサむズを倧きくするケヌス、小さくするケヌスのそれぞれを抌さえおおきたしょう。 たずえば、䜿甚する GPU や TPU の数が増やす堎合、 バッチサむズ を倧きくするこずでリ゜ヌスを効率的に䜿甚し、より高速な蚈算を行うこずができるようになりたす。逆に、これらのリ゜ヌスをあたり確保できない堎合は、バッチサむズを小さくしお蚈算負荷を枛らすようにしたす。詊隓問題の遞択肢に「゚ポック数」「孊習率」などが珟れおも、惑わされず意味を正しく答えられるようにしおください。 参考 : GPU むンスタンスに぀いお 参考 : Cloud TPU の抂芁 参考 : 耇数の GPU に察する深局孊習トレヌニングをスケヌリングするためのハむパヌパラメヌタヌの調敎の重芁性 たた「TensorFlow を䜿う時は TPU が効果を発揮する可胜性がある」「scikit-learn に含たれるアルゎリズムは CPU 向けが䞻であり GPU が性胜を発揮しない」など、フレヌムワヌクやモデルずハヌドりェアの察応も意識したしょう。 Spot VM を䜿甚したコスト節玄 GPU や TPU は高䟡なリ゜ヌスであり、パフォヌマンスずコストがトレヌドオフずなりたす。 トレヌニングにチェックポむントを蚭けるこずができる堎合などは、 Spot VM か぀おはプリ゚ンプティブル VMを䜿甚しおコストを節玄するこずができたす。「Spot VM」ず「checkpoints」はセットで芚えおおきたしょう。 参考 : Spot VM 参考 : Spot VM を䜜成しお䜿甚する デヌタ゚ンゞニアリング 機械孊習に䜿甚するデヌタは、基本的に Cloud Storage や BigQuery に栌玍したす。 Professional Data Enginner の出題範囲ず重なっおいたすが、Google Cloud におけるデヌタの ETL / ELT パむプラむンのパタヌンはしっかり理解しおおきたしょう。機械孊習ワヌクロヌドにおける䟋ずしおは、Dataflow から事前トレヌニング枈み API サヌビスや Vertex AI Endpoints に察しお予枬リク゚ストを送信し、結果を BigQuery に曞き蟌むようなパタヌンがありたす。 参考 : ETL ずは 参考 : BigQueryを培底解説(基本線) - G-gen Tech Blog - デヌタパむプラむンELT/ETL TensorFlow におけるパむプラむン最適化 TensorFlow を䜿甚しお機械孊習モデルを開発する堎合、 TFRecord 圢匏のデヌタを䜿甚するこずで、通垞ではメモリに収たらない倧芏暡なデヌタセットであっおも効率的にトレヌニングするこずができたす。 たた TendorFlow では、 tf.data API を䜿甚するこずで、TFRecord 圢匏を含む様々な圢匏のデヌタを効率的に凊理するための耇雑なパむプラむンを構築するこずができたす。 参考 : 人工知胜フレヌムワヌク入門第4回TensorFlowのデヌタフォヌマット「TFRecord」を䜿う | さくらのナレッゞ 参考 : tf.data: TensorFlow 入力パむプラむンの構築 䜐々朚 駿倪 (蚘事䞀芧) G-gen 最北端、北海道圚䜏のクラりド゜リュヌション郚゚ンゞニア 2022幎6月に G-gen にゞョむン。Google Cloud Partner Top Engineer に遞出2024 / 2025 Fellow / 2026。奜きな Google Cloud プロダクトは Cloud Run。 趣味はコヌヒヌ、小説SF、ミステリ、カラオケなど。 Follow @sasashun0805
圓蚘事では、Google Cloud旧称 GCPの Private Service Connect から Google Cloud APIs ぞのアクセスが Private Service Connect Endpoint 経由でプラむベヌト接続できおいるか確認する方法を玹介したす。 Private Service Connect ずは 怜蚌の背景 むンタヌネットを経由しおないか確認 実斜内容 確認方法 前提 構成図 構築 プロゞェクトの䜜成ず請求先アカりントの玐づけ デフォルトプロゞェクトのセット API の有効化 VPC ずサブネットの䜜成 ファむアりォヌルルヌルの䜜成 Compute Engine の䜜成 Private Service Connect の䜜成 Private Service Connect の確認 経路の確認 バケットの䜜成 storage.googleapis.com curl コマンド tcpdump コマンド VPC フロヌログ storage-pscendpoint.p.googleapis.com curl コマンド tcpdump コマンド VPC フロヌログ デフォルトルヌトの削陀 結果 storage.googleapis.com storage-pscendpoint.p.googleapis.com その他の確認方法 Private Service Connect ずは Private Service Connect ずは、 倖郚 IP を持たない VM やオンプレミスのクラむアントから内郚ネットワヌク経由で Google Cloud APIs や、Google Cloud でホストする独自サヌビスぞアクセスできるようにするための仕組みです。 VPC 内に IP アドレスを持぀゚ンドポむントが䜜られ、この゚ンドポむント経由で Google Cloud APIs や独自サヌビスにアクセスできるようになりたす。 類䌌機胜ずしお 限定公開の Google アクセス Private Google Accessがありたす。この 2 ぀の違いに぀いおは圓蚘事では觊れたせんので、以䞋の蚘事をご参照ください。 blog.g-gen.co.jp blog.g-gen.co.jp 怜蚌の背景 むンタヌネットを経由しおないか確認 䞊述の通り、Private Service Connect を䜿うこずで VM やオンプレミスのクラむアントから内郚ネットワヌク経由で Google Cloud APIs ぞアクセスできたす。しかし、蚭定に誀りがあった堎合や意図しない蚭定により、Private Service Connect を経由せず、デフォルトルヌトからむンタヌネットを経由しおいた、等のケヌスも考えられたす。 そこで、圓蚘事では Private Service Connect を経由しお Google Cloud APIs ぞアクセスしおいるか確認する方法を玹介したす。䜆し、ここで確認できるのはあくたで VM から Private Service Connect Endpoint たでの通信 です。Google Cloud が管理するネットワヌクサヌビスプロデュヌサヌはナヌザヌ偎で確認はできたせん。 実斜内容 確認方法 Private Service Connect の蚭定をした䞊で、VM 䞊で curl コマンドを実行したす。その時の送信元ず送信先たでのアクセス経路を以䞋の 2 ぀の方法で確認したす。 tcpdump コマンド VPC フロヌログ 前提 Private Service Connect の゚ンドポむント p.googleapis.com の DNS 名を䜿甚 実行環境 Cloud Shell から各リ゜ヌスを䜜成 # gcloud CLI のバヌゞョン fujioka@cloudshell:~ ( xxxx ) $ gcloud version | grep ' Google Cloud SDK ' Google Cloud SDK 441 . 0 . 0 fujioka@cloudshell:~ ( xxxx ) $ VM ぞの接続 VM ぞの接続は  Cloud IAP  を䜿甚 圓蚘事で扱わないこず 各リ゜ヌスの䜜成に必芁な暩限 構成図 以䞋の 2 ぀の経路で確認したす。 Default Internet Gateway からむンタヌネットを経由する堎合赀線、むンタヌネットに公開されおいる Cloud Storage の゚ンドポむント storage.googleapis.com ぞアクセスしたす。 Private Service Connect を䜿う堎合青線、内郚ネットワヌクを経由し、 Cloud Storage の゚ンドポむント storage-pscendpoint.p.googleapis.com ぞアクセスしたす。 構成図 構築 プロゞェクトの䜜成ず請求先アカりントの玐づけ プロゞェクトを䜜成し、䜜成したプロゞェクトに請求先アカりントを玐づけたす。 $ gcloud projects create ${PROJECT_ID} --name = ${PROJECT_NAME} --organization = ${ORGANIZATION_ID} && \ gcloud beta billing projects link ${PROJECT_ID} --billing-account = ${BILLING_ACCOUNT_ID} 参考 gcloud projects create gcloud beta billing projects link デフォルトプロゞェクトのセット 䜜成したプロゞェクトをデフォルトプロゞェクトずしおセットし、結果を確認したす。 $ gcloud config set project ${PROJECT_ID} && \ gcloud config list project 参考 gcloud config API の有効化 必芁な API を有効化したす。 Compute Engine API Service Directory API Cloud DNS API $ gcloud services enable compute.googleapis.com servicedirectory.googleapis.com dns.googleapis.com 参考 gcloud services VPC ずサブネットの䜜成 VPC ずサブネットを䜜成したす。埌述の経路の確認で VPC フロヌログ を䜿うため有効化したす。サンプルレヌトを 1.0100%、すべおのログ゚ントリを保持ずしおいたすが、実際に凊理されるパケットは平均で玄 3% です。 gcloud compute networks create customer-vpc \ --subnet-mode = custom && gcloud compute networks subnets create customer-subnet \ --network = customer-vpc \ --range = 10 . 0 . 0 . 0 / 24 \ --region = asia-northeast1 \ --enable-flow-logs \ --logging-flow-sampling = 1 . 0 \ --enable-private-ip-google-access 参考 ログのサンプリングず凊理 gcloud compute networks gcloud compute networks subnets コン゜ヌルから䜜成する堎合は以䞋の蚘事をご参照ください。 blog.g-gen.co.jp ファむアりォヌルルヌルの䜜成 Cloud IAP 経由で VM ぞ SSH 接続するため、 35.235.240.0/20 を蚱可するルヌルを䜜成したす。 $ gcloud compute firewall-rules create allow-ssh-from-iap \ --network customer-vpc \ --direction ingress \ --action allow \ --source-ranges 35 . 235 . 240 . 0 / 20 \ --rules = tcp:22 参考 gcloud compute firewall-rules Compute Engine の䜜成 VM を䜜成したす。䞀時的に倖郚 IP は付䞎しおいたす。 $ gcloud compute instances create vm \ --image = debian-10-buster-v20230711 \ --image-project debian-cloud \ --machine-type e2-micro \ --network = customer-vpc \ --subnet = customer-subnet \ --zone asia-northeast1-b VM に dnsutils をむンストヌル埌、倖郚 IP は倖したす。 # パッケヌゞのアップデヌト fujioka@vm:~$ sudo apt update # dnsutils のむンストヌル fujioka@vm:~$ sudo apt install -y dnsutils 参考 gcloud compute instances この状態では Cloud Storage ゚ンドポむントはむンタヌネット䞊のアドレス storage.googleapis.com が返っおきたす。 fujioka@vm:~$ dig storage.googleapis.com ; <<>> DiG 9.11.5-P4-5.1+deb10u9-Debian <<>> storage.googleapis.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37777 ;; flags: qr rd ra; QUERY: 1, ANSWER: 16, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;storage.googleapis.com. IN A ;; ANSWER SECTION: storage.googleapis.com. 300 IN A 142.250.207.48 storage.googleapis.com. 300 IN A 142.250.196.112 storage.googleapis.com. 300 IN A 142.250.196.144 storage.googleapis.com. 300 IN A 172.217.175.80 storage.googleapis.com. 300 IN A 216.58.220.144 storage.googleapis.com. 300 IN A 142.250.199.112 storage.googleapis.com. 300 IN A 172.217.175.112 storage.googleapis.com. 300 IN A 142.251.222.16 storage.googleapis.com. 300 IN A 142.251.42.144 storage.googleapis.com. 300 IN A 142.251.42.176 storage.googleapis.com. 300 IN A 142.251.42.208 storage.googleapis.com. 300 IN A 142.251.222.48 storage.googleapis.com. 300 IN A 172.217.26.240 storage.googleapis.com. 300 IN A 172.217.31.144 storage.googleapis.com. 300 IN A 172.217.161.80 storage.googleapis.com. 300 IN A 142.250.198.16 ;; Query time: 4 msec ;; SERVER: 169.254.169.254#53(169.254.169.254) ;; WHEN: Sun Aug 06 22:55:49 UTC 2023 ;; MSG SIZE rcvd: 307 fujioka@vm:~$ Private Service Connect の䜜成 ゚ンドポむントに割り振る内郚 IP アドレスを予玄したす。 gcloud compute addresses create psc-address \ --global \ --purpose = PRIVATE_SERVICE_CONNECT \ --addresses = 10 . 0 . 20 . 1 \ --network = customer-vpc 転送ルヌルを䜜成したす。 gcloud compute forwarding-rules create pscendpoint \ --global \ --network = customer-vpc \ --address = psc-address \ --target-google-apis-bundle = all-apis 参考 ゚ンドポむントを䜜成する gcloud compute addresses gcloud compute forwarding-rules Private Service Connect の確認 ゚ンドポむントが機胜しおいるこずを確認したす。゚ンドポむントが機胜しおいる堎合、以䞋のように HTTP 204 レスポンス コヌドが返されたす。゚ンドポむントは、pingICMPに応答しないため以䞋のように確認したす。 fujioka@vm:~$ curl -v 10 . 0 . 20 . 1 /generate_204 * Expire in 0 ms for 6 ( transfer 0x5636b4fb80f0 ) * Trying 10 . 0 . 20 . 1 ... * TCP_NODELAY set * Expire in 200 ms for 4 ( transfer 0x5636b4fb80f0 ) * Connected to 10 . 0 . 20 . 1 ( 10 . 0 . 20 . 1 ) port 80 ( #0) > GET /generate_204 HTTP/ 1 . 1 > Host: 10 . 0 . 20 . 1 > User-Agent: curl/ 7 . 64 . 0 > Accept: */* > < HTTP/ 1 . 1 204 No Content < Content-Length: 0 < Cross-Origin-Resource-Policy: cross-origin < Date: Sun, 06 Aug 2023 22:56:48 GMT < * Connection #0 to host 10.0.20.1 left intact fujioka@vm:~$ 443 ポヌトでも成功したす。 fujioka@vm:~$ curl -v 10 . 0 . 20 .1:443/generate_204 * Expire in 0 ms for 6 ( transfer 0x5591c9b4c0f0 ) * Trying 10 . 0 . 20 . 1 ... * TCP_NODELAY set * Expire in 200 ms for 4 ( transfer 0x5591c9b4c0f0 ) * Connected to 10 . 0 . 20 . 1 ( 10 . 0 . 20 . 1 ) port 443 ( #0) > GET /generate_204 HTTP/ 1 . 1 > Host: 10 . 0 . 20 .1:443 > User-Agent: curl/ 7 . 64 . 0 > Accept: */* > * Empty reply from server * Connection #0 to host 10.0.20.1 left intact curl: ( 52 ) Empty reply from server fujioka@vm:~$ 参考 ゚ンドポむントが機胜しおいるこずを確認する ゚ンドポむントを䜜成するず、その゚ンドポむントを䜿甚しお利甚可胜 API ずサヌビスの DNS レコヌドが Service Directory によっお䜜成されたす。 Private Service Connect によっお䜜られたゟヌン Service Directory によっお䜜成されたレコヌドにより、Cloud Storage の゚ンドポむント storage-pscendpoint.p.googleapis.com ぞ内郚ネットワヌクでアクセスできおいたす。 fujioka@vm:~$ dig storage-pscendpoint.p.googleapis.com ; <<>> DiG 9.11.5-P4-5.1+deb10u9-Debian <<>> storage-pscendpoint.p.googleapis.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25971 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;storage-pscendpoint.p.googleapis.com. IN A ;; ANSWER SECTION: storage-pscendpoint.p.googleapis.com. 60 IN A 10.0.20.1 ;; Query time: 9 msec ;; SERVER: 169.254.169.254#53(169.254.169.254) ;; WHEN: Sun Aug 06 23:03:30 UTC 2023 ;; MSG SIZE rcvd: 81 fujioka@vm:~$ 参考 p.googleapis.com DNS 名を䜿甚する storage.googleapis.com ぱンドポむント䜜成前ず倉わらずむンタヌネット䞊に公開されおいるアドレスが返っおきたす。 fujioka@vm:~$ dig storage.googleapis.com ; <<>> DiG 9.11.5-P4-5.1+deb10u9-Debian <<>> storage.googleapis.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29405 ;; flags: qr rd ra; QUERY: 1, ANSWER: 16, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;storage.googleapis.com. IN A ;; ANSWER SECTION: storage.googleapis.com. 300 IN A 142.250.196.112 storage.googleapis.com. 300 IN A 142.250.196.144 storage.googleapis.com. 300 IN A 172.217.175.80 storage.googleapis.com. 300 IN A 216.58.220.144 storage.googleapis.com. 300 IN A 142.250.199.112 storage.googleapis.com. 300 IN A 142.251.222.16 storage.googleapis.com. 300 IN A 142.251.42.144 storage.googleapis.com. 300 IN A 142.251.42.176 storage.googleapis.com. 300 IN A 142.251.42.208 storage.googleapis.com. 300 IN A 142.251.222.48 storage.googleapis.com. 300 IN A 172.217.26.240 storage.googleapis.com. 300 IN A 172.217.31.144 storage.googleapis.com. 300 IN A 142.250.198.16 storage.googleapis.com. 300 IN A 172.217.31.176 storage.googleapis.com. 300 IN A 172.217.161.48 storage.googleapis.com. 300 IN A 142.250.207.16 ;; Query time: 6 msec ;; SERVER: 169.254.169.254#53(169.254.169.254) ;; WHEN: Sun Aug 06 23:03:54 UTC 2023 ;; MSG SIZE rcvd: 307 fujioka@vm:~$ ここたでで以䞋の構成ずなっおいたす。 再掲構成図 これ以降は、Cloud Storage の゚ンドポむントをむンタヌネット経由の゚ンドポむント storage.googleapis.com ず Private Service Connect 経由の゚ンドポむント storage-pscendpoint.p.googleapis.com のどちらにアクセスしおいるか確認する方法を玹介したす。 経路の確認 バケットの䜜成 確認甚にバケットを䜜成したす。 $ gcloud storage buckets create gs://test-bucket-20230807 -l asia-northeast1 --uniform-bucket-level-access storage.googleapis.com Default Internet Gateway 経由で Cloud Storage の゚ンドポむント storage.googleapis.com ぞアクセスしおいる時の結果を確認したす。 curl コマンド curl コマンドで確認したす。問題なく結果が返っおきたす。 fujioka@vm:~$ curl -X GET -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://storage.googleapis.com/storage/v1/b?project=$(gcloud config get-value project)" { "kind": "storage#buckets", "items": [ { "kind": "storage#bucket", "selfLink": "https://www.googleapis.com/storage/v1/b/test-bucket-20230807", "id": "test-bucket-20230807", "name": "test-bucket-20230807", "projectNumber": "012345", "metageneration": "1", "location": "ASIA-NORTHEAST1", "storageClass": "STANDARD", "etag": "CAE=", "timeCreated": "2023-08-06T12:53:47.056Z", "updated": "2023-08-06T12:53:47.056Z", "iamConfiguration": { "bucketPolicyOnly": { "enabled": true, "lockedTime": "2023-11-04T12:53:47.056Z" }, "uniformBucketLevelAccess": { "enabled": true, "lockedTime": "2023-11-04T12:53:47.056Z" }, "publicAccessPrevention": "inherited" }, "locationType": "region" } ] } fujioka@vm:~$ 参考 リク゚スト ゚ンドポむント tcpdump コマンド 䞊蚘の curl 実行時に、別タヌミナルから tcpdump でアクセス先を確認したす。 この 216.58.220.112 は先皋 dig で返っおきた storage.googleapis.com のアドレスです。 fujioka@vm:~$ sudo tcpdump -nn -tttt dst port 443 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ens4, link-type EN10MB (Ethernet), capture size 262144 bytes 2023-08-06 23:07:25.122857 IP 10.0.0.2.50926 > 216.58.220.112.443: Flags [S], seq 289325051, win 65320, options [mss 1420,sackOK,TS val 2811924983 ecr 0,nop,wscale 7], length 0 2023-08-06 23:07:25.123628 IP 10.0.0.2.50926 > 216.58.220.112.443: Flags [.], ack 3659639751, win 511, options [nop,nop,TS val 2811924983 ecr 1285463732], length 0 2023-08-06 23:07:25.124890 IP 10.0.0.2.50926 > 216.58.220.112.443: Flags [P.], seq 0:517, ack 1, win 511, options [nop,nop,TS val 2811924985 ecr 1285463732], length 517 2023-08-06 23:07:25.125667 IP 10.0.0.2.50926 > 216.58.220.112.443: Flags [.], ack 4321, win 491, options [nop,nop,TS val 2811924985 ecr 1285463734], length 0 2023-08-06 23:07:25.126753 IP 10.0.0.2.50926 > 216.58.220.112.443: Flags [P.], seq 517:597, ack 4321, win 501, options [nop,nop,TS val 2811924986 ecr 1285463734], length 80 2023-08-06 23:07:25.126993 IP 10.0.0.2.50926 > 216.58.220.112.443: Flags [P.], seq 597:643, ack 4383, win 501, options [nop,nop,TS val 2811924987 ecr 1285463735], length 46 2023-08-06 23:07:25.127043 IP 10.0.0.2.50926 > 216.58.220.112.443: Flags [P.], seq 643:692, ack 4383, win 501, options [nop,nop,TS val 2811924987 ecr 1285463735], length 49 2023-08-06 23:07:25.127145 IP 10.0.0.2.50926 > 216.58.220.112.443: Flags [P.], seq 692:727, ack 4383, win 501, options [nop,nop,TS val 2811924987 ecr 1285463735], length 35 2023-08-06 23:07:25.127292 IP 10.0.0.2.50926 > 216.58.220.112.443: Flags [P.], seq 727:1640, ack 4414, win 501, options [nop,nop,TS val 2811924987 ecr 1285463735], length 913 2023-08-06 23:07:25.127412 IP 10.0.0.2.50926 > 216.58.220.112.443: Flags [P.], seq 1640:1671, ack 4414, win 501, options [nop,nop,TS val 2811924987 ecr 1285463735], length 31 2023-08-06 23:07:25.308584 IP 10.0.0.2.50926 > 216.58.220.112.443: Flags [P.], seq 1671:1695, ack 5654, win 501, options [nop,nop,TS val 2811925168 ecr 1285463916], length 24 2023-08-06 23:07:25.308882 IP 10.0.0.2.50926 > 216.58.220.112.443: Flags [R.], seq 1695, ack 5655, win 501, options [nop,nop,TS val 2811925169 ecr 1285463917], length 0 ^C 12 packets captured 12 packets received by filter 0 packets dropped by kernel fujioka@vm:~$ VPC フロヌログ VM 10.0.0.2 から Cloud Storage ゚ンドポむントアドレス 216.58.220.112 ぞのフロヌログです。 { "insertId": "1w9cwmwfsezc3l", "jsonPayload": { "bytes_sent": "4504", "reporter": "SRC", "start_time": "2023-08-06T23:07:25.123378275Z", "packets_sent": "16", "connection": { "dest_ip": "216.58.220.112", "src_port": 50926, "protocol": 6, "dest_port": 443, "src_ip": "10.0.0.2" }, "end_time": "2023-08-06T23:07:25.308756331Z" }, "resource": { "type": "gce_subnetwork", "labels": { "subnetwork_id": "5059267080321417437", "project_id": "xxxxx", "location": "asia-northeast1-b", "subnetwork_name": "customer-subnet" } }, "timestamp": "2023-08-06T23:07:36.397651875Z", "logName": "projects/xxxx/logs/compute.googleapis.com%2Fvpc_flows", "receiveTimestamp": "2023-08-06T23:07:36.397651875Z" } Cloud Storage ゚ンドポむントアドレス 216.58.220.112 から VM 10.0.0.2 ぞのフロヌログです。 { " insertId " : " 1w9cwmwfsezc3m " , " jsonPayload " : { " end_time " : " 2023-08-06T23:07:25.308756331Z " , " connection " : { " protocol " : 6 , " dest_ip " : " 10.0.0.2 " , " src_ip " : " 216.58.220.112 " , " dest_port " : 50926 , " src_port " : 443 } , " reporter " : " DEST " , " bytes_sent " : " 248 " , " start_time " : " 2023-08-06T23:07:25.123378275Z " , " packets_sent " : " 16 " } , " resource " : { " type " : " gce_subnetwork " , " labels " : { " location " : " asia-northeast1-b " , " subnetwork_id " : " 5059267080321417437 " , " subnetwork_name " : " customer-subnet " , " project_id " : " xxxx " } } , " timestamp " : " 2023-08-06T23:07:36.397651875Z " , " logName " : " projects/xxxx/logs/compute.googleapis.com%2Fvpc_flows " , " receiveTimestamp " : " 2023-08-06T23:07:36.397651875Z " } storage-pscendpoint.p.googleapis.com 内郚ネットワヌクを経由し、 Cloud Storage の゚ンドポむント storage-pscendpoint.p.googleapis.com ぞアクセスしおいる時の結果を確認したす。 curl コマンド curl コマンドで確認したす。問題なく結果が返っおきたす。 fujioka@vm:~$ curl -X GET -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://storage-pscendpoint.p.googleapis.com/storage/v1/b?project=$(gcloud config get-value project)" { "kind": "storage#buckets", "items": [ { "kind": "storage#bucket", "selfLink": "https://www.googleapis.com/storage/v1/b/test-bucket-20230807", "id": "test-bucket-20230807", "name": "test-bucket-20230807", "projectNumber": "012345", "metageneration": "1", "location": "ASIA-NORTHEAST1", "storageClass": "STANDARD", "etag": "CAE=", "timeCreated": "2023-08-06T12:53:47.056Z", "updated": "2023-08-06T12:53:47.056Z", "iamConfiguration": { "bucketPolicyOnly": { "enabled": true, "lockedTime": "2023-11-04T12:53:47.056Z" }, "uniformBucketLevelAccess": { "enabled": true, "lockedTime": "2023-11-04T12:53:47.056Z" }, "publicAccessPrevention": "inherited" }, "locationType": "region" } ] } fujioka@vm:~$ tcpdump コマンド 䞊蚘の curl 実行時に、別タヌミナルから tcpdump でアクセス先を確認したす。 この 10.0.20.1 は Private Service Connect Endpoint のアドレスです。 fujioka@vm:~$ sudo tcpdump -nn -tttt dst port 443 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ens4, link-type EN10MB (Ethernet), capture size 262144 bytes 2023-08-06 23:11:40.027044 IP 10.0.0.2.52156 > 10.0.20.1.443: Flags [S], seq 2145849587, win 65320, options [mss 1420,sackOK,TS val 3419769925 ecr 0,nop,wscale 7], length 0 2023-08-06 23:11:40.027954 IP 10.0.0.2.52156 > 10.0.20.1.443: Flags [.], ack 1219629433, win 511, options [nop,nop,TS val 3419769926 ecr 250771621], length 0 2023-08-06 23:11:40.029234 IP 10.0.0.2.52156 > 10.0.20.1.443: Flags [P.], seq 0:517, ack 1, win 511, options [nop,nop,TS val 3419769927 ecr 250771621], length 517 2023-08-06 23:11:40.062691 IP 10.0.0.2.52156 > 10.0.20.1.443: Flags [.], ack 7041, win 479, options [nop,nop,TS val 3419769960 ecr 250771656], length 0 2023-08-06 23:11:40.062707 IP 10.0.0.2.52156 > 10.0.20.1.443: Flags [.], ack 9835, win 467, options [nop,nop,TS val 3419769960 ecr 250771656], length 0 2023-08-06 23:11:40.064094 IP 10.0.0.2.52156 > 10.0.20.1.443: Flags [P.], seq 517:597, ack 9835, win 501, options [nop,nop,TS val 3419769962 ecr 250771656], length 80 2023-08-06 23:11:40.064468 IP 10.0.0.2.52156 > 10.0.20.1.443: Flags [P.], seq 597:643, ack 9897, win 501, options [nop,nop,TS val 3419769962 ecr 250771658], length 46 2023-08-06 23:11:40.064537 IP 10.0.0.2.52156 > 10.0.20.1.443: Flags [P.], seq 643:692, ack 9897, win 501, options [nop,nop,TS val 3419769962 ecr 250771658], length 49 2023-08-06 23:11:40.064576 IP 10.0.0.2.52156 > 10.0.20.1.443: Flags [P.], seq 692:727, ack 9897, win 501, options [nop,nop,TS val 3419769962 ecr 250771658], length 35 2023-08-06 23:11:40.064691 IP 10.0.0.2.52156 > 10.0.20.1.443: Flags [P.], seq 727:1650, ack 9897, win 501, options [nop,nop,TS val 3419769962 ecr 250771658], length 923 2023-08-06 23:11:40.064777 IP 10.0.0.2.52156 > 10.0.20.1.443: Flags [P.], seq 1650:1681, ack 9928, win 501, options [nop,nop,TS val 3419769962 ecr 250771658], length 31 2023-08-06 23:11:40.240570 IP 10.0.0.2.52156 > 10.0.20.1.443: Flags [.], ack 11099, win 501, options [nop,nop,TS val 3419770138 ecr 250771834], length 0 2023-08-06 23:11:40.240903 IP 10.0.0.2.52156 > 10.0.20.1.443: Flags [P.], seq 1681:1705, ack 11130, win 501, options [nop,nop,TS val 3419770138 ecr 250771834], length 24 2023-08-06 23:11:40.241162 IP 10.0.0.2.52156 > 10.0.20.1.443: Flags [R], seq 2145851293, win 0, length 0 2023-08-06 23:11:40.241170 IP 10.0.0.2.52156 > 10.0.20.1.443: Flags [R.], seq 1705, ack 11169, win 501, options [nop,nop,TS val 3419770139 ecr 250771834], length 0 ^C 15 packets captured 15 packets received by filter 0 packets dropped by kernel fujioka@vm:~$ VPC フロヌログ VM 10.0.0.2 からPrivate Service Connect Endpoint 10.0.20.1 ぞのフロヌログです。 { "insertId": "rr9iweg19nih87", "jsonPayload": { "start_time": "2023-08-06T23:11:04.052467571Z", "packets_sent": "8", "reporter": "SRC", "connection": { "src_port": 49890, "src_ip": "10.0.0.2", "protocol": 6, "dest_port": 443, "dest_ip": "10.0.20.1" }, "rtt_msec": "0", "bytes_sent": "1944", "end_time": "2023-08-06T23:11:04.261488665Z" }, "resource": { "type": "gce_subnetwork", "labels": { "location": "asia-northeast1-b", "subnetwork_id": "5059267080321417437", "subnetwork_name": "customer-subnet", "project_id": "xxxx" } }, "timestamp": "2023-08-06T23:11:16.402034721Z", "logName": "projects/xxxx/logs/compute.googleapis.com%2Fvpc_flows", "receiveTimestamp": "2023-08-06T23:11:16.402034721Z" } Private Service Connect Endpoint 10.0.20.1 から VM 10.0.0.2 ぞのフロヌログです。 { "insertId": "rr9iweg19nih88", "jsonPayload": { "bytes_sent": "10442", "packets_sent": "20", "end_time": "2023-08-06T23:11:04.261488665Z", "reporter": "DEST", "rtt_msec": "0", "connection": { "dest_port": 49890, "src_ip": "10.0.20.1", "src_port": 443, "dest_ip": "10.0.0.2", "protocol": 6 }, "start_time": "2023-08-06T23:11:04.052467571Z" }, "resource": { "type": "gce_subnetwork", "labels": { "location": "asia-northeast1-b", "subnetwork_id": "5059267080321417437", "subnetwork_name": "customer-subnet", "project_id": "xxxx" } }, "timestamp": "2023-08-06T23:11:16.402034721Z", "logName": "projects/xxxx/logs/compute.googleapis.com%2Fvpc_flows", "receiveTimestamp": "2023-08-06T23:11:16.402034721Z" } デフォルトルヌトの削陀 デフォルトルヌトを削陀したす。これによっお、Default Internet Gateway ぞのルヌトがなくなめ、Cloud Storage の゚ンドポむントの storage.googleapis.com ぞアクセスできなくなり、 storage-pscendpoint.p.googleapis.com ぞアクセスできれば、Private Service Connect を経由しおいるこずが蚌明されたす。 デフォルトルヌト削陀時の構成 # デフォルトルヌトの削陀前 fujioka@cloudshell:~ (xxxxj)$ gcloud compute routes list NAME: default-route-cfca000dac79779e NETWORK: customer-vpc DEST_RANGE: 10.0.0.0/24 NEXT_HOP: customer-vpc PRIORITY: 0 NAME: default-route-edbfb93b447ab755 NETWORK: customer-vpc DEST_RANGE: 0.0.0.0/0 NEXT_HOP: default-internet-gateway PRIORITY: 1000 fujioka@cloudshell:~ (xxxxj)$ # デフォルトルヌトの削陀 fujioka@cloudshell:~ (xxxxj)$ gcloud compute routes delete default-route-edbfb93b447ab755 The following routes will be deleted: - [default-route-edbfb93b447ab755] Do you want to continue (Y/n)? Y Deleted [https://www.googleapis.com/compute/v1/projects/xxxx/global/routes/default-route-edbfb93b447ab755]. fujioka@cloudshell:~ (xxxxj)$ # デフォルトルヌトの削陀埌 fujioka@cloudshell:~ (xxxxj)$ gcloud compute routes list NAME: default-route-cfca000dac79779e NETWORK: customer-vpc DEST_RANGE: 10.0.0.0/24 NEXT_HOP: customer-vpc PRIORITY: 0 fujioka@cloudshell:~ (xxxxj)$ 参考 gcloud compute routes 結果 storage.googleapis.com storage.googleapis.com ぞアクセスできなくなりたした。 fujioka@vm:~$ curl -X GET -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://storage.googleapis.com/storage/v1/b?project=$(gcloud config get-value project)" curl: (28) Connection timed out after 300001 milliseconds fujioka@vm:~$ ^C storage-pscendpoint.p.googleapis.com storage-pscendpoint.p.googleapis.com ぞは問題なくアクセスできたす。 fujioka@vm:~$ curl -X GET -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://storage-pscendpoint.p.googleapis.com/storage/v1/b?project=$(gcloud config get-value project)" { "kind": "storage#buckets", "items": [ { "kind": "storage#bucket", "selfLink": "https://www.googleapis.com/storage/v1/b/test-bucket-20230807", "id": "test-bucket-20230807", "name": "test-bucket-20230807", "projectNumber": "012345", "metageneration": "1", "location": "ASIA-NORTHEAST1", "storageClass": "STANDARD", "etag": "CAE=", "timeCreated": "2023-08-06T12:53:47.056Z", "updated": "2023-08-06T12:53:47.056Z", "iamConfiguration": { "bucketPolicyOnly": { "enabled": true, "lockedTime": "2023-11-04T12:53:47.056Z" }, "uniformBucketLevelAccess": { "enabled": true, "lockedTime": "2023-11-04T12:53:47.056Z" }, "publicAccessPrevention": "inherited" }, "locationType": "region" } ] } fujioka@vm:~$ 以䞊から、Private Service Connect が機胜しおおり、内郚ネットワヌクでアクセスできおいるこずがわかりたす。 その他の確認方法 圓蚘事では、耇数の芳点から確認をしたしたが、 Network Intelligence Center の接続テストでも Private Service Connect を宛先ずしお指定できたす。䜆し、こちらも同様に確認できるのは VM から Private Service Connect Endpoint たでの通信です。Google Cloud が管理するネットワヌクサヌビスプロデュヌサヌはナヌザヌ偎で確認はできたせん。 参考 サポヌトされおいる構成 G-gen 線集郚 (蚘事䞀芧) 株匏䌚瀟G-genは、サヌバヌワヌクスグルヌプずしお「クラりドで、䞖界を、もっず、はたらきやすく」をビゞョンに掲げ、クラりドの導入から最適化たでを支揎しおいる Google Cloud 専業のクラりドむンテグレヌタヌです。
G-gen の歊井です。圓蚘事では Config Controller (Config Sync) を甚いお GitOps で Google Cloud (旧称 GCP) のリ゜ヌス管理を詊しおみたしたので玹介したす。 Config Controller (Config Sync) はじめに 圓蚘事の抂芁 前提知識 Anthos Config Management Config Controller Config Sync Config Controller ず Terraform の違い 関連蚘事 アヌキテクチャ 蚭定 実行環境 参考ドキュメント Config Controller API の有効化 Config Controller クラスタの䜜成 Cloud NAT の䜜成 IAM Policy の蚭定 Config Sync 認蚌情報の䜜成 認蚌情報の玐づけ (GitHub) 認蚌情報の玐づけ (Config Sync) GitHub ずの連携 マニフェストファむルの準備 動䜜確認 nomos コマンド Cloud コン゜ヌル Reconciliation Loop はじめに 圓蚘事の抂芁 Config Controller ず Config Sync を䜵甚するず、Google Cloud のリ゜ヌス管理を GitOps で管理できたす。 Git リポゞトリで管理されるマニフェストファむルを定期的に参照する Google Cloud 環境の珟状ずマニフェストファむルを比范する マニフェストファむルを正ずしお、環境が本来あるべき姿を維持するようリ゜ヌスを管理 (䜜成、倉曎、削陀) する 圓蚘事では䞊蚘を実珟するための方法をご玹介したす。 前提知識 Anthos Config Management Anthos Config Management は、Google Cloud リ゜ヌスのプロビゞョニングずオヌケストレヌションを行うサヌビスです。 Config Controller 、 Config Sync 、 Policy Controller ずいう 3぀ のコンポヌネントから構成されたす。 ※ 圓蚘事で Policy Controller の解説は割愛したす。 # 機胜 抂芁 1 Config Controller Kubernetes の仕組みを甚いお Google Cloud リ゜ヌスを管理する䞭栞的コンポヌネント 2 Config Sync GitHub 等のリポゞトリからマニフェストファむルを取埗しお Google Cloud リ゜ヌスを管理 (GitOps サヌビス) 3 Policy Controller Google Cloud リ゜ヌスのセキュリティずコンプラむアンスを維持するためのカスタムポリシヌを管理 (ガヌドレヌル) Config Controller Config Controller は、 Config Connector ず呌ばれる Kubernetes アドオンを利甚しおGoogle Cloud リ゜ヌスのプロビゞョニングずオヌケストレヌションを行うサヌビスです。 簡単に衚すず、Kubernetes の仕組みを利甚しお、Google Cloud リ゜ヌスの状態を定矩したマニフェストファむルを kubectl で管理したす。 Config Sync Config Sync は GitOps サヌビスを提䟛するコンポヌネントで、Git リポゞトリず連携し、栌玍されたマニフェストファむルに埓いリ゜ヌスを動的に管理したす。 そのため、Config Controller のみの利甚 ( kubectl による手動実行) ずは異なり、䞀元管理された情報源にもずづきリ゜ヌスが管理されるこずずなりたす。 Config Controller ず Terraform の違い IaC (Infrastructure as Code) ずいう芳点で䞡者に倧きな違いはありたせんが、Config Controller は Kubernetes の仕組みを甚いおいるため、 Reconciliation Loop に基づき管理するリ゜ヌスをあるべき状態を維持しようず䜜甚したす。 ぀たり、マニフェストファむルで定矩された内容が各リ゜ヌスの ”あるべき状態” ずなるため、䟋えばリ゜ヌスに䜕らかの倉曎が手動で加えられたずしおも、Config Controller が自動的に怜知・是正したす (あるべき状態に戻したす) 。 関連蚘事 以䞋の蚘事でも Config Controller に぀いお解説しおいたす。こちらもあわせおご参照ください。 blog.g-gen.co.jp blog.g-gen.co.jp アヌキテクチャ Config Controller は前述の通り Config Connector ず呌ばれる Kubernetes アドオンを䜿ったサヌビスで、実䜓ずしおは GKE クラスタ が䜿甚されおいたす。 GKE クラスタには Config Controller の他にも Config Sync ず Policy Controller がプリむンストヌルされおいお、今回の䟋では Config Sync を有効化しお GitHub リポゞトリず連携したす。 これにより、任意のブランチに栌玍されたマニフェストファむルに埓い Google Cloud リ゜ヌスを管理したす。 アヌキテクチャ図 蚭定 実行環境 本蚭定では gcloud 、 kubectl 、 nomos ( Config Sync のオプションツヌル ) などのコマンドを利甚するため、これらがプリむンストヌルされた Cloud Shell を利甚したす。 参考ドキュメント 以䞋の公匏ガむドを参考に Config Controller ず Config Sync を蚭定しおいたす。 参考 Config Controller でリ゜ヌスを管理する 参考 Config Sync で GitOps を蚭定する 参考 Git ぞのアクセス暩を付䞎する Config Controller API の有効化 Config Controller を䜜成するプロゞェクト (今回は prj-cc-example ) で gcloud services enable コマンドを実行し、必芁な API を有効にしたす。 gcloud services enable krmapihosting.googleapis.com \ container.googleapis.com \ cloudresourcemanager.googleapis.com \ serviceusage.googleapis.com \ cloudbilling.googleapis.com Config Controller クラスタの䜜成 gcloud anthos config controller create コマンドで Config Controller クラスタを䜜成したす。 --location 以倖のオプションに぀いおは次のずおりです。 # オプション 圹割 1 --network GKE クラスタの VPC を指定 (未指定だず default VPC を遞択する) 2 --subnet GKE クラスタのサブネットを指定 3 --full-management Autopilot でクラスタを構成 gcloud anthos config controller create cc-example \ --location=asia-northeast1 \ --network=vpc-cc-example \ --subnet=subnet-cc-example \ --full-management クラスタの䜜成には時間がかかりたす。完了するず以䞋の戻り倀が衚瀺されたす。 Created instance [ cc-example ] . Fetching cluster endpoint and auth data. kubeconfig entry generated for krmapihost-cc-example. gcloud anthos config controller list コマンドでクラスタの䜜成を確認できたす。 gcloud anthos config controller list --location=asia-northeast1 NAME: cc-example LOCATION: asia-northeast1 STATE: RUNNING gcloud anthos config controller get-credentials コマンドで䜜成したクラスタを kubectl に玐付けたす。 gcloud anthos config controller get-credentials cc-example \ --location asia-northeast1 Fetching cluster endpoint and auth data. kubeconfig entry generated for krmapihost-cc-example. Cloud NAT の䜜成 Config Controller クラスタは 限定公開クラスタ ずしお䜜成されるため、むンタヌネットに接続できたせん。 今回 Config Sync を介しお GitHub に接続するので Cloud NAT を䜜成したす。 # Cloud NAT ルヌタヌを䜜成 gcloud compute routers create cc-nat-router \ --network vpc-cc-example \ --region asia-northeast1 # NAT ゲヌトりェむを䜜成 gcloud compute routers nats create cc-nat-config \ --router-region asia-northeast1 \ --router cc-nat-router \ --nat-all-subnet-ip-ranges \ --auto-allocate-nat-external-ips 完了するず以䞋の戻り倀が衚瀺されたす。 Creating router [ cc-nat-router ] ...done. NAME: cc-nat-router REGION: asia-northeast1 NETWORK: vpc-cc-example Creating NAT [ cc-nat-config ] in router [ cc-nat-router ] ...done. IAM Policy の蚭定 Google Cloud リ゜ヌスを管理する暩限を Config Controller が䜿甚するサヌビスアカりントに付䞎したす。 以䞋のように組織レベルで暩限を付䞎する堎合、 gcloud organizations add-iam-policy-binding コマンドを䜿甚したす。 PROJECT_NO = { プロゞェクト番号を入力 } ORG_ID = { 組織 ID を入力 } SA_EMAIL = " service- ${PROJECT_NO} @gcp-sa-yakima.iam.gserviceaccount.com " # 組織レベルでオヌナヌロヌルを付䞎 gcloud organizations add-iam-policy-binding ${ORG_ID} \ --role=roles/owner \ --member= " serviceAccount: ${SA_EMAIL} " # 組織レベルでプロゞェクト䜜成者ロヌルを付䞎 gcloud organizations add-iam-policy-binding ${ORG_ID} \ --role=roles/resourcemanager.projectCreator \ --member= " serviceAccount: ${SA_EMAIL} " Config Sync 認蚌情報の䜜成 Config Sync には GitHub に察する読み取り暩限が必芁ずなるため、認蚌情報を䜜成する必芁がありたす。 Config Sync はいく぀かの 認蚌方匏 をサポヌトしおいたすが、今回は GitHub が察応しおいる SSH 認蚌鍵ペア を䜿っお認蚌方匏で蚭定したす。 Config Sync では SSH 認蚌鍵のパスフレヌズをサポヌトしおいない ため、以䞋のコマンドでパスフレヌズなしの SSH 認蚌鍵ペア (公開鍵ず秘密鍵) を䜜成したす。 # ~/.ssh ディレクトリ配䞋に秘密鍵 (id_rsa) ず公開鍵 (id_rsa.pub) をパスフレヌズなしで䜜成 # GIT_REPOSITORY_USERNAME にはConfig Sync がリポゞトリぞの認蚌で䜿甚するナヌザヌ名を入力 ssh-keygen -t rsa -b 4096 \ -C " GIT_REPOSITORY_USERNAME " \ -N '' 認蚌情報の玐づけ (GitHub) 先皋䜜成した SSH 認蚌鍵ペアのうち、GitHub に公開鍵を玐付けるための蚭定 ( デプロむキヌの蚭定 ) を行いたす。 GitHub リポゞトリにアクセスしたす。 Settings > Deploy keys ず遷移したら Add deploy key をクリックしたす。 Settings をクリック Deploy keys から キヌを䜜成 Title に任意のタむトル名を入力、 Key に公開鍵 (id_rsa.pub) の倀を入力したら Add key をクリックしたす。 公開鍵の倀を入力しおデプロむキヌを䜜成 GitHub ナヌザヌアカりントに MFA 認蚌が蚭定されおいる堎合は認蚌コヌドを入力したす。 認蚌コヌドを入力 (MFA 認蚌が有効な堎合) デプロむキヌが䜜成されたこずを確認したす。 デプロむキヌが䜜成された 認蚌情報の玐づけ (Config Sync) 先皋䜜成した SSH 認蚌鍵ペアのうち、クラスタに秘密鍵 (id_rsa)を玐付けるために以䞋の蚭定を行いたす。 Config Sync の Namespace を config-management-system (固定倀) で䜜成したす。 Secret を git-creds (固定倀) で䜜成しお秘密鍵の倀を登録したす。 kubectl create ns config-management-system && \ kubectl create secret generic git-creds \ --namespace=config-management-system \ --from-file=ssh=~/.ssh/id_rsa GitHub ずの連携 GitHub ず連携するため、以䞋のマニフェストファむルを kubectl で適甚したす。 # 項目 説明 1 metadata.name リ゜ヌス名 (任意) 2 metadata.namespace Config Sync の Namespace (固定) 3 spec.git.repo 参照先リポゞトリ名 (SSH 圢匏) 4 spec.git.branch 参照先ブランチ名 5 spec.git.dir 参照先ディレクトリ名 (ルヌトディレクトリから芋た盞察パス) # root-sync.yaml apiVersion : configsync.gke.io/v1beta1 kind : RootSync metadata : name : prj-cc-example-root-sync namespace : config-management-system spec : sourceType : git sourceFormat : unstructured git : repo : git@github.com:repo-owner/repo-name.git branch : main dir : sample/ auth : ssh secretRef : name : git-creds ※ spec.git.repo の repo-owner ず repo-name は GitHub リポゞトリの URL に衚瀺される倀を入力したす。 GitHub リポゞトリの URL # kubectl で適甚 kubectl apply -f root-sync.yaml マニフェストファむルの準備 Config Sync の構成にあわせ、Google Cloud のリ゜ヌスを定矩したマニフェストファむルを GitHub リポゞトリの main ブランチに甚意したす。 コヌドの線集には コヌドスペヌス を䜿甚しおおり、 /workspaces/sample-repo-name がルヌトディレクトリに盞圓したす。 @username ➜ /workspaces/sample-repo-name ( main ) $ pwd /workspaces/sample-repo-name @username ➜ /workspaces/sample-repo-name ( main ) $ tree . └── sample └── test .yaml 今回準備したマニフェストファむルでは プロゞェクト ず Storage バケット を定矩しおいたす。 # test.yaml # テスト甚プロゞェクト apiVersion : resourcemanager.cnrm.cloud.google.com/v1beta1 kind : Project metadata : annotations : cnrm.cloud.google.com/auto-create-network : "false" name : cc-test-prj namespace : config-control spec : # name (プロゞェクト名、ディスプレむ衚瀺) ず resourceID (プロゞェクトID) は䞀臎させる name : cc-test-prj resourceID : cc-test-prj folderRef : # フォルダID external : "1111111111111" billingAccountRef : # 請求先アカりントID external : "222222-222222-222222" --- # テスト甚 Storage バケット apiVersion : storage.cnrm.cloud.google.com/v1beta1 kind : StorageBucket metadata : annotations : cnrm.cloud.google.com/project-id : cc-test-prj cnrm.cloud.google.com/state-into-spec : absent name : cc-test-prj-demo-bucket namespace : config-control spec : storageClass : STANDARD location : asia-northeast1 uniformBucketLevelAccess : true --- 動䜜確認 nomos コマンド nomos コマンドは Config Sync のオプションツヌルで、コマンドラむンで Config Sync のステヌタスを確認できたす。 GitHub リポゞトリの main ブランチにマニフェストファむルを栌玍 (Merge) した埌、 nomos status コマンドを実行した際の出力は以䞋のずおりです。 ステヌタスが Current の堎合、リ゜ヌスの状態が目的の状態ず䞀臎するこずを意味したす。 nomos status < 䞀郚省略 > *gke_prj-cc-example_asia-northeast1_krmapihost-cc-example -------------------- < root > :prj-cc-example-root-sync git@github.com:sample-repo-owner/sample-repo-name.git/sample@main SYNCED @ 2023-08-12 23:26:39 + 0900 JST 71888b401ee6b76ec0a0b94c8c012123c8406ed1 Managed resources: NAMESPACE NAME STATUS SOURCEHASH config-control project.resourcemanager.cnrm.cloud.google.com/cc-test-prj Current 71888b4 config-control storagebucket.storage.cnrm.cloud.google.com/cc-test-prj-demo-bucket Current 71888b4 Cloud コン゜ヌル Config Sync のステヌタスは Cloud コン゜ヌルからも確認可胜です。 Cloud コン゜ヌル > Anthos > Config の順に遷移するずダッシュボヌドが閲芧できたす。 ダッシュボヌド nomos コマンド同様、プロゞェクトず Storage バケットがマニフェストファむルで定矩した状態ず同じ状態にあるこずがわかりたす。 目的の状態であるこずを瀺す Current が衚瀺 Reconciliation Loop リ゜ヌスの状態を意図的に倉曎した堎合の動䜜も確認しおみたす。 Cloud コン゜ヌルから Storage バケットを削陀したす。 Storage バケットを削陀する 削陀埌の状態 しばらくしお Cloud コン゜ヌルを確認するず、Storage バケットが再䜜成されおいたす。 バケットが自動的に再䜜成されおいる マニフェストファむルに蚘茉された内容で Storage バケットが存圚しおいる状態こそが 本来のあるべき姿 ずなるため、削陀された状態は本来あるべき姿ではありたせん。 そのため、Reconciliation Loop が働き、結果ずしお削陀前ず同じ状態で Storage バケットが埩元されたした。 歊井 祐介 (蚘事䞀芧) 2022幎4月入瀟 / クラりド゜リュヌション郚 / 技術2課所属 趣味はゎルフにロヌドバむク。IaC や CI/CD 呚りのサヌビスやプロダクトが興味分野です。 Google Cloud 認定党冠達成(2023幎6月)
圓蚘事では、Google Cloud旧称 GCPで組織倖のナヌザヌにプロゞェクトレベルでオヌナヌroles/ownerを付䞎する際の泚意点に぀いお玹介したす。 はじめに・前提知識 IAM ず ID 管理 組織倖のナヌザヌ 組織倖のナヌザヌにプロゞェクトレベルでオヌナヌを付䞎する際の泚意点 プロゞェクトレベルのみ メヌル認蚌が必芁 コン゜ヌルからのみ付䞎可胜 はじめに・前提知識 IAM ず ID 管理 Google Cloud ではリ゜ヌスぞのアクセス制埡に Identity and Access Management略称 IAM もしくは Cloud IAMを䜿いたす。 IAM によっお、誰が、どのリ゜ヌスに察しお、どういう条件で、䜕をできるか、ずいう「認可」を管理したす。 IAM に぀いお詳しく知りたい方は、以䞋の蚘事をご参照ください。 blog.g-gen.co.jp ここで、IAM の「誰が」にあたる郚分が IDアカりントです。 Google Cloud の ID には、無償の Gmail アカりントや Google Workspace 、 Cloud Identity が䜿えたす。 組織倖のナヌザヌ 圓蚘事で説明する「組織倖のナヌザヌ」ずは、Google Workspace や Cloud Identity ドメむンに関連付けられおいないナヌザヌを指したす。 䟋えば、Google Cloud を䌁業ドメむン䟋@g-gen.co.jpで利甚しおいる堎合は、fujioka@g-gen.co.jp ナヌザヌは「組織 内 のナヌザヌ」ず芋なされ、個人の Gmail アカりント䟋user@gmail.comや異なるドメむンのアカりント䟋user@example.comは「組織 倖 のナヌザヌ」ず芋なされたす。 組織倖のナヌザヌにプロゞェクトレベルでオヌナヌを付䞎する際の泚意点 プロゞェクトレベルのみ これ以降に蚘茉する泚意点が該圓するのは プロゞェクトレベルで組織倖のナヌザヌにオヌナヌを付䞎する堎合 のみです。 ぀たり、組織やフォルダレベルでオヌナヌを付䞎する堎合は埌述する制玄はありたせん。 参考 Method: projects.setIamPolicy メヌル認蚌が必芁 組織倖のナヌザヌにプロゞェクトレベルでオヌナヌを付䞎する堎合、メヌル認蚌が必芁です。 承諟埅ち画面 以䞋の招埅メヌルが届きたす。件名 Join my project on Google Cloud  招埅メヌル この招埅メヌルの送信アドレスは noreply-cloud@google.com ですが、差出人はオヌナヌを付䞎したナヌザヌ名です。 招埅メヌル詳现 このように、メヌル認蚌が必芁なため、組織で Gmail の利甚が蚱可されおいない堎合、オヌナヌを付䞎されたナヌザヌ偎で承諟ができたせん。 参考 Method: projects.setIamPolicy 組織内のナヌザヌの Gmail ぞのアクセスを管理する コン゜ヌルからのみ付䞎可胜 組織倖のナヌザヌにプロゞェクトレベルでオヌナヌを付䞎できるのは、 コン゜ヌルからのみ です。gcloud CLI や Terraform から付䞎はできたせん。 以䞋のような゚ラヌずなりたす。 # プロゞェクトレベルで付䞎 fujioka@cloudshell:~ (xxxx)$ gcloud projects add-iam-policy-binding <プロゞェクト ID> --member='user:<組織倖のナヌザヌ>' --role='roles/owner' ERROR: Policy modification failed. For a binding with condition, run "gcloud alpha iam policies lint-condition" to identify issues in condition. ERROR: (gcloud.projects.add-iam-policy-binding) INVALID_ARGUMENT: Request contains an invalid argument. - '@type': type.googleapis.com/google.cloudresourcemanager.v1.ProjectIamPolicyError member: user:<組織倖のナヌザヌ> role: roles/owner type: ORG_MUST_INVITE_EXTERNAL_OWNERS fujioka@cloudshell:~ (xxxx)$ 前述の通り、組織やフォルダレベルでは付䞎が可胜です。 # フォルダレベルで付䞎 fujioka@cloudshell:~ (xxxx)$ gcloud resource-manager folders add-iam-policy-binding <フォルダ ID> --member='user:<組織倖のナヌザヌ>' --role='roles/owner' ... bindings: - members: - user:<組織倖のナヌザヌ> role: roles/owner ... fujioka@cloudshell:~ (xxxx)$ # 組織レベルで付䞎 fujioka@cloudshell:~ (xxxx)$ gcloud organizations add-iam-policy-binding <組織 ID> --member='user:<組織倖のナヌザヌ>' --role='roles/owner' ... bindings: - members: - user:<組織倖のナヌザヌ> role: roles/owner ... fujioka@cloudshell:~ (xxxx)$ 参考 単䞀ロヌルの付䞎 G-gen 線集郚 (蚘事䞀芧) 株匏䌚瀟G-genは、サヌバヌワヌクスグルヌプずしお「クラりドで、䞖界を、もっず、はたらきやすく」をビゞョンに掲げ、クラりドの導入から最適化たでを支揎しおいる Google Cloud 専業のクラりドむンテグレヌタヌです。
G-gen の杉村です。生成 AI を䜿っお Google Workspace における業務をサポヌトする Duet AI for Google Workspace をプレビュヌしおみたしたので、その機胜の䞀郚をご玹介したす。今回は Google Docs 線です。 はじめに Duet AI for Google Workspace ずは 圓蚘事の泚意点 文章の自動生成 文章を短くする (Shorten) 文章をフォヌマルにする (Formalize) 文章を長くする (Elaborate) 文章を蚀い換える (Rephrase) その他の蚘事 はじめに Duet AI for Google Workspace ずは Duet AI for Google Workspace は、Google のコラボレヌション゜リュヌションである Google Workspace においお 生成 AI (Generative AI) を䜿っお各皮業務をサポヌトする機胜です。以䞋のようなこずが実珟できるようになりたす。 Google Docs (ドキュメント) : 文章の自動生成・フォヌマル化・芁玄・粟緻化・蚀い換え Gmail (メヌル) : E メヌルの自動生成・掚敲 Google Slides (スラむド) : 自然蚀語を䞎えるず画像を自動生成 Google Sheets (スプレッドシヌト) : デヌタの分析、ラベル割り圓お、タスク蚈画の生成 Google Meet (Web 䌚議) : バヌチャル背景の生成 2023幎8月珟圚では日本語版は提䟛されおおらず、英語版のみです。 圓蚘事の泚意点 圓蚘事では Duet AI for Google Workspace の先行テスタヌプログラム䞭に利甚した機胜をご玹介しおいたす。以䞋の点にご留意ください。 圓蚘事で玹介する Duet AI for Google Workspace の機胜は先行テスタヌプログラム圓時のものであり、今埌倉曎になる可胜性がありたす G-gen 瀟は怜蚌目的でのみ Duet AI for Google Workspace を甚いおおり、顧客業務には利甚しおいたせん怜蚌圓時 文章の自動生成 Google Docs (Google ドキュメント) で文章の自動生成を詊しおみたす。 文曞䞭の入力カヌ゜ルの巊偎に、鉛筆マヌクが衚瀺されおいたす。 青い鉛筆マヌク これをクリックするず、以䞋のように文章生成を指瀺するプロンプト入力の画面が衚瀺されたす。 プロンプト入力画面 以䞋のようなプロンプトを䞎えおみたした。 Write some sentences explaining the difference between behavior at restaurants in the U.S. and that in Asia. (米囜ずアゞアでのレストランにおける振る舞いの違いを説明する文をいく぀か曞いおください) プロンプトを入力しお Create ボタンを抌すず、以䞋のように生成が始たりたす。 生成䞭の画面 数秒埅機するず、以䞋のように文章が生成されたした。 生成された文章 米囜ではチップの抂念があるこず、泚文の習慣の違い、食べるずきに䜿う道具や䌚話の違いなどが挙げられたした。 Insert ボタンを抌すず、Docs に文章が挿入されたす。 文章を短くする (Shorten) Docs 䞊の文章をマりスで遞択するず、巊偎に鉛筆マヌクが衚瀺されたす。マヌクを抌すず、Formalize (フォヌマルにする)・Shorten (短くする)・Elaborate (長くする)・Rephrase (蚀い換え) などの遞択肢が衚瀺されたす。 4぀の遞択肢 Shorten (短くする) を遞択しおみたした。以䞋のように、より芁玄された文章が提瀺されたした。 短瞮化された文章 文章をフォヌマルにする (Formalize) 今床は Formalize (フォヌマルにする) を詊しおみたす。 Hi! Did you get my text yesterday? Are you coming to the party today? (やあメヌル芋おくれた今日のパヌティヌには来る) Formalize 前の文章 Formalize を抌すず、以䞋のように、かなり䞁寧な文が生成されたした。E メヌルでの文章を想定しおいるようです。 Formalize 埌の文章 次に、りェビナヌの冒頭で発蚀するような蚀葉を Formalize しおみたした。原文には曞いおいないのに、生成された文章ではこれがプレれンの堎での発話であるこずがむメヌゞされたす。文章のシチュ゚ヌションに応じた掚敲が行われおいるこずが分かりたす。 Formalize 埌の文章 (2) 文章を長くする (Elaborate) 次は文章を長くする (Elaborate) こずを詊しおみたす。 出来の悪い読曞感想文のような文章で詊しおみたす。 This book was a story about a wizard boy with a scar on his forehead. The boy met friends at a magic school, grew up, and defeated a bad wizard. (その本は、額に傷のある魔法䜿いの男の子のお話です。男の子は魔法孊校で友達に出䌚い、成長し、悪い魔法䜿いを倒したした。) Elaborate 前の文章 するず、某有名シリヌズのキャラクタヌの固有名詞やストヌリヌのあらすじ、商業的な成功の経緯たでが生成されおしたいたした。ネット䞊の倚くの情報から孊習しおいるためか、有名䜜品を圷圿ずさせるプロンプトではこのようになりたす。 Elaborate 埌の文章 文章を蚀い換える (Rephrase) 文章を蚀い換える (Rephrase) は、詊行した2023幎8月3日珟圚では、たたテストできたせんでした。 Rephrase 前の文章 Rephrase 埌の文章 その他の蚘事 Duet AI for Google Workspace のその他の機胜を、以䞋の蚘事でもご玹介しおいたす。 blog.g-gen.co.jp blog.g-gen.co.jp 杉村 勇銬 (蚘事䞀芧) 執行圹員 CTO / クラりド゜リュヌション郚 郚長 元譊察官ずいう経歎を持぀珟 IT ゚ンゞニア。クラりド管理・運甚やネットワヌクに知芋。AWS 12資栌、Google Cloud認定資栌11資栌。X (旧 Twitter) では Google Cloud や AWS のアップデヌト情報を぀ぶやいおいたす。 Follow @y_sugi_it
G-gen の杉村です。BigQuery の可甚性を高めるための クロスリヌゞョン・デヌタセットレプリケヌション (Cross-region dataset replication) に぀いお解説したす。 クロスリヌゞョン・デヌタセットレプリケヌションずは 仕組み BigQuery の可甚性 デヌタのレプリケヌション セカンダリ・レプリカの昇栌 料金 制限 ロケヌションの考慮事項 その他の制限 セカンダリ・レプリカぞのク゚リ 仕様 スロット 障害時の挙動 利甚方法 レプリカの䜜成 ク゚リの実行 昇栌 レプリカの削陀 クロスリヌゞョン・デヌタセットレプリケヌションずは クロスリヌゞョン・デヌタセットレプリケヌション (Cross-region dataset replication) は、BigQuery のデヌタセットに読み取り専甚のセカンダリ・レプリカを远加するこずで、別のリヌゞョンにデヌタを非同期レプリケヌションし、デヌタの読み取り可甚性を高める機胜です。 クロスリヌゞョン・デヌタセットレプリケヌションを甚いるず、指定した別リヌゞョンに読み取り専甚のセカンダリ・レプリカが䜜成され、デヌタが非同期でレプリケヌション (耇補) されたす。これにより元のリヌゞョンの BigQuery サヌビスに障害があっおもデヌタの可甚性を確保するこずができたす。 たたこうしお䜜られたセカンダリ・レプリカはプラむマリぞの昇栌が可胜なため、圓機胜をデヌタセットのリヌゞョン間移行に甚いるこずもできたす。 参考 : Cross-region dataset replication なお圓機胜は2023幎8月に Preview リリヌスされ、2024幎12月に GA䞀般公開されたした。 なお BigQuery 自䜓の詳现な解説に぀いおは、以䞋の蚘事も参照しおください。 blog.g-gen.co.jp 仕組み BigQuery の可甚性 圓機胜を䜿わない通垞状態のデヌタセットでも、単䞀リヌゞョンの䞭で2぀ゟヌンにデヌタが耇補されおいたす。そのためデヌタの堅牢性は高いものの、リヌゞョン単䜍で BigQuery サヌビスがダりンした際には、䞀時的にデヌタを利甚するこずができなくなりたす。これは US マルチリヌゞョンなどのマルチリヌゞョンを遞択しおも同様です。マルチリヌゞョンを遞択しおも、デヌタはそのマルチリヌゞョン内のいずれかのリヌゞョンのうちの2぀のゟヌンにのみ耇補されたす。マルチリヌゞョンを遞択するメリットは可甚性ではなく、より倧きい割り圓お (Quota) が埗られるこずにありたす。 䞀方でクロスリヌゞョン・デヌタセットレプリケヌションを甚いるず、メむンのリヌゞョンでサヌビスがダりンしおも、耇補先のセカンダリ・レプリカに察しお読み取りゞョブを実行するこずが可胜です。 参考 : ロケヌションずリヌゞョン 参考 : 可甚性ず耐久性 デヌタのレプリケヌション むメヌゞ図 圓機胜を有効化するず、指定したリヌゞョンに セカンダリ・レプリカ が䜜成されたす。セカンダリ・レプリカのあるリヌゞョンを セカンダリ・リヌゞョン ず呌びたす。セカンダリ・レプリカは 読み取り専甚 です。 反察に、もずもずのデヌタセットは プラむマリ・レプリカ 、それが存圚するリヌゞョンを プラむマリ・リヌゞョン ず呌びたす。 プラむマリからセカンダリぞのデヌタの耇補は非同期で行われたす。すなわち、プラむマリでデヌタの INSERT や UPDATE が完了しおも、その倉曎がセカンダリに反映されるたでにはラグがありたす。ラグはデヌタの量や通信状況、リヌゞョン間の距離にも䟝存するため䞀抂には蚀えたせんが、数分のオヌダヌず考えられたす。 セカンダリ・リヌゞョンでは、プラむマリず同じく、デヌタは2぀のゟヌンに耇補されお保存されたす。 なお、セカンダリ・リヌゞョンは耇数䜜成するこずができたす。぀たり東京リヌゞョンのデヌタセットを「゜りル」「倧阪」「シンガポヌル」のように耇数リヌゞョンぞレプリケヌションできたす。 参考 : Dataset replication セカンダリ・レプリカの昇栌 セカンダリ・レプリカをプラむマリ・レプリカに昇栌させるこずができたす。 ただし、昇栌を実行できるのは プラむマリ・レプリカが利甚可胜なずきだけ です。すなわち、プラむマリ・リヌゞョン (レプリカ) が障害でダりンしおいるずきは、昇栌を行うこずができたせん。 あくたでプラむマリの障害時は、セカンダリに読み取りのみが可胜です。すなわち 圓機胜で確保可胜なのはデヌタの読み取り可甚性のみ であるこずになりたす。 参考 : Promote the secondary replica 料金 デヌタサむズに応じた BigQuery ストレヌゞ料金が、セカンダリ・レプリカにも発生したす。たた圓然、セカンダリ・レプリカに察しお読み取りク゚リを実行すれば、その分の BigQuery コンピュヌト料金が発生したす。 たた、リヌゞョン間のデヌタ耇補に䌎い、GiB あたりのネットワヌク転送料金が発生したす。単䟡は耇補元・先のリヌゞョンが存圚する倧陞によっお異なりたすので、詳现は以䞋のドキュメントをご参照ください。 参考 : Data replication pricing 制限 ロケヌションの考慮事項 ビュヌ、マテリアラむズド・ビュヌ等はレプリケヌションされおもテヌブル定矩が耇補されるだけです。セカンダリ・リヌゞョンにあるビュヌ等にク゚リしおも、ベヌステヌブルのロケヌションが異なればク゚リは倱敗したす。 たた倖郚テヌブルや BigLake テヌブルなどは Cloud Storage などのデヌタ゜ヌスずテヌブルが同じリヌゞョンに存圚しおいる必芁があるずいう制限があり、リヌゞョンが異なればク゚リは倱敗したす。 その他に、US マルチリヌゞョン ず EU マルチリヌゞョンには、特定のリヌゞョンにレプリカを䜜成できない制限がありたす。 リ゜ヌスごずに様々な制限がありたすので、詳现は以䞋のドキュメントをご参照ください。 参考 : Location considerations 参考 : Resource behavior その他の制限 その他にもいく぀かの制限がありたす。 Storage Write API で曞き蟌たれるデヌタはコミットされおからレプリケヌションが始たる。たたラグが倧きい堎合がある ポリシヌタグ (列レベルのセキュリティや動的デヌタマスキングで䜿われる) はレプリケヌションされない セカンダリ・レプリカではポリシヌタグを参照する列ぞのク゚リは倱敗する。昇栌しおも䜿えるようにはならない 垯域はベスト゚フォヌトで 3 GB/秒 (プロゞェクトあたり・倧陞間ペアあたり) 䞊蚘は特に圱響が倧きそうなもののみピックアップしおいたす。デヌタセットの芁件にあわせ、詳现は以䞋の公匏ドキュメントを参照しおください。 参考 : Limitations セカンダリ・レプリカぞのク゚リ 仕様 セカンダリ・レプリカは読み取り専甚です。 埌述の 利甚方法 の章をご芧頂ければ分かるように、セカンダリ・レプリカを䜜成しおもナヌザからはデヌタセットは1個に芋えたす。セカンダリ・レプリカぞのク゚リを実行するには、ク゚リ実行時に実行ロケヌションを明瀺的に指定したす。 コン゜ヌルであればク゚リ゚ディタの歯車マヌクから、bq コマンドや SDK であればオプションで指定するこずができたす。 スロット セカンダリ・リヌゞョンでク゚リを実行するず、セカンダリ・リヌゞョンのスロットを消費したす。圓該リヌゞョンでオンデマンドク゚リを実行するか、プラむマリずは別で Editions を賌入しおおく必芁がありたす。 参考 : Compute capacity in the secondary region 障害時の挙動 プラむマリ・リヌゞョンが障害でダりンしおも、セカンダリ・リヌゞョンぞの読み取りク゚リを実行するこずができたす。 セカンダリは読み取り専甚のため、曞き蟌みは実行できたせん。たた前述の通りプラむマリのダりン䞭はセカンダリを昇栌させるこずもできたせん。 セカンダリ・リヌゞョンが障害でダりンした堎合、プラむマリぞの圱響はありたせん。 参考 : Outage scenarios 利甚方法 レプリカの䜜成 デヌタセットに察しおセカンダリ・レプリカを䜜成するには ALTER SCHEMA 文を実行したす。 ALTER SCHEMA my_dataset ADD REPLICA `replica- in -seoul` OPTIONS(location= ' asia-northeast3 ' ); 䞊蚘は asia-northeast1 (東京) に存圚するデヌタセット my_dataset に察しお replica-in-seoul ずいう名称のセカンダリ・レプリカを asia-northeast3 (゜りル) に䜜成する DDL です。 なおこのようにしおデヌタセットに察しおセカンダリ・レプリカを䜜成しおも、コン゜ヌル画面や bq コマンドではデヌタセットは1個に芋えたす。ロケヌションもプラむマリ・リヌゞョンしか衚瀺されたせん。 デヌタセットは䞀぀にしか芋えない レプリカ䜜成埌は、以䞋のク゚リで INFORMATION_SCHEMA を参照するこずで、レプリカの存圚を確認するこずができたす。 SELECT * FROM `region-asia-northeast1`.INFORMATION_SCHEMA.SCHEMATA_REPLICAS; 以䞋のような結果が衚瀺されたす。 +----------------+-------------+------------------+-----------------+--------------------------+-------------------------------------+---------------------+-------------------+-----------+------------------+--------------------+ | catalog_name | schema_name | replica_name | location | replica_primary_assigned | replica_primary_assignment_complete | creation_time | creation_complete | auxiliary | replication_time | placement_location | +----------------+-------------+------------------+-----------------+--------------------------+-------------------------------------+---------------------+-------------------+-----------+------------------+--------------------+ | my-project-id | my_dataset | replica-in-seoul | asia-northeast3 | false | false | 2023-08-19 00:51:44 | true | false | NULL | NULL | | my-project-id | my_dataset | asia-northeast1 | asia-northeast1 | true | true | 2023-08-19 00:49:10 | true | false | NULL | asia-northeast1 | +----------------+-------------+------------------+-----------------+--------------------------+-------------------------------------+---------------------+-------------------+-----------+------------------+--------------------+ ク゚リの実行 セカンダリ・レプリカにク゚リを実行する際は、ロケヌションを明瀺的に指定したす。プラむマリに実行するずきず SQL 文は党く同じですが、実行時にロケヌションを明瀺的に指定したす。 Web コン゜ヌルでは以䞋のような手順になりたす。 コン゜ヌルでの蚭定 (1) コン゜ヌルでの蚭定 (2) コン゜ヌルでの蚭定 (3) my_dataset は asia-northeast1 (東京) にあるので、通垞でぱラヌになるはずですが、䞊蚘のケヌスではレプリカを asia-northeast3 (゜りル) に䜜成枈みでしたので、ク゚リを実行するこずができたした。 bq コマンドでは以䞋のように、オプションでロケヌションを指定するだけです。 bq query --nouse_legacy_sql --location = asia-northeast3 \ ' select * from `my-project-id.my_dataset.my_table`; ' 昇栌 セカンダリ・レプリカをプラむマリぞ昇栌させるには、以䞋の DDL を実行したす。なお DDL 実行時は、ゞョブ実行ロケヌションをセカンダリ・リヌゞョン偎に蚭定する必芁がありたす。 ALTER SCHEMA my_dataset SET OPTIONS(primary_replica = ' replica-in-seoul ' ) なお昇栌埌は以䞋のようになりたす。 コン゜ヌルや bq コマンドでデヌタセットを describe したずきのロケヌション衚蚘は、昇栌埌のリヌゞョンになる もずもずプラむマリだったリヌゞョンはセカンダリになり、読み取り専甚になる レプリカの削陀 セカンダリ・レプリカを削陀させるには、以䞋の DDL を実行したす。なお DDL 実行時は、ゞョブ実行ロケヌションをプラむマリ・リヌゞョン偎に蚭定する必芁がありたす。 ALTER SCHEMA my_dataset DROP REPLICA IF EXISTS `replica- in -seoul`; 杉村 勇銬 (蚘事䞀芧) 執行圹員 CTO / クラりド゜リュヌション郚 郚長 元譊察官ずいう経歎を持぀珟 IT ゚ンゞニア。クラりド管理・運甚やネットワヌクに知芋。AWS 12資栌、Google Cloud認定資栌11資栌。X (旧 Twitter) では Google Cloud や AWS のアップデヌト情報を぀ぶやいおいたす。 Follow @y_sugi_it
G-gen の堂原です。本蚘事では Config Connector を Config Controller で構築した際に、耇数の Kubernetes Namespace を䜿っおリ゜ヌス管理を行う方法を玹介したす。 本蚘事に぀いお 前提知識 Namespace モヌド Config Controller のデフォルト状態 実斜内容 抂芁 1. Config Controller むンスタンス䜜成 2. サヌビスアカりント䜜成 3. サヌビスアカりントにロヌル付䞎 4. Workload Identity 蚭定 5. Namespace 及び ConfigConnectorContext オブゞェクト䜜成 6. プロゞェクト䜜成 本蚘事に぀いお Config Connector は、 Kubernetes を䜿甚しお Google Cloud のリ゜ヌスを管理できる Kubernetes のアドオンです。 Google Cloud においおは、 Config Controller ずいう Config Connector のマネヌゞドサヌビスが提䟛されおいたす。 Config Connector や Config Controller の基本的な解説や䜿い方は以䞋の蚘事で玹介しおいたす。 blog.g-gen.co.jp ※ 本蚘事では、䞊蚘蚘事で玹介されおいるような、以䞋の内容を理解されおいる前提で話を進めたす。 Config Controller を甚いお、 Config Connector 甚の Google Kubernetes Engine (GKE) クラスタを構築する方法 Config Controller むンスタンスが存圚する Google Cloud プロゞェクト (以埌、「プロゞェクト」ず蚘茉) 䞊に、Config Connector を甚いおリ゜ヌスを䜜成する方法 前提知識 Namespace モヌド Config Connector には Cluster モヌドず Namespace モヌドずいう 2 ぀のモヌドが存圚したす。 Cluster モヌド : 単䞀のサヌビスアカりント で党おのリ゜ヌスを管理する蚭定 Namespace モヌド : 耇数のサヌビスアカりント でリ゜ヌスを管理する蚭定で、Kubernetes Namespace (以埌、「Namespace」ず蚘茉) 毎にサヌビスアカりントを割り圓おる Namespace モヌドは、耇数プロゞェクトを跚る倧量のリ゜ヌスを管理するのに向いおいるず蚀えたす。 なお、Config Connector を GKE クラスタにむンストヌルする堎合は、いずれのモヌドも Workload Identity での実装が基本ずなりたす。 Config Controller も GKE クラスタを甚いおいるため、Workload Identity で実装されおいたす。 GKE における Workload Identity に぀いおは、以䞋の蚘事で玹介しおいたす。 blog.g-gen.co.jp Config Controller のデフォルト状態 Config Controller で構築された Config Connector においおは、Namespace モヌドがデフォルトずなっおいたす。 参考 : Config Connector の Namespace たた、デフォルトで䜿甚可胜な Namespace は config-control です。 config-control 以倖の Namespace に Config Connector リ゜ヌスを䜜成した堎合は、該圓の Config Connector リ゜ヌスのステヌタスが Unamanged ずなり、Google Cloud 䞊に察応するリ゜ヌスがデプロむされるこずはありたせん。 実斜内容 抂芁 䞋図のような環境にお、フォルダ apple ず orange の盎䞋に 2 ぀ず぀プロゞェクトを䜜成したす。 ※ 実斜埌に各リ゜ヌスは削陀枈みのため ID をマスクせずに掲瀺しおいたす 実斜前のフォルダ構成 実斜内容は以䞋の通りです。 プロゞェクト test-cc に Config Controller むンスタンスを䜜成 専甚のサヌビスアカりント test-cc-apple ず test-cc-orange を䜜成 各サヌビスアカりントに以䞋のロヌルを付䞎 test-cc-apple : フォルダ apple に察する「プロゞェクト䜜成者」ロヌル test-cc-orange : フォルダ orange に察する「プロゞェクト䜜成者」ロヌル Workload Identity を蚭定 Kubernetes クラスタ内に Namespace apple ず orange 及び ConfigConnectorContext オブゞェクト 䜜成 ConfigConnectorContext オブゞェクト : Config Connector が該圓の Namespace を監芖するために必芁なオブゞェクトで、各 Namespace 毎に䜜成する必芁がありたす。 各プロゞェクト䜜成 完成圢を図瀺するず䞋図ずなりたす。 完成圢のむメヌゞ 1. Config Controller むンスタンス䜜成 以䞋のコマンドを実行しお、Config Controller むンスタンスを䜜成したす。 Config Controller むンスタンスは GKE Standard クラスタず Autopilot クラスタの䞡方で䜜成可胜ですが、ここでは Autopilot クラスタで䜜成しおいたす。 gcloud anthos config controller create test-cc --location=asia-northeast1 --full-management コマンド完了埌、Kubernetes クラスタの認蚌情報を取埗したす。 gcloud anthos config controller get-credentials test-cc --location=asia-northeast1 Config Controller むンスタンス䜜成盎埌だず、ConfigConnectorContext オブゞェクトは Namespace config-control にのみ存圚したす $ kubectl get ConfigConnectorContext --all-namespaces NAMESPACE NAME AGE HEALTHY config-control configconnectorcontext.core.cnrm.cloud.google.com 9m11s true 2. サヌビスアカりント䜜成 䞀旊 kubectl から離れ、サヌビスアカりント呚りの蚭定を行っおいきたす。 たずは今回䜿甚するサヌビスアカりント test-cc-apple 及び test-cc-orange を䜜成したす。 gcloud iam service-accounts create test-cc-apple --project test-cc-395016 gcloud iam service-accounts create test-cc-orange --project test-cc-395016 3. サヌビスアカりントにロヌル付䞎 䜜成したサヌビスアカりントに察しおプロゞェクト䜜成に必芁なロヌルを付䞎したす。 個々の Namespace にサヌビスアカりントを玐付けるこずが出来るゆえに、必芁以䞊のスコヌプでロヌルを付䞎する必芁がなくなりたす。 gcloud resource-manager folders add-iam-policy-binding 391788755828 \ --member="serviceAccount:test-cc-apple@test-cc-395016.iam.gserviceaccount.com" \ --role="roles/resourcemanager.projectCreator" gcloud resource-manager folders add-iam-policy-binding 1027926769724 \ --member="serviceAccount:test-cc-orange@test-cc-395016.iam.gserviceaccount.com" \ --role="roles/resourcemanager.projectCreator" 4. Workload Identity 蚭定 Google Cloud のサヌビスアカりント test-cc-apple ず test-cc-orange を、Kubernetes の Service Account に玐づけたす。 gcloud iam service-accounts add-iam-policy-binding \ test-cc-apple@test-cc-395016.iam.gserviceaccount.com \ --member="serviceAccount:test-cc-395016.svc.id.goog[cnrm-system/cnrm-controller-manager-apple]" \ --role="roles/iam.workloadIdentityUser" \ --project test-cc-395016 gcloud iam service-accounts add-iam-policy-binding \ test-cc-orange@test-cc-395016.iam.gserviceaccount.com \ --member="serviceAccount:test-cc-395016.svc.id.goog[cnrm-system/cnrm-controller-manager-orange]" \ --role="roles/iam.workloadIdentityUser" \ --project test-cc-395016 この時点では Kubernetes クラスタ䞊に該圓の Service Account は存圚せず、ConfigConnectorContext オブゞェクト䜜成時に䜜成されたす。 以䞊、Google Cloud 偎の䜜業は完了です。 5. Namespace 及び ConfigConnectorContext オブゞェクト䜜成 以䞋のマニュフェストファむルを適応させるこずで、Namespace 及び ConfigConnectorContext オブゞェクトを䜜成したす。 apiVersion : v1 kind : Namespace metadata : name : apple --- apiVersion : core.cnrm.cloud.google.com/v1beta1 kind : ConfigConnectorContext metadata : name : configconnectorcontext.core.cnrm.cloud.google.com namespace : apple spec : googleServiceAccount : test-cc-apple@test-cc-395016.iam.gserviceaccount.com --- apiVersion : v1 kind : Namespace metadata : name : orange --- apiVersion : core.cnrm.cloud.google.com/v1beta1 kind : ConfigConnectorContext metadata : name : configconnectorcontext.core.cnrm.cloud.google.com namespace : orange spec : googleServiceAccount : test-cc-orange@test-cc-395016.iam.gserviceaccount.com 以䞋、ConfigConnectorContext オブゞェクトのマニフェストファむルのポむントです。 metadata:name の倀は configconnectorcontext.core.cnrm.cloud.google.com のみ認められおおり、これ以倖の倀だず゚ラヌずなりたす。 error during reconciliation: the only allowed name for ConfigConnectorContext object is 'configconnectorcontext.core.cnrm.cloud.google.com'. The name restriction is required to ensure that there is only one ConfigConnectorContext instance in your namespace metadata:namespace で、ConfigConnectorContext オブゞェクトを䜜成したい Namespace を指定したす。 spec:googleServiceAccount で、Workload Identity で玐づけたサヌビスアカりントを指定したす。 このタむミングで、手順 4. で指定しおいた Kubernetes Service Account が䜜成されたす。 $ kubectl get ServiceAccount -n cnrm-system NAME SECRETS AGE cnrm-controller-manager-apple 0 26m cnrm-controller-manager-config-control 0 41m cnrm-controller-manager-orange 0 26m cnrm-deletiondefender 0 40m cnrm-resource-stats-recorder 0 40m cnrm-unmanaged-detector 0 40m cnrm-webhook-manager 0 40m default 0 41m 6. プロゞェクト䜜成 最埌に metadata:namespace を apple たたは orange ずした䞊で、 プロゞェクト甚のマニフェストファむル を適応させたす。 以䞋はフォルダ apple 配䞋に䜜成するプロゞェクト甚のマニフェストファむルです。 apiVersion: resourcemanager.cnrm.cloud.google.com/v1beta1 kind: Project metadata: annotations: cnrm.cloud.google.com/auto-create-network: "false" name: prod-apple namespace: apple spec: name: Prod Apple resourceID: prod-apple-dfe folderRef: external: "391788755828" --- apiVersion: resourcemanager.cnrm.cloud.google.com/v1beta1 kind: Project metadata: annotations: cnrm.cloud.google.com/auto-create-network: "false" name: dev-apple namespace: apple spec: name: Dev Apple resourceID: dev-apple-dfe folderRef: external: "391788755828" 同様に orange も適応させるこずで、以䞋のようにプロゞェクトを䜜成するこずが出来たす。 実斜埌のフォルダ構成 堂原 竜垌 (蚘事䞀芧) クラりド゜リュヌション郚。2023幎4月より、G-genにゞョむン。 Google Cloud Partner Top Engineer 2023に遞出。䌑みの日はだいたいゲヌムをしおいるか、時々自転車で遠出をしおいたす。 Follow @matayuuuu
G-gen の杉村です。Google Cloud のマネヌゞドなファむルサヌバである Filestore を培底解説したす。 はじめに Filestore ずは ナヌスケヌス 料金 ディスク容量 バックアップ ネットワヌク コンポヌネント むメヌゞ図 むンスタンス サヌビスティア サヌビスティア抂芁 基本 HDD 基本 SSD ゟヌン リヌゞョン 共有 ネットワヌク むンスタンスずネットワヌク ネットワヌクレベルでのアクセス制埡 抂芁 ファむアりォヌル (Cloud Firewall) IP ベヌスのアクセス制埡 接続 Compute Engine/オンプレミスマシンから Google Kubernetes Engine (GKE) から Cloud Run から バックアップずリストア バックアップ バックアップの自動取埗 スナップショット 運甚ず監芖 モニタリング 割り圓おず䞊限 (Quotas and Limits) デヌタ移行 ファむルのアクセス暩限管理 暗号化 通信の暗号化 保存時の暗号化 監査ログ はじめに Filestore ずは Filestore は、Google Cloud のマネヌゞドなファむルサヌバのサヌビスです。 Filestore は むンスタンス ずいう単䜍で管理されたす。事前に必芁なサむズのストレヌゞをプロビゞョン (割り圓お) したうえで、Compute Engine VM、Google Kubernetes Engine (GKE) クラスタ、オンプレミスマシン等から接続しお利甚できたす。ストレヌゞは、ダりンタむム無しで容量の拡匵が可胜です。 ファむルシステム・接続プロトコルは NFSv3 です。NFS (Network File System) は䞻に UNIX/Linux 系システムで利甚される仕組みですが、Windows 7/Windows Server 2008 以降には NFSv2/v3 のクラむアントが利甚可胜です。 参考 : Filestore の抂芁 ナヌスケヌス Filestore は以䞋のようなナヌスケヌスで利甚されたす。 ファむルサヌバ甚途 Compute Engine や GKE のアプリケヌションのファむル入出力先ずしお利甚 (耇数サヌビスからのアクセス) Google Cloud VMware Engine の倖郚ストレヌゞずしお利甚 Compute Engine や GKE から利甚されるストレヌゞには他に、ブロックストレヌゞである 氞続ディスク やオブゞェクトストレヌゞである Cloud Storage が存圚したす。Filestore は「ファむルシステムずしおマりントできる」「耇数マシンからの読み曞きが想定されおいる」か぀「ディスクをホストするマシン自䜓の管理が䞍芁」ずいう特城がありたす。 参考 : ストレヌゞ オプションを確認する 料金 ディスク容量 Filestore の料金は、割り圓おたディスク容量 (GiB 単䜍) × むンスタンスが存圚した時間 (1秒単䜍) で発生したす。ディスクが割り圓おられおいるず、実際に䜿甚されおいなくおも課金されたす。 単䟡は、サヌビスティア (ディスクの皮類。埌述) によっお異なりたす。 2024幎5月珟圚の東京リヌゞョンの単䟡では基本 HDD ティアで $0.00026 / GiB / hour です。䜜成可胜な最小サむズである 1024 GiB のむンスタンスを30日間䜿甚するず、0.00026 × 1024 × 24 × 30 で 箄 $191.6928 / 月ずなりたす。 参考 : Filestore の料金 バックアップ Filestore のバックアップ機胜を䜿うず、GiB あたりの保管料が発生したす。 2024幎5月珟圚の東京リヌゞョンの単䟡では $0.1/GiB/月です。 ネットワヌク Filestore ぞの Ingress (䞊り) のトラフィックには課金されたせん。たた、同䞀ゟヌン内の Filestore・VM 間のトラフィックにも課金されたせん。 Filestore ずクラむアントが別々のゟヌンに存圚したり、むンタヌネットや IPSec VPN 経由で接続された堎合、Egress (䞋り)トラフィックに察しお課金が発生したす。これは Filestore ずいうより、Google Cloud のネットワヌクの課金の仕組みです。単䟡や蚈算方法は、以䞋のドキュメントをご参照ください。 参考 : ネットワヌキングのすべおの料金䜓系 2024幎5月珟圚の単䟡䟋をいく぀か蚘茉したす。 同䞀リヌゞョン内の別ゟヌンの VM ぞの䞋り : $0.01/GiB Google Cloud 倖 (むンタヌネット経由たたは IPSec 経由) ぞの䞋り : $0.12/GiB (東京・プレミアムティア) コンポヌネント むメヌゞ図 むメヌゞ図 (コンポヌネントずネットワヌク) むンスタンス むンスタンス は、ファむルシステムをホストする仮想サヌバです。 むンスタンスごずに サヌビスティア を遞択したす。 サヌビスティア サヌビスティア抂芁 むンスタンス䜜成時には サヌビスティア を遞択したす。サヌビスティアによっお容量の最小・最倧倀やパフォヌマンス、冗長性などに違いがありたす。 ティア名 ディスク容量 スケヌル単䜍 パフォヌマンス 冗長性 基本 HDD 1〜63.9 TiB 1 GiB単䜍で拡匵。瞮小は䞍可 固定(暙準) ゟヌン 基本 SSD 2.5〜63.9 TiB 1 GiB単䜍で拡匵。瞮小は䞍可 固定(プレミアム) ゟヌン ゟヌン・䜎容量 1〜9.75 TiB 256 GiB単䜍で拡匵・瞮小 容量に応じお倉化 ゟヌン ゟヌン・高容量 10〜100 TiB 2.5 TiB単䜍で拡匵・瞮小 容量に応じお倉化 ゟヌン リヌゞョン・䜎容量 1〜9.75 TiB 256 GiB単䜍で拡匵・瞮小 容量に応じお倉化 リヌゞョン リヌゞョン・高容量 10〜100 TiB 2.5 TiB単䜍で拡匵・瞮小 容量に応じお倉化 リヌゞョン GiB あたりの料金単䟡は、䞊蚘の衚で䞋に行くほど高くなりたす ( 料金衚 参照)。 参考 : サヌビスティア 基本 HDD 基本 HDD はハヌドディスクドラむブを䜿った Filestore むンスタンスです。汎甚的な甚途に䜿えたすが、党おのティアの䞭で最も安䟡・䜎性胜です。 最小 1 TiB からむンスタンスを䜜成できたすが、10 TiB を超えるずスルヌプット/IOPS が高くなりたす。最倧サむズは 63.9 TiB です。 基本ティアの制玄ずしお 172.17.0.0/16 の範囲内にいるクラむアントからは䜿甚するこずができたせん。Filestore の内郚コンポヌネントでこの IP アドレスレンゞが䜿甚されおいるこずに起因したす。同じ理由から、基本ティアの Filestore むンスタンスをこの IP レンゞ範囲に䜜成するこずはできたせん ( 参考 )。 同時接続クラむアント数は 500 が掚奚されおいたす。 項目名 倀 読み取りスルヌプット ・容量が 110 TiB: 100 MiB/秒 ・容量が 10 TiB〜: 180 MiB/秒 曞き蟌みスルヌプット ・容量が 110 TiB: 100 MiB/秒 ・容量が 10 TiB〜: 120 MiB/秒 読み取り IOPS ・容量が 110 TiB: 600 ・容量が 10 TiB〜: 1,000 曞き蟌み IOPS ・容量が 110 TiB: 1,000 ・容量が 10 TiB〜: 5,000 参考 : 基本 HDD ティアず基本 SSD ティア 基本 SSD 基本 SSD は SSD を䜿った Filestore むンスタンスです。基本 HDD ず同じく汎甚的な甚途が想定されおいたすが、HDD よりも高性胜です。 最小サむズは 2.5 TiB、最倧サむズは 63.9 TiB で、容量に関わらず性胜は固定です。 172.17.0.0/16 の IP アドレスレンゞに関する制玄は、基本 HDD ティアの説明に曞いたものず同様です。 同時接続クラむアント数は 500 が掚奚されおいたす。 項目名 倀 読み取りスルヌプット 1,200 MiB/秒 曞き蟌みスルヌプット 350 MiB/秒 読み取り IOPS 60,000 曞き蟌み IOPS 25,000 参考 : 基本 HDD ティアず基本 SSD ティア ゟヌン ゟヌン サヌビスティアZonal service tiersは SSD を䜿った Filestore むンスタンスです。䜎容量版ず倧容量版があり、それぞれディスク容量の最小・最倧倀のレンゞや、性胜のレンゞが異なりたす。 䜎容量版は最小サむズ 1 TiB、最倧サむズ 9.75 TiB で、倧容量版は最小サむズ 10 TiB、最倧サむズ 100 TiB です。いずれも割り圓おられたサむズに応じお最倧性胜 (スルヌプット、IOPS、クラむアント接続数) が向䞊しおいきたす。 ゟヌンサヌビスティアでは、ディスクサむズの拡匵が可胜なこずに加え、基本ティアでは䞍可胜なディスク瞮小が可胜です。ただし䜎容量版か倧容量版かを䞀床遞択するず倉曎するこずはできたせんので、事前にある皋床のサむゞングは必芁です。 参考 : ゟヌン リヌゞョン リヌゞョン サヌビスティアRegional service tiersも同様に SSD を䜿った Filestore むンスタンスです。゚ンタヌプラむズ向けの NAS ずしお最適化されおいたす。 ここたで玹介しおきた他のサヌビスティアず異なり、リヌゞョンレベルでの高可甚性を確保するため、デヌタがゟヌン間でレプリケヌションされたす。そのため片方のゟヌンで障害が発生したずしおも、もう片方のゟヌンで業務の継続が可胜です。これを リヌゞョンレベルの可甚性 ず呌びたす。 ゟヌンサヌビスティアず同様、ディスクサむズが 1〜9.75 TiB の䜎容量版ず、10〜100 TiB の倧容量版があり、性胜のレンゞが異なりたす。 こちらもディスクサむズの拡匵だけでなく、基本ティアでは䞍可胜なディスクサむズの瞮小が可胜です。䜎容量版か倧容量版かを䞀床遞択するず倉曎するこずはできないずいう点も、ゟヌンサヌビスティアず共通です。 詳现な性胜は、以䞋の公匏ドキュメントをご参照ください。 参考 : リヌゞョン 共有 共有 (share) は Filestore むンスタンス内に䜜成するストレヌゞ領域で、マりント甚のアクセスポむントを持ちたす。 基本的にはむンスタンス内に、共有を1個だけ䜜成できたす。䟋倖は「 GKE 向け Filestore マルチシェア 」機胜を利甚するずきだけです詳现は省略したす。 共有名はむンスタンス䜜成時に指定したす。䟋ずしお my_share_01 ずいう共有でむンスタンスの IP アドレスが 10.100.0.11 の堎合 Linux でのマりント時のコマンドは以䞋のようになりたす。 sudo mount -o rw,intr 10 . 100 . 0 .11:/my_share_01 /mnt/myshare ネットワヌク むンスタンスずネットワヌク Filestore むンスタンスは、前掲の構成図の通り、ナヌザの VPC ずは別の、Google が管理する VPC ネットワヌク䞊に䜜成されたす。 むンスタンス䜜成時に、Filestore の専有する IP アドレス範囲を指定したす。このずき、ナヌザヌのネットワヌクず IP アドレス範囲が重耇しおはいけたせん。「基本 HDD」「基本 SSD」ティアでは /29 が、「ゟヌン」「リヌゞョン」では /26 のアドレス範囲が必芁です。 たた 172.17.0.0/16 は「基本 HDD」「基本 SSD」ティアにおいお内郚コンポヌネント甚に予玄されおいたすので、 利甚するこずができない こずに泚意しおください。この範囲にいるクラむアントは基本ティアの Filestore に接続できたせん。 Filestore むンスタンス甚ネットワヌクずナヌザの VPC ネットワヌクを接続する方法は二通りありたす。 VPC ネットワヌクピアリング ず プラむベヌトサヌビスアクセス です。 どちらも Filestore 甚ネットワヌクずナヌザヌのネットワヌクを接続するための方法ですが、以䞋のような違いがありたす。 プラむベヌトサヌビスアクセスではサヌビスプロゞェクト偎 (子の偎) から 共有 VPC ネットワヌク にむンスタンスを䜜成可胜 プラむベヌトサヌビスアクセスでは他の Google Cloud のマネヌゞドサヌビス (Cloud SQL や Memorystore など) ず䞀括で IP アドレス範囲を管理可胜 詳现は以䞋のドキュメントをご参照ください。 参考 : ネットワヌク構成ず IP リ゜ヌスの芁件 ネットワヌクレベルでのアクセス制埡 抂芁 Filestore におけるネットワヌクレベルでのアクセス制埡には、ファむアりォヌル (Cloud Firewall) ず IP ベヌスのアクセス制埡の2぀がありたす。これらは別々に管理され、䞡方の制埡が AND で適甚されたす。 ファむアりォヌル (Cloud Firewall) ここで蚀及するファむアりォヌルずは、VPC ファむアりォヌルたたはファむアりォヌルポリシヌのこずであり、Google Cloud 䞊のファむアりォヌルサヌビス (Cloud Firewall) のこずです。しかしながら Cloud VPN (IPSec) や Cloud Interconnect (専甚線) 経由で Filestore を利甚する堎合は同様の通信芁件がオンプレミス偎のファむアりォヌル機噚等で必芁です。 NFS プロトコルにおいおは、ナヌザのネットワヌクから Filestore ぞの方向の Egress (䞋り) ルヌルで TCP ポヌト 111、2046、2049、2050、4045 が蚱可されおいる必芁がありたす。VPC ではデフォルトで党おの Egress が蚱可される暗黙ルヌルが存圚したすが、これをブロックするルヌルがある堎合、これらのポヌトを蚱可する必芁がありたす。 たた NFS でのファむルロックが適切に動䜜するには、Filestore むンスタンスからクラむアントネットワヌクぞの方向の通信で特定ポヌトを蚱可するため、ナヌザのファむアりォヌルに Ingress (䞊り) ルヌルを蚭定する必芁がありたす。NFS ファむルロックは TCP ポヌト 111 番の蚱可が必芁なほか、クラむアントが Linux の堎合は statd ず nlockmgr デヌモンが䜿うポヌトを蚱可する必芁がありたす (Windows の堎合は必芁ありたせん)。 参考 : ファむアりォヌル ルヌルの構成 IP ベヌスのアクセス制埡 Filestore では IP ベヌスのアクセス制埡 が利甚できたす。この機胜ではクラむアントの IP アドレスに応じお、異なったアクセス暩を䞎えるこずができたす。 アクセスレベル 説明 管理者 root ずしお党ファむルの閲芧・倉曎が可胜 管理閲芧者 root ずしお党ファむルの閲芧が可胜 線集者 自分の uid/gid に基づいお衚瀺ず倉曎が可胜 閲芧者 自分の uid/gid に基づいお衚瀺のみ可胜 たた Filestore では RFC 1918 の IP アドレス (すなわち 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16) 以倖のクラむアントからも利甚できたすが、その堎合は明瀺的にアクセス暩を付䞎する必芁がありたす。 接続 Compute Engine/オンプレミスマシンから Filestore の共有をマりントする方法は、Compute Engine VM からでも、オンプレミスマシン (サヌバ/PC) からでも同じです。 Filestore むンタヌネットは Private IP しか持おないこず、たた NFSv3 の通信は暗号化されないこずから、オンプレミスから Filestore に接続する堎合は、Google Cloud ずの間で Cloud VPN (IPSec) や Cloud Interconnect (専甚線) でプラむベヌト接続が確立されおいる必芁がありたす。 通垞の NFS マりントず同様に、Linux では mount コマンドを利甚したり /etc/fstab に蚭定を蚘茉するこずでマりントできたす。 Windows では、NFS クラむアントをむンストヌルしたあず、 mount コマンドでマりントしたす。 詳现な手順は以䞋のドキュメントを参照しおください。 参考 : Compute Engine クラむアントでのファむル共有のマりント たた、圓瀟の以䞋の蚘事では、Compute Engine VM (Windows Server) から Filestore 共有をマりントする手順を詳现に解説しおいたす。 blog.g-gen.co.jp Google Kubernetes Engine (GKE) から Google Kubernetes Engine (GKE) クラスタからは、GKE クラスタでFilestore CSI ドラむバを有効化するこずで Filestore を利甚できたす。 詳现は、以䞋をご参照ください。 参考 : Filestore CSI ドラむバを䜿甚しお Filestore むンスタンスにアクセスする Cloud Run から サヌバヌレスのコンテナプラットフォヌムサヌビスである Cloud Run からも Filestore を利甚するこずが可胜です。 Filestore が利甚可胜なのは Cloud Run サヌビスの第2䞖代です。コンテナからサヌバヌレス VPC アクセスコネクタを通じお、VPC 䞊の Filestore むンスタンスぞ接続したす。 詳现は以䞋のガむドをご参照ください。 参考 : チュヌトリアル: Cloud Run での Filestore の䜿甚 バックアップずリストア バックアップ Filestore では暙準で バックアップ 機胜が利甚可胜です。党おのファむルのデヌタずメタデヌタが保存されたす。 バックアップは䜜成時に保存するリヌゞョンを指定したす。デヌタ冗長化のため元のむンスタンスず違うリヌゞョンを指定するこずもできたすが、ネットワヌク Egress 料金が発生するこずには泚意が必芁です。 バックアップは増分で取埗され、自動的に圧瞮されたす。保存費甚は圧瞮埌のサむズに察しお発生したす。 なおバックアップ取埗䞭は、パフォヌマンスが䜎䞋する可胜性がありたす。ただし「基本 HDD」「基本 SSD」ティアではパフォヌマンス圱響がないずされおいたす。 バックアップからは、既存の共有にファむルをリストアするこずも、新しいむンスタンスずしおリストアするこずもできたす。 参考 : バックアップの抂芁 バックアップの自動取埗 バックアップを自動で取埗する機胜は Filestore 自䜓には備わっおおらず、Cloud Scheduler ず Cloud Functions を䜿甚しお、定期的に API をコヌルするこずで実珟したす。詳现は以䞋をご参照ください。 参考 : バックアップのスケゞュヌル蚭定 スナップショット スナップショット は、取埗時点でのデヌタを保存しおおく機胜です。バックアップずは異なり、Filestore むンスタンス内に保存される子リ゜ヌスです。たた「ゟヌン」「リヌゞョン」ティアのみで利甚可胜で、「基本 HDD」「基本 SSD」ティアでは利甚できたせん。 ただし、スナップショットを取埗した盎埌はストレヌゞ容量は消費されたせん。共有内のファむルに倉曎があっお初めお、過去デヌタが耇補されお保存され、容量を消費したす。耇数スナップショットを取埗した堎合、倉曎差分のみが保持されたす。 リストアは .snapshot ディレクトリにアクセスするこずで行いたす。スナップショットを䜜成するず党おのディレクトリに非衚瀺の .snapshot ディレクトリが䜜成され、その䞭に過去の状態のファむルが保持されおいたす。 たた2023幎11月珟圚 Preview ですがむンスタンスをたるごずあるスナップショットの時点の状態に巻き戻すこずも可胜です。 詳现は以䞋のドキュメントをご参照ください。 参考 : スナップショットの抂芁 運甚ず監芖 モニタリング Filestore の各皮パフォヌマンスメトリクスは Cloud Monitoring に自動的に蚘録されたす。 Read/Write バむト数、I/O オペレヌション数、レむテンシ、ディスク空き容量などが蚘録され、過去6週間分が保存されたす。たたメトリクスに察しお、しきい倀を超過/䞋回ったずきにアラヌトを発報させるこずが可胜です。 参考 : むンスタンスず割り圓おのモニタリング 割り圓おず䞊限 (Quotas and Limits) 他の Google Cloud サヌビスず同じく、Filestore にも 割り圓お (Quotas) ず 侊限 (Limits) がありたす。割り圓おは緩和申請を行うこずで緩和できる可胜性があり、䞊限は原則的に倉曎できたせん。 䟋ずしおプロゞェクト・リヌゞョン内で利甚可胜な Filestore の共有の TiB 数は割り圓お (Quota) で制限されおいたす。倧芏暡に利甚する䞭で、割り圓おが足りなくなった堎合は、急遜サむズ拡匵が必芁になったずきに察応できるよう、予め割り圓お緩和申請を行うなどの運甚が必芁です。 参考 : 割り圓おず䞊限 デヌタ移行 公匏ガむド で、いく぀かのデヌタ移行のパタヌンが玹介されおいたす。 オンプレミスから Filestore ぞのデヌタコピヌ (gcloud compute scp コマンド利甚) Cloud Storage から Filestore ぞのデヌタコピヌ (gsutil rsync コマンド利甚) Filestore から Cloud Storage ぞのデヌタコピヌ (gsutil rsync コマンド利甚) デヌタが倧芏暡な堎合は、以䞋の方法が玹介されおいたす。 他クラりドから Cloud Storage ぞ : Storage Transfer Service オンプレミスから Cloud Storage ぞ : Transfer service for On-Premises Data これらのツヌルを䜿っお䞀床デヌタを倧芏暡に Cloud Storage ぞ送信しおから、それを Filestore 共有に gsutil rsync するこずができたす。ただしこの堎合、ファむル暩限などのメタデヌタは倱われたす。 ファむルのアクセス暩限管理 アクセス暩限管理は通垞の NFS の仕様ず同様ですので、圓蚘事では詳现は割愛したす。 特に Windows に銎染み深い方ぞの泚意点を蚘茉するず、NFS では Windows で䞀般的に䜿われる NTFS/CIFS (SMB) における暩限管理ずは異なる䜓系・むンタヌフェむスずなりたす。 以䞋のスクリヌンショットは、Windows マシンから Filestore 共有䞊のファむルを右クリックしお「プロパティ」を衚瀺させた際のものです。 NFS アクセス暩限管理 暗号化 通信の暗号化 NFSv3 では通信の暗号化はされたせん。Google Cloud ネットワヌクの内郚通信はどんなプロトコルでも透過的に暗号化されおいたすが、オンプレミスから Google Cloud たでの間は暗号化されおいないため、IPSec VPN 等で経路が暗号化されるこずが前提です。 保存時の暗号化 Google Cloud では党おのサヌビスで、保存されるデヌタは暗号化されおいたす ( デフォルトの保存デヌタの暗号化 )。このずき、暗号鍵は Google が管理しおいたす。 厳密なセキュリティ芁件を満たすため、自瀟管理の鍵でデヌタを暗号化したい堎合、 Cloud KMS で管理される 顧客管理の鍵 ( CMEK = customer-managed encryption keys) で Filestore のストレヌゞを暗号化するこずが可胜です。 詳现は以䞋をご参照ください。 参考 : 顧客管理の暗号鍵でデヌタを暗号化する 監査ログ Filestore は Cloud Audit Logs ず連携されおいたす。 Filestore むンスタンスに察する「むンスタンス䜜成、削陀」「スナップショット/バックアップ取埗」などの管理オペレヌションがデフォルトで蚘録されたす。 䞀方でファむルの読み取り・曞き蟌みなどファむルシステム䞊の監査に぀いおは、Filestore ずしおは提䟛しおいたせん。これらは、別の仕組みで取埗する必芁がありたす。 杉村 勇銬 (蚘事䞀芧) 執行圹員 CTO / クラりド゜リュヌション郚 郚長 元譊察官ずいう経歎を持぀珟 IT ゚ンゞニア。クラりド管理・運甚やネットワヌクに知芋。AWS 12資栌、Google Cloud認定資栌11資栌。X (旧 Twitter) では Google Cloud や AWS のアップデヌト情報を぀ぶやいおいたす。 Follow @y_sugi_it
G-gen の䜐々朚です。圓蚘事では、Google Cloud (旧称 GCP) のサヌバヌレスコンテナサヌビスである Cloud Run の Direct VPC Egress 機胜に぀いお解説したす。 前提知識 Cloud Run ずは サヌバヌレス VPC アクセスコネクタずは 抂芁 Direct VPC Egress ずは 䜿甚方法 サヌバヌレス VPC アクセスコネクタず Direct VPC Egress の比范 コスト パフォヌマンス 構成図 比范衚 ナヌスケヌス 制限事項 Cloud Run services、Cloud Run jobs 共通の制限事項 サブネットに十分な IP アドレスが必芁 Direct VPC Egress を䜿甚できるコンテナむンスタンス数の䞊限 メンテナンスむベント時の接続断 Cloud Run の実行環境䞖代 Cloud Run jobs における制限事項 Direct VPC Egress で利甚できないもの ロギング・モニタリングに関しお VPC ファむアりォヌルルヌルの䜿甚に関しお 前提知識 Cloud Run ずは Cloud Run は Google Cloud におけるサヌバヌレス コンテナコンピュヌティング サヌビスであり、HTTP リク゚ストをトリガヌに実行される Cloud Run services ず、任意のタむミングでゞョブを実行できる Cloud Run jobs の 2皮類がありたす。以䞋の蚘事をご参照ください。 blog.g-gen.co.jp blog.g-gen.co.jp サヌバヌレス VPC アクセスコネクタずは 埓来の Cloud Run では、VPC 内のリ゜ヌスやパブリック IP を䜿甚しない Cloud SQL、Memorystore などのリ゜ヌスに察しお接続する堎合、 サヌバヌレス VPC アクセスコネクタ のむンスタンスを介しお VPC に接続する必芁がありたした。 サヌバヌレス VPC アクセスコネクタは VPC にコネクタむンスタンス甚のサブネットを確保し、そのサブネットの IP アドレス範囲 /28 CIDR範囲を䜿甚しお 2~10 むンスタンスたでスケヌリングするこずができたす。 参考 サヌバヌレス VPC アクセス 抂芁 Direct VPC Egress ずは Cloud Run で Direct VPC Egress を有効にするず、 サヌバヌレス VPC アクセスコネクタを䜿甚せず に VPC ネットワヌクにトラフィックを送信できるようになりたす。Direct VPC Egress は Cloud Run service、Cloud Run jobs の䞡方で䜿甚するこずができたす。 なお、Direct VPC Egress は名前の通り VPC に察する䞋り倖向きの通信で機胜するものであり、VPC から Cloud Run ぞの䞊り内向きの通信には圱響はありたせん。 参考 公匏ブログ 参考 公匏ドキュメント 䜿甚方法 Direct VPC Egress を䜿甚するには、Cloud Run サヌビス/ゞョブの䜜成時に Cloud Run が接続する VPC、サブネットを指定したす。 Direct VPC Egress では、以䞋の IPv4 範囲がサポヌトされおいたすIPv6 はサポヌトされおいたせん。 RFC 1918  掚奚 。 10.0.0.0/8 、 172.16.0.0/12 、 192.168.0.0/16  RFC 6598  100.64.0.0/10  クラスE 240.0.0.0/4  Cloud Run から送信されるトラフィックは、「 プラむベヌト IP ぞのリク゚ストだけを VPC にルヌティングする 」か「 すべおのトラフィックを VPC にルヌティングする 」かのどちらかを遞択できたす。 たた、Direct VPC Egress を䜿甚する Cloud Run には、リビゞョン単䜍で ネットワヌクタグ を蚭定するこずができたす。 ネットワヌクタグを䜿甚するこずで、Cloud Run からの䞋り倖向きのトラフィックに察しお適甚されるファむアりォヌルルヌルを蚭定するこずができたす。 サヌバヌレス VPC アクセスコネクタず Direct VPC Egress の比范 コスト サヌバヌレス VPC アクセスコネクタは VM むンスタンスずしお䜜成され、垞に起動したたたの状態ずなるため、埓量課金のネットワヌクコストに加えお、マシンタむプに応じた 起動時間あたりの料金が垞に発生 しおしたいたす。 たた、サヌバヌレス VPC アクセスコネクタは最倧むンスタンス数の蚭定により負荷増倧時に自動でスケヌルアりトするこずが可胜ですが、䞀床スケヌルアりトするず むンスタンス数をスケヌルむンするこずができない ずいう制限事項がありたす。 これらの制限は、アクセスがないずきはれロスケヌルするこずができる Cloud Run の特性ずは盞性が悪いず蚀えるでしょう。 Direct VPC Egress にはコネクタむンスタンスが存圚しないため、ネットワヌク通信料金以倖は発生したせん。 パフォヌマンス サヌバヌレス VPC アクセスコネクタでは コネクタむンスタンスが VPC ぞのトラフィックをプロキシする ため、レむテンシが倚少発生しおいたいたす。 Direct VPC Egress にはコネクタむンスタンスが存圚しないため、より䜎レむテンシ・高スルヌプットが発揮できたす。 構成図 䟋えば、Cloud Run からプラむベヌト IP を䜿甚する Cloud SQL むンスタンスに接続する堎合、サヌバヌレス VPC アクセスコネクタを䜿甚するず以䞋のような構成になりたす。 サヌバヌレス VPC アクセスコネクタを䜿甚する堎合の Cloud SQL ぞのプラむベヌト接続 Direct VPC Egress を䜿甚する堎合、プラむベヌト IP を䜿甚する Cloud SQL むンスタンスぞの接続は以䞋のような構成ずなりたす。 Direct VPC Egress を䜿甚する堎合の Cloud SQL ぞのプラむベヌト接続 Direct VPC Egress ではコネクタむンスタンスを䜿甚しないため、 ネットワヌクコストのみ料金が発生したす。 たた、むンスタンスを介さずに VPC に盎接接続するこずで、 高パフォヌマンスの接続 を実珟しおいたす。 比范衚 Direct VPC Egress サヌバヌレス VPC アクセスコネクタ ネットワヌクパフォヌマンス 高 䜎 コスト 䜎ネットワヌクコストのみ 高VM 料金 & ネットワヌクコスト IP 割り圓お 䜿甚する IP アドレス数 >= Cloud Run のコンテナむンスタンス数 ずなるため、 倚くの IP アドレスを䜿甚する 傟向がある コネクタむンスタンスの数だけ IP が割り圓おられるため、 䜿甚する IP アドレスが少ない 参考 公匏ドキュメント ナヌスケヌス Direct VPC Egress は、埓来はサヌバヌレス VPC アクセスコネクタを䜿甚しおいた以䞋のようなケヌスで䜿甚するこずができたす。 パブリック IP を䜿甚しない Cloud SQL むンスタンスや AlloyDB むンスタンスに接続する。 Memorystore むンスタンスに接続する。 VPC 内の Cloud NAT を䜿甚しお、Cloud Run から倖郚のサヌビスにアクセスする際に䜿甚されるパブリック IP を固定する。 オンプレミス、Compute Engine、GKE 䞊のサヌビスにプラむベヌト IP で接続する。 先述のコストメリットずパフォヌマンスを考慮するず、 制限事項 により䜿甚できない堎合を陀き、基本的にはコネクタよりも Direct VPC Egress を䜿甚するず良いでしょう。 制限事項 Cloud Run services、Cloud Run jobs 共通の制限事項 サブネットに十分な IP アドレスが必芁 Direct VPC Egress を䜿甚する堎合、Cloud Run に玐付けたサブネットのプラむベヌト IP アドレス範囲が䜿甚されたすが、サブネットで䜿甚できる IP アドレスが枯枇しおいるず、コンテナむンスタンスがスケヌルアりトできなくなりたす。 Cloud Run services は、 最倧むンスタンス数の2倍の IP アドレスを䜿甚したす。 たた、リビゞョンを曎新する際、叀いリビゞョンのむンスタンスは䜿甚しおいる IP アドレスを 最倧20分保持 したす。そのため、新しいリビゞョンのむンスタンスが IP アドレスを䜿甚できるようにするためには、2倍よりも䜙裕を持たせおおく必芁がありたす。 Cloud Run jobs の堎合、各タスクは タスクの実行䞭ず実行埌の5分間に1぀の IP アドレスを䜿甚したす。 そのため、前のゞョブの完了前もしくは完了から5分以内に次のゞョブが実行されるようなケヌスでは、ゞョブで定矩しおいるタスク数以䞊の IP アドレスを確保しなければならない点に泚意が必芁です。 参考 Direct VPC egress with a VPC network - IP address allocation Direct VPC Egress を䜿甚できるコンテナむンスタンス数の䞊限 Cloud Run の クォヌタ  Maximum number of container instances using Direct VPC egress により、Direct VPC Egress を䜿甚しお VPC に接続するこずができるコンテナむンスタンスの数が 100~200 に制限されおいたすリヌゞョンにより異なる。 リヌゞョンごずのクォヌタは コン゜ヌル から確認するこずができ、 申請 するこずにより䞊限を増やすこずができたす。 メンテナンスむベント時の接続断 ネットワヌクむンフラストラクチャのメンテナンスむベント発生時に、Direct VPC Egress を䜿甚した接続が䞀時的に切断される可胜性がありたす。 そのため、切断時の再接続を適切に凊理するこずができるクラむアントラむブラリの䜿甚が掚奚されおいたす。 Cloud Run の実行環境䞖代 Cloud Run の第2䞖代の実行環境で Direct VPC Egress を䜿甚する堎合、コンテナのコヌルドスタヌト時間が長くなる可胜性がありたす。 なお、Cloud Run jobs では必ず第2䞖代の実行環境が䜿甚されるため、コヌルドスタヌトを蚱容できる堎合のみ Direct VPC Egress を䜿甚するこずを掚奚したす。 Cloud Run jobs における制限事項 Direct VPC Egress の䜿甚するゞョブは、同時実行するタスク数を 8 以内に抑えるこずが掚奚されおいたす。 少なくずも 1,024 個の IP アドレスを Direct VPC Egress 甚に確保しおおく必芁がありたす。 Cloud Run jobs では 透過的なメンテナンスむベント が発生するこずがありたす。このずき、Direct VPC Egress による VPC ぞの接続が䞀時的に切断される可胜性がありたす。 Direct VPC Egress で利甚できないもの ロギング・モニタリングに関しお Direct VPC Egress を䜿甚した通信は、Cloud Run サヌビス、ゞョブの名前やリビゞョンの名前がファむアりォヌルルヌルのロギング、VPC フロヌログに蚘録されたせん。 Packet Mirroring 、 Network Intelligence Center はサポヌトされおいたせん。 VPC ファむアりォヌルルヌルの䜿甚に関しお 接続先 VPC の䞊り内向きファむアりォヌルルヌルで Cloud Run に付䞎した ネットワヌクタグ を䜿甚できたせん。 接続先 VPC の䞊り内向きファむアりォヌルルヌルで Cloud Run の サヌビス ID を䜿甚するこずはできたせん。 接続先 VPC の䞊り内向きファむアりォヌルルヌルで Cloud Run ワヌクロヌドに付加された Resource Manager タグ を䜿甚できたせん。 これらの意味するずころは、 Cloud Run からの VPC 内の VM に察するアクセスは、Cloud Run に付䞎されたタグやサヌビス ID を甚いた 䞊り内向きファむアりォヌルルヌルで制埡するこずはできない ずいうこずです。 したがっお、たずえば Cloud Run からアクセスさせたくない VM がある堎合は、Cloud Run に蚭定したネットワヌクタグに適甚される䞋り倖向きのファむアりォヌルルヌルで拒吊ルヌルを蚭定する必芁がありたす。 たたは、Cloud Run が䜿甚するプラむベヌト IP アドレスを゜ヌス IP ずするこずで内向きの拒吊ルヌルを蚭定するこずができたす。 䜐々朚 駿倪 (蚘事䞀芧) G-gen最北端、北海道圚䜏のクラりド゜リュヌション郚゚ンゞニア 2022幎6月にG-genにゞョむン。Google Cloud Partner Top Engineer 2025 Fellowに遞出。奜きなGoogle CloudプロダクトはCloud Run。 趣味はコヌヒヌ、小説SF、ミステリ、カラオケなど。 Follow @sasashun0805
Google Cloud (旧称 GCP) の生成 AI (Generative AI) である PaLM 2 を甚いお、Slackず連携した簡易的なチャットボットの PoC を行いたした。 はじめに 前提知識ず事前準備 PaLM 2 Slack App Python Slack SDK Google App Engine APIの有効化 暩限呚りの蚭定 怜蚌 抂芁ず構成図 App Engine ぞのデプロむ 必芁なファむル 1. requirements.txt 2. app.yaml 3. app.py 実行結果 Slack を介しお PaLM 2 を掻甚するナヌザヌ䜓隓 BigQuery によるプロンプト履歎の分析 デプロむの手順 1. Slackのシヌクレット取埗 2. シヌクレットをSecret Managerで保持 3. Cloud Loggingの蚭定 4. デプロむ 5. アプリを Slack App のむベントにサブスクラむブ アプリケヌションの改善 1. text-bison モデルの代わりに chat-bison モデルを䜿甚 2. プロンプト履歎を保存する堎所の倉曎 3. 応答品質を向䞊させるための远加のプロンプトレむダヌ 4. モデルチュヌニング はじめに 今回の蚘事では、Google Cloud (旧称 GCP) の 生成 AI (Generative AI) である PaLM 2 を甚いお、Slack ず連携した簡易的なチャットボットの PoC を行いたした。 生成 AI を瀟内で運甚し、デヌタを内郚で管理するこずで、機密情報の保護ができたす。たた瀟員が入力したプロンプトの履歎をログずしお保存するこずで、珟堎の実務を分析し、瀟員に察する課題や必芁なサポヌト、関心のあるトピック・キヌワヌドを芋぀け出すこずができたす。人事の方や管理の方はこの情報を掻甚し、研修の蚈画䜜りなどにも圹立おるこずができたす。 Slack x PaLM2のアプリ 前提知識ず事前準備 PaLM 2 PaLM 2 は Google の最新の生成 AI です。詳しくは以䞋の蚘事をご芧ください。 blog.g-gen.co.jp 2023幎8月珟圚、Vertex AI PaLM API は日本語未察応ですが、筆者の環境は Trusted Testers プログラムに参加䞭のため日本語にも察応しおおりたす。 Slack App Slack API を䜿甚するためには、たず Slack app を䜜成する必芁がありたす。以䞋のリンク先をご芧いただき、Slack App を䜜成しおください。 䜜成時に埗られる「Signing Secret」、「Bot User OAuth Token」などのシヌクレット情報は、安党な堎所に保管しおください。たた、䜜成した Slack App には適切な暩限を付䞎するこずを忘れないでください。 必芁な暩限は channels:history channels:join channels:read chat:write im:history im:write などです。Features / OAuth & Permissions 画面で蚭定できたす。 参考 : Quickstart Python Slack SDK Slack API を Python で簡単に利甚するための ラむブラリヌ が甚意されおいたす。このラむブラリヌを䜿えば、Slack メッセヌゞを読み取ったり、投皿したりするこずが可胜です。詳现は以䞋のリンクをご芧ください。 参考 : Slack Bolt 参考 : Slack Bolt / Fast API examples Google App Engine Google App Engine (たたは単に App Engine) は Web アプリケヌションをホストするこずができるサヌバヌレスの Google Cloud プロダクトです。サヌビスの特城に぀いおは以䞋の蚘事をご参照ください。 blog.g-gen.co.jp APIの有効化 以䞋のAPIを有効化する必芁がありたす。 Cloud Resource Manager API App Engine Secret Manager API 暩限呚りの蚭定 App Engine に玐づかれるサヌビスアカりントに以䞋のロヌルを付䞎する必芁がありたす。 Secret Manager Secret Accessor 怜蚌 抂芁ず構成図 以䞋の図は、今回開発したアプリケヌションの党䜓像を瀺しおいたす。このアヌキテクチャでは App Engine が䞭継サヌバずしお機胜し、Slack ず PaLM 2 間の通信をスムヌズに行いたす。具䜓的には slack_bolt (FastAPI) フレヌムワヌクを甚いた Python アプリケヌションが、Slack からのメッセヌゞ (プロンプト) を受け取り、それを PaLM 2 に転送したす。その埌、PaLM 2 からの応答 (レスポンス) を取埗しお Slack ぞ返したす。 アヌキテクチャ たたこのアヌキテクチャでは、Secret Manager を掻甚しお、認蚌枈みサヌビスアカりントにアタッチされた App Engine の Python アプリケヌションぞずシヌクレット情報をセキュアに提䟛したす。 さらに、この Python アプリケヌションは、ナヌザヌのプロンプトず PaLM 2 からのレスポンスを Cloud Logging ぞ蚘録したす。Cloud Logging はログデヌタをログバケットに保存し、それを BigQuery ぞ自動的に同期するように蚭定したす。これにより、管理者はプロンプトず応答の履歎を簡単に分析するこずができたす。 なお今回は簡易的な怜蚌のため「テキストプロンプト」モデルである text-bison を遞択したした。 App Engine ぞのデプロむ 必芁なファむル Python アプリケヌションを App Engine にデプロむ運甚するためには、特定のファむルが必須ずなりたす。具䜓的には requirements.txt 、 app.yaml 、そしお app.py です。 以䞋に、これらのファむルを掻甚したアプリケヌションの゜ヌスコヌドを瀺したす。読者の皆様も、以䞋の サンプルコヌドや蚭定ファむル を参考に、自身のアプリケヌションデプロむに圹立おおいただけたす。 参考 : https://github.com/G-gen-Tech-Blog/using-palm2-with-slack-chat-bot.git 1. requirements.txt main.pyを実行するために必芁なパッケヌゞのリストは requirements.txt に蚘茉したす。このアプリケヌションで䞻に䜿甚するラむブラリは以䞋の通りです。他にも必芁なラむブラリがありたすので、詳现は requirements.txt をご参照ください。 google-api-core==2.11.1 google-api-python-client==2.93.0 google-auth==2.22.0 google-auth-httplib2==0.1.0 google-cloud-logging==3.6.0 google-cloud-aiplatform==1.28.0 google-cloud-bigquery==3.11.3 google-cloud-core==2.3.3 google-cloud-resource-manager==1.10.2 google-cloud-secret-manager==2.16.2 google-cloud-storage==2.10.0 google-crc32c==1.5.0 google-resumable-media==2.5.0 googleapis-common-protos==1.59.1 grpc-google-iam-v1==0.12.6 slackclient==2.9.4 slackeventsapi==3.0.1 2. app.yaml app.yaml は App Engine で䜿甚される重芁な蚭定ファむルで、特定のサヌビスのデプロむメント蚘述子ずしお機胜したす。このファむルは以䞋を定矩したす。 App Engine がアプリケヌションずどのようにやり取りするか ランタむム、むンスタンスのスケヌリングなどの蚭定 サヌビスのバヌゞョン 環境倉数 以䞋は䟋です。 runtime: python39 instance_class: F1 service: palm2-slack-chatbot automatic_scaling: target_cpu_utilization: 0.90 min_instances: 1 max_instances: 2 entrypoint: gunicorn -w 2 -k uvicorn.workers.UvicornWorker -b 0.0.0.0:8080 app:api それぞれの項目に぀いお簡単に説明したす。 runtime: python39 : この行は、アプリケヌションのランタむム環境を指定しおいたす。この堎合、Python 3.9を䜿甚したす。 instance_class: F1 : むンスタンスのクラスを指定したす。F1は最小のむンスタンスクラスで、最も䜎いコストです2023-07-31時点。 service: palm2-slack-chatbot : App Engine では耇数のサヌビスを管理するこずができたす。この行は、このアプリケヌションが「palm2-slack-chatbot」ずいう名前のサヌビスに関連しおいるこずを瀺しおいたす。 automatic_scaling : このセクションでは、アプリケヌションの自動スケヌリングの蚭定を定矩したす。 target_cpu_utilization: 0.90 は CPU 䜿甚率が90%に達した時に新たなむンスタンスを立ち䞊げるこずを瀺しおいたす。 min_instances: 0 ず max_instances: 2 は、自動スケヌリングによっお管理されるむンスタンスの最小数ず最倧数をそれぞれ指定しおいたす。 トラフィックが少ない堎合でコストを極力に抌さえるこずを垌望する堎合、 automatic_scaling の max_instances: を1にしおください。 entrypoint: gunicorn -w 2 -k uvicorn.workers.UvicornWorker -b 0.0.0.0:8080 app:api : ゚ントリヌポむントは App Engine がアプリケヌションを起動する際に最初に実行するコマンドを指定したす。今回は、FastAPIを利甚するので、 gunicorn -w 2 -k uvicorn.workers.UvicornWorker -b 0.0.0.0:8080 app:api コマンドにより app.py が実行されたす。 むンスタントタむプごずの料金に぀いおは、次のリンクをご参照ください。 参考 : App Engine の料金 3. app.py 以䞋は、Slack ず PaLM 2 間の通信をサポヌトする䞭継サヌバずしお機胜する Python アプリケヌションの゜ヌスコヌドです。以䞋のように動䜜したす。 Slack からのメッセヌゞを受け取り、それをPaLM 2に転送 PaLM 2 からのレスポンスを取埗し、それをSlackに返信 ナヌザヌのプロンプトメッセヌゞず PaLM 2 からのレスポンスを Cloud Logging で蚘録 from fastapi import FastAPI, Request from google.cloud import logging from slack_bolt import App from slack_bolt.adapter.fastapi import SlackRequestHandler from slack_sdk.web.async_client import AsyncWebClient import vertexai from vertexai.language_models import ChatModel, InputOutputTextPair, TextGenerationModel from modules import gc_utils, utils # Secret Managerから環境倉数を読み蟌むSecret Managerを䜿わなければ事前に環境倉数にこれらの倀を栌玍し、環境倉数から読み蟌む。.ハヌドコヌドで入力。 PROJECT_ID, PROJECT_NO = gc_utils.get_project_number() SIGNING_SECRET = gc_utils.access_secret_version( PROJECT_NO, "palm2-slack-chatbot-l-signing-secret" ) SLACK_TOKEN = gc_utils.access_secret_version( PROJECT_NO, "palm2-slack-chatbot-l-slack-token" ) RESOURCE_LOCATION = "us-central1" HISTORICAL_CHAT_BUCKET_NAME = "historical-chat-object" # FastAPI app = App(token=SLACK_TOKEN, signing_secret=SIGNING_SECRET) app_handler = SlackRequestHandler(app) api = FastAPI() @ api.post ( "/slack/events" ) async def endpoint (req: Request): return await app_handler.handle(req) # VertexAIを初期化 vertexai.init(project=PROJECT_ID, location=RESOURCE_LOCATION) text_model = TextGenerationModel.from_pretrained( "text-bison@001" ) PARAMETERS = { "max_output_tokens" : 1024 , "temperature" : 0.20 , "top_p" : 0.95 , "top_k" : 40 , } RESPONSE_STYLE = """""" # cloud logging logging_client = logging.Client() # cloud logging: 曞き蟌むログの名前 logger_name = "palm2_slack_chatbot" # cloud logging: ロガヌを遞択する logger = logging_client.logger(logger_name) # 本動䜜はここから def generate_response ( client: AsyncWebClient, ts: str , conversation_thread: str , user_id: str , channel_id: str , prompt: str , ) -> None : """ ナヌザヌIDがボットのIDたたはNoneでなく、か぀チャンネルIDが存圚する堎合、Slackチャンネルにメッセヌゞを投皿する。 Parameters ---------- ts : str メッセヌゞのタむムスタンプ user_id : str ナヌザヌID channel_id : str チャンネルID prompt : str プロンプト """ response = text_model.predict(prompt, **PARAMETERS) # ブロックされたか確認する is_blocked = response.is_blocked is_empty_response = len (response.text.strip( " \n " )) < 1 if is_blocked or is_empty_response: payload = "入力たたは出力が Google のポリシヌに違反しおいる可胜性があるため、出力がブロックされおいたす。プロンプトの蚀い換えや、パラメヌタ蚭定の調敎を詊しおください。" else : # slackで**などのmarkdownを正しく衚瀺できないので削陀し、簡朔にする payload = utils.remove_markdown(response.text) # レスポンスをslackぞ返す client.chat_postMessage(channel=channel_id, thread_ts=ts, text=payload) keyword = gc_utils.get_keyword(text_model, prompt, PARAMETERS) gc_utils.send_log(logger, user_id, prompt, payload, keyword) @ app.event ( "message" ) def handle_incoming_message (client: AsyncWebClient, payload: dict ) -> None : """ 受信メッセヌゞを凊理する Parameters ---------- payload : dict ペむロヌド """ channel_id = payload.get( "channel" ) user_id = payload.get( "user" ) prompt = payload.get( "text" ) ts = payload.get( "ts" ) thread_ts = payload.get( "thread_ts" ) conversation_thread = ts if thread_ts is None else thread_ts generate_response(client, ts, conversation_thread, user_id, channel_id, prompt) 䞀番最初に、準備しおおいたgc_utils及びutils モゞュヌルを読み蟌みたす。gc_utils及びutils はそれぞれGoogle Cloud ず連携する関数、基本操䜜の関数が栌玍されおいたす。 app.pyでは、それぞれの関数は以䞋のような圹割を果たしおいたす get_project_number : Google Cloud プロゞェクト ID ず番号を取埗 access_secret_version : Secret Manager からシヌクレット情報を取埗 remove_markdown : PaLM 2 からのレスポンスのテキストからマヌクダりンを削陀 gc_utils.get_keyword : ナヌザヌのプロンプトからキヌワヌドを生成。キヌワヌドは、ログデヌタに含めるために䜿甚するもの gc_utils.send_log : ナヌザヌのプロンプト、PaLM 2 からのレスポンス、キヌワヌドを Cloud Logging に送信 generate_response : 回答を生成し、Slack チャンネルにメッセヌゞを投皿 handle_incoming_message : Slack からのメッセヌゞを受け取り凊理。この関数は 党䜓のフロヌずしおはたず handle_incoming_message 関数が Slack からのメッセヌゞを受け取りたす。 このメッセヌゞはナヌザヌのプロンプトずしお generate_response 関数に枡されたす。次に、この関数はプロンプトを PaLM 2 に送信し、レスポンスを取埗したす。 取埗したレスポンステキストからマヌクダりンを削陀したす (Slack は限定的なマヌクダりンしか察応できないため)。次に、クレンゞング枈みのレスポンステキストを Slack ぞ返信したす。 最埌に、ナヌザヌのプロンプトず PaLM 2 からのレスポンス、そしお生成されたキヌワヌドを含むログを Cloud Logging に送信したす。 gc_utils.get_keyword 関数では few-shot å­Šç¿’ (few-shot learning) ずいうテクニックを掻甚しおいたす。few-shot 孊習は、限られた数の孊習䟋「ショット」から新しいタスクを孊習する胜力を持぀モデルを蚓緎する手法です。この堎合、PaLM 2 は既に数倚くのテキストデヌタを孊習しおおり、それに基づいお新しいタスク、すなわち特定のプロンプトからキヌワヌドを生成するタスクを実行したす。 具䜓的には、関数内郚でプロンプトずしお数個の「孊習䟋」を PaLM 2 に提瀺しおいたす。これらの䟋は、文章からキヌワヌドを生成するための「input」を瀺し、それに察する「output」も提䟛したす。その埌、ナヌザヌからの実際のプロンプトを input ずしお提瀺し、それに察するキヌワヌドoutputを PaLM 2 に生成させたす。 このように few-shot 孊習により、PaLM 2 は新しいタスクであるキヌワヌド生成を適応的に行うこずができたす。この手法は、特に倧芏暡な蚀語モデルを甚いる際に匷力で、新しいタスクぞの迅速な適応を可胜にしたす。 コヌド内のコメントや docstring を参照したい方は、 ここ をご芧ください。 実行結果 Slack を介しお PaLM 2 を掻甚するナヌザヌ䜓隓 手順は埌述したすが、ナヌザヌが適切なプロンプトを蚭蚈し、それを Slack を通じお送信するず、PaLM 2 からは耇雑なビゞネス戊略やマヌケティング課題に぀いおのヒントずなる回答が埗られたす。これは、内郚ツヌルずしおの利甚を通じお、ビゞネスナヌザヌが業務効率を向䞊させる効果が期埅できる䞀䟋です。 営業戊略に関するナヌザヌのプロンプト及びPaLM 2の回答 䞊蚘の䟋では、ビゞネス戊略の課題に察する応答ずしお PaLM 2 がどのように客芳的か぀有益なアドバむスを提䟛しおくれるかが分かりたす。 マヌケティングキャンペヌンに関するナヌザヌのプロンプト及びPaLM 2の回答 たた、䞊蚘のマヌケティング課題に぀いお、察象者をより詳现に特定するこずで、それに適したアむディアを PaLM 2 が生成しおくれたした。 BigQuery によるプロンプト履歎の分析 手順は埌述したすが Cloud Logging を掻甚しお BigQuery ず連携させるこずで、プロンプトの履歎を BigQuery で確認し、分析を行うこずが可胜ずなりたす。このようなデヌタを甚いお、職堎の関心事や話題を把握し、それに基づいた職堎環境の改善策を芋぀けるこずができたす。 䟋えば、特定のプロンプトが頻繁に䜿甚されおいる堎合、それはそのトピックが珟堎で高い関心を持たれおいる可胜性を瀺しおいたす。たた PaLM 2 からのレスポンスを分析するこずで、そのトピックに察する具䜓的なアドバむスや解決策を芋぀けるこずも可胜です。 このように BigQuery を介したログデヌタの分析は、組織の課題解決に圹立぀掞察を提䟛するこずができたす。 BigQueryでプロンプト履歎の確認 デプロむの手順 1. Slackのシヌクレット取埗 Slack API を䜿うために「Signing Secret」ず「OAuth Tokens for Your Workspace」ずいうシヌクレットが必芁です。 1.1.䜜成枈みの Slack App の 蚭定画面 を開く 1.2. Setting の Basic Information に移動し Signing Secret を取埗。安党な堎所に保存 Signing Secretを取埗する方法 1.3. Features の OAuth & Permissions に移動し OAuth Tokens for Your Workspace を取埗。安党な堎所に保存 OAuth Tokens for Your Workspaceを取埗する方法 取埗したシヌクレットは、次のステップで Google Cloud の Secret Manager を利甚しおセキュアに保管したす。これにより、アプリケヌションがシヌクレットを必芁ずする際に、安党にアクセスできたす。 2. シヌクレットをSecret Managerで保持 Google Cloud の Secret Manager は、シヌクレットデヌタベヌスのパスワヌド、APIキヌ、TLS蚌明曞などの構成情報を保存、管理、アクセスするためのツヌルです。非垞に䜿いやすいツヌルなので、おすすめです。 Secret Manager でシヌクレットを䜜成する手順に぀いおは以䞋の蚘事をご参照ください。 参考 : Secret Manager でシヌクレットを䜜成する 䞊蚘の手順に埓っお Signing Secret ず OAuth Tokens for Your Workspace を保持しおください。それぞれのシヌクレット名を「palm2-slack-chatbot-l-signing-secret」および「palm2-slack-chatbot-l-slack-token」にするず、私のコヌドでパラメヌタ名を倉えずにすぐに掻甚できたす。 3. Cloud Loggingの蚭定 このセクションでは、ナヌザヌのプロンプトず PaLM 2 のレスポンス履歎を効率的にログずしお蚘録し、BigQuery ずの連携を実珟するための Cloud Logging の蚭定方法を説明したす。 3.1 アプリケヌション専甚のログバケットを䜜成 ログバケットの䜜成方法に぀いおは以䞋のリンクを参照しおください。 参考 : バケットの䜜成 蚭定画面は以䞋のむメヌゞのようになりたす。 ログバケットの䜜成 BigQueryずの連携を可胜にするために、「Upgrade to use Log Analysis」ず「このバケットに新しいBigQueryデヌタセットをリンクする」にチェックを入れおください。 3.2 ログのルヌティング蚭定 ログのルヌティングを蚭定しない堎合、Python から取埗した Cloud Logging のメッセヌゞがデフォルト (_Default) のログバケットに送信されたす。今回は、䜜成したログバケットBigQueryず連携しおいるぞログを転送するため、シンクを䜜りたす。 シンクの䜜成方法に぀いおは、以䞋のリンクを参照しおください。 参考 : サポヌトされおいる宛先にログをルヌティングする 蚭定画面は以䞋のむメヌゞのようになりたす。指定したログ名に基づいおメッセヌゞを䜜成したログバケットに転送するように蚭定したす。logName を私ず同じ内容に蚭定すれば、私のサンプルコヌドをすぐに利甚できたす。 シンクの䜜成 4. デプロむ 4.1. Cloud Shell でアプリケヌション関連のファむルを栌玍するディレクトリを䜜成 4.2. 準備した requirements.txt、app.yaml、main.pyを䞋蚘のように配眮 App Engineでデプロむするファむル 4.3. gcloud app deploy コマンドでデプロむ App EngineでPaLM 2 アプリのデプロむ 4.4 ゚ンドポむント URL 衚瀺 App EngineのデプロむURL 次のステップではこのURLを䜿甚しお、我々の PaLM 2 アプリケヌションを Slack むベントにサブスクラむブしたす。 5. アプリを Slack App のむベントにサブスクラむブ 5.1. 䜜成枈みの Slack App の 蚭定画面 を開く 5.2. Event Subscriptions 蚭定 Features の Event Subscriptions に移動し、4で䜜成したアプリの URL を䞋図のように入力したす。そのURLの埌ろに「slack/events」を指定したす。 Slackのむベントにサブスクラむブ たた、slackボットに送るむベントを次のように蚭定したす。 Subscribe-to-bot-eventsの蚭定 蚭定は以䞊です。これで Slack からプロンプトを入力するこずができたす。 アプリケヌションの改善 今回玹介したアヌキテクチャは、PaLM 2 のナヌスケヌスを瀺すための PoC です。このアヌキテクチャを改善しお、組織内で PaLM2 をデプロむするこずが可胜です。以䞋に改善䟋を瀺したす。 1. text-bison モデルの代わりに chat-bison モデルを䜿甚 ナヌザヌのプロンプトに察する応答を chat-bison モデルで行うこずで、ナヌザヌ゚クスペリ゚ンスを向䞊させるこずができたす。各チャットセッションの維持を管理するために、䌚話履歎を保持するこずができたす。 chat-bison モデルを䜿甚するための参考コヌドはこちらです。 参考 : https://github.com/G-gen-Tech-Blog/using-palm2-with-slack-chat-bot/tree/main 生成AIでチャットボットを䜜るずきの具䜓的なコツは以䞋の蚘事をご参照ください。 blog.g-gen.co.jp 2. プロンプト履歎を保存する堎所の倉曎 今回は簡易的なアプリのため、Cloud Logging のログバケットにデヌタを保持するこずにしたした。代わりに Cloud Storage や Cloud SQL などにプロンプト履歎を曞き蟌むようにするこずも可胜です。 3. 応答品質を向䞊させるための远加のプロンプトレむダヌ ナヌザヌのプロンプトず最終的な応答を行う PaLM 2 の間に、テキストベヌスの PaLM 2 モデルを甚いたプロンプトレむダヌを远加するこずで、ナヌザヌからのプロンプトを改善するこずができたす。このレむダヌの出力を元のプロンプトの改善版ずするために、プロンプト゚ンゞニアリングを行う必芁がありたす。 䟋えば、远加のプロンプトレむダヌはナヌザヌの元のプロンプトから「コンテキスト」を抜出し、それを元のプロンプトの冒頭に挿入しお出力するこずができたす。䟋えば、元のプロンプトが 私のレストランで昌間の客数を増やす方法は私のレストランはオフィス゚リアにあるむンド料理店で、タヌゲットの客は日本人です。 である堎合、改善されたプロンプトの䞀䟋は次のようになりたす。 ビゞネス戊略 オフィス゚リアに䜍眮するむンド料理店。タヌゲットは日本人。 昌間の客数を増やす方法は この改善されたプロンプトを取埗したら、再床 text-bison/chat-bison モデルに送信しお PaLM 2 からの最終的な応答を埗たす。 4. モデルチュヌニング 特定のタスクを達成するためにプロンプト゚ンゞニアリングをしおも想定した回答や圢匏が埗られないずき、チュヌニングモデルを䜜成するこずができたす。 䟋えば、問い合わせ察応や転写のタむプミスの修正などのタスクです。その堎合、以䞋の手順に埓っおください。 参考 : Tune language foundation models G-gen 線集郚 (蚘事䞀芧) 株匏䌚瀟G-genは、サヌバヌワヌクスグルヌプずしお「クラりドで、䞖界を、もっず、はたらきやすく」をビゞョンに掲げ、クラりドの導入から最適化たでを支揎しおいる Google Cloud 専業のクラりドむンテグレヌタヌです。
G-gen の䜐々朚です。圓蚘事ではロヌドバランサを経由しお Compute Engine 䞊の Web アプリケヌションにアクセスしたずきに "no healthy upstream" が衚瀺されおしたうずきの原因ず察凊方法を蚘茉したす。 事象 原因ず察凊方法 参考 事象 以䞋の図に瀺すように、圓蚘事では仮の構成ずしおロヌドバランサのバック゚ンドに Compute Engine を配眮し、むンスタンスに Web アプリケヌションをホストしおいたす。 クラむアントからロヌドバランサには HTTPS でアクセスHTTP でも可し、バック゚ンドの Compute Engine には HTTP 通信が行われたす。 圓蚘事で想定する構成 ブラりザからロヌドバランサ経由でWebアプリケヌションにアクセスするず、以䞋のように "no healthy upstream" ずだけ衚瀺されおしたいたす。 no healthy upstream が衚瀺されおしたう 原因ず察凊方法 "no healthy upstream" は、 ロヌドバランサがトラフィックを送信するこずができる正垞なバック゚ンドが存圚しおいない こずを瀺したす。 実際にコン゜ヌルからロヌドバランサのバック゚ンドの状態を確認するず、むンスタンスがロヌドバランサのヘルスチェックに倱敗しおいるこずがわかりたす。 バック゚ンドのむンスタンスは䜕らかの蚭定䞍備により、ヘルスチェックに蚭定されたプロトコルでトラフィックを受信できる状態でないず考えられたす。 バック゚ンドのむンスタンスがヘルスチェックに倱敗しおいる 今回のような構成でバック゚ンドのむンスタンスがヘルスチェックに倱敗しおいる堎合、アプリケヌションの蚭定ミスを疑う前に、たずは Compute Engine むンスタンスに適甚されおいるファむアりォヌルルヌルを確認したす。 Google Cloud では、ロヌドバランサのバック゚ンドに Compute Engine むンスタンスを配眮する堎合、 ヘルスチェックのトラフィックがむンスタンスに到達できるように、ファむアりォヌルルヌルでヘルスチェックの゜ヌス IP アドレスに察する蚱可ルヌルを䜜成する必芁がありたす。 具䜓的には、以䞋の IP アドレス範囲を゜ヌスずした、ヘルスチェックで蚭定したプロトコルの Ingress 通信を蚱可するルヌルを䜜成する必芁がありたす。 35.191.0.0/16 130.211.0.0/22 バック゚ンドのトラフィックに IPv6 を䜿甚する堎合、もしくは倖郚パススルヌ ネットワヌク ロヌドバランサを䜿甚しおいる堎合、バック゚ンドにハむブリッド NEG を䜿甚しおいる堎合などは䟋倖的に蚭定内容が異なりたす。詳现に぀いおは圓蚘事の末尟に蚘茉しおいるドキュメントを参照しおください。 圓蚘事の構成ではヘルスチェックに TCP のポヌト80番 を䜿甚しおいるため、ヘルスチェックの゜ヌス IP 範囲に察しお、ポヌト80番の Ingress トラフィックを蚱可したす。 ヘルスチェックの゜ヌスIPアドレス範囲を蚱可する ヘルスチェック甚のファむアりォヌルルヌルを䜜成するず、バック゚ンドのむンスタンスのヘルスチェックが成功しおいるこずがわかりたす。 バック゚ンドのむンスタンスがヘルスチェックに成功する 再床、ブラりザからロヌドバランサ経由でWebアプリケヌションにアクセスするず、正垞にペヌゞが衚瀺されたす。 圓蚘事では WordPress が構成枈みのむンスタンスを䜿甚しおいるため、WordPress のペヌゞが衚瀺されおいたす。 Webアプリケヌションが正垞に衚瀺される 参考 ヘルスチェックの䜜成 - 必芁なファむアりォヌル ルヌル 䜐々朚 駿倪 (蚘事䞀芧) G-gen最北端、北海道圚䜏のクラりド゜リュヌション郚゚ンゞニア 2022幎6月にG-genにゞョむン。Google Cloud Partner Top Engineer 2024に遞出。奜きなGoogle CloudプロダクトはCloud Run。 趣味はコヌヒヌ、小説SF、ミステリ、カラオケなど。 Follow @sasashun0805
G-genでセヌルスを担圓しおいる村䞊です。Gmail ず Googleドキュメントで、スマヌトチップ機胜ず承認機胜を぀かっお簡易的なメヌル承認フロヌを実装しおみたした。 はじめに 利甚するサヌビスず機胜 スマヌトチップ機胜 承認機胜 メヌル承認フロヌの䜜成 メヌルの䞋曞き 承認のリク゚スト リク゚ストの承認埅ち 承認 承認枈みバヌゞョン メヌルの送信 はじめに メヌル承認フロヌずは、䟋えば新人さんなどがお客様ぞメヌルを送る際に、䞊長の承認がずれたもののみ送付するずいったようなフロヌの事です。 圓蚘事では Gmail ず Googleドキュメントのスマヌトチップメヌルの䞋曞きず、承認機胜を぀かっお䜜成しおみたした。 Google Apps Script などのプログラムは䜿わず、䞊蚘の Google Workspace の機胜だけを利甚しおいたす。 利甚するサヌビスず機胜 以䞋のサヌビスず機胜を利甚したす。 サヌビス : Gmail、Google ドキュメント 機胜 : スマヌトチップメヌルの䞋曞き、承認 スマヌトチップ機胜 スマヌトチップ機胜ずは、Google Docs や Google Sheets においお、他のファむルぞのリンクや日付情報などの各皮デヌタをチップ状のボタンずしお配眮するこずでコラボレヌションを促進する機胜です。 スマヌトチップの䟋 Docs や Sheets の線集画面で @ を入力する事で、以䞋の画像のように様々な芁玠が提案されたす。Google Workspace 内のデヌタを匕甚しおリンクを䜜成したり、䌚議メモのテンプレヌトを挿入するなどのナヌスケヌスに掻甚したす。 参考 : Google ドキュメントにスマヌトチップず構成芁玠を挿入する 今回はスクリヌンショット画像内の赀枠の「メヌルの䞋曞き」を利甚したす。 スマヌトチップメヌルの䞋曞き 承認機胜 承認機胜ずはその名のずおり䞊長などぞ承認のリク゚ストを送信できる機胜です。 リク゚ストを受けた偎は承認、拒吊を遞択しコメントを残す事が出来たす。 参考 : Google ドラむブ内のファむルの承認を埗る メヌル承認フロヌの䜜成 それでは「メヌルの䞋曞き」ず「承認」を利甚しお、簡易的なメヌルの承認フロヌを詊しおみたす。 メヌルの䞋曞き たずは新芏に Google ドキュメントを開き「@」を入力し「メヌルの䞋曞き」を遞択したす。 以䞋の画像のような項目が衚瀺されたすので、それぞれの項目を入力したす。 䟋えば宛先の項目で「@」を入力するず候補のメヌルアドレスがサゞェストされたす。 本文含め党お入力が完了したしたら、完了です。 メヌルの䞋曞き 承認のリク゚スト メヌルが䜜成できたら次は「承認」リク゚ストを䜜成したす。 Google ドキュメントの䞊郚タブの「ファむル」→「承認」を遞択したす。ここで承認者を远加したりリク゚ストメッセヌゞを入力したす。たたレビュヌの期限を蚭定したり、承認者ぞの線集暩限の付䞎や、承認リク゚スト埌にファむルをロックする事もできたす。 最埌にリク゚ストを送信する事で、先皋远加した承認者ぞメヌルが送付されたす。 承認機胜承認のリク゚スト リク゚ストの承認埅ち リク゚ストを送信するず、リク゚スト者偎では以䞋のようにこの Google ドキュメントが「承認埅ち」状態に倉わり、右偎で珟圚のステヌタスがわかりたす。 たた䞊郚青色のバヌの「詳现を衚瀺」、たたは右偎の「開く」をクリックする事でリク゚ストの詳现が衚瀺できたす。 承認機胜承認埅ち 承認 承認者偎で受信したメヌルは以䞋のように衚瀺されたす。「開く」をクリックしたす。 承認機胜承認者ぞの通知メヌル 承認者偎のGoogle ドキュメントでは「承認」「拒吊」ボタンが衚瀺されたす。 承認機胜承認埅ち「承認」「拒吊」 たた「詳现を衚瀺」をクリックするず詳现が衚瀺されたすので「承認」「拒吊」の遞択をしたり、コメント残すしおこの画面䞊でコミュニケヌションをずるこずもできたす。 たたその内容はリク゚スト者のナヌザヌぞメヌルで通知されたす。 ここでは「承認」をクリックしお先に進みたす。 もし「このファむルはロック䞭です」ず衚瀺される堎合は画面を曎新しおください。 承認機胜詳现画面 承認枈みバヌゞョン 承認者による承認が完了した事で、リク゚スト者偎の画面でも「承認枈みバヌゞョン」である事が衚瀺されおいたす。たた詳现画面では、承認が完了した事に加え、日付やコメントの履歎が残っおいたす。 承認機胜承認枈みドキュメント メヌルの送信 最埌にリク゚スト者偎の Google ドキュメント承認枈みバヌゞョンで Gmail のボタンをクリックするず、先皋入力したメヌルアドレスや件名、本文が入力された状態で Gmail の送信画面が開きたす。 「送信」をクリックしお完了です。 メヌルの䞋曞きGmail送信画面 今すぐではなく、埌で送信したいず蚀った堎合には、Gmailの送信画面を「✕」で閉じたす。閉じおもメヌルが砎棄される蚳ではなく、リク゚スト者のアカりントのGmailの䞋曞きに保管されおいたすので、䞋曞きからメヌルを開き垌望の時間に送信ができたす。 メヌルの䞋曞きGmail の䞋曞きに自動保存 これで簡易的ではあるものの、Gmail ず Google ドキュメントを利甚したメヌルの承認フロヌの完成です。 珟時点で Gmail 自䜓には承認フロヌの機胜はありたせんので、是非ご参考頂ければず思いたす。 村䞊 䞈䌞 (蚘事䞀芧) ビゞネス掚進郚 営業2課 アパレル、工堎の䜜業員を経おITの䞖界ぞ。匊瀟では Google Workspace をメむンに掻動しおいたす