SCSKクラウドソリューション の技術ブログ
全1141件
こんにちは。SCSKの山口です。 Google Cloud にて利用できる『Google Agentspace』についてご存知でしょうか？？ Agentspaceを利用することで、 組織全体のコンテンツを連携させ、根拠に基づいたパーソナライズされた回答を生成する。 ワークフローアクションと連携してタスクを実行することで、従業員が必要な情報を適切なタイミングで入手する。 ことが可能となります。 Google Cloud 公式サイト： Google Agentspace | Google Cloud Google Agentspace の利用に際しては 『 早期アクセス（Early Access）の申請が必要』 となります。 （執筆時 2025.4.9時点） 詳細については、以下の応募フォームをご確認ください。 Google Agentspace early access また、本ブログに添付しているコンソール画面についても執筆時時点のものとなります。 更新されている内容については、公式のドキュメントをご確認ください。 本記事では、 『 Google Agentspace 』について色々と調査し、実際に触ってみましたので、その魅力について少しだけご紹介させていただければと思います。 また、「Agentspaceについてもっと知りたい！！！」という方はあわせて以下もご覧ください。 【Google Cloud】Agentspaceについてご存じですか？①「概要編」 Google Agentspace について調査し、実際に触ってみましたので、その魅力についてご紹介させていただければと思います。 blog.usize-tech.com 2025.04.10 【Google Cloud】Agentspaceについてご存じですか？③「Agent呼び出し編」 Dialogflow (DFCX) エージェントをアシスタント機能としてAgentspaceから呼び出してで利用できるようにする構成を紹介します。 blog.usize-tech.com 2025.04.10 この記事に書いてあること 今回は、そんなAgentSpaceを実際に触ってみたブログになるのですが、下記について書きます。 ブレンドRAG ブレンドRAGとは、 Agentspace Enterpriseの主要な7つの柱 のうちの一つとされている機能です。 ブレンドRAGを活用することで、 複数の形式やプラットフォームに分散されたエンタープライズデータ に基づく、AI生成ユースケースを強化することができます。 普段の業務において、一つの資料だけで完結する作業は限りなく少なく、複数のソースからの情報の収集が必要になることがほとんどだと思います。 今回ご紹介するブレンドRAGは、そういった 「複数のデータソースから情報を収集し、精査する」 際にかなり強力な機能になります。 Google Agentspace Enterprise overview | Google Cloud cloud.google.com とりあえず触ってみる 今回は、 BigQueryテーブル（構造化データ） Cloud Storage上のテキストファイル（非構造化データ） の二つをデータソース（データストア）として接続し、ブレンドRAGを構成します。 使用データ BigQueryテーブル 過去のブログで使用した下記テーブルを流用します。 従業員の氏名、業種、誕生日、居住国が入っています。 Cloud Storage テキストファイル もう一つのデータストアとして、Cloud Storageを指定し、下記テキストファイルを入れておきます。 とある従業員の業種が変更になっており、とある従業員がアメリカへ引っ越した とある従業員が4月いっぱいで退職する という内容の議事メモが含まれています。 しかし、このメモの内容は まだBigQueryの従業員情報のテーブルには反映がされていません 。 この状態で二つのデータストアを接続し、最新の情報を返してくれるのか？を試します。 データストア接続 ここでは詳細な手順の説明を省きます。手順については下記ブログをご参照ください。 【Google Cloud】Agentspaceについてご存じですか？②「検索（Cloud Storage）編」 本記事では、Agentspaceのアシスタント機能（検索機能）を紹介します。 blog.usize-tech.com 2025.04.10 アプリを使ってみる 接続されているデータストアを確認します。アプリ画面右上の「ソースを管理」から確認できます。 議事録（Minutes）と従業員情報（User Datastore）の二つが接続されていることがわかります。 まずは、 議事録（Minutes）の接続を切った状態で 質問を投げてみます。 「エンジニアだ」という答えが返ってきました。こちらはBigQueryテーブルの内容と一致していますね。 次に、 議事録（Minutes）を含んだ状態 で同じ質問を投げてみます。（※ソースの変更は反映に時間がかかる場合があります。） 「以前はエンジニアだったが、セールスに変更になった」という答えが返ってきました。 BigQueryテーブルとCloud Storage上のファイルの内容を収集 し、回答を出力していることがわかります。 もう一つ、従業員が転居した情報も、 変更履歴をふまえて 回答してくれています。 2025年5月以降の情報を聞いてみると、 決定している将来の変更についても情報を回答してくれました。 最後に 今回は『 Google Cloud のAgentspace 』について実際のデモともにご紹介させていただきました。 複数のデータソース（データストア）を接続し、精査した上で回答を生成させる 。そんなデモを実感いただけたと思います。 実務においては、 いろんな場所にある いろんなフォーマットの いろんな人が書いた 情報を精査する必要がある場面が多くあると思います。 それは大抵、今回のデモのような小規模なデータではなく、膨大な量のデータになると思われます。 そんな時、今回紹介した「ブレンドRAG」を活用することで、 情報の収集、精査が瞬時に可能になり、業務の大幅な効率化 が見込めます。 また、Agentspaceは様々なデータソースの横断検索に対応しています。（※2025年4月時点） そのため、導入にあたって 「データソースを一か所に集約させる」 という作業を行うことなく、 現状の業務環境にフィットさせる形 で利用を開始することが可能です。 デモを通して、皆さんにもこの恩恵をぜひ味わっていただきたいなと強く感じました。 今後とも、AIMLに関する情報やGoogle CloudのAIMLサービスのアップデート情報を掲載していきたいと思います。 最後まで読んでいただき、ありがとうございました。 [共同執筆者紹介] 八巻綾太 クラウド(主に生成AI)の専門部隊に所属し、 ボイスボット導入やVOC分析など、生成AIを絡めた業務効率化の案件を担当しています。 Google Cloudを触り始めて２年目です。 ブログを通じて技術をインプットしたり、案件や自己研鑽で培ったノウハウを積極的にアウトプットしていきたいと思います。 島村裕哉 SCSK株式会社のクラウド専門部隊に所属 Google Cloudの ・AI MLサービス選定/導入コンサルティング/導入サポート/AI 基盤・運用構築 まで多く案件を担当 Google Cloud Partner Top Engineer 2024・2025 受賞 カテゴリ：Cloud AI/ML Google Cloud Next Tokyo 出展 Google Cloud Day ’23 Tour 登壇 「AI は選んで組み込んで実装！最新 AI を道具として有効利用するためには！？」 ■好きな Google Cloud サービス：Vertex AI / Dialogflow CX / Visual Inspection AI / Cloud Run
こんにちは。SCSKの山口です。 Google Cloud にて利用できる『Google Agentspace』についてご存知でしょうか？？ Agentspaceを利用することで、 組織全体のコンテンツを連携させ、根拠に基づいたパーソナライズされた回答を生成する。 ワークフローアクションと連携してタスクを実行することで、従業員が必要な情報を適切なタイミングで入手する。 ことが可能となります。 Google Cloud 公式サイト： Google Agentspace | Google Cloud Google Agentspace の利用に際しては 『 早期アクセス（Early Access）の申請が必要』 となります。 （執筆時 2025.4.9時点） 詳細については、以下の応募フォームをご確認ください。 Google Agentspace early access また、本ブログに添付しているコンソール画面についても執筆時時点のものとなります。 更新されている内容については、公式のドキュメントをご確認ください。 本記事では、 『 Google Agentspace 』について色々と調査し、実際に触ってみましたので、その魅力について少しだけご紹介させていただければと思います。 また、「Agentspaceについてもっと知りたい！！！」という方はあわせて以下もご覧ください。 【Google Cloud】Agentspaceについてご存じですか？①「概要編」 Google Agentspace について調査し、実際に触ってみましたので、その魅力についてご紹介させていただければと思います。 blog.usize-tech.com 2025.04.10 【Google Cloud】Agentspaceについてご存じですか？③「Agent呼び出し編」 Dialogflow (DFCX) エージェントをアシスタント機能としてAgentspaceから呼び出してで利用できるようにする構成を紹介します。 blog.usize-tech.com 2025.04.10 この記事に書いてあること 今回は、そんなAgentSpaceを実際に触ってみたブログになるのですが、下記について書きます。 データストア接続（BigQuery） 情報の検索元（データストア）として「BigQuery」を接続し、様々な質問をチャット形式で投げて実際にデータを探索してみたいと思います。 実際にエージェントを使う際、 「どこまで回答してくれるの？？？」 が一番気になるポイントになると思うので、今回は下記の質問を試します。 レベル①：テーブル内のデータに対するシンプルな質問 レベル➁：テーブル内に直接回答となるデータはないが、一目で回答がわかるレベルの質問 レベル③：テーブル内にない情報（今回は今日の日付）をふまえた上で回答が必要になる質問 レベル④：テーブル内にない情報（今回は今日の日付）をふまえた上で、計算が必要になる質問 レベル⑤：テーブル内にないデータに対する質問 とりあえず触ってみる データストア接続：BigQuery まずは、データストアとしてBigQueryテーブルを接続し、検索をやってみます。 下記のテーブルを接続します。 アプリを作成 Google Cloudコンソールから「AI Applications」ページへ遷移します。 画面上部の「アプリを作成する」をクリックし、アプリ作成画面へ遷移します。 「エンタープライズ検索とアシスタント」の「作成」をクリックし、構成画面に遷移します。 各種情報を入力後、「続行」をクリックします。今回の構成は下記です。 アプリ名：bigquery-app 会社名：SCSK アプリのロケーション：global 階層の選択：検索＋アシスタント 「データストア」画面で「データストアを作成」をクリックします。 今回は新規でデータストアを作成します。 「データソースを選択」の画面で、「BigQuery」の「SELECT」をクリックします。 「BigQueryからデータをインポート」の画面で、情報を入力後、「続行」をクリックします。 What kind of data are you importing?：Structured – BigQuery table with your own schema 同期の頻度：1回限り BigQueryのパス：scsksdv-dev-agentspace.agent_space.user 「スキーマの確認とキープロパティの割り当て」で各種情報を入力し、「続行」をクリックします。 アプリケーション側に「データを理解させるため」に重要な項目となりそうなので、選択が可能な項目について説明します。 項目名 概要 キープロパティ ドキュメントの意味を理解するために使用される重要な情報を示します。 取得可能 このフィールドが検索レスポンスに含まれるかどうかが決まります インデックスを作成可能 このフィールドをファセット（検索結果を絞り込むための属性）として使用できるかどうかが決まります 動的ファセット可能 動的ファセットとしてこのフィールドを使用できるかどうかを決定します 検索可能 このフィールドを検索で使用できるかどうかが決まります 完了可能 今回は下記設定で進めます。 「データストアの構成」画面で、下記情報を入力し「作成」クリックします。 アプリ作成の画面に再度遷移するので、画面下部の「作成」をクリックします。 作成が正常に完了すると、作成したアプリの画面に遷移します。 作成したアプリを使ってみる では、作成したアプリを使ってみます。 作成したアプリ画面の左ペイン内「統合」タブの「ウェブアプリへのリンク」に、作成したアプリのURLが記載されています。この右側の「開く」をクリックします。 →この画面（使用可能）になるまで数分かかりました。 作成したアプリでいろいろ聞いてみましょう。 レベル①：テーブル内のデータに対するシンプルな質問 お～、正しい情報がちゃんと情報が返ってきましたね。 レベル➁：テーブル内に直接回答となるデータはないが、一目で回答がわかるレベルの質問 テーブルの情報だけじゃ回答できない、ちょっと複雑な質問を投げてみましょう。 凄い、、正しい人数がちゃんと返ってきました。裏で「SELECT COUNT(*) WHERE role=…」みたいな SQLクエリが必要になりそうな情報 も回答してくれています。 レベル③：テーブル内にない情報（今回は今日の日付）をふまえた上で回答が必要になる質問 もう少し砕けた質問を（砕けた聞き方で）聞いてみましょう。 凄いですね、、今日の日付をふまえた上で情報精査し、回答してくれました。 レベル④：テーブル内にない情報（今回は今日の日付）をふまえた上で、計算が必要になる質問 もう少し難しくしましょう。今日の日付情報をふまえた上で、簡単な計算が必要になる（クエリ発行が必要な）質問を投げます。 これもちゃんと回答してくれます。さらに、 「回答の下書き」 を展開すると、 なんと、回答のために 裏で発行されたコード（Python） を見ることができます。 最後に、データストア上に存在しない情報を聞いてみましょう。 思いがけず、 ドラ●もん を描いていそうな名前になりましたが、 デ ータストア上に情報がないので、その旨回答 してくれています。 「ロールは漫画家です。」とか返ってこなくてよかったです。 最後に 今回は『 Google Cloud のAgentspace 』について実際のデモともにご紹介させていただきました。 データソースとして実際に BigQuery を接続し、回答を生成させる 。そんなデモを実感いただけたと思います。 今回は小規模のデータでのデモとなりましたが、実務で膨大なデータ量を扱うケースで、Agentspaceを活用するメリットは計り知れません。 まだまだ掘り下げられていない機能もありますので、今後さらに発信していければと思います。 （ちなみに、サンプルデータに”5歳”の天才エンジニア少女（US）が紛れ込んでいたの気づきましたか、、、？） [共同執筆者紹介] 八巻綾太 クラウド(主に生成AI)の専門部隊に所属し、 ボイスボット導入やVOC分析など、生成AIを絡めた業務効率化の案件を担当しています。 Google Cloudを触り始めて２年目です。 ブログを通じて技術をインプットしたり、案件や自己研鑽で培ったノウハウを積極的にアウトプットしていきたいと思います。 島村裕哉 SCSK株式会社のクラウド専門部隊に所属 Google Cloudの ・AI MLサービス選定/導入コンサルティング/導入サポート/AI 基盤・運用構築 まで多く案件を担当 Google Cloud Partner Top Engineer 2024・2025 受賞 カテゴリ：Cloud AI/ML Google Cloud Next Tokyo 出展 Google Cloud Day ’23 Tour 登壇 「AI は選んで組み込んで実装！最新 AI を道具として有効利用するためには！？」 ■好きな Google Cloud サービス：Vertex AI / Dialogflow CX / Visual Inspection AI / Cloud Run
LifeKeeperの販売元となるサイオステクノロジー株式会社が2024年10月31日より、LifeKeeper技術者認定制度の提供を開始しました。 今回は新たに提供が始まった LifeKeeper認定資格について概要と受験した流れと結果について紹介していきます。 技術者認定試験について LifeKeeper技術認定制度とは、LifeKeeperに携わるエンジニアのスキルをサイオステクノロジーが正式に認定する制度となり、LifeKeeperに関する技術力の証明と向上を支援していただける制度となっております。 内容としては、eラーニングによる学習とオンラインでの認定試験を通じて資格を取得できるセットで提供されています。 LifeKeeperの基本的な利用方法や用語を学習でき、製品理解を深めることができるプログラムとなっております。 種類 現在、提供されている技術者認定資格としては、以下２つの内容となります。 LifeKeeper for Linux 技術者認定資格（BASIC） LifeKeeper for Windows 技術者認定資格（BASIC） LinuxとWindowsの２種類のBASIC(入門編)の内容となっております。 認定資格取得の流れ 認定資格を取得いただくまでの大まかな流れは以下の通りとなります。 受講申し込み 技術コース受講 認定試験受験 認定証発行 1. 受講申し込み 以下URLよりアカウント作成のため、メールアドレスの新規登録を行います。 新規登録ページ lifekeeper.share-wis.com 登録を行いアカウント作成が完了しましたら、認定資格のサイトにログインできます。 ログイン後、表示されているコースを受講することができます。 まずはトレーニングを受講いただき、その後試験を受験するといった流れとなります。 コースの最後のセクションが試験になっていますが、トレーニングは任意となるため、試験だけ受験しても問題ありません。 2. 技術コース受講 動画と各セクションの最後にまとめとなる資料(PDF)があります。 Linuxコースは以下セクションに分かれており、各セクションの動画をみて講座を受けていく流れとなります。 動画の総合計は3時間程度となります。 No. セクション名 項目数 合計時間 1 基礎編 第1章 LifeKeeper for Linux概要 10 33分20秒 2 基礎編 第2章 LifeKeeperforLinuxのインストール 10 26分41秒 3 基礎編 第3章 アプリケーションの冗長化 9 26分21秒 4 基礎編 第4章 共有領域の保護 5 10分17秒 5 応用編 第1章 DataKeeperの利用 9 23分28秒 6 応用編 第2章 汎用アプリケーションの保護 9 19分52秒 7 応用編 第3章 LifeKeeperアーキテクチャ 5 23分45秒 8 応用編 第4章 メンテナンスとトラブルシューティング 5 15分48秒 Windowsは以下の内容となります。Windowsコースでの動画総合計時間は2時間30分程度となります。 No. セクション名 項目数 合計時間 1 第1章 LifeKeeper/DataKeeper 概要 7 36分29秒 2 第2章 LifeKeeper および DataKeeper のインストールと基本設定 9 46分16秒 3 第3章 リソース作成の基本 10 38分12秒 4 第4章 汎用アプリケーションの保護とコマンドの利用 9 38分21秒 3. 認定試験受験（BASIC） 各セクションの内容から抜粋されて出題されます。 制限時間は60分、設問数は40問となります。 正答率80%以上で合格となり、認定証が発行されます。 また、受験可能回数は制限があり、10回までとなりますのでご注意ください。 試験結果についてはメールで送信されます。メールにあるリンクから確認する事が可能です。 ※サイトから試験結果の確認はできない仕様となります。 4.認定証発行 試験に合格すると、サイトの「認定証一覧」のページに認定証が表示されます。 以上が認定資格取得までの大まかな流れとなります。 詳細なシステムの利用方法や手順については、 LifeKeeperユーザーポータルの以下の資料に掲載されておりますので、そちらからご覧ください。 LifeKeeper 技術者認定試験受講手順 費用について 現在の受講・受験費用は無償となっております。 ただ、将来的には有償に変更する可能性もあるとのことなので、今のうちに動画の受講と受験をしておいた方がよさそうですね。 受験してみて、、 受験をしてみた所感ですが、動画に関してはLifeKeeperに関する動作/機能説明が順序よく構成されており、 また図やグラフが頻繁に用いられており、当時LifeKeeperに触って3か月そこらの初心者の私でも分かりやすく、丁寧に説明がされている内容だなと感じました。 また、私の場合は先に一度試験を受けて(一発合格なりませんでした、、)要点を掴んでから動画を1.5倍速でみて理解を深め、 再度試験を受けて合格したという流れで本資格を取得しました。 試験については、動画の内容がそのまま出てきたりと動画を視聴すれば難なく解ける難易度でしたので、一度落ちても再度解答を見直せば合格できるかと感じました。 最後に 今回は、サイオステクノロジーが新たに提供を開始したLifeKeeper認定資格制度についてご紹介しました。 現在は入門者向けのみのコースを提供しておりますが、 今後は、中級者/上級者向けのコースもでてくるとの噂もあるので引き続き注目していきたいです。 イベント告知 このたび、LifeKeeper製品に関するウェビナーを4/16に開催いたします。 HULFTの最新バージョンであるHULFT10のサポートをLifeKeeperが開始いたしました。 これに際し、「HULFT×LifeKeeper」ウェビナーを開催いたします。 お申し込みは下記サイトよりお待ちしております。 HULFT7 Limitedサポート終了間近！HULFT10新機能および高可用性ソリューションのご紹介
こんにちは。SCSKの島村です。 Google Cloud にて利用できる生成AIサービス『Google Agentspace』についてご存知でしょうか？？ Agentspaceを利用することで、 組織全体のコンテンツを連携させ、根拠に基づいたパーソナライズされた回答を生成する。 ワークフローアクションと連携してタスクを実行することで、従業員が必要な情報を適切なタイミングで入手する。 ことが可能となります。 Google Cloud 公式サイト： Google Agentspace | Google Cloud Google Agentspace の利用に際しては 『 早期アクセス（Early Access）の申請が必要』 となります。 （執筆時 2025.4.9時点） 詳細については、以下の応募フォームをご確認ください。 Google Agentspace early access また、本ブログに添付しているコンソール画面についても執筆時時点のものとなります。 更新されている内容については、公式のドキュメントをご確認ください。 本記事では、 『 Google Agentspace 』について色々と調査し、実際に触ってみましたので、その魅力について少しだけご紹介させていただければと思います。 また、「Agentspaceについてもっと知りたい！！！」という方はあわせて以下もご覧ください。 【Google Cloud】Agentspaceについてご存じですか？①「概要編」 Google Agentspace について調査し、実際に触ってみましたので、その魅力についてご紹介させていただければと思います。 blog.usize-tech.com 2025.04.10 【Google Cloud】Agentspaceについてご存じですか？②「検索（Cloud Storage）編」 本記事では、Agentspaceのアシスタント機能（検索機能）を紹介します。 blog.usize-tech.com 2025.04.10 この記事に書いてあること 本記事を通して、最終的に以下を実現できるようになると思います。 Dialogflow（DFCX） エージェントをアシスタント機能としてAgentspaceから呼び出してで利用できるようにする。 構成は以下です。 「やってみた」の概要 使用するGoogle Cloudのサービスについて 実際に作ってみる Agentspace アプリからAgentを呼び出してみる。 本記事でご紹介させていただく内容は、 「Google Cloudのトレーニングサービス「Google Cloud Skills Boost」」を参考にしております。 コース名： Accelerate Knowledge Exchange with Agentspace （執筆時 2025.4.9時点では英語のみのコースとなります。） Google Cloud Skills Boost についてもっと知りたい方は以下をご覧下さい。 【GCP】【AIML】 Google Cloud Skills Boostで「生成AI」を学んでみた。 – TechHarmony 「やってみた」の概要 今回作成するデモはコース内の1つのラボを参考にしております。 ラボ名：『Extend Agentspace assistant capabilities with Conversational Agents』 作りたいもの 従業員の出張リクエストを処理するためのAssistantを作成する。 DFCX（Dialogflow）エージェントが Cloud Run 関数とやり取りできるようにし、 バックエンドで出張リクエストを BigQuery に直接書き込む。 ▽ Agentの呼び出しイメージ Agentの呼び出し部分について最小限の機能のみ紹介させていただきます。 Instructionのチューニング並びに詳細な設計については本ブログでは割愛いたします。 作成手順 Google Cloud にて『AgentspaceからのAgent呼び出し機能』を作成する手順は以下となります。 リクエスト記録用BigQueryテーブルを作成し、Cloud Run 関数（アシスタント機能）をデプロイする。 DFCXエージェントが Cloud Run 関数を呼び出せるように、OpenAPI ツールを作成する。 BigQueryデータストアを作成して、Agentspace アプリをデプロイする。 Playbook を使用して、シンプルな生成AI会話エージェントを作成する。 DFCXエージェントを Agentspace アプリに統合する。 使用するGoogle Cloudのサービスについて Cloud Run 関数 コンテナ化されたアプリケーションをサーバーレスで実行できるフルマネージドプラットフォーム 本デモでは、出張リクエストを記録するためのBigQueryへの書き込みを行うための関数としてデプロイします。 Cloud Run フルマネージドのプラットフォームであらゆる言語（Go、Python、Java、Node.js、.NET、Ruby）で記述されたスケーラブルなコンテナ型アプリを構築してデプロイできます。 cloud.google.com 会話エージェント(Dialogflow) ウェブサイト、モバイルアプリ、メッセージングプラットフォーム、IoT デバイスなど、さまざまなチャネルでユーザーと自然な会話ができる会話型インターフェース（チャットボット、音声アシスタントなど）を構築するためのプラットフォームです。 本デモでは、記録用関数（Cloud Run）を呼び出すための設定（Tool）並びにユーザとのやり取りを実現する シンプルな生成会話エージェントを作成するために利用します。 会話エージェント（Dialogflow CX）のドキュメント | Google Cloud Dialogflow CX 仮想エージェント cloud.google.com BigQuery スケーラブルで費用対効果の高いサーバーレスのデータウェアハウス（DWH）です。 本デモでは、出張リクエストを記録するためのDBとして利用します。 BigQuery エンタープライズ向けデータ ウェアハウス BigQuery は、ビッグデータから価値あるビジネス分析情報を得るために設計された、サーバーレスで費用対効果に優れたマルチクラウド データ ウェアハウスです。ぜひ、無料トライアルをお試しください。 cloud.google.com 実際に作ってみる 作成手順に沿って実際に作成してみました。 リクエスト記録用BigQueryテーブルを作成し、Cloud Run 関数（アシスタント機能）をデプロイする。 DFCXエージェントが Cloud Run 関数を呼び出せるように、OpenAPI ツールを作成する。 BigQueryデータストアを作成して、Agentspace アプリをデプロイする。 Playbook を使用して、シンプルな生成AI会話エージェントを作成する。 DFCXエージェントを Agentspace アプリに統合する。 1.リクエスト記録用BigQueryテーブルを作成し、 Run 関数（アシスタント機能）をデプロイする。 BigQueyテーブルを以下のスキーマで作成する。 ＊リクエストから記録した内容に合わせてスキーマは適宜修正ください。 [ { "name" : "user" , "type" : "STRING" , "mode" : "REQUIRED" }, { "name" : "travel_purpose" , "type" : "STRING" , "mode" : "REQUIRED" }, { "name" : "departure_city" , "type" : "STRING" , "mode" : "NULLABLE" }, { "name" : "destination_city" , "type" : "STRING" , "mode" : "NULLABLE" }, { "name" : "departure_date" , "type" : "STRING" , "mode" : "NULLABLE" }, { "name" : "return_date" , "type" : "STRING" , "mode" : "NULLABLE" } ] Cloud Run関数はリクエストをBigQueryに記録するための関数としてデプロイします。 JSON として送信されたリクエストを受け取り、BigQueryの記録用テーブルに書き込むための処理（関数）を作成する。 ▽requirements.txt functions-framework==3.* google-cloud-bigquery ▽ main.py POST リクエストに提供された旅行リクエストの詳細を JSON として取得し、それらの値を、BigQuery テーブルの新しい行に書き込みむ。 import functions_framework from google.cloud import bigquery @functions_framework.http def record_travel_request(request): request_json = request.get_json(silent=True) request_args = request.args print("JSON:" + str(request_json)) print("args:" + str(request_args)) bq_client = bigquery.Client() table_id = "Project_ID.Bigquery_Dataset.Bigquery_Table" row_to_insert = [ {"user": request_json["user"], "travel_purpose": request_json["travel_purpose"], "departure_city": request_json.get("departure_city",""), "destination_city": request_json.get("destination_city",""), "departure_date": request_json.get("departure_date",""), "return_date": request_json.get("return_date",""), }, ] errors = bq_client.insert_rows_json(table_id, row_to_insert) # Make an API request. if errors == []: return {"message": "New row has been added."} else: return {"message": "Encountered errors while inserting rows: {}".format(errors)} 上記の関数をデプロイする。 2. DFCXエージェントが Cloud Run 関数を呼び出せるように、OpenAPI ツールを作成する。 Cloud Run 関数を呼び出すためのエージェントをDialogflow Conversational agents を使って 作成する。 ▽ [会話エージェントの使用を開始する] ペインで、[独自のエージェントを作成する] を選択します。 ▽ 左側のナビゲーション メニューから [ツール] を選択します。 ▽「Create Tool」から OpenAPI ツールを作成する。 ＊タイプは OpenAPIのままにする。 ▽ Schema参考 openapi: 3.0.0 info: title: Travel Requests API version: 1.0.0 servers: - url: 'YOUR_CLOUD_RUN_FUNCTION_URL' paths: /: post: summary: Record a new travel request operationId: recordTravelRequest requestBody: description: Travel request to add required: true content: application/json: schema: $ref: '#/components/schemas/TravelRequest' responses: '200': description: Success content: application/json: schema: type: object properties: message: type: string example: "Favorite flavor recorded successfully!" components: schemas: TravelRequest: type: object required: - user - travel_purpose properties: user: type: string travel_purpose: type: string departure_city: type: string destination_city: type: string departure_date: type: string return_date: type: string 上記の仕様の YOUR_CLOUD_RUN_FUNCTION_URL を、Cloud Run 関数の URL に置き換える。 ツールが Cloud Run 関数を呼び出せるようにするには 「Dialogflow Service Agent に対して Cloud Run Invoker（起動元）ロール 」を付与する必要があります。 https://cloud.google.com/dialogflow/cx/docs/concept/playbook/tool?hl=ja#openapi エージェントは、 OpenAPI スキーマを提供することで、OpenAPI ツールを使用して外部 API（Cloud Run関数） に接続可能となります。 記載方法は以下を参考ください。 https://cloud.google.com/dialogflow/cx/docs/concept/playbook/tool?hl=ja#openapi 3. BigQueryデータストアを作成して、Agentspace アプリをデプロイする。 BigQueryデータストアを作成する。 先程作成したBigQueryテーブルをデータストアとしてAgentspaceアプリに登録します。 左側のナビゲーション パネルから [データ ストア] を選択します。 [+ データ ストアを作成] をクリックします。 BigQuery を検索して BigQuery カードを見つけ、[選択] をクリックします。 データの種類については、デフォルトの選択である [構造化 – BigQuery テーブルと独自のスキーマ] をそのままにします。 BigQuery パスについては、[参照] を選択します。 データセット Bigquery Dataset を検索します。 テーブル Bigquery Table を選択します。 [選択] をクリックします。 [続行] をクリックします。 スキーマはそのままにして、[続行] をクリックできます。 ▽ 作成すると以下一覧からも確認可能です。 Agentspace アプリをデプロイする [AI アプリケーション] > [アプリ] > [+ アプリの作成] に移動します。 Agentspace カードを見つけて [作成] をクリックし、Agentspace アプリを作成します。 アプリ名には、「Agentspace アプリ名」と入力します。 会社名には、「Agentspace 会社名」と入力します。 場所はグローバルに設定したままにします。 [階層の選択] で、[検索 + アシスタント] を選択します。 [続行] をクリックします。 ID プロバイダの場合は、Google ID プロバイダ カードの [選択] をクリックします。 [データ] ペインで、上で作成した Travel Requests データ ストアを選択します。 [作成] をクリックします。 4. Playbook を使用して、シンプルな生成AI会話エージェントを作成する。 自然言語でリクエストを受け取り、ツールを使用して Cloud Run 関数を介して BigQuery テーブルに書き込むことができる会話エージェントを作成する。 会話エージェント コンソールのブラウザ タブで、左側のナビゲーション メニューを使用してプレイブックを選択します。 すでに作成されているデフォルトの生成プレイブックを選択します。 プレイブックの名前を「旅行データの確認」に変更します。 目標には、「ユーザーが旅行を予約できるように支援する」と入力します。 手順については、テキスト フィールドに次の内容を貼り付けます。 – Ask the user to provide for user name, travelpurpose, departure city, destination city, and a range of dates. Assume a year of 2025 for dates without a year: – Use ${TOOL:Record Travel Request} – Let the user know that they should receive a list of flights to choose from in their email within 24 hours. これらのプレイブックの手順は Agentspace で使用するために設計されています。後後で、このプレイブックを呼び出す前に関連情報を収集する機能を Agentspace エージェントに付与します。 プレイブック ペインの上部にある [保存] をクリックします。 5. DFCXエージェントを Agentspace アプリに統合する。 Agentspace アシスタントに、会話エージェントにメッセージを送信し、その応答を受信する権限を付与する。 AI アプリケーション > アプリに移動し、Agentspace アプリ名 アプリを選択します。 左側のナビゲーションから、[構成］を選択します。 アシスタント タブを選択します。 エージェント ヘッダーの下で、アイテムの追加を選択します。新しいエージェントを接続するためのカードが表示されます。 会話エージェントコンソールの上部にあるエージェント ドロップダウンから、[すべてのエージェントを表示] を選択します。 Corporate Travel Bot エージェントの行の最後にあるオプション アイコン (縦に並んだ 3 つのドット) を選択し、[名前をコピー] を選択します。 AI アプリケーション タブに戻り、新しいエージェント カードのエージェント フィールドにコピーした値を貼り付けます。 エージェントの表示名には、Corporate Travel Bot を使用します。 手順には次のように入力します。 Use for booking travel by providing a user, travel purpose, departure city, destination city, and a date range. [完了] をクリックします。 Agentspace アプリからAgentを呼び出してみる。 Agentspace アシスタントは会話（DFCX）エージェントと通信できるようになり、会話エージェントはツールを使用して出張リクエストを記録できるようになりました。実際に呼び出してみましょう。 Agentspace アプリの Agentspace アプリ名を選択します。左側のナビゲーション メニューから [統合] タブに移動します。 Web アプリ ヘッダーへのリンクの下で、[開く] をクリックします。 ＊ Agentspace アプリの作成には最大 10 分かかる場合があります。 メインバーの検索バーに出張リクエスト入力してみます。 正しく、回答できてそうです！！！ きちんと出張リクエストが書き込まれているかBigQueryテーブルを見てみましょう。 リクエストが記録されていることを確認するには、BigQuery Bigquery テーブルが表示されているブラウザ タブに戻ります。[プレビュー] タブで、[更新] アイコン BigQuery 更新アイコン をクリックして、最新のデータを表示します。 [診断情報]から、作成したAgentがきちんと呼び出されていることが分かります。 今回のデモはここまでです。Agentspaceから作成したAgentを呼び出すところを確認できたかなと思います。 最後に 今回は『 Google Cloud のAgentspace 』について簡単なデモをご紹介させていただきました。 AgentspaceアプリからAgentを実行し、実行結果を確認する。 そんなデモを実感頂けたと思います。 外部データに対してAPIを経由してアクセスすることもでき、純粋なRAG基盤を超えたAgentとしての使い方も広がるそんな機能ではないでしょうか。 色んな関数（tools）を定義し、Agentとしての機能を広げていくことができるデモのご紹介でした。 また、Agentspaceには本ブログにてご紹介できなかった機能がたくさんあります！！！続報をぜひお待ちいただけますと幸いです。 今後とも、AIMLに関する情報やGoogle CloudのAIMLサービスのアップデート情報を掲載していきたいと思います。 最後まで読んでいただき、ありがとうございました！！！ [共同執筆者紹介] 八巻綾太 クラウド(主に生成AI)の専門部隊に所属し、 ボイスボット導入やVOC分析など、生成AIを絡めた業務効率化の案件を担当しています。 Google Cloudを触り始めて２年目です。 ブログを通じて技術をインプットしたり、案件や自己研鑽で培ったノウハウを積極的にアウトプットしていきたいと思います。 山口翔平 Google Cloud歴2年目です。 日々捌ききれないほどのインプットを浴びているので、本ブログをアウトプットの場として活用しています。 ----- 好きな(よく触っている)サービス：BigQuery、Cloud Functions、Data Fusion 保有資格：応用情報技術者、Google Cloud 認定資格全冠（11冠） 受賞歴：Google Cloud Partner Top Engineer 2025（カテゴリ：General）受賞
こんにちは！SCSKの八巻です。 Google Cloud にて利用できる『Google Agentspace』についてご存知でしょうか？？ Agentspaceを利用することで、 組織全体のコンテンツを連携させ、根拠に基づいたパーソナライズされた回答を生成する。 ワークフローアクションと連携してタスクを実行することで、従業員が必要な情報を適切なタイミングで入手する。 ことが可能となります。 Google Cloud 公式サイト： Google Agentspace | Google Cloud Google Agentspace の利用に際しては 『 早期アクセス（Early Access）の申請が必要』 となります。 （執筆時 2025.4.9時点） 詳細については、以下の応募フォームをご確認ください。 Google Agentspace early access また、本ブログに添付しているコンソール画面についても執筆時時点のものとなります。 更新されている内容については、公式のドキュメントをご確認ください。 本記事では、 『 Google Agentspace 』について色々と調査し、実際に触ってみましたので、その魅力についてご紹介させていただければと思います。 また、 Agentspace について「もっと知りたい！！！」方は、 他サービスとのデータ連携やAgent関連について記載している以下「あわせて読みたい」もぜひご覧ください。 【Google Cloud】Agentspaceについてご存じですか？①「概要編」 Google Agentspace について調査し、実際に触ってみましたので、その魅力についてご紹介させていただければと思います。 blog.usize-tech.com 2025.04.10 【Google Cloud】Agentspaceについてご存じですか？③「Agent呼び出し編」 Dialogflow (DFCX) エージェントをアシスタント機能としてAgentspaceから呼び出してで利用できるようにする構成を紹介します。 blog.usize-tech.com 2025.04.10 この記事に書いてあること 本記事では、Agentspaceのアシスタント機能（検索機能）を紹介します。 アシスタント機能について アシスタントの作成方法 検索結果 アシスタント機能について アシスタント機能は一言でいえば、ドキュメント検索機能です。 ユーザーが知りたい内容に対して、接続したデータソースからドキュメントの横断検索(様々なデータから参照/検索)を行い、 要約された回答を返します。 PDF、画像、ビデオなど、アップロードしたファイルの分析や、自然言語の指示に基づいて画像を生成させるなど、 生成 AI チャットアプリと似たようなタスクも実行可能です。 連携できるデータストア Agentspaceは、多くのGoogleサービスやサードパーティと連携させることができます。 以下の画像は連携可能なサービスの一覧です。 アシスタントの作成方法 今回は、Google Cloud Storageとデータ連携させた、新規アシスタントを作成します。 ①Google Cloudコンソールから、『AI Applications』を開き、『アプリを作成する』をクリックします。 ②『エンタープライズ検索とアシスタント』の作成をクリックします。 ③『アプリ名』『会社名』『ロケーション』を入力し、『検索＋アシスタント』を選択します。 ④『データストアを作成』をクリックします。 ⑤Cloud Storage配下のSELECTをクリックします。 ⑥Cloud Storageに保存されているフォルダ/ファイルを選択します。 ⑦作成をクリックし、完了です。 検索結果 先ほど作成したアシスタントには、Cloud Storageに保存していたSCSK株式会社の概要資料(ホームページ抜粋)を連携しています。 早速、作成したアシスタントに質問してみましょう！ 『SCSKについて教えて』と質問すると、連携していたデータソースから検索し、代表者や売上高などを端的に回答してくれました！ 画面右の検索結果に、参考にしたデータが表示されています。 最後に 今回は『 Google Cloud のAgentspace 』のアシスタント機能をご紹介させていただきました。 本記事を見てAgentspaceに興味を持った方は、次の記事を是非ご覧ください！！ 【Google Cloud】Agentspaceについてご存じですか？③「Agent呼び出し編」 Dialogflow (DFCX) エージェントをアシスタント機能としてAgentspaceから呼び出してで利用できるようにする構成を紹介します。 blog.usize-tech.com 2025.04.10 今後とも、Agentspaceのアップデート情報を掲載していきたいと思います。 最後まで読んでいただき、ありがとうございました！！！ [共同執筆者紹介] 島村裕哉 SCSK株式会社のクラウド専門部隊に所属 Google Cloudの ・AI MLサービス選定/導入コンサルティング/導入サポート/AI 基盤・運用構築 まで多く案件を担当 Google Cloud Partner Top Engineer 2024・2025 受賞 カテゴリ：Cloud AI/ML Google Cloud Next Tokyo 出展 Google Cloud Day ’23 Tour 登壇 「AI は選んで組み込んで実装！最新 AI を道具として有効利用するためには！？」 ■好きな Google Cloud サービス：Vertex AI / Dialogflow CX / Visual Inspection AI / Cloud Run 山口翔平 Google Cloud歴2年目です。 日々捌ききれないほどのインプットを浴びているので、本ブログをアウトプットの場として活用しています。 ----- 好きな(よく触っている)サービス：BigQuery、Cloud Functions、Data Fusion 保有資格：応用情報技術者、Google Cloud 認定資格全冠（11冠） 受賞歴：Google Cloud Partner Top Engineer 2025（カテゴリ：General）受賞
こんにちは！SCSKの八巻です。 Google Cloud にて利用できる『Google Agentspace』についてご存知でしょうか？？ Agentspaceを利用することで、 組織全体のコンテンツを連携させ、根拠に基づいたパーソナライズされた回答を生成する。 ワークフローアクションと連携してタスクを実行することで、従業員が必要な情報を適切なタイミングで入手する。 ことが可能となります。 Google Cloud 公式サイト： Google Agentspace | Google Clou d Google Agentspace の利用に際しては 『 早期アクセス（Early Access）の申請が必要』 となります。 （執筆時 2025.4.9時点） 詳細については、以下の応募フォームをご確認ください。 Google Agentspace early access また、本ブログに添付しているコンソール画面についても執筆時時点のものとなります。 更新されている内容については、公式のドキュメントをご確認ください。 本記事では、 『 Google Agentspace 』について色々と調査し、実際に触ってみましたので、その魅力についてご紹介させていただければと思います。 また、 Agentspace について「もっと知りたい！！！」方は、 他サービスとのデータ連携やAgent関連について記載している以下「あわせて読みたい」もぜひご覧ください。 https://blog.usize-tech.com/agentspace-search-gcs/ blog.usize-tech.com 【Google Cloud】Agentspaceについてご存じですか？③「Agent呼び出し編」 Dialogflow (DFCX) エージェントをアシスタント機能としてAgentspaceから呼び出してで利用できるようにする構成を紹介します。 blog.usize-tech.com 2025.04.10 この記事に書いてあること 本記事を通して、Agentspaceはどんなことができるのかを理解することができると思います。 Agentspaceの主要機能を中心にお伝えします。 Google Agentspaceとは アシスタント機能 エージェント機能 Deep Research Notebook LM Google Agentspaceとは？？ 『 Google Agentspace 』とは、Google（Google Cloud）が提供する生成AIサービスの１つです。 組織内に分散しているドキュメント、メール、チャット履歴などのデータを横断検索し、情報の発見を手助けすることができます。 また AI エージェント機能により、カレンダーの登録などのタスクなどを人間の代わりに行うことも可能です。 Agentspaceの画面 Agentspaceの特徴 Agentspaceは以下のような特徴があります。 ・私たちが知りたいことを、保存された情報/データから検索して、回答を返してくれる ・複数の情報/データを横断的に検索し、適切に回答してくれる ・セマンティック検索（意味論検索）により、あいまいな言葉や自然言語でも検索ができる ・Googleサービス以外にも、Teams、Outlook、Box、Slackなど多くのサードパーティに対応 詳細については、以下、Google Cloud公式ドキュメントからご確認ください。 Google Agentspace 公式サイト アシスタント機能 アシスタント機能は一言でいえば、ドキュメント検索機能です。 ユーザーが知りたい内容に対して、接続したデータソースからドキュメントの横断検索(様々なデータから参照/検索)を行い、 要約された回答を返します。 PDF、画像、ビデオなど、アップロードしたファイルの分析や、自然言語の指示に基づいて画像を生成させるなど、 生成 AI チャットアプリと似たようなタスクも実行可能です。 Google Agentspace の横断検索は、以下のGoogleサービスやサードパーティのデータソースとも連携できます。 エージェント機能 アシスタント画面で入力されたユーザーからの自然言語による指示に基づき、Google Agentspace が代わりに作業を行う機能です。 例として Gmail や Outlook でのメール作成、Google カレンダーや Outlook カレンダーで予定を作成するなどが挙げられます。 また、Dialogflow（Google Cloud のフルマネージドサービス）と統合することで、ユーザーとの会話に基づき、タスクの実行が可能です。Google Agentspace がネイティブにサポートしていないアクションも実現できます。 エージェント機能については、以下の記事に詳細を記載しています。 【Google Cloud】Agentspaceについてご存じですか？③「Agent呼び出し編」 Dialogflow (DFCX) エージェントをアシスタント機能としてAgentspaceから呼び出してで利用できるようにする構成を紹介します。 blog.usize-tech.com 2025.04.10 Deep Reserch インターネット上の複数のデータソースに基づいて深い調査を行い、レポートにまとめてくれる機能です。 通常の生成 AI チャットアプリとは異なり、多段で詳細な調査と生成を行うため、回答の生成には数分間を要しますが、 提案されたリサーチ機能に基づき、詳細なレポートが返ってきます。 NotebookLM 生成 AI ウェブサービスであり、アップロードしたファイルに基づいて、生成 AI が分析/要約、新たな文章の生成を行うことができます。 生成した回答をメモとして残したり、アクセス権限を設定して、組織内の特定のユーザーまたはグループと共有が可能です。 最後に 今回は『 Google Cloud のAgentspace 』について概要をご紹介させていただきました。 『Agentspace ってこんなことができるんだ！』という概念的な理解はしていただけたかと思います。 今回紹介できていませんが、データストアと連携した検索機能や、他サービスとの接続、Agent活用など、 Agentspaceには多くの機能が備わっています。 Agentspaceは、業務効率化を行うための可能性を秘めたサービスだと思います！ 本記事を見てAgentspaceに興味を持った方は、次の記事を是非ご覧ください！！ https://blog.usize-tech.com/agentspace-search-gcs/ blog.usize-tech.com 今後とも、Agentspaceのアップデート情報を掲載していきたいと思います。 最後まで読んでいただき、ありがとうございました！！！ [共同執筆者紹介] 島村裕哉 SCSK株式会社のクラウド専門部隊に所属 Google Cloudの ・AI MLサービス選定/導入コンサルティング/導入サポート/AI 基盤・運用構築 まで多く案件を担当 Google Cloud Partner Top Engineer 2024・2025 受賞 カテゴリ：Cloud AI/ML Google Cloud Next Tokyo 出展 Google Cloud Day ’23 Tour 登壇 「AI は選んで組み込んで実装！最新 AI を道具として有効利用するためには！？」 ■好きな Google Cloud サービス：Vertex AI / Dialogflow CX / Visual Inspection AI / Cloud Run 山口翔平 Google Cloud歴2年目です。 日々捌ききれないほどのインプットを浴びているので、本ブログをアウトプットの場として活用しています。 ----- 好きな(よく触っている)サービス：BigQuery、Cloud Functions、Data Fusion 保有資格：応用情報技術者、Google Cloud 認定資格全冠（11冠） 受賞歴：Google Cloud Partner Top Engineer 2025（カテゴリ：General）受賞
この記事では、Catoクラウドにおけるユーザー識別について記載します。 特に拠点のSocket配下のユーザーについて、ユーザー識別が可能かどうか？といったお問い合わせに対する内容となっておりますので、ご参考にしていただければ幸いです。 ユーザー識別とは？ 接続環境による違い Cato Clientを使用して モバイル接続 した場合、Cato Management Application（以下CMA）ではZTNAユーザー名（旧SDPユーザー名）で管理されます。なのでユーザー単位もしくは複数ユーザーをグルーピングしてFirewallの送信元オブジェクトに設定したり、Eventsでログ確認を行う場合は、ユーザー名で通信ログが確認できます。 一方、Socketによる サイト接続 の場合、Socket配下のユーザーはZTNAユーザーとして登録はされないので、CMA上では そのデバイスのIPアドレスでしか識別されません 。仮にCato ClientをインストールしたデバイスをSocket配下のLANに接続してもオフィス・モードになるので、同じ事になります。 例えば、オフィスのPCが固定IPなら、IPアドレスから「誰」かが判別できるかもしれませんが、DHCPを使用している場合は「この危険なサイトにアクセスしているのは〇〇拠点からだとは分かるけれど誰なのか？」の特定ができないので、かなり致命的な状態と言えます。 このような場合は、 Identity Agent機能 を活用し、Socket配下のユーザーも名前での識別が可能となります。 <Identity Agent機能のイメージ図> Identity Agentのクライアント条件 Identity Agentの条件や仕様は、Catoのナレッジに記載がありますのここでは簡単に記載します。 サポートされるクライアントOSは、Windows、macOS、Linux サポートしているIdp環境は、オンプレAD、EntraID、Oktaなどのその他Idp Cato Clientのインストールは必要 WindowsにはZTNAライセンスの付与は不要だが、macOSとLinuxはZTNAライセンスの付与が必要（※1 参照） Cato Clientでの1回の初回認証が必要 ログイン後は30秒毎にチェックされ、IPアドレスが変わるとすぐに検出される Just a moment... support.catonetworks.com ※CatoクライアントのバージョンやIdpの条件は、Catoのナレッジを参考にして下さい。 なお、Identity Agentの仕組みは、定期的なユーザ認証とそのIPアドレスをPoP側で紐づけて保持することで実現されているものと推測していますので、プロキシ経由でCatoに接続する環境などでは識別ができないと思われます。 Identity Agentの設定と確認ポイント Identity Agentによるユーザー識別を利用する前提として、CMAの[Access] > [Directory Services] にて、オンプレADもしくはIdpと連携させユーザーをプロビジョニングします。プロビジョニング手順はここでは省略します。 また公式サイトによると、CMAに手動でユーザーを作成した場合でもユーザー識別はできるようです。 その後、Identity Agentを有効にする手順です。 [Access] > [User Awareness]を選択します。 Identity Agentを選択します。 Enable Identity Agentのトグルスイッチをスライドして有効にします。 [Save]をクリックします。 Identity Agentが動作しているかを確認するには、Cato Clientの「Stats」画面で「Identity Agent Status」をご確認ください。ここがONになっていればIdentity Agentが正常に動作しています。（下図のサンプル画像はOFFになってます） また、Identity Agentがうまく動作しない場合は、 Catoの提供するDNSサーバ「10.254.254.1」となっていない 可能性があります。 Cato以外のDNSを参照している場合はIdentity Agentは動作しませんので、CatoのDNSを参照するよう設定を見直す必要があります。 ZTNAライセンスの付与（※1） Cato Clientは、契約中のZTNAユーザーライセンス数に関係なくインストールが可能です。そのため、Windows PCでは、ZTNAライセンスを付与しなくてもCato Clientがインストールされているだけでユーザー識別が可能です。ただし、macOSやLinuxを識別するには、ライセンスが付与されている必要があります。 ユーザーライセンスの付与は、CMAにて以下の2つが選択できます。 全てのZTNAユーザーに付与する「Assign SDP license to all users」 特定ユーザーに付与する「Assign SDP license to selected users or groups」 ライセンス付与は、CMAの[Access] > [License Assignment]で行います。 特定ユーザーにライセンスを付与するには、「Assign SDP license to selected users or groups」を選択して、 [User]若しくは[User Group]を選び、特定のユーザーやユーザーグループを登録して[Save]をクリックします。 例えば、ライセンスを付与するユーザーには、別途ユーザーグループを作成し、グループへの追加や削除によってユーザー管理を行う方法も有効かもしれません。 [付録] Device Postreにおけるユーザー識別 Identity Agentに関係する話で、時折問い合わせをいただくのが「Socket配下の識別されたユーザーもDevice Postureによるデバイス制御が可能か」というものです。 2024年4月のアップデートで、この制御が可能と発表がありましたが紛らわしいところがあるので整理しておく必要があります。 Socket配下でのDevice Posture機能は、あくまでもモバイルユーザーとしての機能となっており、モバイルユーザーとして、Device PostureでBlockをされたとしても、その後Socket配下の環境に移動するとオフィス・モードになるので、デバイス制御は効かずCatoクラウド接続が可能となります。 一方、Internet FirewallやWAN Firewallのルール設定の項目「Device」の中に「Device Posture Plofile」があります。これを使用すればデバイス制御条件に合致したユーザーを、宛先のシステムやアプリケーションへのアクセスを許可したりブロックするといった設定が可能となります。 つまり、 Socket配下のデバイスをCatoに接続させる/させないの制御はできないが、デバイス制御の条件を満たしたユーザーは、Internet FirewallやWAN Firewallで特定宛先へのアクセス制御はできる 、という事です。 これも一応Identity Agentによりユーザー識別ができる事によるメリットではありますが、その他の設定方法でも対応可能な気はします。 最後に 今回は、Identity Agentによるユーザー識別を整理する目的で本記事を作成しましたが、細かい仕様や条件は、Catoのナレッジ（中段にリンクを貼り付けてます）に記載されていますので、ご一読される事をお勧めします。
社会人2年目になりました。 上司のサポートをいただきながら案件に取り組んでおり、その過程で得られた知見を記事にまとめて共有しようと思います。 はじめに 案件にて、Azure VM に SSMS (SQL Server Management Studio) を追加インストールするようにと依頼がありました。 Download SQL Server Management Studio (SSMS) | Microsoft Learn 既に 2 台の VM にはインストール済みだったのですが、今回の依頼で担当している全てのVMに入れる必要が出てきました。 途中から案件に入った私にとっては、 この作業経験が初めてだったので苦労しました。今回の作業で遭遇した問題点と解決策をまとめて記事にしてみようと思います。 今回の作業で使う SSMS のインストーラーですが、以前インストールした時と同じバージョンのもの（ローカルに保存済み）を使うことになりました。 ローカル PC にある SSMS-Setup-JPN.exe を Azure VM へコピー＆ペーストを試したところ、まさかのエラーが発生。 File transfer is either not supported or not enabled. Please contact support. えーなんでだろ、何かの設定してないのかな？と迷っていると公式リファレンスでこんな記述見つけました。 現在、テキストのコピー/貼り付けのみがサポートされています。 Windows 仮想マシンとの間のコピーと貼り付け: Azure – Azure Bastion | Microsoft Learn なんと、ファイル転送はサポートされていないことが判明しました。 今回は気を取り直して、別の方法を試すことにしました。 Azure Storage 経由で SSMS インストーラーを VM に転送しインストール作業を完了できましたので、その手順について解説します。 前提条件 次の項目を事前に作成する。 Azure Bastionがデプロイされた仮想ネットワーク 仮想ネットワークにデプロイされたAzure VM 作成できたらBastion経由で接続できることを確認。 ちなみにローカルからコピペしようとすると右下に表示されます。 ローカルからのファイル転送 VMにAzure CLIをインストール “https://azcliprod.blob.core.windows.net/msi/azure-cli-2.58.0-x64.msi” VMのブラウザにこのurlをコピペしてインストールします。（テキストはコピペ可能） その後PowerShellでazコマンド打つと確認できます。 ※注意 Windows 用 Azure CLI をインストールする | Microsoft Learn 公式ドキュメント参考にwingetを実行した場合、wingetがインストールされてなければ成功しません。 なのでブラウザを使いました 。 適当なストレージアカウントを作成しファイルをアップロード まずストレージアカウントを作成します。 サイドバーにあるデータストレージ/コンテナーからコンテナー作成し、ファイルをアップロードでき完了。 VMにストレージアカウントに対する権限を付与（ストレージBLOB共同作成者） ストレージアカウントに対する権限付与は、以下記事を参考にさせていただきました。 AzureシステムマネージドIDを使ったVM→Blobへのアップロード #Azure – Qiita Azure VM上でポータルログインできないように認証の設定がされているので、マネージドID利用する方法を選びました。 VM上でコマンド実行 Powershell ではなくコマンドプロンプトを使用します。 <認証> az login --identity <ダウンロード実行> az storage blob | Microsoft Learn az storage blob download --container-name コンテナ名 --name ファイル名 --file ダウンロード先パス\ファイル名 --account-name ストレージアカウント名 --auth-mode login こちらを利用して、 az storage blob download --container-name ssmsexefile --name SSMS-Setup-JPN.exe --file C:\Users\tomioka-test01\Downloads\SSMS-Setup-JPN.exe --account-name tomiokasqlserver20250325 --auth-mode login –container-name VMのダウンロードフォルダに転送完了しました。 これでやっとSSMSをインストールできます。あとはexeファイル実行するだけです。 感想 そもそもなぜファイルのコピペはサポートされていないのでしょうか？ セキュリティの問題なのか、ビジネス的に採算とれないからなのか…。 様々な推察はできますが、なかなか確定したことは分からないです。 社会人2年目は、こういった疑問を自分で解決することを目標に頑張ろうと思います。
こんにちは、SCSK の松山です。 Amazon Aurora DSQL (以下 DSQL と略す) について、従来の PostgreSQL との差異に焦点をあてて調べてみたシリーズ、前回(第二弾)は、従来の PostgreSQL と比較した場合の機能制限についてお伝えしました。 Amazon Aurora DSQL について調べてみた (機能制限編) Amazon Aurora DSQL について従来の PostgreSQL との差異に焦点をあてて調べてみたシリーズ第二弾。第二弾は機能制限編です。 blog.usize-tech.com 2025.03.19 制限されている機能の内容から、従来の PostgreSQL と比較して、単純 かつ 短時間で完了するクエリが大量に同時実行されるようなシステム( OLTP系の処理 )に向いた機構になっていることがわかりました。 第三弾として、本件では DSQL が採用している 楽観的同時実行制御 に焦点をあててまとめていきます。 ※本件は 2025/2 時点の検証結果をもとに記載しています。 今後動作が変更される可能性がある旨、ご注意ください。 同時実行制御とは 実際に実機検証を行う前に、まずは同時実行制御について簡単に説明します。 同時実行制御とは、データベースが複数のトランザクション処理を同時実行する際、データの整合性を保つための制御方法です。 データベースは同時に複数のトランザクション要求を受け付けることができます。 しかし同じデータに対して複数のトランザクションから異なる更新を同時に行ってしまうと、データに矛盾が発生してしまいます。 【在庫が100個存在する商品を AさんとBさんが同時に取り出せてしまった場合】 上記のような矛盾が発生しない様に管理するのが同時実行制御です。 この際、DSQL では 主なデータベース製品 ORACLE、MySQL、PostgreSQL などとは異なる制御方法として楽観的同時接続制御が採用されています。 同時実行制御の種類 悲観的同時実行制御 (PCC) 主なデータベース製品 ORACLE、MySQL、PostgreSQL などでは悲観的同時実行制御 ( PCC : Pessimistic Concurrency Control) を採用しています。「同時実行制御」とだけ記載されている場合には、主に悲観的同時実行制御を指していることが多いでしょう。 「同時にトランザクションが実行されている可能性がある」という悲観的な考え方で制御を行うため、このような名称になっています。 悲観的同時実行制御の場合は、内部的に処理に順番を割り振ります。 順番が先に割り当てられた処理が対象をロックし、後に割り当てられた処理はロックが解放されるまで待機します。ロック獲得側が処理を確定する COMMIT を行ったタイミングで更新の反映とロックの解除が行われるため、後に割り当てられた処理との整合性が保たれます。 楽観的同時実行制御 (OCC) DSQL では楽観的同時実行制御 (OCC：Optimistic concurrency control) を採用しています。 「同時に実行しているトランザクションは存在しない」という楽観的な考え方で制御を行うため、このような名称になっています。 楽観的同時実行制御の場合は、処理実行中に矛盾が発生する更新が行われても待ちは発生しません。 かわりに処理を確定する COMMIT を行ったタイミングで、矛盾する操作が行われたかがチェックされます。 先に COMMIT した処理の更新内容に対して、後から行った処理の更新内容が矛盾している場合、エラーを返して処理の再実行を要求することで処理の整合性が保たれます。 実機検証 検証内容 DSQL_1 Versinia 環境と DSQL_2 Ohio 環境から、同時に同一表の競合する行へ更新を行う DSQL_1 Versinia 環境を先に COMMIT し、DSQL_2 Ohio を COMMIT した場合の動作と表の更新状況を確認する まとめ 楽観的同時実行制御では処理を確定する COMMIT を行ったタイミングで整合性のチェックが行われることがわかりました。 悲観的同時実行制御では何らかの理由でロックが長期間解放されない場合、後続の処理が待たされますが、楽観的同時実行制御では先に COMMIT した処理が優先されるため、待ちが発生しません。 ただし COMMIT 時に先に実行していた処理と矛盾が発生した場合には、エラーを受け処理の再実行が必要です。そのため、悲観的同時実行制御で動作していたシステムを DSQL へ移行する場合には、リトライ処理の仕組みを作りこむことが重要と言えるでしょう。 DSQL の利用ケースを検討する際に、今回の内容がお役に立てば幸いです。 Amazon Aurora DSQL について調べてみた (構築編) Amazon Aurora DSQL について従来の PostgreSQL との差異に焦点をあてて調べてみたシリーズ第一弾。第一弾は DSQL の簡単な概要と構築編です。 blog.usize-tech.com 2025.03.17 Amazon Aurora DSQL について調べてみた (機能制限編) Amazon Aurora DSQL について従来の PostgreSQL との差異に焦点をあてて調べてみたシリーズ第二弾。第二弾は機能制限編です。 blog.usize-tech.com 2025.03.19
こんにちは、SCSK 野口です。 『 第６回 HAクラスター構成の敵「スプリットブレイン対策」はこれだ！ 』 では、 LifeKeeper の Quorum/Witnessについて少し触れましたが、Quorum/Witness は クラスターシステムにおいて重要な役割（スプリットブレイン対策）です。 今回は、もう少し深堀をし、Quorum/Witnessの種類とパラメータについてお伝えします。 Quorum/Witnessとは おさらい 『 第6回 』 でも Quorum/Witness の機能について説明しましたが、 改めて「Quorum Check」( Quorum機能) と 「Witness Check」( Witness機能) を下記に記します。 Quorum Check⋅⋅⋅⋅⋅⋅⋅⋅⋅⋅クラスター全体で合意(多数決)するための機能 「リソースを起動する権利はあるのか」クラスター全体で合意するための仕組みです。 Witness Check⋅⋅⋅⋅⋅⋅⋅⋅⋅⋅第三者ノードに問い合わせて再確認する機能 （セカンドオピニオン） 「相手ノードは本当にダウンしたのか」第三者ノード（デバイス）に問い合わせる仕組みです。 Quorum/Witnessは、「Quorum Check」と「Witness Check」が合わさった機能なんだね！ Quorumの種類（Majorityモード、Storageモード） おさらいで、Quorum/Witnessの機能についてざっくりと説明しましたが、 次は、実際にどのような構成があるか具体的な例を2つご紹介いたします。 Storage構成図では、Node1がQWKオブジェクト1にデータを書き込み、そのデータをNode2が監視しています。 同時に、Node2はQWKオブジェクト2にデータを書き込み、そのデータをNode1が監視しています。 つまり、両方のノードが互いにデータを書き込み、監視し合っている状態です。 Majority構成は多数決だから、ノードを奇数台用意しなきゃなんだね！ Storage構成はお互いに書き込みと監視してるんだ⁉ Quorumの種類によって設定可能なWitnessモード majorityモードで使用可能なWitnessモード storageモードで使用可能なWitnessモード ・remote_verify ・storage（他は選択できません。） ・none または off 選択したQuorumモードで、設定できるWitnessモードは決まっています。 QuorumとWitnessの構成が正しくないと、 リソース作成 & 拡張時に サーバーが誤って停止する可能性 があるわよ！ パラメータの設定値 続いては、実際にどのようなパラメータの設定値があるのかをご紹介いたします。 今回、ご紹介するパラメータの設定値は 「Quorum/Witness共通のパラメーター」 と 「選択したモードによって有効なパラメーター」 です。 Quorum/Witness共通のパラメータ ※ 青文字はデフォルト値となります。 QUORUM_MODE ・majority……… ハートビート通信で疎通確認をし、Quorum チェックを行う ・tcp_remote …… ハートビート通信で独立したホストに対して、 指定されたポート上の TCP/IP サービスに接続確認をし、Quorum チェックを行う ・storage ……… 共有ストレージを Witness デバイスとして用いて、Quorum チェックを行う ・none/off ……… Quorumチェックを無効にする。 WITNESS_MODE ・remote_verify …… クラスター内で他のすべてのノードに対して 障害が疑われるノードのステータスに関する意見を求める ・storage ……… 共有ストレージに書き込まれた情報を定期的に確認する ・none/off ……… Witnessチェックを無効にする QUORUM_LOSS_ACTION ・fastkill …… Quorumの喪失が検出されると、システムを直ちに再起動する ・fastboot …… Quorumの喪失が検出されると、システムを直ちに停止する (手動で起動する必要があります) ・osu …… ……… Quorumの喪失が検出されると、システム上のリソースをサービス休止状態にする ALLOW_EXTEND_WITH_QUORUM_ERROR ・true …… Quorumシステムの障害/エラーが発生した場合拡張する ・false …… Quorumシステムの障害/エラーが発生した場合拡張しない 選択したモードによって有効なパラメーター ※ 青文字はデフォルト値となります。 QUORUM_HOSTS ・”host:port” 形式 ……複数指定の場合はカンマ区切り （設定例）QUORUM_HOSTS=myhost:80,router1:443,router2:22 QUORUM_TIMEOUT_SECS ・整数値 を指定 ※ 青文字はデフォルト値となります。 QWK_STORAGE_TYPE ・block ……… 共有ストレージに物理ストレージやRDM（物理互換）、iSCSI（VM 内イニシエーター）を使用する場合 ・file ………… 共有ストレージにNFS (または Amazon EFS) を使用する場合 ・aws_s3 …… 共有ストレージに AmazonのS3 、または Amazon S3互換のオブジェクトストレージを使用する場合 QWK_STORAGE_HBEATTIME ・5以上10以下 …… QWKオブジェクトへ読み書きする間隔を秒単位で設定 QWK_STORAGE_NUMHBEATS ・3以上 …… QWKオブジェクトの読み込みにおいて、設定した回数以上更新が停止していると障害と判断 QWK_STORAGE_OBJECT_<ホスト名> ・ホスト名に”-”または”.”を含む場合、アンダースコア“_”に置き換える HTTP_PROXY, HTTPS_PROXY , NO_PROXY ・ AWS CLIの通信をプロキシ経由で行う場合に設定 （設定した値がそのまま AWS CLI へ渡される） これらのパラメータは etc/default/LifeKeeper 設定ファイルで編集や追記できるわよ！ まとめ 今回は、Quorum/Witness の種類 と パラメータ についてご紹介しましたがいかがでしたか。 ・ Quorum/Witnessは「 Quorum Check 」と「 Witness Check 」という 2つの機能がある ・Quorumの種類には「 Majorityモード 」と「 Storageモード 」という種類がある ・パラメータは 「共通のパラメーター 」と「 選択したモードによって有効なパラメーター 」がある この記事で、上記3点をご認識いただけたら幸いです。 詳細情報をご希望の方は、以下のバナーからSCSK Lifekeeper公式サイトまで
こんにちは。SCSKの山口です。 Google Cloud認定資格の全冠を目指す際、避けて通れないのが「英語版のみの試験」です。今回は、英語が（まだそこまで）堪能でない私が編み出した、「英語版試験突破のコツ」を書き留めたいと思います。 2025.03現在 英語版のみの認定資格 これを書いている2025.03時点では、下記がまだ英語のみとなっているようです。 ・Associate Data Practitioner ・Associate Google Workspace Administrator ・Professional Cloud Database Engineer ・Professional Machine Learning Engineer 早く日本語化してほしいところですが、いつまで経っても日本語化されず、いつまで経っても受験に踏み切れない。みたいなことになりかねないので、ある程度覚悟を決めて受験することも必要です。 今回はそんなときに使えるTipsをお伝えできればと思います。 英語の試験で当たった壁 私はよくUdemyなどで模擬試験を購入し。英語の問題に慣れる練習をしていたのですが、 問題呼んでも目が滑って内容が全然頭に入ってこない、、、 これに陥りました。 問題文をはじめから読み始めて、わからない単語に何度も当たり、そうするうちに「あれ、これ何を聞かれてるんだっけ？？」となってもう一度頭から読み直す。を繰り返して、日本語の試験の数倍の体力を使っていました。 もちろん、50問解き終わるのに日本語試験とは比にならないくらいの時間を要し、試験本番でも見直す時間と体力がない。みたいなことになっていました。 このブログでは、英語の問題文を効率的に読み、正解の回答にアプローチする私流のコツを書きたいと思います。 解き方のコツ 今回は、問題の形式ごとに私が使っている解き方を書きます。 もちろん試験に登場する全パターンを網羅できているわけではないので、予めご了承ください。 （※また、もちろんある程度の英語を読めるスキルは当然必要です。） シナリオが描かれているパターン ほとんどの問題がこのパターンなんじゃないかと個人的に思っています。例題を書きます。 You are a data administrator for a company that stores and manages critical business data in cloud storage. You have been asked by management to ensure high availability with minimal downtime in the event of a region failure. Data redundancy needs to be provided in multiple geographic locations, while at the same time requiring low-latency access for users in certain regions. Which configuration best meets these requirements? Dual-Region Storage Multi-Region Storage Regional Storage with Object Versioning Standard Storage in a Single Region はい。自分で書きながらもう頭が痛くなってきました。 上の問題は、アソシエイトレベルでよく聞かれそうな問題を、あえて冗長な文を含ませて作っています。 まず最後の文を見る 正直、このブログで言いたいことの半分はこれです。 Which configuration best meets these requirements? まず、 「最後の一文」だけ を見ます。 上の例でいうと、 「 どの構成がもっとも要求に合っていますか？」ですね。これくらいならすぐ訳せそうです。 「何かの構成を選ぶんだな。」 ということがここでわかります。 これをつかんだ状態で他を読むと、この後読み進める段階で 情報を取捨選択 できます。 次に選択肢を見る Dual-Region Storage Multi-Region Storage Regional Storage with Object Versioning Standard Storage in a Single Region 次に選択肢を見ると、「Cloud Storageに関する問題っぽい。」と分かります。 最後の文と合わせると、 「最適なCloud Storageの構成」 を選ぶ問題だということがわかります。 怪しい単語を探す 最適なCloud Storageの構成を聞かれている問題だということがわかりました。選択肢を見ると「冗長化・高可用性」や、「データ保持」に関する用語が登場しているので、 その要件となりそうな単語を探しに行きます 。 ・to ensure high availability （ 高可用性 ） ・minimal downtime in the event of a region （ リージョン障害発生時 のダウンタイム最小に） ・Data redundancy needs to be provided in multiple geographic locations （ 複数の地理的ロケーション が必要） ・requiring low-latency access for users in certain regions （ 特定のリージョンのユーザ の低遅延を保証） この太字辺りが怪しいですね。 選択肢を削る 今回、大きく四つの要求が経営層から出されていますが、大前提となる要件として 「高可用性」 があります。なので、 3. Regional Storage with Object Versioning 4. Standard Storage in a Single Region シングルリージョン構成のこの二つの選択肢がまず最初に消えます。 残る二つの選択肢は高可用性が確保されているように見えますが、そのほかの要件として、 「特定リージョンのユーザの低遅延を確保」 する要件があります。 Cloud Storageのマルチリージョンでは ユーザがリージョンを選択することができません 。 なので、2番の選択肢も消え、 Dual-Region Storage これが正しい答えだとわかります。 最終的に、”Cloud Storageのマルチリージョンでは ユーザがリージョンを選択することができません 。”これを知識として持っておく必要がありますが、要件と選択肢を見るだけで選択肢を2/4に減らすことができます。 複数選択するパターン こちらも例文を書きます。 ETL (Extract, Transform, Load) and ELT (Extract, Load, Transform) are two methods for processing data in the Google Cloud environment. Which two statements accurately describe these processes? (Choose two) ETL is converted before the data is loaded. This minimizes storage requirements. ETL is preferred in Google Cloud environments where BigQuery is the primary processing tool. ETL is more compatible with unstructured data sources than ELT. ELT requires a powerful data warehouse or processing engine in the data warehouse that holds the data to handle transformations after the data is loaded. ELT is generally not suitable for scenarios involving large data sets. 前のパターンと違って、よく内容を見る必要がありそうですね。 何について聞かれているか整理する 今回の例題ではわかりやすいですが、 ETLとELTについて 聞かれています。 5つの選択肢から正しいものを二つ選ぶ問題です。 選択肢を整理する 選択肢が5つもあるので整理します。 ETLについての説明：1,2,3番 ELTについての説明：4,5番 こういう場合は、 ETL、ELTの説明からひとつずつ選ぶパターン が圧倒的に多いです。 闇雲にすべての選択肢をじっくり見るのではなく、ある程度のあたりをつけて読むことをオススメします。 選択肢を読む まず、ETLの説明から順に読んでいくことにします。 1. ETL is converted before the data is loaded. This minimizes storage requirements. いきなり当たりを読んだ気がします。（実はこれが正解です。） このように、ETLの選択肢から正解を一つ見つけたら、 他のETLの選択肢は飛ばして、ELTの問題を見ます 。 4. ELT requires a powerful data warehouse or processing engine in the data warehouse that holds the data to handle transformations after the data is loaded. これが正解です。 正解を選ぶための知識を持って入れば、5つすべての選択肢に目を通すことなく解くことができます。 今回の例でいうと、まず1の選択肢（ETLの説明）が正解とわかれば、あとは「 ELTの適切な説明どれだろう。 」の目線で選択肢を探しに行きます。なので、他のETLの説明の2,3の選択肢は後回し（もしくは読まない）です。 私は英語の試験だと試験時間がぎりぎりになることが多いので、1周目はこの解き方で選択肢を選び、時間が余ったときのみ選ばなかった選択肢を念のため確認しています。 また、一つは確実に分かったけどもう一つが選べない。ということも多くあると思います。そういうときは今回の例でいうと 「ETLの選択肢は絶対コレが正解だから、残り1つの正解はELTの選択肢にあるはず。」 という当たりをつけて選択肢を選んでいます。 タイムアップが近づき、どうしても考える時間が足りないときは、当てずっぽうでそれぞれの説明から一つずつ選択します。
こんにちは。SCSK 阿部です。 Cato クラウドを用いたモバイル接続を行う場合、ユーザの作成が必要となります。 ユーザは手動で作成することも可能ですが、既存のディレクトリサービスと連携させる形で管理することも可能です。 今回は、SCIMプロビジョニングによるユーザ作成・管理について、注意点も含めて記事といたします。 はじめに：SCIMプロビジョニングでできること SCIMは「System for Cross-domain Identity Management」の略で、Entra IDをはじめとするドメインサービスや システムの間でID（ユーザやグループ）情報のやり取りを行うための標準規格です。 Catoは、ディレクトリサービスからのSCIMによるユーザプロビジョニングに対応しています。 2025年4月現在、対応しているサービスは下記のとおりです。 Microsoft Entra ID Okta OneLogin OneWelcome SCIMプロビジョニングを用いることで、プロビジョニング元にあたるサービスにおける ユーザの追加、削除、変更といった操作をCato側に自動で反映する ことが可能です。運用の手間を省けるほか、ユーザの削除し忘れによるセキュリティリスクも低減することが可能です。 「他のIDとの連携」としてSSO（Single Sign On）もよく用いられますが、SCIMはこれとは別の概念です。 SCIM：ユーザやグループの連携が目的 SSO：認証の連携が目的 Catoにおいて、SCIMプロビジョニングでユーザを作成・管理するのみの設定とする場合、ログインには通常のユーザと同様に別途設定のパスワードを使用します。SSO認証を併用する場合、後述の通り追加の設定が必要です。 SCIMプロビジョニングを設定してみる 実際に、Entra IDを一例としてSCIMプロビジョニングを設定してみます。 今回は、以下のイメージ図の通り、Entra IDの特定のグループ「Test-group1」に属するユーザ 「テスト 太郎」のみをCatoへプロビジョニングします。 Entra管理センター上でアプリケーション「Cato Networks Provisioning」を作成 連携予定のEntra管理センターにて、 「エンタープライズ アプリケーション」から新しいアプリケーションを作成します。 「Cato Networks Provisioning」を選択し、「作成」をクリックします。「Cato」で検索すれば簡単に見つかります。 アプリケーションが無事に作成されました。自動で詳細画面が開きます。 この画面はすぐ後に参照するので、開いたままにしておきます。 CatoテナントとCato Networks Provisioningを紐づけ 作成したアプリケーションを、プロビジョニング先のCatoテナントと連携させます。 CMAにログインし、[Access > Access Configuration > IDENTITY > Directory Services]へ移動します。 [SCIM]タブにて、「New」を選択します。 Directory Nameとして任意の名前をつけて、「Generate Token」をクリックします。 出力されたトークンと「Base URL」をメモ帳等に控えてから、「Save」をクリックします。 SCIMの連携は、複数のIdPと同時に実施可能 です。 （二つ以上のEntra IDテナントとOktaアカウント等） ただし、 「LDAP連携」を実施しているCatoテナントでは、複数IdPとのSCIM連携を実施できません 。 複数IdPとのSCIM連携が必要な場合は、事前にLDAP連携を削除する必要があります。 なお、SCIMプロビジョニングの結果、LDAP連携のユーザと同名のユーザが存在した場合は、 SCIMが優先され、LDAP連携のユーザを上書きします。 参考リンク： Provisioning Users with SCIM and LDAP – Cato Learning Center Entraのアプリケーション画面に戻り、[3.ユーザー アカウントのプロビジョニング > 作業の開始]をクリックします。 表示される画面で、改めて「作業の開始」をクリックします。 プロビジョニングモードとして「自動」を選択し、管理者資格情報を入力します。 テナントのURL: CMA画面で控えた「Base URL」 シークレット トークン: CMA画面で控えた「Bearer Token」 「テスト接続」をクリックし、結果に問題が無いことを確認したら「保存」をクリックします。 プロビジョニング対象を指定 プロビジョニングの対象を指定します。 Cato Networks Provisioningの概要画面より、「ユーザーとグループの割り当て」をクリックします。 アプリケーションの割り当て一覧画面にて、「ユーザーまたはグループの追加」をクリックします。 プロビジョニングの対象とするユーザやグループを選択したうえで、「割り当て」をクリックします。 Entra ID P1以上を契約しているEntra IDテナントでは、割り当て対象としてグループの指定が可能です。 グループに直接所属しているユーザだけを対象とする（子グループの中身は参照しない） ので、 グループに必要なユーザが所属していることを確認してから設定しましょう。 参考リンク： アプリケーションへのユーザーとグループの割り当てを管理する – Microsoft Entra ID | Microsoft Learn プロビジョニングのマッピング設定を変更（オプション） Entra IDのユーザ情報をCatoに連携するうえで、Entra IDのプロパティのどの項目をCatoのどのプロパティ向けに連携するかを決定しているのがマッピング設定です。 デフォルトで設定が行われているため、基本的に変更する必要はありませんが、必要に応じ調整が可能です。 以下は、「Cato側のEメール（およびユーザID）の参照元を、Entra IDのEmailからUPNに変更する」 という変更を行う場合の例です。 Cato Networks Provisioning詳細画面左の[管理 – プロビジョニング]を選択します。 [マッピング > Provision Microsoft Entra ID Users]をクリックします。 プロビジョニングのマッピング設定画面が表示されます。 「属性マッピング」の項目に、Cato上のプロパティとEntra IDのプロパティの対応関係が一覧化されています。 今回は、CatoNetworks属性の「emails[type eq “work”].value」へEntra IDの「mail」をマッピングする設定について 「編集」をクリックします。 編集対象の詳細が表示されます。 ソースはEntra IDの特定のプロパティを直接代入するのみではなく、固定値や式を用いることも可能です。 今回は、「userPrincipalName」をソース属性に指定し、「OK」を押下します。 「保存」を押下することで、設定変更が反映されます。 プロビジョニングを有効化 Cato Networks Provisioning詳細画面左の[管理 – プロビジョニング]を選択します。 以下の設定となっていることを確認のうえ、「保存」をクリックします。 設定 > 範囲：割り当てられたユーザーとグループのみを同期する プロビジョニング状態：オン 設定の保存後、自動でプロビジョニングが開始されます。 Catoの[Access > Users]にて[Users Directory]タブを確認すると、ユーザが追加されていることを確認できます。 プロビジョニングされたユーザにライセンスを割り当てる (オプション) プロビジョニングされたユーザは、デフォルト設定では自動的にSDP licenseの未使用分が割り当てられます。 ライセンス割り当て対象を明確に指定するオプション（Assign SDP license to selected users or groups）を 利用している場合は、下記のようにSDP licenseの割り当てを行う必要があります。 CMAコンソールの[Access > License Assignment]にて追加されたユーザーを選択し、「Save」を実行します。 数分で設定が反映され、無事にリモートアクセスできるようになりました。 Cato Clientを用いたリモートアクセスの方法については、 こちら の記事もご参照ください。 プロビジョニングされたユーザの管理 プロビジョニングによって作成したユーザは、手動作成とは異なる管理方法が求められます。 プロパティの変更 SCIMプロビジョニングで作成されたユーザは、CMA画面上ではプロパティを変更できないようになっています。 変更が必要な場合は、同期元のIdPで値を変更します。 今回は、Entra ID側のプロパティにて、氏名を「テスト 次郎」に変更します。 自動プロビジョニングを有効にしていれば、 40分毎に自動で更新 されます。 CMAのプロパティ画面を見てみると、変更が反映されていることを確認できます。 パスワードの変更（SSO認証非設定時） SSO認証を用いずにパスワードの個別設定を行っている場合、パスワードリセットはCMA上で実施します。 CMAの[Access > Users]に移動し、[Users Directory]タブで対象ユーザを選択します。 [Actions > Reset Password]を実行しましょう。 SSO認証を使用している場合は、連携元のログイン処理を用いることとなるため、 パスワードリセット等の処理も連携元にて行います。 ユーザの削除 SCIMプロビジョニングにより作成されたユーザを削除する場合は、 必ず先に連携元で操作を実施する必要があります 。 Entra IDテナントのアプリケーションにて、プロビジョニング対象から削除したいユーザを外します。 具体的には、下記のような方法をとることができます。 対象のユーザを削除する 対象のユーザを、プロビジョニング割り当て対象から外す 今回は、アプリケーションの「ユーザーとグループ」から直接割り当てを削除します。 グループ単位での割り当てを行っている場合は、対象ユーザを当該グループから外すことで 他のユーザに影響を与えずに割り当て対象から外すことが可能です。 プロビジョニングによる同期後にCMAの[Access > Users > Users Directory]を確認すると、 対象ユーザが「Disabled」のステータスになっています。（割り当てたライセンスは自動で外されます。） 「Disabled」になったことを確認した後に 、[Actions ＞Delete]でユーザーを削除しましょう。 IdP側での操作を行う前にCMA上で削除を実行した場合、 削除成功のメッセージが表示されるにもかかわらずユーザが削除されないといった現象が発生します。 想定外の挙動を引き起こす可能性もあるため、 必ずIdP側での操作を先に実施 しましょう。 SSO認証の設定（オプション） Cato推奨（デフォルト）のユーザー認証方法はSSO認証となっており、 2025年4月現在でSCIM連携に対応しているサービスは全てSSO認証にも対応しております。 SSO認証を用いると、パスワードの管理までIdPで一括管理できるようになります。 Microsoft Entra IDでの設定手順は下記のとおりです。 CMAの[Access > Single Sign-On]に移動し、「New」をクリックします。 Identity Providerとして「Microsoft Azure」を選択し、任意の名前を付けて「Apply」を押下します。 その後、画面右上の「Save」をクリックします。 追加されたAzureの項目にカーソルを合わせ、編集（ペンのアイコン）を押下します。 プロパティ画面にて、「Setup Microsoft Consent」をクリックし、 連携先テナントの管理者アカウントにて認証を実施します。 終わりに 今回は、SCIM連携にてユーザを管理するための一連の操作を紹介しました。 初期設定こそ必要とするものの、設定後はIdPでユーザを統合管理することが可能となり、 運用負担を大きく軽減することが可能です。 Entra IDをはじめとするIdPサービスを利用している組織では、ぜひ積極的に活用してみてください。
こんにちは、石原です。 最近、AWS上のデータベースのバージョンアップの検証を行うタイミングで 「Insight SQL Testing」 を触る機会があったので、こちらの製品についてご紹介いたします。 Insight SQL Testingとは？ Insight SQL Testingはインサイトテクノロジー社が提供している製品になります。 Insight SQL Testing - 株式会社インサイトテクノロジー データベース移行及びバージョンアップ向けSQLテストソフトウェア。異種データベース間でSQLのテストができる唯一の製品。 www.insight-tec.com Insight SQL Testingは、データベース移行やバージョンアップに伴うSQLテストを効率化するためのソフトウェアになります。このツールは、データベース移行やバージョンアップ時の工数を大幅に削減し、性能や互換性を確認して修正が必要なSQLを検出することができます。 こちらの製品には以下のような特徴があります。 ①マルチデータベース対応 Oracle をはじめ、様々なデータベースをサポートしています。 ②自動SQL収集 本番環境で実行されるSQLを自動(または手動)で収集し、テストを実行することができます。これにより、手動での作業を大幅に削減できます。 ③異種データベース間のテスト 異なるデータベース製品間でのSQLテストを行うことができ、移行時の問題点を洗い出すことができます。 MySQLのバージョンアップで使ってみた データベースのバージョンアップを行うことにより内部動作が大きく変わることがあります。そこまで動作が変わらないだろうと思い、バージョンアップした後に今まで実施していた処理を流してみたらエラーになったという話はよく聞くと思います。では事前にバージョンアップさせた検証機を作成し、テストしようとしても結局どれの処理で問題が起きエラーになったのか、処理が遅延が発生したのか切り分けていくのは大変です。 今回は、このような検証を一括で容易に行えるInsight SQL Testingを用いることでどのような結果が得られるか、本当にSQLテストを効率化させることができるのか試してみました。なお用いたデータベースはMySQLになるため、本内容もMySQLに特化した内容となる点はあらかじめご了承ください。 Insight SQL Testingを利用するうえで用意するもの 今回私がInsight SQL Testing環境を用意するにあたり、AWS上で実施しました。そのためAWS観点で使用する前提の内容とはなりますが、具体的には AWS Marketplace から SQL Testing Manager のAmazon マシンイメージを入手してInsight SQL Testing用の EC2 を用意しました。 後は、別途以下を用意する必要があります。Insight SQL Testingにこれらの環境を自動で生成する能力はないので、頑張って用意します。いずれもAWS上にあるRDSになります。 ①移行元のジェネラルログ ※ジェネラルログは一般ログと呼称する場合もありますが、ここではジェネラルログで統一します。 ②移行元のコピーDB(A) ※コピー後にバージョンアップした環境 ③移行元のコピーDB(B) それぞれについて用途を説明します。 ①移行元のジェネラルログ このログはMySQL環境で出力されるログであり、データベース内で実行されるすべてのSQLの処理を記録します。SELECT文も含め、全部のSQLを記録するのですからMySQLは凄いですね。この特性を持つジェネラルログを利用して移行元で作成されるジェネラルログをまるっとInsight SQL Testing側に読み込ませます。ちなみにユーザー情報もセットで読み込ませることができるので、最終的には不要なユーザーの処理を省くことも可能です。 ②移行元のコピーDB(A) ※コピー後にバージョンアップした環境 これは移行元のコピー環境を用意し、その後目的のバージョンまで引き上げたものです。Insight SQL Testingで読み込ませた処理をこの環境に実行することになります。Insight SQL Testingで読み取った処理は元々はバージョンアップ前では正常に実行できていたものなので、それをバージョンアップした環境で実行するとどうなるかデータの互換性を確認することができます。 ③移行元のコピーDB(B) これはコピーDB(A)同様、移行元のスナップショットなどのバックアップから作成したものです。目的としてはバージョンアップした環境との対比として使用します。移行元のコピー環境Bも用いることでパフォーマンス観点からも確認が行えるようになります。 Insight SQL Testingの操作 環境が揃った状態で、いよいよInsight SQL Testingを操作していきます。操作は大きく分けると以下のような感じになります。 ①ログの読み込み 取り込み方は色々用意されており、実際に移行元につないでQueryの情報を引っ張って来ることも可能です。 今回の場合は、MySQLのジェネラルログをローカルに配置し、そのログを直接読ませて取り込むという方法で実施しました。 ②SQLを流す先のDBの登録 前の記載内容の移行元のコピー環境Bとバージョンアップした環境AをInsight SQL Testingに認識させます。 ③SQLを実行し結果をみる あとは実際に登録したDBに対して読み込んだログの内容を実行をします。バージョンアップ前(コピーDB(B))と後(コピーDB(A))の2つの環境に対して、Insight SQL Testingに読み込ませた処理をInsight SQL Testingの命令によって実行させます。Insight SQL Testingは最終的にパフォーマンス結果や処理の失敗などをまとめて報告してくれるので実際のバージョンアップ前に事前に問題の洗い出しが可能となります。 結果から得られるもの 具体的には以下の項目が確認できます。 ①ターゲットDBでのみ失敗 ②テスト用ソースDBでのみ失敗 ③両DBで失敗 ④結果が相違 ⑤性能が劣化 ⑥成功 最後にそれぞれについて簡単に説明します。 ①ターゲットDBでのみ失敗 ここでいうターゲットDBは「バージョンアップしたDB(A)」を指します。ここに引っかかったSQLはバージョンアップの影響で失敗した可能性が高いといえます。もちろん、そのSQLについて念のために再実行するなどして再現性は確認した方がいいとは思います。なお、Insight SQL Testing内で任意のSQLを実行する画面もあるので、そこから再実行可能です。 ②テスト用ソースDBでのみ失敗 このテスト用ソースDBは「移行元のコピーDB(B)」を指します。本来、ここで失敗することはないと思われます。失敗する可能性としては、例えば移行元のコピーとして用意していますが、その後、コピー元またはコピー先で操作(テーブルなどの作成)を実施しその影響でテーブルがコピー先にないことや逆に既に表が存在するなどが考えられます。 ③両DBで失敗 これは記載どおり、「バージョンアップしたDB(A)」および「移行元のコピーDB(B)」で処理が失敗したSQLになります。これも②同様、ここに載って来る可能性は少ないと考えられます。 ただし、例えば以前実行したことがあるInsert文を含むジェネラルログを実行した場合、Insert先がPRIMARY KEY制約などを持った表の場合には失敗することがあります。 ④結果が相違 こちらはSQL自体、両DBともに正常に実行できたが、 処理の結果として影響があった件数が異なる場合や、処理結果自体が異なる場合（ソート順の仕様変更等に起因するものなど）にカウントされます 。基本はSELECTの結果になりますが、他にDMLやSHOWコマンドなどの結果も対象となります。こちらに該当したものは、ただ単に②のような環境コピー後の差異の影響であるのか、またはバージョンアップによる影響や③のようなDMLを重複実行している場合など確認が必要になります。 ⑤性能が劣化 今までのような問題が発生しない場合、⑤か⑥に振り分けられます。実行速度が、 「コピーDB(B)」＞ 「バージョンアップしたDB(A)」になったSQLがこちらになります。なお、デフォルトの設定を満たしてしまうと劣化扱いになります。そのため、アセスメントの設定において、遅延をどれだけ容認できるか設定しておくことが重要です。設定には秒数だけなく割合も指定することが可能です。実際に実行する場合は、事前にここの設定を行ったうえで実施することがお勧めです。 ⑥成功 以下を満たしたものが対象となります。 ・ 「エラーにならない」 ・「結果も同じ」 ・「処理時間も今まで以下」 基本的に、こちらの枠に入ったSQLは特にバージョンアップにおいて考慮する必要はありません。 一例ですが、以下のように振り分けられます。ステータスは先の画像から判断できます。以下は意図的に各項目に引っかかるような処理をジェネラルログ上に出力させ、Insight SQL Testingから処理を実行したものなのですべてのパターンを網羅した表記になっています。 これらの結果を踏まえて、再度調整してSQLを実行したりしながらバージョンアップの問題点を解決していきます。 まとめ 今回、Insight SQL Testingを操作するにあたって簡単に概要や操作の流れをまとめてみました。 Insight SQL Testingを用いても失敗した処理などにおいて、改善する方法は提示されることはありませんが、Insight SQL Testingを用いた方がより短時間で確実なバージョンアップまたは別ＤＢ移行などが出来そうです。改良の余地がある点はありますが、これは今後に期待です。 今回は簡単に全体の流れからどのようなものが確認できるのかをブログで記載してみました。もっと詳しく細かく知りたい方のために、今後具体的にインストールから実行結果、Insight SQL Testingを扱う際の注意事項を今後も取り上げていこうと思います。 少しでもInsight SQL Testingについて興味を持っていただければ幸いです。
こんにちは。SCSKの山口です。 今回は、Google Cloud認定資格の受験レポート その➁です。 その①のブログ をご覧になった方はお察しかもしれないですが、Associate Data Practitionerに無事一発合格したので、受験後のレポートを書きます。 はじめに その①ブログにも書いた通り、（記憶に残っている範囲で）下記について書きます。 今回はサクッと読める分量で書きたいと思います。 [受験後] ・合否（もう書いた。） ・出題内容（受験前の想定とのギャップ） ・（追加で）抑えておいた方が良い要点 なお、今回書く内容はあくまで2025.03時点の情報です。試験内容が変更になる可能性もありますので、最新の情報は公式ドキュメント等をご確認ください。 出題内容 実際の試験に多く出てきた要点を書きます。詳細な内容は その①のブログ に詰め込んでいるので、そちらをご確認ください。 ETL/ELT で登場するサービス 体感、半分くらいの問題がコレ関連でした。 ・Dataflow ・Dataproc ・Data Fusion ・Cloud Composer このあたりの概要、特徴、ユースケースは確実に抑えておく必要があります。 また、 ETLなのかELTなのかの使い分け も問われます。問題文に ロードする前に変換する必要がある（ETL） リアルタイムにデータを取り込んで処理したい（ELT） など、ヒントとなる文が書いてあるので、注意深く読めば選べる問題ばかりだと思います。 データ転送ツール これもよく聞かれました。 ・BigQuery Data Transfer Service ・Storage Transfer Service ・Transfer Appliance この辺りは特徴とユースケースを抑えておいた方が良いです。 BigQuery やっぱり多くの問題に登場しました。 BigQuery を「データ分析基盤」として活用する使い方や、Google Cloud上での「AI/ML活用を見据えたデータシンク」として活用する使い方が出てきました。 また、BigQuery の機能もそうですが、その①ブログでも書いていた ・アクセス制御 ・暗号化 ・パーティショニング も予想通り問題に登場していました。 Cloud Storage BigQuery まではいかないものの、こちらも多くの問題に登場していました。 その①のブログにも書いていた ・冗長化と高可用性 ・ストレージクラス この辺りは押さえておいた方が良いです。 Looker 2,3問ほど登場しました。 そこまで登場回数は多くないものの、 ・Lookerの用語（Explorer、View、Dimension、Majorなど） ・アクセス制御 ・他メンバとのダッシュボード共有方法 あたりを抑えておくと安心です。 追加で抑えておいた方が良い要点 実際に試験を受けて、その①のブログでは書けていなかった（予想外だった）要点を書きます。 Dataform Dataformに関する問題が数問出てきました。明らかにダミーの選択肢に登場するのではなく、 Dataformの概要を把握したうえで判断すべき問題 として登場していました。 概要はここで書くと長くなるので、 公式のドキュメント をご確認ください。 BigQuery ML こちらも数問出てきました。 BigQuery に貯めているデータに対してMLを活用する際に、 ・要件に合わせた適切なモデル ・実際に実行すべきSQL を選択させる問題が登場します。 過去にブログにまとめていますので、ぜひこちらをご覧ください。 BigQuery MLを触りたいときに読むブログ BigQuery MLで作成した線形回帰モデルを評価してみる BigQueryML ARIMA PLUSモデルで時系列予測してみる まとめ その①のブログの内容はかなりヒットしていたかなと思います。本ブログでは、その①でカバーできていなかった点も書いたので、この日本のブログの範囲を理解できていれば合格は難しくないと思います。 が、人によっては「試験が英語なのがチョット、、」となっている方も多いと思います。 Google Cloud全冠を目指す方にとっては避けて通れないのがいくつかの英語試験です。 私流の英語試験の解き方のコツ。みたいなのもまた発信できたらと思っています。
CloudWatch Agentの設定ファイルについて、どのファイルが読み込まれているのか、理解があやふやだったので整理してみました。 設定ファイルの文法などには触れていません。どこに作ってどう反映されるのかを理解できれば幸いです。 設定ファイルの構成 CloudWatch Agentの設定ファイルは通常、/opt/aws/amazon-cloudwatch-agent/etc/ に配置されます。 大体は以下のようになっているでしょう。 /opt/aws/amazon-cloudwatch-agent/etc/ ┣ amazon-cloudwatch-agent.d ┣ amazon-cloudwatch-agent.json ┣ amazon-cloudwatch-agent.toml ┣ amazon-cloudwatch-agent.yaml ┣ common-config.toml ┣ env-config.json ┗ log-config.json amazon-cloudwatch-agent.json は導入直後は存在しません。ユーザが作成する設定ファイルですが、この名前で作成することは推奨されています。この中でユーザが作成する設定ファイルは、 amazon-cloudwatch-agent.d 配下の設定ファイル amazon-cloudwatch-agent.json の2つです。Agentは両方を参照しています。また、片方が無くても動作しますが、両方無いとアウトです。 あまりやってる人はいないと思いますが、 設定ファイルは複数に分けて持つことができます。 Agent起動時の設定ファイルの読み込み CloudWatch Agentの起動時は、上記の設定ファイルは以下のように使用されているようです。 設定ファイルをマージしてamazon-cloudwatch-agent.toml ファイルを生成し、Agent は.toml を参照して動作しています。 このマージ動作はAgent起動のたびに実行されています。 Agentの起動コマンドは以下です。systemctl startでも起動しますが、こちらで起動するのが正式です。 sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a start 設定ファイルの反映 設定ファイルの作成について、前述のamazon-cloudwatch-agent.json として作成する場合は話すことはありません。手動あるいはwizard で指定の名前としてファイルを作成すればいいです。(この場合は後続のfetch/append/remove コマンドは関係ありません。) 一方、amazon-cloudwatch-agent.d に設定ファイルを作成する場合は、ファイルを直接作成することは推奨されていないようで、作法があります。以下、3通りのコマンドがあるので使い分けます。 fetch-config 任意の場所に作成された設定ファイルを読み込み、amazon-cloudwatch-agent.d にコピーしてtoml ファイルを生成します。 尚、 既存の設定は削除されます。 破棄される内容は amazon-cloudwatch-agent.d 配下の設定ファイル amazon-cloudwatch-agent.json なので注意しましょう。図で書くとこうです。 sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -c file:/path/to/json/sample.json 指定されたファイルは頭に”file_”がついた状態でamazon-cloudwatch-agent.d/ にコピーされ、.tomlに変換されます。 append-config 任意の場所に作成された設定ファイルを読み込み、amazon-cloudwatch-agent.d にコピーしてtoml ファイルを生成します。 尚、 既存の設定は維持されます。 このため、設定内容を追加する場合で、既存の設定ファイルを触りたくない場合に使用します。 fetchと同様に、指定されたファイルは頭にfile_がついた名前でコピーされます。 sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a append-config -m ec2 -c file:/path/to/json/sample.json remove-config 指定した設定ファイルをamazon-cloudwatch-agent.d/ から削除した上で、.toml ファイルを生成します。 こちらも 既存の設定は維持されます。 amazon-cloudwatch-agent.json(あれば)と、amazon-cloudwatch-agent.d/ 内の指定されたファイル以外で.toml が生成されます。 sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a remove-config -m ec2 -c file:sample.json コマンドに指定のfileについては、file_ を除いたファイル名のみを指定します。 手動削除もよいのでしょうが、その場合は.tomlファイルへの変換が行われません。 (しかしAgent起動時にはやはり.tomlへの変換が行われているようであり、結果として問題にはなりませんが。。) まとめ CloudWatch Agentの設定ファイルについて、結局どのファイルが使用されるのかがぼんやりしていたため、実験してひも解いてみました。あまり設定が変わらない場合については直接 amazon-cloudwatch-agent.json として作成してAgentの再起動で反映するのが簡単です。 複雑な設定ファイルや更新が頻繁になる場合には、用途ごとに設定ファイルをappendして使用することも考慮に入ってくるのかと思います。 この記事が参考になる人が一人でもいたら幸いです。
以前、Disaster Recovery 機能を用いたLifeKeeperの構築を行いました。 AWS環境でのLifeKeeperを用いた災害対策！Disaster Recovery Add-on 構築＆機能検証 災害対策サイトへのリアルタイムでのデータレプリケーションと、フェイルオーバーを可能にするDisastar Recovery Add-onの設定手順と機能検証を行いました。 blog.usize-tech.com 2025.02.05 検証環境を一から作成し、LifeKeeperのインストールを初めて行ったのですが、 その際に生じた躓いたところを、自分への備忘もかねて今回まとめました。 概要 AWS環境のRed Hat Enterprise Linux に LifeKeeperをインストール Disaster Recovery Add-onの初期設定及びリソース作成/拡張を実施 インストール時 まず初めにLifeKeeperをインストールの際のトラブルシューティングです。 事前に確認しておくべき項目を記載しておきます。 ライセンスが有効であるか 初歩的なことですが、一番大事な確認かもしれません。 ライセンスが有効になっているか、期限が切れていないかまずは確認しましょう。 SELinuxが無効化されているか SELinux が enforcing モードの場合 、LifeKeeper は動作しないため無効となっているか確認しましょう。 確認コマンド：sestatus 上記事項の確認を終えましたら、インストールに移っていきます。 インストールの手順としては、isoファイルを対象のノードにセットして、セットアップを実行していきます。 私が初めて実施した際は、まずその段階でエラー発生しました。 # ./setup LifeKeeper for Linux Setup Validating files........................................................................OK Collecting system information.....................................done. Preparing configuration information............done. Performing package installation and updating configuration information for LifeKeeper for Linux. Install LifeKeeper and dependent packages done. Setup failed. Fix the problem and try again. ---error message--- - Status code: 999 for https:/--- Error: Failed to --- # 上記表示のように、エラーメッセージやエラーコードが表示されました。 セットアップコマンドが失敗した際は、エラー原因を確認し該当の箇所をある程度は切り分けられることができますので、 対処をして再度チャレンジしていきましょう。 インストールが完了しましたら、LifeKeeperが起動しているか確認してみましょう。 確認方法としては、/opt/LifeKeeper/bin/lktest を実行すると確認ができます。 # /opt/LifeKeeper/bin/lktest F S UID PID PPID C CLS PRI NI SZ STIME TIME CMD 4 S root 23199 23134 0 TS 39 -20 4579 05:29 00:00:00 lcm 4 S root 23201 23140 0 TS 39 -20 5526 05:29 00:00:00 ttymonlcm 4 S root 23205 23133 0 TS 29 -10 6674 05:29 00:00:00 lcd # 上記コマンドを実行して出力がされていれば、無事LifeKeeperは起動されております。 リソース作成時 続いて、LifeKeeperのインストール完了後、リソースと呼ばれる、LifeKeeperにて保護するアプリケーションやファイルシステムを設定する中でのトラブルシューティングとなります。 今回はDisaster Recovery Add-onにおけるDRBDリソース作成および拡張時におきたトラブルシュートの例を記載いたします。 リソース不足 デフォルト値の設定にてリソース作成を試みたところ容量不足でエラーが発生しました。 1.0MBで容量が不足とのことなのでこちらの対処として、AWS EBS で10 GiBのサイズを対象 インスタンスへの割り当てを行い、こちらのエラーは解消となりました。 パーティション作成 続いて、DRBDリソース作成時に発生したエラーです。 このエラーは、パーティションの無いデバイスに対して操作を行うと生じるエラーとのことでした。 こちらは検証を行っていた段階では製品マニュアル等に記載が無い情報となりメーカーのサポート窓口と密にやり取りを行い解消できた事象となります。 対処として、マウント対象のデバイスに対してパーティションを作成し事象が解消となりました。 そのため、データレプリケーションリソース作成の際は、事前にデバイスの確認を行い、無いようであればディレクトリにパーティションの作成を行いましょう。 パーティションの作成方法としては以下となります。 fdiskを使用して新しいパーティションを作成または修正します。 ● sudo fdisk /dev/＜対象デバイス名＞ ● n を押して新しいパーティションを作成。 ● p を選んでプライマリパーティションを設定。 ● 必要に応じて値を設定し、最後にパーティション変更を保存するために w を押します。 DRBDリソース再作成時の注意点 一度リソースの作成ができず、再度リソースの作成を試みようとしたとき、 DRBD の設定が残っている可能性があり、その場合リソース作成でエラーが発生いたします。 その際は以下のコマンドを実行をして余分な情報を削除する必要があります。 rm /etc/drbd.d/*res* ※該当 ファイルの削除確認が表示されますので y で削除してください。 (何度もリソース作成をしていたので、何回も削除をして疲れた思い出があります。) コミュニケーションパス作成時 リソース拡張前にコミュニケーションパスを作成する リソース拡張という操作をするのですが、そもそもリソース拡張とは、なんぞやというところですが リソース拡張とは1号機、2号機で作成したリソースを簡単に言うと紐づける動作となります。 その際の動作ですが、コミュニケーションパスで接続されているサーバーがないとそもそもLifeKeeper側で認識ができず、拡張ができないとのことです。 なので、先にコミュニケーションパスの作成をしましょうというお話です。 ちなみに、コミュニケーションパスの作成が完了し1号機、2号機が接続されている状態でリソース拡張先のサーバーでも該当のARL(今回の場合 DRBD ARK) やとLifeKeeperの設定をGUI上で行うLKWMC のインストールの準備が必要となります。こちらが行えていたら、リソース拡張操作で DRBD リソースの拡張が行えるようになります。 名前解決 コミュニケーションパスの作成時にも、もちろん(？)エラーが発生しました。 エラー原因は1号機、2号機間での名前解決が出来ていないからでした。 今回は、hostsファイルに対象のホスト名を明記し、解消しました。 vi /etc/hosts 192.168.xx.xx 10.142.xx.xx 対象ポートの許可 以下のTCPポートの許可設定が必要となります。 サービス ポート番号 コミュニケーションパス (TCP) 7365/tcp GUI サーバーとの通信 81/tcp、82/tcp GUI サーバーとクライアントとの RMI 通信 1024/tcp 以降の全ポート LKWMCの通信GUIサーバー 5110/tcp LKWMCのREST APIサーバー 5000/tcp Disaster Recovery Add-on機能の確認時 無事DRBDリソース作成及び拡張ができ、設定が完了したかと思い、機能の確認をしたのですが想定通りの動作がせず困ったことに、、、 そこで有識者に確認をしてみたところQuorum/Witness の設定をしてみたらどうかとの見解を頂きました。 構成例 - LifeKeeper for Linux LIVE - 9.9.0 ここでは DRBD を用いた３ノードディザスターリカバリーの構成例を説明します。 概要 以下の AWS... docs.us.sios.com storage モード - LifeKeeper for Linux LIVE - 9.6.1 docs.us.sios.com Quorumパラメータ一覧 - LifeKeeper for Linux LIVE - 9.4.0 下記の表は、Quorumパラメーター名とその意味を説明しています。これらの値は /etc/default/LifeKeeper... docs.us.sios.com 上記3つの資料を参考にQuorum/Witnessの設定をしてみたのですが、/opt/LifeKeeper/bin/qwk_storage_initを実行でエラーが出てしまいました。 よくよく確認すると、AWS CLIの設定を修正(アクセスキー設定を統一)して再度実行したところ解消しました。 その後、東京リージョンのノードを落として、データレプリケーションが大阪ノードで行われるかの機能について確認したところ、 無事フェイルオーバーとデータレプリケーションを確認できました！復旧後の動作も問題なく確認できたため検証終了となりました。 参考設定値 ＃cat /etc/default/LifeKeeper NOBCASTPING=1 QUORUM_MODE=storage WITNESS_MODE=storage ～以下省略～ # Do NOT edit LK_DISTRIBUTION values – this may cause LifeKeeper to malfunction LK_DISTRIBUTION=redhat LK_DISTRIBUTION_VERSION=9.4-0.4.el9 QWK_STORAGE_TYPE=aws_s3 QWK_STORAGE_OBJECT_ip_10_142_xx_xx_compute_internal=s3://drbd/～ QWK_STORAGE_OBJECT_ip_10_142_xx_xx_compute_internal=s3://drbd/～ QWK_STORAGE_OBJECT_ip_192_168_xx_xx_compute_internal=s3://drbd/～ まとめ 今回の検証作業では、一歩進んでは躓き、そこからまた一歩進んだかと思えば違う壁にぶつかりと一進一退の作業でした。 今回行ったトラブルシューティングの対応を今後に活かしていき、スムーズなLifeKeeperの構築を目指していきたいです。 本記事についてより詳しい内容を知りたい方がいらっしゃいましたら 以下画像をクリックし、HPよりお気軽にお問い合わせください。
本記事は 新人ブログマラソン2024 の記事です 。 皆さん、こんにちは！新米エンジニアの佐々木です。 前回は、Snowflakeの新機能コンピュートプールについて記事にまとめさせていただきました。多くの方々に読んでいただき、大変嬉しく思っています。 まだ読めていないという方は、以下の記事をまずは読んでいただけると幸いです！！ Snowflake の新機能！コンピュートプールについて調査してみた – TechHarmony さて今回は、前回の記事の続編ということで、実際に コンピュートプールを用いたSnowflakeの公式チュートリアル に挑戦してみました！ 今回は、そのチュートリアルを通して学んだことについて共有したいと思います。 チュートリアルの概要 今回は「 Snowpark Container Servicesサービスを作成する 」という題材のチュートリアルを実施しました。 チュートリアル1: Snowpark Container Servicesサービスを作成する | Snowflake Documentation docs.snowflake.com えっ、コンピュートプールのチュートリアルじゃないの？と思われた方もいるかと思います。 実は今回扱うSnowpark Container Servicesを理解するにはコンピュートプールへの理解が必要不可欠となります。そのため今回は上記のチュートリアルを実施することにしました！ Snowpark Container Servicesって何？ Snowpark Container Services（以下、SPCS）は、 Snowflakeの強力なデータプラットフォーム上で、コンテナ化されたアプリケーションを直接実行できる画期的なサービス です。Dockerコンテナを活用することで、機械学習モデルのデプロイ、APIの構築、ストリームデータ処理など、様々なワークロードをSnowflake内で実行できます。 これにより、 データとアプリケーションの近接性： データ移動のコストを削減し、パフォーマンスを向上 Snowflakeのセキュリティとガバナンス： Snowflakeの強固なセキュリティとガバナンスをそのまま利用可能 スケーラビリティ： Snowflakeの柔軟なスケーラビリティを活用 といったメリットが生まれます。 コンピュートプールとは？ SPCSを理解する上で欠かせないのが コンピュートプール です。コンピュートプールは、Dockerコンテナを実行するための計算リソースの集合体であり、簡単に言うと「アプリケーションを動かすためのサーバーのグループ」のようなものです。 なぜコンピュートプールが必要なのか？ SPCSでは、Dockerイメージを元にコンテナを作成し、そのコンテナ内でアプリケーションを実行します。コンテナは、CPU、メモリ、ストレージなどのリソースを必要としますが、コンピュートプールは、これらのリソースをコンテナに提供する役割を担います。 つまり、 コンピュートプールがあるからこそ、SPCS上でアプリケーションを動かすことができる のです！ チュートリアルの流れ では上記を踏まえたうえで、実際にチュートリアルを進めた流れについて以下に示します。 環境構築: Snowflakeアカウントの準備、SPCSが利用可能なリージョンの確認、必要なロールの付与など、基本的な環境設定を行う イメージリポジトリ作成: SnowflakeにDockerイメージを保存するためのリポジトリを作成する。これが、コンテナ化されたアプリケーションの保管場所となる イメージプッシュ: ローカルでビルドしたDockerイメージを、先ほど作成したリポジトリにプッシュする。今回の例では、シンプルなHello Worldアプリケーションのイメージを使用する コンピュートプール作成: ここが重要なポイント！SPCSでコンテナを動かすためのリソースとなるコンピュートプールを作成する。CPU、メモリ、インスタンス数などを指定し、アプリケーションのニーズに合わせた構成を定義する サービス定義: コンテナサービスを定義する。どのイメージを使うのか、どのコンピュートプールで動かすのか、ポート設定などを指定する サービスデプロイ: 定義したサービスをデプロイする。Snowflakeが自動的にコンテナを起動し、サービスを稼働状態にする サービスエンドポイントアクセス: 外部からサービスにアクセスするためのエンドポイントを確認し、ブラウザなどでアクセスしてアプリケーションが正常に動作することを確認する この記事では大まかな流れについてしか触れませんが、より具体的なことを知りたい方は公式チュートリアルをご覧ください！ コンピュートプールの重要性 このチュートリアルを通して、特に重要だと感じたのが コンピュートプール の存在です。コンピュートプールは、SPCS でコンテナを実行するためのコンピューティングリソースの集合体であり、以下の役割を担っています。 リソースの管理: CPU、メモリ、GPU などのリソースをプールとして管理し、SPCS で実行されるコンテナに割り当てる スケーラビリティの実現: コンピュートプールのサイズを調整することで、アプリケーションの負荷に合わせて柔軟にスケーリングする 分離性の確保: 異なるワークロードに対してコンピュートプールを分けることで、リソースの競合を防ぎ、安定したパフォーマンスを維持する チュートリアルでは、 COMPUTE_POOL_INSTANCE_FAMILY に STANDARD_1（事前に定義された値） を指定してコンピュートプールを作成しました。この設定により、SPCS は各コンテナに適切な CPU とメモリを割り当て、アプリケーションがスムーズに動作することを保証します。 また、コンピュートプールのサイズを調整することで、アプリケーションの負荷変動に対応できる点も魅力的です。例えば、データ分析のピーク時にはコンピュートプールのサイズを大きくし、夜間などの負荷が低い時間帯にはサイズを小さくすることで、コストを最適化できます。 まとめ 今回のチュートリアルを通して、SPCS の基本的な使い方とコンピュートプールの重要性を学ぶことができました。具体的には以下のことに気づきました。 SPCS は、Snowflake のデータとコンピューティングリソースを組み合わせることで、高度なデータ処理や機械学習のワークロードを効率的に実行できる強力なツールである コンピュートプールは、SPCS のパフォーマンスとスケーラビリティを左右する重要な要素であり、ワークロードの特性に合わせて適切な設定を行う必要がある SPCS を活用することで、データエンジニアリングから機械学習まで、幅広いユースケースに対応できる可能性がある 今回のチュートリアルをもとに、今後はより複雑なアプリケーションのデプロイや、コンピュートプールの最適な設定方法について深く探求していきたいと思います！
こんにちは、佐藤です。 AWS のサービスやアーキテクチャ、全然覚えられないなんてことありませんか…？ 私も最初は「IAM って何？」「S3 って何？Storage Service…？」など、専門用語の洪水に溺れそうになりました… そんな悩みを解決してくれるのが AWS BuilderCards です。 今回は、このカードゲームのルールについて、初めての方でも理解できるように解説していきます。 1. AWS BuilderCards とは AWS BuilderCards は、AWS が提供するサービスやそれらを組み合わせたアーキテクチャを楽しく学ぶことができるカードゲームです。 各カードには QR コードがついており、スキャンするとそのカードが表すサービスやツールについて詳しく学べる仕組みになっています。 ゲームの基本情報 プレイ人数: 2〜4人 プレイ時間: 20〜30分 対象: AWS サービスに興味がある方、IT 専門家、クラウド技術を学習したい人 2. カードの種類と役割 AWS BuilderCards には主に 3 種類のカードがあります。 ① スターターカード（Starter Cards） スターターカードはプレイヤーごとに色分けされた 10 枚のセットで、オンプレミス環境を表します。右上隅にグレーの S-アイコン（Starter の「S」）がついており、ゲーム開始時に各プレイヤーの手札となります。 ちなみに第 2 版では、オンプレミスカードの名前が「より多様なオンプレミス IT 環境を反映するように」という変更がされ、Virtual Machine カードとの新しい組み合わせ効果も追加されています。 ② Well-Architected カード Well-Architected カードは、ゲームの獲得ポイントとなるカードです。1 ポイントと 3 ポイントの 2 種類があり、最終的にこのカードを集めることがゲームの勝利条件になります。 ちなみに、プレイヤー数によって使用するカード数が変わる点に注意が必要です。（右上の赤い□をチェック） 2 人プレイ：2 人用アイコンのカードのみ 3 人プレイ：2 人用・3 人用アイコンのカード 4 人プレイ：すべてのカード ③ ビルダーカード（Builder Cards） ビルダーカードは、AWS サービス、認証、ツール、フレームワークなどを表すカードです。これらはクラウド環境を表しており、アーキテクチャ構築の基本となります。 このカードには QR コードが記載されており、スキャンするとそのトピックについて詳しく学べます。ゲームをしながら AWS の知識を身につけられるのが大きな特徴です。 3. ゲームの準備 実際にゲームを始める準備をしていきましょう。 各プレイヤーは好きな色のスターターカード 10 枚を受け取ります（4 色あるので最大 4 人までプレイ可能） プレイヤー数に応じて Well-Architected カードを用意します（1 ポイントカードを 3 ポイントカードの上に置きます） ビルダーカードをコストなし（無料で取れるカード）とコストあり（クレジットが必要なカード）の 2 つの山札に分けます コンソール（取り札）を作ります： コストなしの山札から 4 枚 コストありの山札から 1 枚 同じカードが出たら重ねて、常に 5 種類のカードが並ぶようにします 各プレイヤーは自分のスターターカード 10 枚をシャッフルし、5 枚を手札に取ります ミッションカードを使う場合は、各プレイヤーがミッションカードを 1 枚引きます これで準備完了です！ 4. ターンの進め方 – 3 つのフェーズ 各ターンは 3 つのフェーズで構成されています。 フェーズ 1：ビルド このフェーズでは、手札からカードを出してアーキテクチャを構築していきます。 オンプレミスカードの処理 ： ターン開始時に、手札 5 枚のうちビルダーカードがオンプレミスカードより多い場合、オンプレミスカード 1 枚を捨てることができます。ただし、捨てる場合は、そのターン中に少なくとも 1 枚のカードをコンソール（取り札）から取る必要があります。 アーキテクチャの構築 ： 手札からカードを場に出してアーキテクチャを作ります。アーキテクチャは最低 2 枚のカードで構成されますが、単体カードの配置も可能です。 カードの効果 ・カードを引く効果 (🃏)：追加で手札からカードを引けます ・クレジット追加 (💰)：そのターンで使えるポイント（ビルダーカードの右上の数字）が増えます ・クラウド採用追加 (☁️)：コンソール(取り札)からカードを追加で取れます ・効果使用後に捨てる (🌇)：一度だけ効果を使えるカードです わかりづらい用語をまとめてみましたのでご参考までに！ ・クレジット(💰)：手札を増やすためのポイント。手札の合計値がポイントになり、コストありカードの購入に使います ・コストなし/ありカード：無料で取れるカードと、クレジットが必要なカード（右上に数字がある） ・クラウド採用(☁️)：コンソール（取り札）からカードを取得する行為。基本 1 ターン 1 回！ 特定のカードを組み合わせると追加効果が発生するコンボ効果もあります。ただし、そのターンで組み合わせたカードは取り消しできないので注意しましょう。 フェーズ 2：カード獲得 このフェーズでは、コンソールからカードを 1 枚採用します。 コストなしのビルダーカードを無料で獲得 または、クレジットを使ってコストありのカード（ビルダーカードまたは Well-Architected カード）を購入 使用できるクレジット数は、配置したカードの合計クレジット値です。各プレイヤーはターンごとに基本 1 回のカード取得が可能ですが、コンボ効果で複数枚取得することもできます。 採用したビルダーカードは捨て札に、Well-Architected カードはプレイヤーエリアに配置します。 コンソールに良いカードがなければ、運試しでコストなしの山札から直接 1 枚引くこともできますが、その場合は引いたカードを返すことはできません。 フェーズ 3：ターン終了 ターンの最後には： アーキテクチャと残りの手札をすべて捨て札に置きます リソース山札から新たに 5 枚のカードを引きます 山札がなくなったら捨て札をシャッフルして新しい山札にします 次のターンの計画を立てます これで 1 ターン完了です。次のプレイヤーに順番が回ります。 5. ゲームの終了と勝利条件 最後の Well-Architected カードが取られ、すべてなくなったらゲーム終了となります。 各プレイヤーは獲得した Well-Architected ポイントを合計し、最も多いプレイヤーが勝者です。同点の場合は、ビルダーカードの数が多いプレイヤーが勝ちます。 ゲームはだいたい 20〜30 分で終わるように設計されているので、ランチタイムや短い休憩時間でも十分プレイできます。 6. まとめ AWS BuilderCards 、カードゲームだからと言って侮れませんね… このゲームを通じてこんなことを学ぶことができます。 ・AWS サービスの基本概念が自然と身につく ：Lambda、S3、EC2 などのサービスの役割や関連性を理解できます ・アーキテクチャの設計思想を学べる ：どのサービスを組み合わせるとよいのか、実践的な知識が身につきます ・Well-Architected フレームワークへの理解が深まる ：AWS の設計原則やベストプラクティスを学べます 私自身、最初はルールが少し複雑に感じましたが、1〜2 回プレイすると以外にもすぐになれました！ ぜひ皆さんも、同僚や友人と AWS BuilderCards を楽しみながら、クラウドの知識を深めてみてください！ 参考： AWS BuilderCards – Cloud Computing for Video Games – AWS
こんにちは、SCSKでAWSの内製化支援『 テクニカルエスコートサービス 』を担当している貝塚です。 AWSの検証をしていて、AWS Transit Gatewayの先にDirect Connect GatewayとAWS Direct Connectがいて、その先にオンプレミスがつながっている構成の検証をしたいこと、ありますよね。 でもAWS Direct Connectが準備できず、AWS Site-to-Site VPNを張りたいけれど検証に使えるオンプレミス上のVPNルータも準備できず、AWS Transit Gatewayに直接つなげたVPCで代用も考えるけれど環境の再現度の問題からVPCで代用は避けたい。そういうこともよくありますよね。（※） ※VPCをTransit Gatewayに直接つなげて疑似オンプレミスとするとサブネットがどのAZにあるかによってTransit Gateway経由通信の挙動に違いが出てしまうのでDirect Connectの代替と見なし難い、など。 そんな時、AWS Site-to-Site VPNでVPC同士つなげればよいのでは？と考えつくわけです。実はAWSのオンラインセミナーにオンプレミスとのVPN接続を行うハンズオンがあり、疑似オンプレミス環境としてVPCを使うようになっています。 https://pages.awscloud.com/JAPAN-event-OE-Hands-on-for-Beginners-Network2-2022-reg-event.html?trk=aws_introduction_page これをそのまま真似ればよいのでは？と思うところですが、疑似オンプレミス環境ではマーケットプレイスのvyosテンプレートを使うようになっており、フリートライアルの後はvyosのライセンス料も発生します。（※） ※素直にvyosのライセンス料払え、という話はありますが… そこでとにかく簡単に・安価にSite-to-Site VPN環境を構築するということで、二つのVPCをAWS標準のAWS Site-to-Site VPN機能を使って接続してみます。（※） ※本稿は、正確には、Transit GatewayとVPCをAWS Site-to-Site VPNで接続する記事になっています。 なお、私の目指すところが、AWS Transit Gatewayの向こう側にあるVPC以外のネットワークと通信できること、であったため、VPNのパラメータや経路冗長化は考慮しておらず、ただ通信できることだけを目標とした記事構成になっています。 アーキテクチャ図 今回構築する構成は下図の通りです。 Site-to-Site VPN以外は構築済みという前提で進めます。 AWS Transit Gateway側VPN設定 管理コンソールより、「VPC」-「Transit Gatewayアタッチメント」から「Transit Gatewayアタッチメントを作成」をクリックし、以下の通り設定します。 アタッチメントタイプ「VPN」を選択します。 カスタマーゲートウェイは、VPNの相手側のグローバルIPです。現時点では決まっていないため、適当に1.1.1.1としておきます。 ルーティングはスタティックで構成するのでBGP ASNは適当で構いません。ルーティングオプションは静的を選択します。 トンネルのオプションは、指定しなければ自動生成されるので空欄のままとします。 作成後、管理コンソールより、「VPC」-「Site-to-Site VPN接続」に移動、VPN接続一覧に新しくVPN接続が作成されているので、そのVPN IDをクリックし、詳細を表示します。 トンネルの状態を確認し、Tunnel 1の外部IPアドレスと内部IPv4 CIDRをメモしておきます。 「設定をダウンロードする」をクリックし、相手側VPNルータのサンプルコンフィグをダウンロードします。必要なのは事前共有キーだけなので、ベンダー等は何を選んでも構いません。 私は以下のようにしました。 ダウンロードしたテキストファイルを開き、事前共有キーを発見してメモしておきます。 VPC(疑似オンプレミス)側VPN設定 管理コンソールより、「VPC」-「Site-to-Site VPN接続」から「VPN接続を作成する」をクリックし、以下の通り設定します。 ターゲットゲートウェイのタイプは「仮想プライベートゲートウェイ」を選択し、適切な仮想プライベートゲートウェイを選択します。 カスタマーゲートウェイは「新規」、IPアドレスに先ほどメモしたTunnel 1の外部IPアドレスを入力します。 ルーティングはスタティックで構成するのでBGP ASNは適当で構いません。ルーティングオプションは静的を選択します。 ローカル IPv4 ネットワーク CIDRに、Transit Gateway側ネットワークのCIDRを入力します。 トンネル 1 の内部 IPv4 CIDR、トンネル 1 の事前共有キーに先ほどメモした値を入力します。 VPN接続を作成したら、先ほどと同様、作成したVPN接続の詳細を確認し、Tunnel 1の外部IPアドレスをメモしておいてください。 AWS Transit Gateway側VPNの設定変更 続いて、VPC(疑似オンプレミス)側VPNの外部IPアドレス情報を反映するため、Transit Gateway側VPNの設定を変更していきます。 管理コンソールより、「VPC」-「カスタマーゲートウェイ」から「カスタマーゲートウェイを作成」をクリックします。 IPアドレスに疑似オンプレミス側VPC接続の作成時にメモしたTunnel 1の外部IPアドレスを入力し、カスタマーゲートウェイを作成します。 次に、Transit Gateway側VPN接続のカスタマーゲートウェイを今作成したものに置き換えます。管理コンソールより、「VPC」-「Site-to-Site VPN接続」からTransit Gateway側のVPN接続を選択し、「アクション」-「VPN接続を変更」をクリックします。 ターゲットカスタマーゲートウェイに今作成したカスタマーゲートウェイを指定して変更を保存をクリックします。 最後に、AWS Site-to-Site VPNはデフォルトではVPN接続を受け付ける側として動作するようになっており、このままでは接続が開始しないので、一方をVPNを開始する側として設定します。 管理コンソールより、「VPC」-「Site-to-Site VPN接続」からTransit Gateway側のVPN接続を選択し、「アクション」-「VPN トンネルオプションを変更」をクリックします。 VPN トンネル外部 IP アドレスのところでTransit Gateway側VPNのTunnel1側IPアドレスを選択すると、IPSecオプション設定が表示されるので、スタートアップアクションを開始に変更します。 トンネルステータスの確認 以上でトンネルがアップするはずですのでステータスを確認してみます。 Transit Gateway側Site-to-Site接続のトンネルの詳細をチェックし、Tunnel1のステータスがアップになっていればOKです。 経路設定～疎通確認 Transit GatewayおよびVPCサブネットのルートテーブルで、疑似オンプレミスへの経路が適切に設定されていることを確認します。また、疑似オンプレミスサブネットのルートテーブルで、Transit Gateway側への経路が適切に設定されていることを確認します。 以上で設定完了です。疎通確認を行い、疎通出来たら環境構築完了です！ まとめ オンプレミス想定のネットワークをAWS Transit GatewayやVPCに接続して検証したい、でもVPNルータやAWS Direct Connectを手配するほどでもない、しかしながらVPC Peeringなどで代用するのはオンプレミスの再現として適切か不安がある、というケースはどのくらいあるのでしょうね……私は頻繁にあるのでこのような記事を執筆するに至ったのですが、需要はあまりないのだろうか……と思いつつ、どなたかのお役に立てれば幸いです。
こんにちは、SCSKでAWSの内製化支援『 テクニカルエスコートサービス 』を担当している貝塚です。 AWS Client VPNの環境を構築する機会がありました。いろいろ試していてそんなに難しいところはないなと思ったのですが、ちょっと注意した方がよいなと感じたことが2点ほどありましたので、それを書き残しておきます。 クライアント証明書失効リスト(CRL)の有効期限が切れるとAWS Client VPNに接続できなくなる クライアント証明書を使用した相互認証を採用している場合に該当します。 証明書失効リスト(CRL)には、クライアント証明書等と同様に有効期限が設定されています。AWS Client VPNエンドポイントにインポートしたCRLの有効期限が切れると、クライアントVPNに一切接続できなくなります。 恥ずかしながら勉強不足でCRLに有効期限があることを意識できておらず、運用に入ってから冷や汗をかきました。実はAWSのドキュメントにも書いてありましたが、見出しと内容が一致していないのでやや見落としがちです……と言い訳。 Troubleshooting AWS Client VPN: Client software returns a TLS error when trying to connect to Client VPN - AWS Client VPN This information helps troubleshoot a Client VPN issue around a TLS error. docs.aws.amazon.com CloudWatchのメトリクスCrlDaysToExpiryでCRL有効期限までの日数を取得できるので、CloudWatchアラームで監視するようにしましょう。 Receive notification before the CRL for Client VPN expires I want to receive a notification that the CRL (Certificate Revocation List), that’s associated with the AWS Client VPN e... repost.aws ユーザー接続ごとの帯域制限は10Mbps……ではない 次は、ちゃんとトラブルシューティングのセクションも目を通さないとだめだな……と思って心を入れ替えてドキュメントを読んだが故のどっきりです。 Troubleshooting AWS Client VPN: Verify the bandwidth limit for a Client VPN endpoint - AWS Client VPN This information helps you check the bandwidth limit for a Client VPN endpoint. docs.aws.amazon.com 「ユーザー接続ごとに 10 Mbps の帯域幅制限があります。」と書かれており、やばっ、顧客の要件にあわないものを提案してしまったか！？と焦りました。 こちらは、ベストプラクティスの項に別の記述がありました。 Rules and best practices for using AWS Client VPN - AWS Client VPN Learn specific rules and best practices for using Client VPN. docs.aws.amazon.com 「ユーザー接続ごとに 10 Mbps の最小帯域幅がサポートされています。」 どちらが正しいのかiperf3を使って検証してみたところ200Mbpsほど出ており、これは私の使用していたインターネット環境の限界速度でしたので、1ユーザ接続だけであればこれ以上は出ると考えてよさそうです。 まとめ 以上、AWS Client VPNに関する小ネタ2点でした。 ドキュメントをちゃんと読むの、重要ですね。見落としなく読むのはなかなか大変ですが、ベストプラクティスやFAQについては一通り目を通すことを心掛けたいです。
管理者
