こんにちは、SCSKの齋藤です。 今回は、Google Cloud Monitoring を活用してログ監視を実装してみました。Terraformを使用して、Cloud WorkflowsやDataformなどのログを監視し、SlackやPagerDutyに通知を送る仕組みを構築しました。 本記事では、その実装内容を紹介します。 この記事でわかること TerraformでGoogle Cloud Monitoringのアラートポリシーを定義する方法 ログ監視の条件設定、通知先設定、環境ごとの設定の違い 具体的な監視項目の設定例（Cloud Run, Composer） 設定のポイントと工夫 実装の概要 Google Cloud MonitoringのアラートポリシーをTerraformで定義し、以下のようなログ監視を実装しました。 特定のサービスの成功/失敗ログ監視 Cloud WorkflowsやCloud Run、Dataformなどの処理結果を監視し、成功や失敗を検知 データ処理パイプラインの状態監視 Composer（Airflow）のDAG実行結果を監視し、成功時に通知 通知先としてSlackやPagerDutyを活用 環境ごとに異なる通知先を設定し、本番環境ではPagerDutyを利用   実装のポイント Terraformでのアラートポリシー定義 Terraformの google_monitoring_alert_policy リソースを使って、ログ監視の条件や通知先を定義します。重要な属性は以下の通りです。 display_name : アラートポリシーの名前（Google Cloud Consoleに表示） combiner : 複数の条件をどのように組み合わせるか conditions : 監視する条件を定義するブロック enabled : アラートポリシーを有効にするかどうか alert_strategy : アラートがトリガーされた際の挙動を設定 notification_channels : 通知先チャネルのリスト documentation : アラート発生時に表示するドキュメント 以下は、テンプレートとして再利用可能なアラートポリシーの例です。この例では、特定のリソースタイプのログから、特定のパターンに合致するログを検知します。 resource "google_monitoring_alert_policy" "example_alert_policy" { display_name = "Service - Example Alert" combiner = "OR" conditions { display_name = "Example Condition" condition_matched_log { filter = <<EOT severity=INFO resource.type="example_resource_type" log_name="projects/example-project/logs/example-log" resource.labels.example_label =~ "example-pattern" EOT label_extractors = { key1 = "EXTRACT(jsonPayload.key1)" key2 = "EXTRACT(jsonPayload.key2)" } } } enabled = true alert_strategy { notification_prompts = ["OPENED"] notification_rate_limit { period = "300s" # 通知の頻度を制限 } auto_close = "1800s" # 自動クローズの時間 } notification_channels = [var.notification_channels["example_channel"]] documentation { content = <<EOT Key1: $${log.extracted_label.key1} Key2: $${log.extracted_label.key2} EOT mime_type = "text/markdown" } } コード解説: filter : Cloud Monitoringのログフィルタを指定します。このフィルタによって、監視対象のログを絞り込みます。 severity=INFO : INFOレベル以上のログを対象とする。 resource.type="example_resource_type" : 特定のリソースタイプ（例:  gce_instance ）のログを対象とする。 log_name="projects/example-project/logs/example-log" : 特定のログ名（例:  projects/my-project/logs/stdout ）を対象とする。 resource.labels.example_label =~ "example-pattern" : リソースのラベルに対して正規表現でマッチングを行う。 label_extractors : ログの内容から特定の情報を抽出します。抽出した情報は、通知内容に含めることができます。 key1 = "EXTRACT(jsonPayload.key1)" :  jsonPayload の key1 というフィールドの値を抽出する。 notification_rate_limit : アラート通知の頻度を制限します。過剰な通知を防ぐために重要です。 documentation : アラート発生時に表示されるドキュメントを記述します。抽出したログの情報を記載することで、問題の原因特定に役立ちます。 通知先の設定 通知先としてSlackやPagerDutyを利用しました。これはTerraformの変数として定義し、環境ごとの柔軟に切り替え可能にしています。 variable "notification_channels" { description = "通知チャネルのマッピング" type = map(string) } ポイント: type = map(string) : 文字列型のキーと文字列型の値を持つマップとして定義します。 default : デフォルトの値を設定します。実際の環境に合わせて適切な値を設定してください。 これらのIDは、Google Cloud Consoleから取得できます。 環境ごとの柔軟な設定  環境（開発、ステージング、本番）ごとに異なる設定を適用するため、var.envを使用しました。 本番環境ではPagerDuty通知を追加しています。 notification_channels = concat( [var.notification_channels["example_channel"]], var.env == "prod" ? [var.notification_channels["pagerduty_channel"]] : [] ) コード解説: concat : 複数のリストを結合する関数です。 var.env == "prod" ? [var.notification_channels["pagerduty_channel"]] : [] :  var.env が prod （本番環境）の場合、PagerDutyの通知チャネルをリストに追加します。それ以外の場合は、空のリスト（ [] ）を追加します。   実装した監視項目の例 Cloud Runジョブのエラーログ監視 特定のジョブのエラーを検知し、通知を行う設定 resource "google_monitoring_alert_policy" "job_error_alert" { display_name = "Job - Error Detected" combiner = "OR" conditions { display_name = "Job Error" condition_matched_log { filter = <<EOT severity>=ERROR resource.type="job_resource_type" resource.labels.job_name =~ "example-job-pattern" EOT label_extractors = { error_message = "EXTRACT(jsonPayload.error_message)" } } } enabled = true notification_channels = [var.notification_channels["error_channel"]] documentation { content = <<EOT Job Name: $${resource.labels.job_name} Error Message: $${log.extracted_label.error_message} EOT mime_type = "text/markdown" } } Composer DAGの成功通知 AirflowのDAG実行結果を監視し、成功時に通知を行う設定 resource "google_monitoring_alert_policy" "dag_success_alert" { display_name = "Composer - DAG Success" combiner = "OR" conditions { display_name = "DAG Success" condition_matched_log { filter = <<EOT resource.type="cloud_composer_environment" resource.labels.environment_name="example-composer-env" textPayload:("DagRun Finished" AND "state=success") EOT } } enabled = true notification_channels = [var.notification_channels["info_channel"]] documentation { content = <<EOT DAG実行が成功しました。 EOT mime_type = "text/markdown" } } ポイント: Cloud Runジョブのエラーログ監視では、 severity>=ERROR でエラーレベルのログを絞り込み、 resource.type="cloud_run_job" でCloud Runジョブのログに限定しています。 Composer DAGの成功通知では、 textPayload:("DagRun Finished" AND "state=success") でログメッセージの内容を確認し、DAGの成功を判断しています。   実装の工夫 再利用性の高いテンプレート設計 環境変数や通知チャンネルを 変数化 することで、異なるプロジェクトや環境でも簡単に適用可能な構成に 詳細なログ情報の抽出 `label_extractors` を活用し、ログから必要な情報を抽出して通知内容に反映 通知の頻度制限 `notification_rate_limit` を設定し、通知が過剰にならないように制御   参考ドキュメント 以下の公式ドキュメントを参考にしました。TerraformやGoogle Cloud Monitoringの設定に役立つ情報が記載されています。 Terraform関連 Terraform Google Provider Documentation https://registry.terraform.io/providers/hashicorp/google/latest/docs Google CloudリソースをTerraformで管理するための公式ドキュメントです。 Terraform Configuration Language https://developer.hashicorp.com/terraform/language Terraformの基本的な構文や変数の使い方、モジュールの作成方法などが記載されています。 Google Cloud Monitoring関連 Google Cloud Monitoring Documentation https://cloud.google.com/monitoring/docs Google Cloud Monitoringの概要やアラートポリシーの設定方法、通知チャネルの作成方法などが記載されています。 Log-based Metrics https://cloud.google.com/logging/docs/logs-based-metrics ログベースのメトリクスを作成する方法についてのドキュメントです。   まとめ Terraformを使用することで、Google Cloud Monitoringのログ監視を効率的に構築できます。テンプレート化により、他のプロジェクトや環境にも容易に適用でき、運用コストを削減できます。 今後は、さらに監視項目を増やし、Custom MetricsやLog-based Metricsを活用して、システム全体の可観測性を向上させていきたいと考えています。 この記事が、皆様のログ監視実装の一助となれば幸いです。

SCSK永見です。 AI関連のサービスはいまや当たり前になってきていて、活用すれば生産性向上に大きく寄与できます。 一方で心配なのがセキュリティ。万が一入力した情報に機密情報が含まれていて、AIサービス提供者の学習データとして使われては困ります。 AWSにそれをしないよう、明示的に制限するための「AI サービスのオプトアウト」の設定をご紹介します。 前提事項 この機能はAWS Organizationsの機能を使います。 そのため、AWS Organizationsのすべての機能が有効になっていることを前提としています。 AI サービスのオプトアウト設定方法 管理アカウントへサインインします。 左上のプルダウン→組織 から、AWS Organizationsのコンソールへ遷移します。 左側「ポリシー」から「AI サービスのオプトアウトポリシー」を選択します。 AIサービスのオプトアウトポリシーを有効にする をクリックします。 有効になった旨のメッセージを確認し、「すべてのサービスからオプトアウト」をクリックします。 ポップアップが出てくるので、「すべてのサービスからオプトアウト」をクリックします。 「OptOutFromAllAIService」のポリシーが作成され、Root OUにアタッチされていることがわかります。   AIサービスのオプトアウトポリシー構文 さて、本当にこれの作業だけでよいのでしょうか。 それを確認するために、作成された「OptOutFromAllAIService」のポリシーを読み解いてみましょう。 { "services": { "@@operators_allowed_for_child_policies": [ "@@none" ], "default": { "@@operators_allowed_for_child_policies": [ "@@none" ], "opt_out_policy": { "@@operators_allowed_for_child_policies": [ "@@none" ], "@@assign": "optOut" } } } } 他のポリシーでも使われている管理ポリシー構文と似たようなものですが、初めて見る人はよくわからないですね。 正しく理解するために、AIサービスのオプトアウトポリシーがどのように構造化されているか を理解してみましょう。 AIサービスのオプトアウトポリシーを図に起こすと、このような構造になっています。 servicesの下に、 各service が指定でき、それぞれのserviceに対して オプトアウトする/しない の設定、および 子ポリシーによる変更可否 の設定をする という構造になっています。 各service ここでは どのサービスに対するオプトアウトの設定をする か、を指定します。 サービス名を指定する値として、「q」「cloudwatch」「guardduty」「quicksightq」などを指定できます。 最新情報は以下を参照ください。 AI サービスのオプトアウトポリシーの構文と例 - AWS Organizations ポリシーの例を分析しながら、AI サービスのオプトアウトポリシーを詳しく確認します。 docs.aws.amazon.com このうち、 default というのは特殊な値で、現在利用可能なすべての AI サービスを表します。今後将来追加される AI サービスも自動的に含まれます。 あらゆるサービスの情報も拒否したい！という場合はdefaultを使うとよいでしょう。 オプトアウトする/しない ここではAWSによる AIデータ収集を許可するかしないか を設定します。 許可する場合は@@assignのキーに対してoptIn、許可しない場合は@@assignのキーに対してoptOutを指定します。 子ポリシーによる変更可否 子ポリシーとは、「そのポリシーがアタッチされたOUに含まれるOU/AWSアカウントにアタッチされたポリシー」だと理解してください。 ここでは 子ポリシーによる、各サービスに対するオプトアウト有無の上書きを許可するかどうか を指定します。 許可する場合は@@operators_allowed_for_child_policiesキーに対して[“@@assign”]を、許可しない場合は[“@@none”]を指定します。これは必須ではなく、記載しないと@@assign、つまり子ポリシーによる上書きを許可する状態になります。 OptOutFromAllAIServiceを読み解く さて、ここまでの理解を踏まえたうえでOptOutFromAllAIServiceを図に起こすと下記のようになります。 日本語にすると「 あらゆるAIサービス(default)に対してAIデータ収集を許可せず(@@assign : “optOut”)、それを子ポリシーによる上書きを許可しない(“@@operators_allowed_for_child_policies”: [“@@none”]) 」 となります。 これがRoot OU、つまり最上位にアタッチされているので、「すべてのサービスからオプトアウト」できるわけですね。 どんなAIサービスが対象なの？ AIを使った機能があり、かつオプトアウトポリシーでサポートされているサービス名が対象です。 王道のAmazon Qはもちろんのこと、Query generatorの機能が組み込まれているCloudwatchなども対象です。 Amazon CloudWatchでAIを活用した自然言語クエリ生成を試してみた Amazon CloudWatchでAIを活用した自然言語クエリ生成を試してみました。CloudWatch Logs InsightsとCloudWatch Metrics Insightsにて実際に自然言語でクエリ生成を行っています。 blog.usize-tech.com 2024.08.24 オプトアウトポリシーでサポートされているサービスは、公式ドキュメントを参照ください。 サポートされているすべての AWS AI サービスからオプトアウトする - AWS Organizations すべての AI サービスからオプトアウトする方法について説明します。 docs.aws.amazon.com オプトアウト前のデータはどうなるの？ オプトアウト前のデータも含めすべて削除されます。ただし、削除されるのはAWSがサービス向上のために使うデータであって、AWSのサービスを利用するために使うデータは削除されません。 AI サービスのオプトアウトポリシー - AWS Organizations AI サービスのオプトアウトポリシーを使用して、組織内のすべてのアカウントの AWS AI サービスのデータ収集を制御します。 docs.aws.amazon.com まとめ AIサービスに対するセキュリティ設定として、AI サービスのオプトアウト設定方法とその内容を解説しました。 利便性と機密性を兼ね備えたAWSのAIサービス、ガンガン活用しましょう！

AWS CDKを使ってEC2インスタンスを構築する際、SSH接続用のKeyPair（キーペア）の指定・管理は避けて通れません。 今回は、CDKでよく使われる3つのKeyPair指定方法を、実際のTypeScriptコード例とともに解説していきたいと思います！ KeyPairとは？ KeyPairは、EC2インスタンスへSSHログインするための「公開鍵・秘密鍵ペア」です。AWSではKeyPairを事前に作成し、インスタンス起動時に指定することで、セキュアなアクセスを実現します。 やってみよう 1. 既存KeyPairのimport すでにAWS上に作成済みのKeyPairをCDKで利用する場合は、fromKeyPairNameを使います。 メリット ：既存運用との親和性が高く、最も一般的な方法です。 class KeyPair (construct) · AWS CDK   // 1. 既存KeyPairのimport   // すでにAWS上に存在するKeyPair名('my-keypair')をCDKでインポートして利用   const importedKeyPair = ec2.KeyPair.fromKeyPairName(this, 'ImportedKeyPair', 'my-keypair');   new ec2.Instance(this, 'InstanceWithImportedKeyPair', {     vpc: vpc,     instanceType: ec2.InstanceType.of(ec2.InstanceClass.T3, ec2.InstanceSize.MICRO),     machineImage: ec2.MachineImage.latestAmazonLinux2(),     keyName: importedKeyPair.keyPairName,     }); 2. keyNameを直指定 KeyPair名を直接文字列で指定する方法です。 メリット ：シンプルで分かりやすいですが、KeyPairの存在チェックはCDK側で行われません。 この方法でデプロイすると次のメジャーバージョンで無くなるので1の方法に置き換えるよう警告が出ます。 なので、この方法は非推奨の実装となります。 class Instance (construct) · AWS CDK [WARNING] aws-cdk-lib.aws_ec2.InstanceProps#keyName is deprecated.   - Use `keyPair` instead - https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_ec2-readme.html#using-an-existing-ec2-key-pair   // 2. keyNameを直指定   // EC2インスタンス作成時にKeyPair名('my-keypair')を直接指定   new ec2.Instance(this, 'InstanceWithDirectKeyName', {     vpc: vpc,     instanceType: ec2.InstanceType.of(ec2.InstanceClass.T3, ec2.InstanceSize.MICRO),     machineImage: ec2.MachineImage.latestAmazonLinux2(),     keyName: 'my-keypair',     }); 3. CfnKeyPairで新規作成＆パラメータストア連携 CDKのL1コンストラクトのec2.CfnKeyPairを使うと、CloudFormation経由でKeyPairを新規作成できます。 注意点：CfnKeyPairで作成したKeyPairは秘密鍵が取得できません。AWSの仕様上、公開鍵のみがAWSに登録され、秘密鍵は生成・保存されません。そのため、SSH接続には利用できず、CI/CDの署名や一時的な検証用途など、秘密鍵が不要なケース向けです。 ですが、KeyPair名はパラメータストア（SSM）やSecretsManagerに保存しておくと、他リソースや運用時に参照しやすくなります。今回はパラメータストアでの実装を下記例として記述します。 class CfnKeyPair (construct) · AWS CDK   // 3. CfnKeyPairでCloudFormationリソース作成し、パラメータストアに保存   // CloudFormationで新規KeyPair('cfn-keypair')を作成   const cfnKeyPair = new ec2.CfnKeyPair(this, 'CfnKeyPair', {     keyName: 'cfn-keypair',   });   // 作成したKeyPair名をSSMパラメータストアに保存   new ssm.StringParameter(this, 'CfnKeyPairNameParameter', {     parameterName: '/ec2/keypair/cfn-keypair/name',     stringValue: cfnKeyPair.keyName as string,     });   // SSMに保存したKeyPair名を利用してEC2インスタンスを作成   new ec2.Instance(this, 'InstanceWithCfnKeyPair', {     vpc: vpc,     instanceType: ec2.InstanceType.of(ec2.InstanceClass.T3, ec2.InstanceSize.MICRO),     machineImage: ec2.MachineImage.latestAmazonLinux2(),     keyName: cfnKeyPair.keyName,     });   まとめ 既存KeyPairのimport  … 既存運用との親和性が高く、CDKでの推奨方法。 keyPair プロパティを使うことで将来的な非推奨にも対応できます。 keyName直指定 … 実装はシンプルですが、 keyName プロパティは非推奨となっており、デプロイ時に警告が出ます。存在チェックも行われません。 CfnKeyPair新規作成  … CloudFormationでKeyPairを新規作成できますが、秘密鍵は取得できません。KeyPair名はSSMパラメータストアで管理するのが推奨です。 要件や運用方針に応じて、最適なKeyPair管理方法を選択しましょう！ 以上、CDKでの実装の参考になれば幸いです。

こんにちは、SCSKの前田です。 3回目は、少しLifeKeeperに特化したリソースで使われている機能や障害について説明したいと思います。 1回目・2回目の用語説明に関しては以下のリンクからどうぞ！ HAクラスター/LifeKeeper用語説明1 – TechHarmony HAクラスター/LifeKeeper用語説明2 – TechHarmony おさらい HAクラスター製品ではアクティブ/スタンバイの構成で、アクティブ側のノードで障害を検知した場合、アクティブ側でアプリケーションの停止を行い、スタンバイ機でアプリケーションの起動を行う必要があります。 LifeKeeperとして、この一連の動作を可能にする製品が ARK になります。 ARK については、このあと説明していきたいと思います。 ARKとは？ ARK とは、Application Recovery Kits の略で、LifeKeeper が特定のアプリケーション（オープンソースソフトウェアや商用アプリケーション）を容易にリソースとして組み込むことが可能になる製品です。 ARK は、アプリケーションを操作するため、下記の4つのスクリプトで構成されています。 ・起動スクリプト(restore)・・・アプリケーションを起動させる処理 ・停止スクリプト(remove)・・・アプリケーションを停止させる処理 ・監視スクリプト(quickCheck)・・・アプリケーションの状態を監視する処理 ・再起動スクリプト(recover)・・・アプリケーションを再起動させる処理 ARK による、アプリケーションのリソースへの組み込みはウィザード形式（GUI上で設定）で作業が可能となり、ARK には、アプリケーションを操作（起動・停止・監視・再起動）するための4つのスクリプトがあらかじめ準備されているため、スクリプトを設計・作成するための開発工数の削減や人的なミスを防止することが出来ます。 また、意図的にスクリプトを変更しない限り、サポートの対象となります。 ARKを使うことで、スクリプトを作る必要が無いから、人的ミスもなく工数が削減出来るね。 ARKはサポートされているから、何か問題があった時に安心ね。 GenericARKとは？ GenericARK とは、LifeKeeper が製品として提供されている ARK が存在しないアプリケーションを操作（起動・停止・監視・再起動）するため、汎用的に利用が可能な ARK になります。 製品として提供されている ARK と違い、アプリケーションを操作（起動・停止・監視・再起動）するためのスクリプトを予め準備する必要があり、変更可能な箇所以外に修正のない汎用スクリプトを利用しない限り、スクリプトに対するサポートは受けられません。 （変更可能な箇所以外に修正のない汎用スクリプトに関してはサポート対象になります。） ただし、サポートを受けられない分、最低限の制約（正常時の戻り値「0」と、異常時の戻り値「1」）を厳守することで自由にスクリプトをカスタマイズすることが可能となります。 QSPとは？ QSP とは、Quick Service Protection の略で、Linux や Windows において、スクリプトを準備せず、OSのサービスをGUI操作で簡単に冗長化出来る ARK になります。 Linux では service コマンドで起動や停止できるサービスが対象となり、Windows では Windows サービスに登録されているサービスが対象になります。 QSP は簡単に冗長化出来る反面、quickCheck では簡易的なチェックしか行っておらず、複雑な起動や停止処理が必要なアプリケーションには対応出来ないため、GenericARK を利用する必要があります。   OS のサービスを簡易的に冗長化するには、QSP を使うのが便利だね。 複雑な起動や停止処理が必要なアプリケーションは、GenericARK があるから、使い分けが出来そうね。   restoreとは？ restore とは、LifeKeeper のリソースにおける、アプリケーションやサービスの起動するためのスクリプトになります。 restore は、LifeKeeper の GUI 管理画面からの操作であったり、LifeKeeper の perform_action コマンドでユーザが明示的にリソースの起動を行う場合や、障害の検知によって実施されるフェイルオーバー時に、移動先サーバの LifeKeeper が自動的にリソースを起動する場合にも実行されます。 removeとは？ remove とは、LifeKeeper のリソースにおける、アプリケーションやサービスの停止するためのスクリプトになります。 remove は、LifeKeeper の GUI 管理画面からの操作であったり、LifeKeeper の perform_action コマンドでユーザが明示的にリソースの停止を行う場合や、障害の検知によって実施されるフェイルオーバー時に、移動元サーバの LifeKeeper が自動的にリソースを停止する場合にも実行されます。 quickCheckとは？ quickCheck とは、LifeKeeper のリソースにおける、アプリケーションやサービスの監視を行うためのスクリプトになります。このスクリプトでは、監視対象のリソースが正常に動作していることを確認するための処理になっており、ARK によっては単純にアプリケーションやサービスが開始されているだけの確認ではなく、内部的な処理が正常に行われているかの確認も含まれます。 quickCheck は、ユーザが明示的に実施することはなく、リソースが起動しているサーバで LifeKeeper が決められた間隔で自動的に実行されています。実行したけ結果、戻り値が0であれば正常で、戻り値が1であれば異常と判断されます。 なお、この処理(スクリプト)はオプションとなっており、監視が必要のないリソース(アプリケーション等)に関しては利用しないことも可能になっています。 ただし、復旧処理(リカバリ処理)が必要な場合、quickCheck は必須なスクリプトになります。 recoverとは？ recover とは、LifeKeeper のリソースにおける、アプリケーションやサービスの復旧処理(リカバリ処理)を行うためのスクリプトになります。 recover は、quickCheck と同様にユーザが明示的に実施することはなく、リソースの監視処理(quickCheck)によって、リソースが異常と判断された場合に LifeKeeper がリソースの稼働サーバで1度だけ復旧処理が実行されます。このスクリプトでリソースの復旧に失敗した場合、フェイルオーバーが行われます。 なお、この処理(スクリプト)もオプションとなっており、復旧処理(リカバリ処理)が必要のないリソース(アプリケーション等)に関しては利用しないことも可能になっています。 その場合、監視処理(quickCheck)で異常と判断された場合、即座にフェイルオーバーが行われることなります。 ノード障害とは？ LifeKeeper としてのノード障害とは、ハードウェアの故障やソフトウェアの問題など、様々な原因によって障害が発生し、ノード間でハートビートとしての通信が一定間隔で確認が出来ない状態になったことを表します。 障害の種類としては、ハードウェア障害となるノードのCPU、メモリ、ディスクなど物理的な故障、ソフトウェア障害となるOSやアプリケーションの不具合、ネットワーク障害となる物理的なケーブルの断線やルータの故障などがあります。 この状態になった場合、LifeKeeper としてはフェイルオーバーの処理が開始されます。 リソース障害とは？ リソース障害とは、LifeKeeper として監視対象となっているリソースの監視処理(quickCheck)によってリソースが異常と判断された状態、または復旧処理(recover)によってリソースの復旧に失敗した状態のことを表します。 リソースが異常と判断される条件としては、冗長化(リソース)対象のサービスが停止されること、ARK によってはサービスが起動されていてもサービスの動作として正常な結果を応答出来ない状態も異常と判断されることもあります。 この状態になった場合も、LifeKeeper としてはフェイルオーバーの処理が開始されます。 まとめ 今回はLifeKeeperのリソースで使われている機能や障害の用語について説明して来ましたが、いかがでしたでしょうか？ 少しでもLifeKeeperを身近に感じて頂けたら幸いです。 次回はLifeKeeperのリソースで使われている機能や障害について説明したいと思いますので、お楽しみに！ 詳しい内容をお知りになりたいかたは、以下のバナーからSCSK LifeKeeper公式サイトまで

こんにちは。SCSKの山口です。 今回は、Google Cloud認定資格の受験レポート その①です。 はじめに 先日、Google Cloudの認定資格として、下記の認定資格が追加されました。 ・ Generative AI Leader 最近立て続けに認定資格が増えていますが、ついに生成AI関連の資格が追加されました。 せっかく受験するので、今回も [受験前] ・対策内容 ・抑えておく要点 [受験後] ・合否 ・出題内容（受験前の想定とのギャップ） ・抑えておいた方が良い要点 をブログとして残そうと思います。 本ブログ執筆時点の筆者はこんな感じです。 Google Cloud歴 3年目 BigQuery一番よく触っている Professional Machine Learning Engineer取得済み 最新のTOEICスコア：645（※試験が英語版しかないので書きました。）   対策内容 ここでは、受験前に実際に取り組んだ対策の内容を書きます。 とりあえず試験ガイドを見てみる 今回も、まずは試験ガイドを見ます。 試験ガイドは、認定資格ページにリンクが貼ってあります。 https://services.google.com/fh/files/misc/v1.0_associate_data_practitioner_exam_guide_english.pdf?hl=ja 英語があまり堪能ではないので、今回もPDFをダウンロードして「 NotebookLM 」にアップして日本語で読みました。   ①生成AIの基本（30％） このセクションでは、下記に焦点が当てられています。 タイトル キーワード 生成AIの主要な概念 自然言語処理 機械学習 基盤モデル マルチモーダル プロンプトエンジニアリング 大規模言語モデル 機械学習のアプローチ・ライフサイクル 教師あり学習 教師なし学習 強化学習 データ取り込み データ準備 モデルトレーニング モデルデプロイ モデル管理 ビジネスユースに適切な基盤モデル Gemini Gemma Imagen Veo データ形式 構造化データ 非構造化データ ラベル付きデータ ラベルなしデータ 生成AIランドスケープの主要なレイヤー インフラストラクチャ モデル プラットフォーム エージェント アプリケーション この辺りが問われるそうです。 「生成AIの基本」というセクションタイトルなだけあって、このセクションにほとんどの主要要素が詰め込まれているんじゃないかと感じます。   ②Google Cloudの生成AI製品（35％） セクション①では主にAI関連の基礎知識に焦点が当てられていますが、ここから「Google」特有の内容が問われます。おそらく本試験のメインはここだと（個人的に）思っています。 タイトル キーワード Googleの「AIファースト」アプローチ エンタープライズ向けAIプラットフォーム 包括的なAIエコシステム 責任あるAI 安全なAI プライベートなAI 信頼性の高いAI スケーラブルなAI 生成AI製品の機能、ユースケース、ビジネス価値 Geminiアプリ Gemini Advanced Agentspace Gemini for Google Workspace 開発者がAIを活用して構築するためのGoogle Cloudツール Vertex AI  Google CloudのRAG製品 Agent Builder エージェントが外部環境と対話し、タスクを達成するために使用するツール 拡張機能 関数 データストア プラグイン この辺りが問われるそうです。 「Agentspace」がやはり試験内容に入ってきていますね。Agentspaceは弊社で検証した内容をブログでご紹介しているのでぜひご覧ください。 【Google Cloud】Agentspaceについてご存じですか？①「概要編」 Google Agentspace について調査し、実際に触ってみましたので、その魅力についてご紹介させていただければと思います。 blog.usize-tech.com 2025.04.10     ③生成AIモデルの出力を改善する技術 (20%) 生成AIを有効に使うための技術要素について問われるセクションです。 タイトル キーワード 基盤モデルの一般的な制限に対するGoogle推奨の対処法 グラウンディング RAG プロンプトエンジニアリング ファインチューニング ヒューマンインザループ（HITL） プロンプトエンジニアリング ゼロショットプロンプティング ワンショットプロンプティング フューショットプロンプティング ロールプロンプト プロンプトチューニング 思考の連鎖（Chain of Thought：CoT）プロンプティング ReActプロンプティング グラウンディングの概念とユースケース モデルの振舞いを制御するパラメータ トークン数 温度（temperature） top-p 安全設計 この辺りが問われるそうです。     ④生成AIソリューションのためのビジネス戦略（15％） ここまでのセクションでは主に技術面に焦点が当てられていましたが、このセクションでは「ビジネス目線」の要素が問われます。 タイトル キーワード Google Cloud推奨の生成AIソリューション実装手順 – セキュアAI Secure AI Framework（SAIF） Google Cloudのセキュリティツール IAM Secure Command Center 責任あるAI プライバシー データ品質 バイアス 公平性 説明可能性 アカウンタビリティ この辺りが問われるそうです。 とりあえず模擬試験を受けてみる 模擬試験は、認定資格ページにリンクが貼ってあります。 Generative AI Leader  |  Google Cloud A Generative AI Leader is a visionary professional with comprehensive knowledge of how generative AI (gen AI) can transf... cloud.google.com 試験の詳細な内容はここには載せませんが、正解率は19/25でした。 今回も英語の試験なので、ちょっと難しく感じます。 ここまでの内容をふまえ、受験前に抑えておいた方が良いと思われる（実際に学習した）内容を書きます。 抑えておく知識 試験ガイドと模擬試験の内容を加味し、試験前にこれだけは押さえておこうと思っている技術ワードの 概要 特徴 ユースケース をまとめます。それぞれの英語名も書いておきます。 機械学習の基礎概念 Generative AIもまた、機械学習の一分野です。まずは、その土台となる学習手法の基礎を理解しましょう。 教師あり学習 (Supervised Learning) 概要: 正解データ（ラベル）が与えられたデータセットを用いてモデルを訓練する学習手法です。入力データとそれに対応する出力データのペアを学習し、未知の入力に対して正しい出力を予測可能。 特徴: 明確な目的変数（ターゲット）が存在する。 高品質なラベル付きデータが不可欠。 分類（Classification）と回帰（Regression）が主なタスク。 ユースケース: 画像認識: 写真に写っているものが何かを識別（例：猫か犬か）。 スパムメール検出: メールがスパムかどうかを分類。 株価予測: 過去のデータから将来の株価を予測。 教師なし学習 (Unsupervised Learning) 概要: 正解データ（ラベル）が与えられていないデータセットから、データの潜在的なパターンや構造を自動的に発見する学習手法。 特徴: ラベル付けの手間が不要。 データの隠れた関係性や類似性を発見するのに適している。 クラスタリング（Clustering）と次元削減（Dimensionality Reduction）が主なタスク。 ユースケース: 顧客セグメンテーション: 購買履歴などから顧客をグループ分けし、マーケティング戦略に活用。 異常検知: 通常とは異なるデータパターンを検出し、不正行為や故障の兆候を把握。 推薦システム: ユーザーの行動履歴から類似する商品やコンテンツを推薦。 深層学習 (Deep Learning) 概要: ニューラルネットワークを多層に重ねた「深層（ディープ）ニューラルネットワーク」を用いる機械学習の一種。画像、音声、テキストなどの複雑なデータから、自動的に特徴量を学習する。Generative AIの多くはこの深層学習を基盤としている。 特徴: 非線形な関係性を表現する能力が高い。 大量のデータと高い計算能力を必要とする。 画像認識、自然言語処理、音声認識などで活用。 ユースケース: 画像生成: 存在しないリアルな顔写真や風景画を生成。 自然言語理解と生成: テキストの要約、翻訳、文章生成。 音声認識: 人間の音声をテキストに変換。 強化学習 (Reinforcement Learning) 概要: エージェントが環境の中で行動し、その結果として得られる報酬を最大化するように学習する手法。試行錯誤を繰り返しながら最適な行動戦略を習得する。 特徴: 正解ラベルではなく、報酬に基づいて学習する。 動的な環境下での意思決定に適している。 シミュレーション環境での訓練が一般的。 ユースケース: ロボット制御: ロボットが複雑なタスク（例：物の把持、歩行）を自律的に学習。 ゲームAI: プロのプレイヤーを凌駕するゲーム戦略を学習。 資源管理: 限られた資源を効率的に配分する戦略を学習。 Generative AIの応用とカスタマイズ Generative AIを最大限に活用するためには、基盤モデルを特定の目的に合わせて調整したり、より高度な制御を行うための技術が重要です。 ファインチューニング (Fine-tuning) 概要: 事前学習済みの（Pre-trained）大規模モデルを、特定のタスクやデータセットに合わせてさらに学習させるプロセス。モデルの重みを微調整することで、特定の用途に特化した性能向上を図る。 特徴: ゼロからモデルを学習させるよりも効率的。 少ないデータ量でも効果が得られやすい。 モデルの汎用性を維持しつつ、専門性を高める。 ユースケース: 特定分野のテキスト生成: 医療や法律など、専門用語を含むテキストを生成。 企業のスタイルに合わせた文章生成: 企業独自のトーン＆マナーを反映した文章を生成。 特定の画像スタイルの生成: 特定のアーティストの画風に似た画像を生成。 プロンプトエンジニアリング (Prompt Engineering) 概要: 大規模言語モデル（LLM）に対して、目的の出力を引き出すための効果的な入力（プロンプト）を設計する技術。モデルの挙動を誘導し、より正確で関連性の高い応答を得ることを目指す。 特徴: コードを書かずにAIの出力を制御可能。 モデルの性能を最大限に引き出すための重要なスキル。 明確性、具体性、文脈、役割付与などが考慮される。 ユースケース: 特定の形式での出力指示: 「箇条書きでまとめてください」「JSON形式で出力してください」。 役割付与による行動誘導: 「あなたは経験豊富なマーケティング担当者です。この製品のキャッチコピーを考えてください」。 思考の連鎖 (Chain-of-Thought) プロンプティング: 段階的な思考プロセスを促し、複雑な問題解決を支援。 RAG (Retrieval-Augmented Generation) 概要: 大規模言語モデル（LLM）が外部の知識ベース（ドキュメント、データベースなど）から関連情報を検索（Retrieval）し、その情報に基づいて応答を生成（Generation）する手法。 特徴: モデルが学習していない最新の情報や社内情報にもアクセスできる。 ハルシネーション（Hallucination：事実に基づかない情報を生成すること）のリスクを低減。 応答の根拠となる情報源を示すことができるため、信頼性が向上。 ユースケース: 社内Q&Aシステム: 社内規定や製品マニュアルから正確な情報を引用して回答。 カスタマーサポートチャットボット: 製品データベースから最新の情報を取得して顧客の質問に回答。 研究支援: 論文データベースから関連情報を取得し、要約や考察を生成。 グラウンディング (Grounding) 概要: 生成AIモデルが生成する情報が、特定の事実（ソース）に基づいていることを保証する概念。特にハルシネーションを抑制し、信頼性のある出力を得るために重要視される。RAGはそのための具体的な手法の一つ。 特徴: AIの出力の信頼性と安全性を高める。 現実世界の知識や制約とAIの生成能力を結びつける。 誤情報や偏見の伝播を防ぐ。 ユースケース: 医療・法律分野での情報生成: 事実に基づいた正確な情報のみを生成。 ニュース記事の自動生成: 信頼できる情報源に基づいた記事を生成。 企業のレポート作成: 社内データや規定に準拠したレポートを作成。 AI運用と品質管理 ヒューマンインザループ (Human-in-the-Loop: HITL) 概要: AIシステムが完全に自動化されるのではなく、特定のプロセスにおいて人間の介入や判断を組み込む設計思想です。AIの精度向上、倫理的課題への対応、複雑なケースの処理などに活用されます。 特徴: AIの限界を補い、より高品質な結果を得る。 人間の専門知識や常識をAIの学習にフィードバックできる。 責任の所在を明確にしやすい。 ユースケース: AI生成コンテンツのレビュー: AIが作成した記事や画像を人間が最終チェックし、品質や倫理性を保証。 自動運転の緊急時介入: AIが判断できない状況で人間ドライバーが運転を代行。 カスタマーサポートにおけるAIと人間の連携: AIが一次対応し、解決できない問い合わせは人間のオペレーターにエスカレーション。   抑えておくサービス 試験ガイドと模擬試験の内容を加味し、試験前にこれだけは押さえておこうと思っているサービスの 概要 特徴 ユースケース をまとめます。 基盤モデル＆モデル開発 これらのサービスは、生成AIアプリケーションの根幹となる大規模言語モデルや、それらを開発・カスタマイズするためのツールを提供します。 Gemini 概要: Googleが開発した最先端のマルチモーダル大規模言語モデル（LLM）。テキスト、画像、音声、動画など、様々な形式の情報を理解し、生成することができます。 特徴: マルチモーダル: 複数のデータ形式を同時に処理し、相互に関連付けて理解・生成が可能。 高性能: 大量のデータで学習されており、複雑な推論、コード生成、クリエイティブなコンテンツ作成など、幅広いタスクに対応。 柔軟なサイズ: Ultra, Pro, Nanoなど、用途に応じた様々なサイズが提供され、エッジデバイスからデータセンターまで幅広い環境で利用可能。 ユースケース: 高度なチャットボットやバーチャルアシスタントの開発 コンテンツの自動生成（記事、広告コピー、脚本など） プログラミングコードの生成、デバッグ、リファクタリング 医療診断支援、科学研究におけるデータ分析 Gemma 概要: Googleが開発した軽量かつ高性能なオープンモデルファミリー。Geminiの技術をベースにしており、研究開発コミュニティや開発者が自身のアプリケーションに組み込みやすいように設計されている。 特徴: オープンモデル: 研究や商業利用において比較的自由に利用できる。 軽量: 比較的小さなリソースで実行可能で、エッジデバイスや限られた計算リソースの環境でも利用しやすい。 パフォーマンス: サイズに対して高い性能を発揮し、様々なタスクに対応。 ユースケース: 研究機関や大学でのAI研究 小規模なアプリケーションへのAI機能組み込み プライバシーに配慮したオンプレミス環境でのモデルデプロイ カスタムAIモデルのファインチューニングのベース Veo 概要: テキストプロンプトから高品質な動画を生成するAIモデル。 特徴: 高品質な動画生成: テキストの説明に基づいて、写実的で滑らかな動画を生成。 高い制御性: カメラワーク、被写体の動き、シーンの変化などを細かく指定可能。 幅広いスタイル: 様々な映像スタイルやジャンルに対応。 ユースケース: 映画、アニメーション、ゲーム制作におけるプレビズやコンセプト作成 広告、マーケティング素材の動画制作 教育コンテンツやプレゼンテーション用の動画作成 個人クリエイターによるショートビデオ制作 Imagen 概要: Googleが開発したテキストプロンプトから高品質な画像を生成するAIモデル。 特徴: 高解像度・高品質: 写実的で詳細な画像を生成。 創造性: 独創的で多様なスタイルの画像を生成可能。 テキスト理解度: 自然言語の複雑な指示を正確に解釈し、画像に反映。 ユースケース: デザイン、広告、マーケティングにおけるビジュアルコンテンツ作成 Webサイト、ブログ記事の挿絵生成 ゲームやメタバースにおけるアセット生成 個人クリエイターによるアート作品制作 アプリケーション開発＆ソリューション これらのサービスは、Generative AIモデルを活用して、具体的なアプリケーションやソリューションを開発・提供するためのプラットフォームやフレームワークです。 NotebookLM 概要: Google AIが提供する、ユーザーのドキュメントやメモを学習し、その情報に基づいて要約、Q&A作成などを行うAIツール。 特徴: パーソナルなAIアシスタント: ユーザー自身の情報源を学習するため、専門的で正確な情報を提供。 多機能: 要約、質問応答、ブレインストーミング支援、ドラフト作成など、多様なタスクに対応。 プライバシー: ユーザーのデータは保護され、モデルのトレーニングには使用されない。 ユースケース: 研究者や学生の文献管理と要約 ライターやコンテンツクリエイターのアイデア整理と記事作成支援 弁護士やコンサルタントの資料分析とレポート作成 個人の学習支援、情報整理 Gemini for Google Workspace 概要: Google Workspace（旧G Suite）の各アプリケーションにGeminiのAI機能が統合されたサービス。Gmail、Google ドキュメント、スプレッドシート、スライドなどで生成AIを活用可能。 特徴: 生産性向上: 各アプリケーション内でのコンテンツ作成、要約、分析などをAIが支援。 シームレスな統合: 既存のワークフローにAIが自然に組み込まれる。 多機能: メール作成、ドキュメントの校正、データ分析、プレゼンテーション作成など幅広いタスクに対応。 ユースケース: Gmailでのメール下書き作成、返信提案 Google ドキュメントでの記事作成、要約、校正 Google スプレッドシートでのデータ分析、数式提案 Google スライドでのプレゼンテーションの概要作成、画像提案 Agentspace 概要: Googleが提唱する、AIエージェントの設計、開発、デプロイメントを支援する概念およびツール群。複数のAIエージェントが連携し、複雑なタスクを自動化。 特徴: エージェントの連携: 複数のAIエージェントが協調して目標達成を目指す。 自律性: エージェントが自律的に判断し、行動する能力。 複雑なタスクの自動化: 従来のAIでは難しかった多段階の意思決定や行動を伴うタスクに対応。 ユースケース: 複雑な顧客対応の自動化（問い合わせ内容に応じて複数のシステムと連携） サプライチェーン管理における意思決定支援と自動化 研究開発における実験計画の自動生成と実行 パーソナルアシスタントの高度化（スケジュール管理、情報収集、予約など） Conversational Agents（会話型エージェント） 概要: 自然言語処理技術を活用し、人間と自然な会話を交わすことができるAIシステム。チャットボットや音声アシスタントとして広く活用されています。 特徴: 自然な会話体験: 人間が話すような言葉を理解し、適切に応答。 意図理解: ユーザーの意図を正確に把握し、適切な情報や行動を提供。 多言語対応: 多くの言語に対応可能。 ユースケース: カスタマーサポートの自動化（FAQ応答、予約、問い合わせ受付） 営業支援（製品情報提供、リード獲得） 社内ヘルプデスク（ITサポート、人事関連の問い合わせ対応） 教育分野での学習支援、言語学習パートナー Contact Center as a Service (CCaaS) 概要: クラウドベースのコンタクトセンターソリューション。AIを活用した自動応答、ルーティング、エージェント支援機能などを統合し、顧客対応業務を効率化・高度化。 特徴: クラウドネイティブ: インフラ管理不要でスケーラブルなサービス。 AI統合: 自然言語処理、音声認識、Generative AIを活用した自動応答、エージェント支援機能。 チャネル統合: 電話、チャット、メール、SNSなど複数のチャネルを統合管理。 分析機能: 顧客対応データの分析により、サービス品質向上や業務改善に貢献。 ユースケース: 大規模コンタクトセンターの構築と運用 顧客満足度向上を目指す企業での顧客対応プロセスの最適化 人手不足解消のための自動化推進 リモートワーク環境下でのコンタクトセンター運用   まとめ 意図せず10000文字越えの超大作になりました。 初級の資格ということなので、複雑な問題は少なく、サービス名や技術的な用語とその意味をおさえておけば突破できそうな気はします。 後は英語の問題文と戦うだけです。

こんにちは。SCSK渡辺(大)です。 今月から家庭菜園をはじめてみました。 ミニトマトを苗から、大葉を種から、育てています。 毎日食べれるようになることを夢見ています。 今回は、 AWS Organizationsを使用できない場合にマルチアカウント環境でAWS Health イベントの通知を集約する方法 を考えてみました。 AWS障害やメンテナンスの情報を得るための手段としてAWSが用意しているものはPHDとSHDの2種類あります。本記事ではPHDを扱います。 AW Personal Health Dashboard （ PHD ） 　・・・特定AWSアカウントに公開される情報 AWS Service Health Dashboard （ SHD ） 　・・・一般に公開される情報 背景 AWSマネジメントコンソールの操作が面倒 マルチアカウント環境の場合、AWSアカウントの数にもよりますが、AWSマネジメントコンソールで１アカウントづつリソース作成や各種設定を行うことには個人的に抵抗があります。 理由は、単純に面倒であることと、作業ミスが発生しやすくなるためです。 また、管理対象のAWSアカウントが増えるたびにAWSマネジメントコンソールで設定することにも抵抗があります。 理由は、手順書を用意しておいたとしても、AWSのUIが変わった場合に手順書を更新しないといけなくなるためです。 AWSが用意している方法はAWS Organizationsを使用できることが前提 PHDの通知（AWS Health イベント（以降、ヘルスイベント））を マルチアカウント環境で１つのアカウントへ集約する方法をAWSが用意してくれてはいるものの、AWS Organizationsを使用できることが前提になっています。 AWS Health ユーザーガイド – アカウント間の AWS Health イベントの集約 —抜粋————————————————————— If you use AWS Organizations, you can also view AWS Health events centrally across your organization. This feature provides access to the same information as single account operations. You can use filters to view events in specific AWS Regions, accounts, and services. ———————————————————————- AWS Health Awareも同様に、集約するためにはAWS Organizationsを使用できることが前提になっています。 AWS Health Aware – REDUME —抜粋————————————————————— By enabling an account as a delegated administrator, you can use AHA in Organization Mode without the need to create and assume the management account IAM role. ———————————————————————- AWS Health Awareを使用する場合は以下記事の内容を必ずお読みください。 Amazon SESでDMARC対応した会社メールアドレスを使うには SESで、会社ドメインのメールアドレスをfromアドレスに指定しています。DMARCに対応した送信を行うため、DKIM署名を有効化しDMARC認証をパスできるよう設定しました。 blog.usize-tech.com 2024.12.13   アーキテクチャ 前回の記事 と同様、AWS CloudFormation StackSets セルフマネージド型を用いる方法で考えました。 （「そんなにAWSマネジメントコンソールを触りたくないならAWS CDKを使えば？」と思われるかもしれませんが、AWS CDKだとソースコードの管理を考えないといけないので今回は選択しませんでした） アーキテクチャは以下の記事を踏襲しています。 HeatlhEventの通知を一つのアカウントへ集約する - Qiita 概要複数のAWSアカウントで発生したHealthイベントを一つのアカウントで確認できるようにしたい上記要件を実現するために、EventBridgeのクロスアカウント送受信を使用するAWS Or… qiita.com AWSアカウント 今回は２つのアカウントを用意しました。 集約するイベントを受信するアカウント（以降、アグリゲータアカウント） 集約するイベントを送信するアカウント（以降、ソースアカウント） 導入のために使用するサービス 以下のサービスを使用します。 Amazon S3 汎用バケット AWS CloudFormation テンプレート（以降、Cfnテンプレート）をアップロードします。 AWS CloudFormation スタック 後述の「作成/設定するリソース」を作成/設定します。 AWS CloudFormation StackSets 後述の「作成/設定するリソース」を作成/設定します。 作成/設定するリソース Cfnテンプレートでは以下のリソースを作成/設定します。 アグリゲータアカウント AWS IAM ロール AWS CloudFormation StackSets セルフマネージド型の管理者用のロール AWS CloudFormation StackSets セルフマネージド型のターゲット用のロール AWS User Notifications 通知ハブ 通知データが保存・処理されるリージョンを設定 AWS User Notifications 配信チャンネル ヘルスイベントの通知先（Eメール）を設定 AWS User Notifications 通知設定 アグリゲータアカウントとソースアカウントのヘルスイベントをEメールで送信するための通知設定 裏で自動的にAmazon EventBridge ルールが作成されます Amazon EventBridge イベントバス ソースアカウントのヘルスイベントを受信するためのポリシー ソースアカウント AWS IAM ロール AWS CloudFormation StackSets セルフマネージド型の管理者用のロール AWS CloudFormation StackSets セルフマネージド型のターゲット用のロール 以下のAmazon EventBridge ルール用のロール Amazon EventBridge ルール ソースアカウントのヘルスイベントをアグリゲータアカウントのイベントバスへ送信するためのルール AWS User Notificationsの各種設定は以下の記事を踏襲しています。 AWS IAM ルートユーザー宛の通知を AWS User Notifications を使用して複数メールアドレスへ送信してみた AWS User Notifications を使用して、AWS から IAM ルートユーザー宛に配信される通知を複数メールアドレスに送信する機能を実装しましたので紹介します。 blog.usize-tech.com 2023.10.06 構成図 上記の設計を図にすると以下になります。 黒線は構築時、オレンジ線は構築後のデータの動きです。   事前作業 ゴール ゴールは下図のようにAmazon S3バケットにCfnテンプレートがアップロードされていることです。 Amazon S3バケット作成 作業実施アカウント アグリゲータアカウント 推奨設定 ブロックパブリックアクセスを有効化 ソースアカウントからもGetObjectできるようにバケットポリシーを設定する {   "Version": "2012-10-17",   "Statement": [       {           "Effect": "Allow",           "Principal": {               "AWS": "arn:aws:iam::${ソースアカウントのAWSID}:root"           },           "Action": "s3:GetObject",           "Resource": "arn:aws:s3:::${S3バケット名}/*"       }   ] }   配置するCfnテンプレートは次の通りです。 Cfnテンプレート:PreHealthNotificationAggregator アグリゲータアカウントから自身に対して実行し以下を作成する。 AWS IAM ロール AWS CloudFormation StackSets セルフマネージド型の管理者用のロール AWS CloudFormation StackSets セルフマネージド型のターゲット用のロール AWS User Notifications 通知ハブ 通知データが保存・処理されるリージョンを設定 AWS User Notifications 配信チャンネル ヘルスイベントの通知先（Eメール）を設定 AWS User Notifications 通知設定 アグリゲータアカウントとソースアカウントのヘルスイベントをEメールで送信するための通知設定 裏で自動的にAmazon EventBridge ルールが作成されます 補足 AWS User Notifications 通知ハブはバージニア北部のみ設定されている状態を想定しています。もし、既に東京リージョンも設定されている状態の場合にはエラーになってしまいます。その場合には、東京リージョンを対象から外すか、Cfnテンプレートを修正してください。 AWS User Notifications 配信チャンネルは最大３つ設定できるようにしました。つまり、１～２つだけの設定でもエラーになりません。４つ以上設定したい場合にはCfnテンプレートを修正するか、メーリングリストにメールアドレスをまとめてしまうようにしてください。 AWS User Notifications 通知設定ではリージョンはデフォルトリージョンをすべて指定しています。 AWSTemplateFormatVersion: '2010-09-09' Parameters: CloudFormationAdministrationRoleName:   Type: String   Default: AWSCloudFormationStackSetAdministrationRole CloudFormationExecutionRoleName:   Type: String   Default: AWSCloudFormationStackSetExecutionRole CloudFormationAdministratorAccountId:   Type: String NotificationName:   Type: String   Default: HealthEventsNotification NotificationDescription:   Type: String   Default: HealthEventsNotification EmailContactName1:   Type: String   Default: "" EmailAddress1:   Type: String   Default: "" EmailContactName2:   Type: String   Default: "" EmailAddress2:   Type: String   Default: "" EmailContactName3:   Type: String   Default: "" EmailAddress3:   Type: String   Default: "" Conditions: HasEmailContact1: !And [!Not [!Equals [!Ref EmailContactName1, ""]], !Not [!Equals [!Ref EmailAddress1, ""]]] HasEmailContact2: !And [!Not [!Equals [!Ref EmailContactName2, ""]], !Not [!Equals [!Ref EmailAddress2, ""]]] HasEmailContact3: !And [!Not [!Equals [!Ref EmailContactName3, ""]], !Not [!Equals [!Ref EmailAddress3, ""]]] Resources: AdministrationRole:   Type: AWS::IAM::Role   Properties:     RoleName: !Ref CloudFormationAdministrationRoleName     AssumeRolePolicyDocument:       Version: 2012-10-17       Statement:         - Effect: Allow           Principal:             Service: cloudformation.amazonaws.com           Action:             - sts:AssumeRole     Path: /     Policies:       - PolicyName: AssumeRole-AWSCloudFormationStackSetExecutionRole         PolicyDocument:           Version: 2012-10-17           Statement:             - Effect: Allow               Action:                 - sts:AssumeRole               Resource:                 - !Sub 'arn:*:iam::*:role/${CloudFormationExecutionRoleName}' ExecutionRole:   Type: AWS::IAM::Role   Properties:     RoleName: !Ref CloudFormationExecutionRoleName     AssumeRolePolicyDocument:       Version: 2012-10-17       Statement:         - Effect: Allow           Principal:             AWS:               - !Ref CloudFormationAdministratorAccountId           Action:             - sts:AssumeRole     Path: /     ManagedPolicyArns:       - !Sub arn:${AWS::Partition}:iam::aws:policy/AdministratorAccess NotificationHub:   Type: AWS::Notifications::NotificationHub   Properties:     Region: ap-northeast-1 EmailContact1Resource:   Type: AWS::NotificationsContacts::EmailContact   Condition: HasEmailContact1   Properties:     Name: !Ref EmailContactName1     EmailAddress: !Ref EmailAddress1 EmailContact2Resource:   Type: AWS::NotificationsContacts::EmailContact   Condition: HasEmailContact2   Properties:     Name: !Ref EmailContactName2     EmailAddress: !Ref EmailAddress2 EmailContact3Resource:   Type: AWS::NotificationsContacts::EmailContact   Condition: HasEmailContact3   Properties:     Name: !Ref EmailContactName3     EmailAddress: !Ref EmailAddress3 NotificationConfiguration:   Type: AWS::Notifications::NotificationConfiguration   Properties:     Name: !Ref NotificationName     Description: !Ref NotificationDescription     AggregationDuration: NONE     Tags:       - Key: Environment         Value: Production HealthEventRule:   Type: AWS::Notifications::EventRule   Properties:     EventPattern: '{"source": ["aws.health"]}'     EventType: 'AWS Health Event'     NotificationConfigurationArn: !Ref NotificationConfiguration     Regions:       - ap-northeast-1       - ap-northeast-2       - ap-northeast-3       - ap-south-1       - ap-southeast-1       - ap-southeast-2       - ca-central-1       - eu-central-1       - eu-north-1       - eu-west-1       - eu-west-2       - eu-west-3       - sa-east-1       - us-east-1       - us-east-2       - us-west-1       - us-west-2     Source: 'aws.health' EmailChannel1:   Type: AWS::Notifications::ChannelAssociation   Condition: HasEmailContact1   Properties:     Arn: !GetAtt EmailContact1Resource.Arn     NotificationConfigurationArn: !Ref NotificationConfiguration EmailChannel2:   Type: AWS::Notifications::ChannelAssociation   Condition: HasEmailContact2   Properties:     Arn: !GetAtt EmailContact2Resource.Arn     NotificationConfigurationArn: !Ref NotificationConfiguration EmailChannel3:   Type: AWS::Notifications::ChannelAssociation   Condition: HasEmailContact3   Properties:     Arn: !GetAtt EmailContact3Resource.Arn     NotificationConfigurationArn: !Ref NotificationConfiguration Outputs: NotificationHubId:   Description: ID of the Notification Hub   Value: !Ref NotificationHub NotificationConfigurationArn:   Description: ARN of the Notification Configuration   Value: !Ref NotificationConfiguration HealthEventRuleArn:   Description: ARN of the Health Event Rule   Value: !Ref HealthEventRule EmailContact1Arn:   Description: ARN of Email Contact 1   Condition: HasEmailContact1   Value: !GetAtt EmailContact1Resource.Arn EmailContact2Arn:   Description: ARN of Email Contact 2   Condition: HasEmailContact2   Value: !GetAtt EmailContact2Resource.Arn EmailContact3Arn:   Description: ARN of Email Contact 3   Condition: HasEmailContact3   Value: !GetAtt EmailContact3Resource.Arn Cfnテンプレート:PreHealthNotificationSource ソースアカウントから自身に対して実行し以下を作成する。 AWS IAM ロール AWS CloudFormation StackSets セルフマネージド型の管理者用のロール AWS CloudFormation StackSets セルフマネージド型のターゲット用のロール 以下のAmazon EventBridge ルール用のロール AWSTemplateFormatVersion: '2010-09-09' Parameters: CloudFormationAdministrationRoleName:   Type: String   Default: AWSCloudFormationStackSetAdministrationRole CloudFormationExecutionRoleName:   Type: String   Default: AWSCloudFormationStackSetExecutionRole EventBridgeRuleRoleName:   Type: String   Default: AWSHealthEventBridgeRuleRole AdministratorAccountId:   Type: String Resources: AdministrationRole:   Type: AWS::IAM::Role   Properties:     RoleName: !Ref CloudFormationAdministrationRoleName     AssumeRolePolicyDocument:       Version: 2012-10-17       Statement:         - Effect: Allow           Principal:             Service: cloudformation.amazonaws.com           Action:             - sts:AssumeRole     Path: /     Policies:       - PolicyName: AssumeRole-AWSCloudFormationStackSetExecutionRole         PolicyDocument:           Version: 2012-10-17           Statement:             - Effect: Allow               Action:                 - sts:AssumeRole               Resource:                 - !Sub 'arn:*:iam::*:role/${CloudFormationExecutionRoleName}' ExecutionRole:   Type: AWS::IAM::Role   Properties:     RoleName: !Ref CloudFormationExecutionRoleName     AssumeRolePolicyDocument:       Version: 2012-10-17       Statement:         - Effect: Allow           Principal:             AWS:               - !Ref AdministratorAccountId           Action:             - sts:AssumeRole     Path: /     ManagedPolicyArns:       - !Sub arn:${AWS::Partition}:iam::aws:policy/AdministratorAccess EventBridgeRuleRole:   Type: AWS::IAM::Role   Properties:     RoleName: !Ref EventBridgeRuleRoleName     AssumeRolePolicyDocument:       Version: "2012-10-17"       Statement:         - Effect: Allow           Principal:             Service: events.amazonaws.com           Action: "sts:AssumeRole"     Policies:       - PolicyName: EventBridgeRulePolicy         PolicyDocument:           Version: "2012-10-17"           Statement:             - Effect: Allow               Action:                 - "events:PutEvents"               Resource:                 - !Sub "arn:aws:events:*:${AdministratorAccountId}:event-bus/default" Outputs: EventBridgeRuleRoleArn:   Description: ARN of the IAM role for AWS EventBridgeRule   Value: !GetAtt EventBridgeRuleRole.Arn Cfnテンプレート:EventBusPolicy ソースアカウントからアグリゲータアカウントに対して実行し以下を作成する。 Amazon EventBridge イベントバス ソースアカウントのヘルスイベントを受信するためのポリシー 補足 aws:PrincipalOrgIDを使っている理由は、ソースアカウントが増えるたびにAmazon EventBridge イベントバスのポリシーを変更したくないからです。「危険だ！」という場合にはアカウント単位での指定方法（aws:PrincipalAccount）も用意されているので、以下リンク先の内容を参考にカスタマイズしてご利用ください。 Amazon global condition context keys AWSTemplateFormatVersion: '2010-09-09' Parameters: OrganizationID:     Type: String Resources: EventBusPolicy:   Type: AWS::Events::EventBusPolicy   Properties:     EventBusName: default     StatementId: AllowPutEventsFromOrganization     Statement:       Effect: Allow       Principal: "*"       Action: events:PutEvents       Resource: !Sub arn:aws:events:${AWS::Region}:${AWS::AccountId}:event-bus/default       Condition:         StringEquals:             aws:PrincipalOrgID: !Ref OrganizationID Outputs: EventBusArn:   Description: ARN of the default event bus   Value: !Sub arn:aws:events:${AWS::Region}:${AWS::AccountId}:event-bus/default Cfnテンプレート:EventRule アグリゲータアカウントからソースアカウントに対して実行し以下を作成する。 Amazon EventBridge ルール ソースアカウントのヘルスイベントをアグリゲータアカウントのイベントバスへ送信するためのルール AWSTemplateFormatVersion: '2010-09-09' Parameters: HealthNotificationAggregatorAccountId:   Type: String RuleName:   Type: String   Default: HealthEventForwardingRule EventBridgeRuleRoleName:   Type: String     Default: AWSHealthEventBridgeRuleRole Resources: HealthEventRule:   Type: AWS::Events::Rule   Properties:     Name: !Ref RuleName     EventPattern:       source:         - "aws.health"       detail-type:         - "AWS Health Event"     State: ENABLED     Targets:       - Arn: !Sub "arn:aws:events:${AWS::Region}:${HealthNotificationAggregatorAccountId}:event-bus/default"         Id: 'CrossAccountEventBusTarget'           RoleArn: !Sub 'arn:aws:iam::${AWS::AccountId}:role/${EventBridgeRuleRoleName}' Outputs: EventRuleArn:   Description: 'ARN of the created EventBridge rule'   Value: !GetAtt HealthEventRule.Arn   設定作業 ゴール アグリゲータアカウントのAWS CloudFormationのスタック画面で下図のようになっていることです。 （バージニア北部のみPreHealthNotificationAggregatorあり）   また、ソースアカウントのAWS CloudFormationのスタック画面で下図のようになっていることです。 （PreHealthNotificationSourceを実行したリージョンでのみPreHealthNotificationSourceあり） Cfnテンプレート: PreHealthNotificationAggregator バージニア北部リージョンで実行してください。 AWS User Notificationsはグローバルサービスのため他のリージョンではエラーになります。 作業実施アカウント アグリゲータアカウント 使用サービス AWS CloudFormation スタック パラメーターについて補足 CloudFormationAdministratorAccountIdにはソースアカウントのAWSアカウントIDを入力してください。 Cfnテンプレート: PreHealthNotificationSource 作業実施アカウント ソースアカウント 使用サービス AWS CloudFormation スタック パラメーターについて補足 AdministratorAccountIdにはアグリゲータアカウントのAWSアカウントIDを入力してください。 Cfnテンプレート: EventBusPolicy 作業実施アカウント ソースアカウント 使用サービス AWS CloudFormation StackSets 画面イメージ等は 前回の記事 を参考にしてください。 パラメーターについて補足 OrganizationID（組織ID）を指定します。組織IDの確認方法は、画面右上のログインユーザーをクリックした後に「組織」をクリックすると見れます Cfnテンプレート: EventRule 作業実施アカウント アグリゲータアカウント 使用サービス AWS CloudFormation StackSets 画面イメージ等は 前回の記事 を参考にしてください。 パラメーターについて補足 HealthNotificationAggregatorAccountIdにはアグリゲータアカウントのAWSアカウントIDを入力してください   以上です。 アカウントを追加したい時はどうしたら良いの？ 追加したいソースアカウントでPreHealthNotificationSourceを実行した後、アグリゲータアカウントのAWS CloudFormation StackSetsからEventRuleを選択し、アクションから「StackSetにスタックを追加」をクリックすることで、追加したいソースアカウントに対してスタックを作成することができます。 なお、aws:PrincipalOrgIDを使わずにaws:PrincipalAccountを使う場合には、アグリゲータアカウントのAmazon EventBridge イベントバスにおいてポリシーの変更も必要になります。   まとめ 記事を書いてみたものの、アカウント数が少ない場合にはAWSマネジメントコンソールで設定したほうが早いと思います。また、通知先のメールアドレス変更やアカウント追加の頻度は多くないと思うので、本記事の内容は運用面でのメリットは殆ど無いように感じました。 しかしながら、マルチアカウント環境関連の設定はAWS Organizationsを使えることが前提のものが多いので、諸事情でAWS Organizationsを使用できないけどAWSマネジメントコンソールで設定するのは避けたいという方は少なからずいると思います。そのような方の参考になったら良いな、と思います。 アカウント数が多い場合には、Eメールで受信する通知を削減することで抜け漏れを防止するために、同じ内容のヘルスイベントは除外するような仕組みも考えたほうが良いかと思います。 試していませんが、AWS LambdaやAWS Step Functionsを活用することで実現できるかと思われます。 その内試したいですが、ヘルスイベントのテスト発行は自分で出来ない（AWSサポートに依頼するしかない）ので、やろうとしたら検証に時間が掛かりそうです…。

激ムズAWS GameDayもAIがあれば爆速クリアできるのか！？ AWS GameDay ~Secure Legends ハードモード~ (再演) with Amazon Q Developer こちらのGameDayに参加してきました！ GameDay参加はこれで2回目です。初回はre:Invent 2023の時、野良でセキュリティ関連のGameDayにチャレンジし、惨敗した想い出があります。 今回ハードモードと聞いて全く太刀打ちできる感じはしませんでしたが、Top Engineer含めた社内パーティで参戦できる & Amazon Q Developerという武器があることでチャレンジしてみようと決めました💪   私のステータス さて、まずは私のステータスを見ていきましょう。 名前 : ウメガタニ　ナオキ ジョブ : プロダクトマネージャ レベル : IT業界15年+ 経験値 : AWSの実務経験は1年未満 武器 : Amazon Q Developer パーティ : 社内のTop Engineerを含む4人チーム 特技 : プロジェクトマネジメント、グローバル案件 アイテム : AWS SAP, SOA, DVA レベルはそこそこですが、AWS経験値があまりありません。 武器とパーティを力にチャレンジすることにしました。 GameDay概要 GameDayの詳細はネタバレを避けるため公開ができないこととなっており、記事に書くことはできません。 そこで、公開されている情報だけ簡単にご紹介します。   今回のGameDayでは、4名1チームとなり技術的課題の解決に挑みました🎯 ワークショップとは異なり手順は示されておらず、解決すべき課題だけがミッションとして与えられます。 ゲームをクリアするためチームメンバーは知恵を絞り自由な方法でシナリオを進めます。   今回のシナリオでは架空の会社があり、セキュリティ対策を全く行っておらず、大変なことになってしまいました。 新入社員に立て直しの任務を課したようです。とんでもないですね😂 参加チームはランサムウェア、サイト改ざん、情報漏洩といったインシデントの対策を行いました。   概要は以下のAPNブログをご参照ください。 AWS GameDay Secure Legends (ハードモード) 2024 年 7 月開催レポート | AWS JAPAN APN ブログ   Amazon Q Developerについて 簡単にAmazon Q Developerについて触れておきます。 有名な機能はコードアシスタントで、コードの生成、レビューやドキュメント化などを行ってくれます。 Tech Harmonyでも過去にコードの生成や改修に関する記事があります。 【Amazon Q】Q Developerを試してみました！ – TechHarmony   運用面でもユースケースがあります。 AWSリソースに関して質問することで、マネジメントコンソールやCLIを使わずに、AWS環境情報を取得することができます。 また、コストの分析やセキュリティの問題点の把握、推奨案、それから修復までできてしまいます。   そしてなんと…このAmazon Q Developerが2025年4月より待望の日本語サポートを開始しました！ これはもはや最強の武器になるのではないでしょうか💪   Amazon Q Developerの力 ゲーム開始後、Amazon Q Developerの環境設定で全員エラーとなってしまい、素手で挑んでいました。 これがかなりタフで、ハードモードということもあり苦戦しました…。   Amazon Q Developerの準備が整った後は、何とか使いこなしてクリアしようと試行錯誤してトライしました。 いくつか効果を感じた点をまとめています。 設問をそのまま与えても動いてくれる 雑に設問をコピーして投げても、いくつかあたりを付け、環境情報の取得や解決案の提示を行ってくれました。 細かく指示しなくても動作するのはお手軽ですね。 問題の特定と解決策を提示してくれる 調査した結果を、問題点と解決策といった形で分けて提示してくれます。 どのようなプロセスで確認し、何を対応しようとしているかが分かりやすいです。 変更作業実施前に確認してくれる 勝手に環境に変更を加えることはなく、事前に聞いてきてくれます。安心して任せることができますね。 上手くいかない場合は何とかするまでトライし続けてくれる わりとタフなタイプのようで、修復ができない場合は再度調査を行い別のアプローチを行ってくれるシーンがありました。任せきりで色々とトライしてくれるのはありがたいです。一方で、プロンプトが戻ってくるまで20分以上かかることもあるため、良し悪しがあると思います。   日本語で指示するだけで、AWSのリソース情報などを細かく取得し分析してくれ、予想以上のパワーがあります。 AWS経験値の少ない私でも、先に進んでいる感覚がありました。 レベルアップに向けて 結果は序盤に環境設定で出遅れたこともあり、後ろの方の順位でした😭 一方で、丸腰で挑むことと比較すると、今回Amazon Q Developerはかなり強い武器になりました。 いくつかAmazon Q Developerを使いこなしレベルアップするために考慮すべき点を挙げておきます。 環境情報を与える必要性 設問内容に加え、環境や背景の情報をしっかり与える必要がありました。 具体的にどのような環境で何のサービスを動かしていて、セキュリティ面で何が起きているかの情報を与えることで、より精度高く状況を理解しアクションしてくれるはずです。 タスクを分解する必要性 あまりに大きなタスクを投げてしまうと、人間と同じで取りこぼしたり混乱してしまいました。 問題点が複数ある場合は適度に分割して指示することで、ひとつひとつ確実に対応を進めることができると思います。 環境を破壊しないよう制御する必要性 今回のGame Dayでは、実験的にAmazon Q Developerに対して変更のアクションをすべて許可してみました。 リソースを修復してくれるという良い面もありましたが、設定ファイルを破壊してしまうこともありました。 この辺りは実際の業務で使う場合は慎重に見定めないといけないため、時間はかかりますが人間がしっかりチェックした方が良いと思います。   感想 久しぶりのGame Dayでしたが、楽しくチャレンジすることができました！ ハードモードは難易度が高く苦戦しましたが、チーム戦ということもありメンバーと相談しつつ進めることができたのは一体感もあり良かったです。 また、今回出社して会議室に籠って実施していたため、コミュニケーションがとりやすく集中できた環境もプラスでした。 Game DayではAWSのサービスを実践的に触ることができるため、また機会があれば参加したいです。 みなさんも是非チャレンジしてみてください。

こんにちは。SCSKの磯野です。 Google Cloudにおける監視は、ログ監視とメトリクス監視の２種類に分けることができます。 今回は、それぞれの監視方法についてご説明します。 ログ監視 – Cloud Logging Google Cloudにおけるログの収集・保管・管理はCloud Loggingで行います。 Cloud Loggingとは 各 Google Cloud サービスが出力するログは自動的に Cloud Logging に集約されます。主な機能は以下の通りです。 ログバケット （GCSとは別物。Cloud Logging専用のストレージ）にログが保管される。 以下2つのバケットがデフォルトで存在。 _Required Google Cloud が必須で取得する監査系のログが投入される、無料。 _Default _Required以外のすべてのログが格納される。デフォルトでは保持期間が30日。 30日までなら保持期間無料。$0.50 / GiB の取り込み(保存)料金は発生する ログエクスプローラー ：ログバケットに格納されているログを閲覧可能 Log Analytics：ログバケットに格納されているログをSQLでクエリ可能 料金  |  Google Cloud Observability Google Cloud Observability の料金を確認する cloud.google.com ログ監視 Cloud Monitoring でアラートポリシーの条件を設定します。アラートポリシーの作成方法には3種類あります。 ログベースの指標(メトリクス) 「ログで Error という文字列を5分間で3個以上検知したらメール通知する」というような、指標をモニタリングするアラートポリシーを作成するイメージ。 昔はこちらしかなかった。ログベースのアラートと異なり、複数のログを集約して検知することが可能。 ログベースのアラート 検知対象の文字列を指定してログベースのアラートを設定する。  SQLベースのアラート Terraformサンプル # CloudRunのエラーログが発生したことを検知するアラートポリシー resource "google_monitoring_alert_policy" "cloud_run_warn" { display_name = "Cloud Run - Error Detected" combiner     = "OR" conditions {   display_name = "Log match - Cloud Run Error"   condition_matched_log {     filter = <<EOT     (resource.type="cloud_function" OR resource.type="cloud_run_revision" OR (resource.type="cloud_run_job" AND protoPayload.serviceName="run.googleapis.com"))       AND severity="ERROR"       AND (         resource.labels.project_id="xxx"       )     EOT     label_extractors = {       error_message = "EXTRACT(protoPayload.status.message)"     }   } } enabled = true alert_strategy {   notification_prompts = ["OPENED"]   notification_rate_limit {     period = "300s" # 5分毎の集計   }   auto_close = "1800s" # 下部に補足あり } notification_channels = "xxx(通知先のslackなど)" documentation {   content   = <<EOT project： $${resource.labels.project_id} job name: $${resource.labels.job_name} error_message： $${log.extracted_label.error_message}   EOT   mime_type = "text/markdown" } } auto_closeとは？ アラート条件を満たすデータが 途絶えてから 指定期間が経過した際にインシデントを閉じるための期間 auto_close期間内に、再度アラート条件を満たすイベントが発生した場合、インシデントはオープンのままとなる メトリクス監視 – Cloud Monitoring Google Cloudにおけるメトリクスの収集・管理はCloud Monitoringで行います。 Cloud Monitoringとは 各種 Google Cloud サービスからパフォーマンスデータ等を収集して保存・閲覧可能にするサービス。取得できる指標には以下のような種類がある。 Google Cloud の指標 ：デフォルトで収集される指標 Google Cloud metrics  |  Cloud Monitoring エージェントの指標 ：Opsエージェントをインストールすると、メモリ使用率 , ディスク使用率 , スワップ利用率 などを取得できる Ops Agent metrics  |  Cloud Monitoring  |  Google Cloud   カスタム指標 ユーザー定義の指標の概要  |  Cloud Monitoring  |  Google Cloud メトリクスエクスプローラー ：グラフの作成が可能 Metrics Explorer でグラフを作成する  |  Cloud Monitoring  |  Google Cloud アラートのdocumentation・ラベルを活用することで、通知メッセージをカスタマイズすることが可能 Cloud Monitoring におけるアラート通知をカスタマイズする Cloud Monitoringでアラートの通知内容をカスタマイズする方法とTerraformでの記載例についてご紹介します。ログ監視・メトリクス監視共に、アラートのdocumentation・ラベルを活用することで通知内容をカスタマイズ可能です。カスタムラベルの作成方法もご紹介します。 blog.usize-tech.com 2025.06.09 メトリクス監視 Cloud Monitoring で設定する 指標ベースのアラート 指標しきい値のアラート ポリシーを作成する  |  Cloud Monitoring  |  Google Cloud 指標なしのアラート ポリシーを作成する  |  Cloud Monitoring  |  Google Cloud 予測指標値のアラート ポリシーを作成する  |  Cloud Monitoring  |  Google Cloud クエリ言語の種類 MQL：非推奨 Monitoring Query Language overview  |  Google Cloud PromQL：推奨 Cloud Monitoring の PromQL  |  Google Cloud          Cloud Monitoringのアラートポリシー作成画面にて、メトリクスのプレビューが可能 Builderで作成した場合でも、Metrics Explore経由であればPromQLへの変換が可能 ※ただし、__intervalなど一部正確に変換できないケースがあります。ご留意ください Cloud Monitoring の指標と PromQL のマッピング  |  Google Cloud クエリナレッジ $__interval ：ダッシュボード UI 内で選択される、時刻範囲に基づく間隔を表します。 例えば、この変数を使用して、経時的な比率や平均などのさまざまな操作の時刻範囲を調整することもできます。 PromQL の使用 | IBM Cloud 資料 Terraformサンプル # VMが停止したことを検知するアラートポリシー。メトリクスが欠損したら発報 resource "google_monitoring_alert_policy" "vm_stoped" { display_name = "VM Instance - Uptime Absent(API VM Stopped)" combiner     = "OR" conditions {   display_name = "VM Instance - Uptime"   condition_prometheus_query_language {     query    = <<EOT     absent(avg by (instance_name, project_id)(     increase(compute_googleapis_com:instance_uptime{     monitored_resource="gce_instance",     project_id="xxx",     instance_name="xxx"}[5m]))     ) == 1     EOT       duration = "240s" # 最大 240 秒間はデータは表示されないため   } } notification_channels = "xxx(通知先のslackなど)" alert_strategy {   notification_prompts = ["OPENED"] } documentation {   content = <<EOT Project: "xxx" instance_name: "xxx" EOT } } 参考資料 Terraformドキュメント： Terraform Registry

こんにちは。SCSKの磯野です。 Google CloudではCloud Monitoringで監視を行うことができます。 監視をする際、Slack等に通知されるアラートのメッセージをカスタマイズしたいというケースがあると思います。 例）CloudRunのエラーログ監視において、Slackの通知にVM名やエラーメッセージを含めたい。 今回は、アラートの通知内容をカスタマイズする方法とTerraformでの記載例についてご紹介します。 アラートの通知内容をカスタマイズする方法 アラートのdocumentation・ラベルを活用することで、通知メッセージをカスタマイズすることが可能です。 詳細は以下公式ドキュメントに記載されています。 ユーザー定義のドキュメントで通知にアノテーションを付ける  |  Cloud Monitoring  |  Google Cloud cloud.google.com 変数として、ラベルを定義することが可能です。 リソースラベル 一覧 Monitored resource types  |  Cloud Monitoring  |  Google Cloud メトリクスラベル 一覧 Google Cloud metrics  |  Cloud Monitoring            上記ドキュメントは最新ではないことも。Google API Explorerで確認するとよい。 Method: projects.metricDescriptors.get  |  Cloud Monitoring  |  Google Cloud カスタムラベル カスタムラベルについて、ログ・メトリクスで扱い方が異なります。詳しく見ていきましょう。 Google Cloud における監視方法について- モニタリングとロギング Google Cloudにおける監視はログ監視とメトリクス監視の２種類に分けることができます。Cloud Loggingの使い方、Cloud Monitoringにおけるクエリの書き方、Terraformでアラート実装方法等をご紹介します。 blog.usize-tech.com 2025.06.09 ログ監視におけるカスタムラベル リソースラベル に加えて、 ログベースのアラートポリシー では、 log.extracted_label. KEY という形でカスタムラベルを付与することが可能です。 Terraformでの記載例は以下の通り。 # CloudRunのエラーログが発生したことを検知するアラートポリシー resource "google_monitoring_alert_policy" "cloud_run_warn" { display_name = "Cloud Run - Error Detected" combiner     = "OR" conditions {   display_name = "Log match - Cloud Run Error"   condition_matched_log {     filter = <<EOT     (resource. type = "cloud_function" OR resource. type = "cloud_run_revision" OR (resource. type = "cloud_run_job" AND protoPayload. serviceName = "run.googleapis.com" ))       AND severity = "ERROR"       AND (         resource.labels. project_id = "xxx"       )     EOT     label_extractors = {       error_message = "EXTRACT(protoPayload.status.message)"     }   } } enabled = true alert_strategy {   notification_prompts = [ "OPENED" ]   notification_rate_limit {     period = "300s"   }   auto_close = "1800s" } notification_channels = "xxx(通知先のslackなど)" documentation {   content   = <<EOT project： $ ${resource.labels.project_id} job name: $ ${resource.labels.job_name} error_message： $ ${log.extracted_label.error_message}   EOT   mime_type = "text/markdown" } } メトリクス監視におけるカスタムラベル リソースラベル や メトリクスラベル に加えて、Monitoring は、モニタリング対象リソースに関する追加情報を内部で収集し、システム メタデータ ラベルに保存します。これらのシステム メタデータ ラベルは、読み取り専用の値として使用できます。一部のリソースでは、Google Cloud コンソールで VM インスタンスなどのリソースを構成するときに、独自のリソース メタデータ ラベルを作成することもできます。 指標モデルのコンポーネント  |  Cloud Monitoring  |  Google Cloud cloud.google.com Terraformでの記載例は以下の通り。 本コードでは、 リソースラベル ・ メトリクスラベル を使用して、通知内容のカスタマイズを行っています。 # CloudRunジョブのCPU使用率が90%を超えたことを検知するアラートポリシー resource "google_monitoring_alert_policy" "cloud_run_memory_utilization_common" { display_name = "Cloud Run Job - Container Memory Utilization > 0.9" combiner     = "OR" conditions {   display_name = "Cloud Run Job - Container Memory Utilization"   condition_prometheus_query_language {     query = <<EOT     histogram_quantile(0.99,sum by (job_name,project_id,le)(     run_googleapis_com:container_memory_utilizations_bucket{     monitored_resource="cloud_run_job",     project_id="xxx"})) > 0.9     EOT   } } enabled               = true notification_channels = "xxx(通知先のslackなど)" alert_strategy {   notification_prompts = ["OPENED"] } documentation {   content = <<EOT Project: $${resource.label.project_id} JobName : $${metric.label.job_name} EOT } } まとめ いかがだったでしょうか。 今回は、Cloud Monitoringでアラートの通知内容をカスタマイズする方法とTerraformでの記載例についてご紹介しました。 本記事が皆様のお役に立てれば幸いです。

みなさん、こんにちは。SCSKのMasedatiです！ 最近の私、週2でラーメン屋に通っています。E.A.Kって最高ですね！ さてさて、今年で新卒3年目を迎える私ですが、昨年度は新人指導員としてOJTに携わっていました。 その中で改めて感じたのは、 新人の皆さんは日々覚えることが多く、なかなかアウトプットにまで手が回らない という課題です。 私が1年目だった頃、アウトプットの機会を提供する取り組みとして、 月1回のブログ発信を支援する「 新人ブログマラソン 」が実験的に始まりました。 当時は新人としてブログ発信に挑戦する立場でしたが、 技術を言語化し発信する経験は、非常に良い刺激 となったのを覚えています。 この経験を踏まえ、2024年度も新人の皆さんが自らテックブログを書き、楽しみながらアウトプットに取り組める場として、 「 新人ブログマラソン 」を継続開催することにしました。 企画概要 新人と指導員がペアを組み、新人がブログ記事を執筆　※ペアは月ごとに交代 指導員は記事に対してフィードバックを行い、その後、ブログを公開 実施期間は 2024年12月〜2025年3月  で、 月1本の投稿 を目安 技術に関連する内容、またはそれに準ずる内容であればテーマは自由 前回開催の「新人ブログマラソン」の活動報告 は↓こちら。 新入社員がブログを書き始めるきっかけとは！？ 当社新人たちがテックブログを書いてみたよ。 blog.usize-tech.com 2024.05.07 そもそもなんでブログを書くのか？（再掲） 人に伝えようとすることで自分の理解になる。 昔の人は言いました「100回の購読より、1回の寄稿」だと。 新人はインプットする機会は多いですがアウトプットすることで知識定着に寄与できます。 「テックブログを書く」という道の最初の一歩を作る。 テックブログなんて社外に発信できるなんてすごいエンジニアだけなんだ。という畏怖の取り除きを解消することができます。 新人育成の中で先輩社員がリードしてあげることで新人様の最初の一歩を促すことができます。 社内外に顔を売るチャンスを作る。 社外発信することにより人目につき、名前や顔が売れていきます。 パブリックな活動を評価するような仕組みも社外にはあるので、そこに取り上げてもらうことで当社としても個人としても対外的な評価を受けれるのは素晴らしいことです。また社内向けには報告会を行うこと新人様と役職者をつなげるような活動にも発展できます。 取り組み紹介 ということで今期取り組んだ新人様6名の記事を紹介したいと思います。 本イベントを通して発信されたブログ一覧は↓こちら！ 新人ブログマラソン 2024 【2024/12月～2024/3月開催】SCSKの新人たちが自由なテーマで毎月クラウド技術やテクノロジーに関する記事をお届けします。 blog.usize-tech.com 2024.11.27 ササキさん ◆主な業務内容 ・DWH基盤構築（Snowflake） ・DB構築（Oracle） ◆趣味 ドライブ・神社仏閣めぐり ◆投稿記事 ササキさんの記事 Snowflakeの最新機能を、新米エンジニアの視点から徹底的に解剖する、Snowflake入門ブログ となっています。 Snowflakeに興味はあるけれど、何から始めれば良いか分からない…最新機能って難しそう…そんな悩みを抱える方にこそ、ぜひ読んでいただきたい内容です。 特に、Cortex AIを使い、ドキュメント検索アシスタントを実際に構築していく過程を、基礎から応用まで、一つ一つ丁寧に解説していただきました。 ✨感想ダイジェスト✨ 知識整理および新情報キャッチアップ ​ 🔍 調査や検証の仕方に慣れることができた ​ ✍️ 習慣的な投稿が大切だと感じた ​ 初学者にも伝わるように執筆することは難しい・・・ ​ 💡 客観的な視点を持つことの大切さに気付いた ​ 今後について 🚀 所属組織のプレゼンス向上につながるため、 より PV 数を意識して投稿していきたい コウさん ◆主な業務内容 ・ USiZE に関連する保守運用/機能開発 ◆趣味 エクストリームスポーツ・スキー ◆投稿記事 コウさんの記事 Rubrikの様々な側面を深く理解していただけるようなコンテンツ を寄稿いただきました！ Rubrikそのものの概要、提供される機能、そしてバックアップ管理の全体像について詳しく解説されています。 また、Rubrikが備えるランサムウェア対策機能の仕組みと検証や機密データの可視化と管理を容易にするSensitive Data Discoveryについても掘り下げていただきました。 さらには、RubrikとAWSとの連携に注目し、EC2のバックアップを自動化するための設定手順から、アーカイブに至るまでの具体的な流れを検証されています。 ✨感想ダイジェスト✨ Rubrikに対する理解の促進 💪実際に手を動かして検証する中で、知識が定着することができた​ ​アウトプットの効果 🤝自部署以外との交流が増えた 🤔伝わりやすい言葉選びや構成の工夫の習得 今後について​ 🎨より多くの人に届くよう、タイトルや見せ方も工夫したい​ 🔥実務で得た知見をわかりやすく発信し続けていきたい オダさん ◆主な業務内容 ・ USiZE に関連する運用 ◆投稿記事 オダさんの記事 実務経験に基づいたIT技術情報 を寄稿いただきました！ PowerShell、ITIL、vCLS、Vagrant/VirtualBoxの技術での課題解決から学習内容の共有まで広く情報発信されていますが、 特に vSphereのvCLS仮想マシンについてのブログ が必見です。そもそもvCLSとは何なのか、vCLSが有効であるとどんないいことがあるのか、無効にするとどのような影響があるのかを中心に調べてまとめていただきました。 ✨感想ダイジェスト✨ 発信活動に対する心理的ハードルの低下 😓これまで何かを発信した経験がほとんどなかったので、かなり苦戦 💪イベントを通して、​自分の中で何となく書き方のようなものがわかるように 📝情報のまとめ方、ブログの書き方への理解度向上 情報調査の深化​ マガリフチさん ◆主な業務内容 ・コンテナ構築 ・IaaSクラウド移行作業 ◆趣味 料理・スポーツ観戦 ◆投稿記事 マガリフチさんの記事 AWS Fargateコンテナへのログイン方法やAWS Cloud9の代替サービス比較といった、 AWSを利用する中で多くの方が抱える課題 を中心に記事執筆いただきました。 コンソール画面のスクリーンショットを豊富に掲載し、各操作の意味を丁寧に解説しています。読者の皆様が実際に手を動かしながら理解を深められるように工夫されているのが伝わります。 ✨感想ダイジェスト✨ 曖昧だった知識を整理​ ✍️文字に書き起こすことで自分の中の考えを整理しなおし、人に説明できるレベルまでもっていくことができた！ アウトプットでスキルアップ 👂自分以外の読み手が何を求めているのかを知ることができた。 🎨サービスの理解だけでなく、相手に読んでもらうブログとしてデザイン力も鍛えることができた。​ 🗣️指導員フィードバックから、新たな知見を得ることができた。 他部署との交流 👨‍🏫イベント参加者のブログを読むことで、自然に業務以外のサービスの知識を知ることができた。 ワタナベさん ◆主な業務内容 ・ S-Cred + プラットフォーム 運用 ◆趣味 吹奏楽（クラリネット）・油そばをすすること ◆投稿記事 ワタナベさんの記事   Amazon Bedrockの最新機能やDatadogハンズオン について寄稿いただきました。 特に、re:Invent 2024で発表された 「Amazon Bedrock Multi-Agent Collaboration」を最速で検証したブログ はおすすめです。 教材がない中の独力でのハンズオンのため、​エラーを繰り返した苦労も含めていただいたことで、AWS公式記事を見て触ってみる人にとって有用なものになったと思います。 ✨感想ダイジェスト✨ ブログ発信の壁突破 ✍️最初の投稿で先輩からのアシストを受けることで、​読みやすいブログ執筆のための作法を知ることができた​ 🎉イベントとして一定回数の投稿を行うことで投稿の仕方が分かる & 習慣化​ 指導員レビューからの学び 👀読み手の求めていることを意識した記述​（例：ハンズオン所要時間​の記載） 🎨視覚的な分かりやすさ​を意識した記述（図や改行の活用​/内容の明瞭性/​表現の統一） ノガミさん ◆主な業務内容 ・DB構築（MySQL） ◆趣味 スノーボード・お笑い芸人のYouTubeを見ること ◆投稿記事 ノガミさんの記事   MySQLレプリケーション中心に、業務で得た知識のアウトプット としてブログを作成いただきました。 レプリケーション初学者による初学者向けの解説となっています。MySQLレプリケーション方式の比較検討から、実際の案件における考慮のポイント、さらには、Amazon QuickSightでの集計関数利用時のエラーの共有と対処法まで、実践的なノウハウを発信いただいています。 ✨感想ダイジェスト✨ ブログ発信の壁突破​ 🤓技術ブログは敷居が高いように感じていたが、自分でも書くことができるという自信につながった​ アウトプットの場として最適​ 🧠業務で一度学んだ知識を振り返ることができ、知識が整理された​ 今後について​ 🌟知見を広げるための業務知識以外のブログ執筆にもチャレンジしたい！ 完走した感想 イベントは、「 アウトプット習慣の育成 」「 組織コミュニケーションの活性化 」「 社外からの評価獲得のきっかけ作り 」という3つの点で、期待以上の成果を上げることができました。 昨年に比べて、新人の皆さんからは多種多様な技術発信をしていただきました。 私自身も、知らなかった技術や知識に触れることができ、大変勉強になりました。 イベントを通じて、参加者同士が互いに刺激を受け、新たな学びを得られた濃密な期間 だったのではないでしょうか。 積極的に参加の声をあげてくださった新人の皆さんに、心から敬意を表します。 また、本イベントの運営にご協力いただいた皆さまにも、この場を借りて感謝申し上げます。ありがとうございました。 本ブログを閲覧された社内の皆様へ 2025年度も「 新人ブログマラソン 」の開催を予定しています。 「参加してみたい」「興味がある」という指導員/新人の方は、私までぜひお気軽にご連絡ください！何卒何卒。

以前、AWS CDK で Application Load Balancer (ALB) の作成時にアクセスログを Amazon S3 バケットに出力する設定で躓いたので、設定方法を備忘として執筆します。 モジュールはこちらを利用しています。 aws-cdk-lib.aws_elasticloadbalancingv2 module · AWS CDK やってみよう スタックファイルにてALB の作成を定義した後に、以下のように logAccessLogs メソッドを使用して ALB のアクセスログを有効化できます。 第一引数に S3 バケットオブジェクト、第二引数にログを保存する S3 バケット内のプレフィックス（フォルダパス）を指定します。 ALBのアクセスログ配信はAWS管理のELBログ配信アカウントから配信されるので、S3バケットには適切なバケットポリシーを事前に付与してください。 設定は以下のリンクを参照してください。 Application Load Balancer のアクセスログを有効にする – エラスティックロードバランシング 　// ALBの作成   const alb = new elasticloadbalancingv2.ApplicationLoadBalancer(this, 'ALB', {       vpc: tokyoVpc,                 // ALBを配置するVPCを指定       internetFacing: true,          // インターネット向けALBとして設定       securityGroup: albSg,          // ALB用のセキュリティグループを指定       vpcSubnets: { subnets: vpcPublicSubnets },  // ALBをパブリックサブネットに配置       loadBalancerName: 'tokyo-alb',  // ALBの名前を指定       }); 　　　　 // アクセスログをS3バケットに保存する設定       alb.logAccessLogs(albAccessLogsBucket, 'alb-accesslogs'); bin配下のappは以下のように定義してデプロイしてみます。 const app = new cdk.App(); new AlbStack(app, 'AlbStack', { }); そうすると、以下のリージョン指定が不足しているというエラーが発生してデプロイが失敗します。 ValidationError: Region is required to enable ELBv2 access logging at path [AlbStack/ALB] in aws-cdk-lib.aws_elasticloadbalancingv2.ApplicationLoadBalancer   logAccessLogsメソッドを確認していきましょう。 確認するとリージョンを明示的に指定する旨の説明文と実装方法が記載されたURLがありました。 class ApplicationLoadBalancer (construct) · AWS CDK   logAccessLogs(bucket: s3.IBucket, prefix?: string): void;   /**    * Enable connection logging for this load balancer.    *    * A region must be specified on the stack containing the load balancer; you cannot enable logging on      * environment-agnostic stacks. * * @see https://docs.aws.amazon.com/cdk/latest/guide/environments.html */ 解決方法 解決方法として一例ですが、appファイルにenvとしてリージョン名を明示的に指定することでデプロイが可能になります。 const app = new cdk.App(); new AlbStack(app, 'AlbStack', { 　env: { region: 'ap-northeast-1' } // 東京リージョンを指定する例 }); 設定を追加するとデプロイが成功し、ALBにアクセスログが設定されました。 以上となります、CDKでの実装の参考になれば幸いです。

皆さんこんにちは！SCSKの鳴島です！ 今日はBasecampフロアに出展しているパートナーブースを周ってきました🚶‍♀️ 日本国内に展開されていないプロダクトを含め、デモやお話を伺ってきましたので、レポートしていきます！ 注目パートナーブース atlan 現代のデータチーム向けのアクティブメタデータプラットフォームを提供しており、データカタログ領域にて、業界リードする存在です ※現時点では日本国内にパートナーは無し ブースでは、簡単にデータリネージのデモを見せていただきました。 オリジナルデータソースがPostgresDBからSnowflakeにデータ投入し、LookerやTableauなどのBIツールで可視化しているデータパイプラインについて、カラムレベルでリネージします。 機能も充実しており、価格もそれなりということで、大規模でデータ活用を行っているかつ、予算をかけられるユーザー向け、といったところのようです。 Column-Level Lineage | Atlan Why settle for table-level lineage when you can have column-level confidence? atlan.com   hightouch 主にリテールのマーケティングやカスタマーエンゲージメント向けに開発されているプロダクトです。 Snowflakeなどに貯めたデータの分析結果から、SQL不要でメールの送付やアプリケーションへのバウチャー配布など、顧客への販促施策を打つところまで、自動でできる仕組みを持っています（リバースETL）。 個人的には、恥ずかしながリバースETLという言葉を、今回のイベント参加で初めて耳にしました。。。😅 マーケティングなどの意思決定の迅速化にとても魅力的なプロダクトであると思います。 Hightouch Reverse ETL | Sync data in minutes Get data into more hands throughout your organization.
No messy scripts or CSV uploads — just SQL. hightouch.com   sigma Basecampフロアに入ると、必ず目に入るのがsingmaブース。 今回出展しているパートナーの中でもHELI-SKI Tierという、前例のない最高Tierで出展をしています。 ソリューションとしては、クラウドネイティブのBI・データ分析ツールを提供しており、スプレッドシートライクなインターフェースでデータ分析ができるのが1番の特徴です！ BIツールを使う人の中で、分析結果をExcelベースでダウンロードし、そこから独自でデータ操作して。。。ということをする方も少なくないのでしょうか。 sigmaが提供するツールは、ExcelやGoogle Sheetsのような使い慣れているかつ、Snowflakeとも接続し、分析したデータをクラウド上でデータ操作ができることが魅力のようです。 ※現時点で日本国内にコンサルティングパートナーは無し Spreadsheets | Sigma Data analysis in spreadsheets. The way you already know how to. You don’t need coding skills to analyze massive datasets... www.sigmacomputing.com   感想 それぞれのブースで展示されている製品の画面を見ると、どの製品も見分けが全くつかないほど同じようなUIで、行き着く先はここなんだなーと思いました笑 日本未上陸の企業も数多く出展しており、初めて聞く企業の方と「SCSKという日本のIT企業から来ました」という自己紹介から始まり、プロダクトのヒアリングや質問をするのは、海外カンファレンスだからこそ経験できることと思います。 ときどき技術関係なく、ブースにいる方とメイクやファッションの話で盛り上がったりもしました笑   おまけ　~ イベント中のランチ🍙 ~ イベント２日目は会場で提供されるランチをいただきました。 世界中から、Snowflakeユーザー／パートナーが集結するため、こちらのビーガンやベジタリアンにも対応するランチボックスが提供されていました。 私はオレンジのハムサンドイッチをチョイス。ポテトチップス🥔とチョコチップクッキー🍪はご飯扱いのようです。 丸ごと一個、雑多に入っているプラムに、とてつもないUS味を感じました🇺🇸 ３日目の今日は元シリコンバレートレイニーのBobさんから教えてもらったハンバーガー屋さんに行ってきました。 お店の名前が入っている定番のスーパーバーガーとおすすめのガーリックフライをオーダー。 フライドポテトにチーズがかかっているという、ハイカロリー必至の組み合わせですが、カロリーは熱に弱いし、海外出張中なので０キロカロリーです。 このイベントも明日がラスト！！楽しみたいと思います！！ Have a good one:D [速報] Opening Keynote K1（Mon, June 03, 05:00 PM PDT） 概要 [現地写真] Keynote HALL会場の様子 セッションサマリー おまけ：現地会場（Moscone Center）の様子 最後に

こんにちは。SCSK株式会社　中村です。 5/13(火)に当社でAWSのカードゲームイベントが開催されましたので参加してきました。 当記事は AWSの業務に携わることになったけど、サービスの種類とかあんまり知らないなあ とか 色々なAWSサービスの組み合わせを知りたいけど今の現場だと決まったパターンしか触れないからいい方法ないかなあ と考えている AWS業務従事初心者 にはとても有意義な記事かと思いますので是非ご一読いただければ幸いです！ 参加したきっかけ 当方AWSサービス業務には関わったことがないのですが、将来的にクラウド案件に携わってみたいという思いがありました。 そんな中今回のイベントは”初心者でも問題なし！”ということでしたのでその触れ込みに惹かれて恐る恐る応募しました。 なお、資格として「AWS Certified Solutions Architect – Associate(AWS SA-A)」は2年ほど前に取得している状態です。 そんなAWS初心者でも実際楽しめたのか？ゲームを通して知見を深めることができたのかレポートしたいと思います！   AWS Builder Cardsとは AWS BuilderCards は、Amazon Web Services が提供するクラウドサービスや、サービスを組み合わせたアーキテクチャを学べるカードゲームです。 実際にゲームを経験してみて自分でも購入してみたいなあと考えたのですが、なんと現状BuilderCardsは一般販売されていないとのこと、、！手に入れるにはAWSのイベントに参加することで配布されることがあるのでそこで入手するしかないという意外とレアな代物となっております。 英語版と日本語版があるのですが、日本語版は人気ですぐに無くなってしまうようです。。   ゲームアイテム紹介 ※注意 今回私が参加したグループはおそらく自由度が高く、マニュアルは用意されていたものの英語表記なのでちゃんと読める人もそんなにおらず、「この場合どうするんだっけ？」「よく分かんないけどこの場合はこうしよう！」みたいなノリで実施されました。ですので、 本来のルールと異なることを記載している場合がございます のでご了承ください。 ～カードの種類～ ・ Starter Card(スターターカード) 最初にプレイヤーが手にするカードです。(10枚配られる) オンプレ環境にあるサービスや機器群という解釈で、このスターターカードは基本的には何も効果を持たないゴミ的なカード。(一部AWSカードと組み合わせて使用するということもできる) これらのカードを最終的にAWSサービスのカードに置き換えていき、様々なAWSサービスを作り上げていくのがこのゲームの主となる考え方となります。 ・ Builder Card(ビルダーカード) マーケットプレイスというフィールドから取得できる様々なAWSサービスのカードです。 無料で取得できるものと、コストを支払って取得できるものの2種類があります。 オレンジの丸で記載されているのがコスト ・真ん中に記載されているコスト＝そのカードが持つコスト ・右上に記載されているコスト＝そのカードを取得するために必要なコスト ・ Well-Architected Card(ウェルアーキテクテッドカード) 勝利点となるカード。 BuilderCardsは最終的にこのカードの総点数が多い人の勝ちです。 このカードもマーケットプレイスからでしか取得できません。 コストを支払ってビルダーカードを充実させて高いコストを作れる環境を整えるか、早期にWell-Architectedカードを集めて点数を稼ぐかがプレイヤーの色が出るところであり醍醐味となります。 ～プレイマット～ ・Market Place(マーケットプレイス) 山札(場に積んでおくカード)やWell-Architectedカードがおかれるフィールド的な場所です。以下用途ごとに説明を記載します。 ①取得コストなしのビルダーカードの山札置き場 ②Well-Architectedカード置き場 ③取得コスト有のビルダーカードの山札置き場 ④取得コストなしのビルダーカードの展開場所 ⑤取得コスト有のビルダーカードの展開場所 ・Player Mat(プレイヤーマット) 各プレイヤーが手札からカードを展開していく場所です。人数分用意されますが、最悪なくてもプレイはできます ①Well-Architectedカード置き場 ②リソースパネル →プレイヤーが自分のターンを始めるまでカードを置いておく場所です。裏向きで置きます。 ③プレイヤーエリア →手札のカードを展開する場所です。 ④捨て札パネル →そのターンで使用済みのカードを置く場所です。表向きで置きます。   基本ルール ～初期準備～ 最初はスターターカードを色ごとにわけて各プレイヤーに10枚づつ配ります。 ビルダーカードをコストなしとコスト有で分けて、それぞれよくシャッフルしたらマーケットプレイスに配置します。 Well-Architectedカードもマーケットプレイスに配置します。 プレイヤーは自分のスターターカードをシャッフルしてリソースパネルに配置します。 プレイヤー間でプレイする順番を決めます。 ～ゲームスタート～ 自分のターンになったらリソースパネルの山札から5枚引いて場に展開します。 展開したカードでAWSサービスをデプロイ(サービスの起動/実行)できるのであれば、 どのようにサービスをデプロイするか他のプレイヤーに説明しながらデプロイを実行します。(これ重要です)　 この時、場に展開したカードは何枚使っても大丈夫です。 ※デプロイできない場合は、マーケットプレイスにあるコストなしのビルダーカードを1枚選んで取得してターンを終えます。 上記のデプロイが有効だと他のプレイヤーから了承を得ると、デプロイに使用したビルダーカードが持つコストを得ることができます。 プレイヤーはコストを使って、ビルダーカードを取得したりWell-Architectedカードを取得します。 ※ビルダーカード、Well-Architectedカードはそれぞれ1ターンに1枚のみ取得できます。 カードの取得が完了したら次のプレイヤーにターンが移ります。 各プレイヤーのターンが1周して終了したら2周目です。取得したビルダーカードとスターターカードを混ぜてカードをシャッフルし、再度リソースパネルに配置します。 これ以降は6～10の繰り返しで、最終的にマーケットプレイスにあるWell-Architectedカードが全てなくなった時点でゲーム終了。 ゲーム終了時点でWell-Architectedカードの総点数が一番多い人が勝者となります。   とりあえずやってみる！ つらつらアイテムの紹介やルールを書きましたが、とりあえずやってみないことにはなんのことやらという感じなのでやってみましょう！ ↑上記はプレイ中盤で撮った写真です。(見返すと捨て札パネルにカードを裏向きで置いたり、細かいとこ間違えちゃってますね。。) 順番を決めて一人ずつターンを消化していくんですが、最初はスターターカードしかないのでひたすらマーケットプレイスからビルダーカードを拾っていく作業が続きます。これは誰がやってもだいたいそうで最初の3～5ターンくらいはビルダーカードを集める作業だと思います 戦いの狼煙は突然に、、 そんな感じで4周ほどカード集めが続いてる時に私の対面に座る方のターン じゃあ私はこのVPCを使ってEC2をデプロイしますね。VPCが1コスト、EC2が2コストなので計3コストかな 私の心の声：(おぉ、なんか宣言が始まった、、！) ※これ以降、現場で感じた私の心の声はかっこ書きでお届けします うんうん、ベーシックなパターンですね。問題ないと思います 宣言に対して他のプレイヤーの方が了承する。 (へぇ、ベーシックなパターンなんだ、、)ド初心者の私は心の中でそう思う Well-Architectedカードも取れるけど、、まだ手札充実させたいからとりあえずEFSもらおうかな (ふむふむ、たしかにビルダーカードは各々3～4枚は取得しているけど、スターターカード10枚に対してビルダーカードの数が心許ないしな ただ、、、 デプロイする時に説明しなきゃいけないのはド初心者には無理ではないか！！！ これはAWSを実際に触ってたり、ある程度知識がある人じゃないと機能なんて分からないし何もできないんじゃないのか？) とんだ場違いな場所に来てしまったかもしれない。そう私は心の中で途方に暮れていた。 途方にくれていた時の光明 そんな私が勝手に途方にくれている中、ターンが次の方に移る うーん、じゃあ私もEC2を単体デプロイするんですけど、それに対して”OpenSearch”でログ解析するってやり方は問題なさそうですか？ うん、いいんじゃないですかね。問題ないと思いますよ へえ、そういう組み合わせもいけるんですねえ。いいと思います！ (おぉ、なるほど、別に 完全にサービスの組み合わせを把握してなくても相談ベースで進めることもできる のか) ありがとうございます！じゃあ、これで私もコストが計３使えるのでWell-Architectedカードもらっちゃおうかな Well-Architectedカード早めに取らないと点数稼げないですからねえ、私も次のターンで何か作れないかなあ (ふむふむ、確かに。どんなに良いビルダーカードを揃えてすごいサービスをデプロイしても最終的にWell-Architectedカードを持ってないと勝つことはできないからなあ。ビルダーカードとWell-Architectedカードの取得の兼ね合いがゲームの肝だなあ) 見様見真似でデプロイだ！ 幸い、私以外のお三方はみなBuilderCardsの経験者だったので上記で書いたようなやり取りを見たり、ゲームの手順を教えてもらったりしながら自分のなかの理解を深めていきました。 そして、ゲームの中盤では自分でも他の人が使ったデプロイの真似などを駆使してサービスの組み合わせができるようになってきました！ えーとー、じゃあVPC使ってEC2をデプロイしてWebサービスを立ち上げて、そのデータをEFSを使って格納するって感じでいけそうでしょうか、、？ いいすね ありだと思います 問題ないです！ (おぉ、認められた、、！この時点では既に何回も出たようなパターンのデプロイだし なんとなくみんな淡泊な返事だが、いざ自分が宣言して認められると嬉しい、、！) 2年前にAWS Certified Solutions Architect – Associateを取得してそれっきりクラウド業務に携われなかった自分のようなド初心者でも1時間ほどでBuilderCardsを楽しめている、、！ しかもプレイしながら様々なAWSサービスの組み合わせを覚えることができるから、遊びながら学習しているような気持ちになる！   まとめ 結果的に今回のBuilderCardsは3時間ほどの時間がありましたが、終わってみればあっという間に時間が過ぎるほど楽しめていました。 通常のカードゲームと違うところはやはり 自分でＡＷＳサービスを組み立てて、それを他者に説明してポイントを得る ということですね また、今回のイベントにはAWSアンバサダーの方が2名ほどいらっしゃっており、デプロイに悩んでいるプレイヤーがいると「このサービスってこういう使い方できるんですよね」などとアドバイスをくれて、それによってさらに知識をつけることもできました。 さて、イベント参加前に心配していたド初心者でも楽しめるのか？というお題については 正直に言うとAWS業務に携わっていなかったり、私のようにAWS Certified Solutions Architect – Associateを取得してからある程度時間が経っている方には難しいです 多分ほんとにAWSの知識が何もない方がプレイしたとしたら終始意味が分からないまま終わってしまうのではないでしょうか。 単純なカードゲームではなく、あくまで AWSサービスを楽しく学習するためのツール という捉え方が良いと思います。 ただ、絶賛AWSを勉強中だったり業務に携わりだした初心者の方にとっては非常に有効な学習方法になる と感じました。 自分の知らないAWSサービスの組み合わせを知る機会 にもなりますし、ゲームの中で知った組み合わせを自分でも真似して作って宣言することで、 即座にインプット＆アウトプットを行うことができ知識としてとても身に付きやすい と感じました。 あとこれは想像ですが、自分の現場と似たような環境が作られたときに、BuilderCardsで作られた構成がヒントとなり自分の現場にも反映できるのでは？という気づきにもなりそうな気がしました。 私自身も今回の経験でまたAWSへの興味が上がってきましたので、自分自身もAWS業務に携われるように資格取得などの勉強頑張っていきたいと思います！ぜひみなさんも機会があればBuilderCardsイベントに参加してみてください！

サンフランシスコからこんにちは🌉 SCSKの松岡です。 サンフランシスコで開催されている、Snowflake Summit 25速報記事の第二弾です。 今回は、6/3のPlatform Keynoteで紹介された最新のサービスアップデート情報を中心にお届けしたいと思います。 6/2のOpening Keynoteに関する記事はこちら↓ 【現地レポート：Day1】Snowflake Summit 25開幕！（Opening Keynoteまとめ） Snowflake の最大のイベント、Snowflake Summit 25が San Francisco🦀 にて開幕しました！！ 本記事では、4日間に及ぶSnowflake Summit 25 の「Day1開幕」として、現地の情報を皆さんにお届けしていきます！！ blog.usize-tech.com 2025.06.03 Platform Keynote K2 (Tuesday, Jun 03, 09:00 PDT)概要 Snowflake | Summit 25 Snowflake | Summit 25 reg.summit.snowflake.com 🎪会場の様子 会場はOpening Keynoteと同じホールでした。 昨日と変わらない盛り上がりの中、盛大な音楽とともに始まりました！ 📝主なアップデート（セッションメモ） セッション中に発表された主なアップデートを一気にご紹介します！ 生成AI  OpenAI、Anthropic、Meta、Mistralのような、主要なAIモデルが利用可能   コスト管理 組織全体のコスト管理を1つのビューで可能に アンバランスなコスト消費を通知でお知らせ   ADAPTIVE COMPUTE ウェアハウス管理の複雑さを解消するための機能 ポリシーを指定することで、Snowflakeが自動で最適なコンピュートリソースの選定やスケーリングを実施 Snowflake Unveils Next Wave of Compute Innovations For Faster, More Efficient Warehouses and AI-Driven Data Governance SAN FRANCISCO – June 3, 2025 – Snowflake (NYSE: SNOW), the AI Data Cloud company, today announced at its annual user con... www.snowflake.com   SNOWPIPE 価格体系の簡素化 データ量に基づくシンプルな価格体系に変更 最大50%のコスト削減も可能に   HORIZON CATALOG データの自動分類、追跡、AIモデルのRBAC制御などが可能に Copilot for Horizon Catalogにより、操作や管理がより簡単に Power BIやTableauなど外部サービスもデータソースとして可視化可能に https://x.com/Snowflake/status/1929940350396953005 x.com   SNOWFLAKE OPENFLOW 数百種類のコネクタが用意されており、構造化/非構造化データのパイプライン構築が容易に Oracleとの提携により、スケーラブルでコスト効率の高いCDCソリューション提供を実現 Snowflake Openflow Unlocks Full Data Interoperability, Accelerating Data Movement for AI Innovation SAN FRANCISCO – June 3, 2025 – Snowflake (NYSE: SNOW), the AI Data Cloud company, today announced at its annual user con... www.snowflake.com   SNOWPIPE STREAMING レイテンシの低減とスループットの向上を実現   DBT PROJECTS DBTプロジェクトがSnowflake上でネイティブに実行可能に WORKSPACESのUIを刷新。ソース管理やDBT編集がブラウザ上で完結 ※近日プレビュー公開予定   ZERO-ETL DATA SHARING ETLに伴う煩わしさを解消し、データアクセスの制御を維持しながら、安全なデータ共有を実現   SNOWFLAKE POSTGRES PostgreSQL互換のマネージドサービス Crunchy Dataの買収により開発が加速 Snowflake Acquires Crunchy Data to Bring Enterprise Ready Postgres Offering to the AI Data Cloud Empowering enterprises across industries to build and deploy secure, compliant AI agents and applications with Snowflake... www.snowflake.com   GEN2 WAREHOUSES 分析、データエンジニアリングワークロードのパフォーマンス向上に重点を置いた次世代の標準ウェアハウス Snowflake generation 2 standard warehouses | Snowflake Documentation docs.snowflake.com   DATA SCIENCE AGENT データサイエンティストがMLモデルの開発から運用までのプロセスを迅速かつ効率的に進めるための支援を行うエージェント機能 ※近日公開予定 Snowflake Intelligence and Data Science Agent Deliver The Next Frontier of Data Agents for Enterprise AI and ML SAN FRANCISCO – June 3, 2025 – Snowflake (NYSE: SNOW), the AI Data Cloud company, today announced at its annual user con... www.snowflake.com   CORTEX AISQL 生成AIをクエリに組み込んで利用できる機能 画像や音声をインプットにできる独自関数を使用したマルチモーダルな分析 新しいデータタイプを用いた非構造化データの参照 条件を自然言語で指定したジョイン処理 AI集計関数による可視化 Snowflake Introduces Cortex AISQL and SnowConvert AI: Analytics Rebuilt for the AI Era SAN FRANCISCO – June 3, 2025 – Snowflake (NYSE: SNOW), the AI Data Cloud company, today announced at its annual user con... www.snowflake.com   SNOWFLAKE INTELLIGENCE ノーコードでAIが使える新しい会話型データエージェント Snowflake Intelligence and Data Science Agent Deliver The Next Frontier of Data Agents for Enterprise AI and ML SAN FRANCISCO – June 3, 2025 – Snowflake (NYSE: SNOW), the AI Data Cloud company, today announced at its annual user con... www.snowflake.com   ✉メッセージ Keynoteの最後に、Snowflakeによって以下のようなことが実現できるとありました。 YOU CAN GET BETTER ECONOMICS → より優れた経済性（コスト効率）を実現できる YOU CAN GOVERN ALL DATA → すべてのデータをガバナンス（管理・統制）できる YOU CAN INTEGRATE ALL TYPES OF DATA → あらゆる種類のデータを統合できる YOU CAN DELIVER MORE BUSINESS IMPACT → より大きなビジネスインパクトを生み出せる YOU CAN GET FASTER INSIGHTS → より迅速にインサイト（洞察）を得られる YOU CAN LEVERAGE AI WITH YOUR DATA → 自社のデータを活用してAIを利用できる YOU CAN ACCELERATE BUSINESS GROWTH WITH AI AGENTS → AIエージェントによってビジネス成長を加速できる 「データのすべてのライフサイクルをを包括的にサポートする」という意思が強く伝わってくる最後のメッセージでした。   最後に(感想) 初日、二日目のKeynoteともに、 「Simplify（シンプル化）」 というワードが繰り返し使用されていたのが印象的でした。 今回のSnowflake Summitでは、AIを高度な分析ツールとしてではなく、 誰もが自然に使える機能として組み込む という方向性が明確に示されていたように感じました。 「シンプルさを中核価値とする」という発言の通り、発表されたアップデートは、操作性やユーザー体験を洗練させるものが多く、特にAIについては、専門家だけでなく、日常業務に自然に組み込んで活用できるレベルに進化していることが伝わってきました。 昨年のサミットでは、AIに関する内容が中心的に掲げられながらも、なかなか実用には至らなかった方もいたのではないかと思います。しかし今回のアップデートによって、AIによるデータ利活用がより身近に、より実務で活用できるようになるのではないかと感じました。 発表された多くの新機能の中について、気になるものから調査や検証してみたいと思います！  

こんにちは。SCSKの北川です。 今回はServiceNowとElasticを連携させる方法をご紹介します。 この連携によって、Elasticで検知したアラートをServiceNowに送信し、インシデントとして記録・管理することが可能になります。 本記事は執筆時点（2025年5月）の情報です。最新の情報は製品ドキュメントを参考にしてください。 連携手順 事前準備(Elastic) Elasticで新規ルールを作成します。 作成手順の詳細は Create and manage rules | Elastic Docs を参照してください。 Elastic for ITSMを取得 Elastic for ITSM – ServiceNow Store より ServiceNow Storeにサインイン後、[Get]を押下します。 「Ready to install」になっていることを確認します。 アプリケーションのインストール ServiceNowの環境にログインし、System Definition>Plugins を選択します。 Application Managerから「Elastic for ITSM」を選択後、[Install]を押下します。 ServiceNow Storeから取得後、Application Managerに反映されるまで時間がかかる場合があります。 [Install]ボタンが表示されなくなったことを確認します。 クロススコープ権限の割り当て アプリケーションスコープを「Elastic for ITSM」に変更します。 Cross scope privileges[sys_scope_privilege]テーブルを開きます。 6つのクロススコープ権限のステータスが「Allowed」になっていることを確認します。 ユーザーの作成 System Security>Users and Groups>Users よりElasticと接続するためのユーザーを作成します。 ユーザーIDおよびユーザー名には、任意の値を設定してください。 作成後、以下4つのロールを付与してください。 x_elas2_inc_int.integration_user personalize_choices import_transformer import_set_loader Password needs resetにチェックが付いている状態では正常に接続できないため、チェックが外れていることを確認してください。 CORSルールの作成 アプリケーションスコープが「Elastic for ITSM」になっていることを確認します。 System Web Services>REST>CORS Rules を選択後、CORSルールを作成します。 以下の項目を設定後、[Submit]を押下します。 Name：任意の文字列 REST API：Elastic ITSM API[x_elas2_inc_int/elastic_api] Domain：KibanaのURL HTTP Methods：「GET」を選択 以上でServiceNow側の作業は完了です。 接続確認 最後に接続確認を行います。 Elasticで作成したルールを開き、[Edit rule]を押下します。 Select a connector typeから「ServiceNow ITSM」を選択してください。 次に[Create a connector]を押下します。 必要な項目を入力後、[Save]を押下します。 Connector name：任意の値 ServiceNow instance URL：ServiceNowのURL(https://〇〇〇〇〇.service-now.com) Username：「ユーザの作成」で設定したもの Password：「ユーザの作成」で設定したもの 接続確認のため、Ruleが「Enabled」になっていることを確認してください。 Elasticからアラートを発生・検知後、ServiceNowのインシデントテーブルを開き、 インシデントが作成されていることを確認します。 以上がServiceNowとElasticの連携手順です。 レコードを開き、Elasticで設定した内容と一致することをご確認ください。 まとめ 今回はServiceNowとElasticの連携方法についてご紹介しました。 今後の業務の中で、少しでも参考になれば嬉しいです。

皆さんこんにちは！SCSKの鳴島です。 Snowflake の最大のイベント、Snowflake Summit 25が San Francisco🦀 にて開幕しました！！ 今年のSnowflake summitのテーマは “Build the future together with AI and APPs” “AI・アプリと共に未来を築く” です✨ 現地時間6月2日(月)-5日(木) の4日間にわたり、 基調講演や、先進事例セッション、テーマ別のブレイクアウトセッションなどなど、 最新の技術動向や事例などなど170を超える Snowflake のあらゆることに関するセッション が用意されております。 本記事では、4日間に及ぶSnowflake Summit 25 の「 Day1 開幕 」として、現地の情報を皆さんにお届けしていきます！！ [会場の様子]Moscone Center 現地に到着🚶 雪山、ゲレンデをイメージしたとても可愛らしいテーマの装飾で会場が盛り上がっています❄️ ↓Moscone Center ↓BadgeをGET!! ↓展示会場マップ ↓Data Superheroesのみなさん🦸💃   Opening Keynote(Mon, June 02, 05:00 PM PDT) 概要 Keynote Hall🎪 現地時間5PMから開始となる、本イベントのOpening Keynote。 開始の約一時間前から新しい発表を待ち望む長蛇の列が。。。 Keynote Hallに入ると、音楽のLive会場かのようなワクワク感を掻き立てられる雰囲気に包まれていました。 オープニングトーク はじめに、CEOのRamaswamy氏からの歓迎・感謝の言葉とともに、Snowflake社CEOに就任した昨年からこの一年間で以下の２つを大切にしてきたと、冒頭挨拶がありました。 顧客やパートナーの声を聞き、その言葉を大切にすること Innovation また、以下の点について言及がありました。 データの価値と共に、データによりすべての企業が変化し続けるべきであること また、アストラゼネカ社の事例を元に、データが生命科学分野にも応用し、人々の生命へ価値創出など社会貢献にもつながる存在であること Crunchy dataの買収 対談 以下の３セッションにて、事例やテクノロジーのハイライトがありました。 NYSE Group – President Lynn Martin氏（ニューヨーク証券取引所） 1日１兆を超える金融データのトランザクションにSnowflakeが使用されていることの事例。 金融データというクリティカルかつ、膨大なデータにも対応できるSnowflakeの高性能・信頼性 （US国防省　Impact Level 5)について強調。 Open AI – Founder & CEO Sam Altman氏 企業リーダーへのAI活用の助言として、とにかく始める、やってみてほしいとのこと。 また、AGI（人工汎用知能）について、強く言及。 LA2028オリンピック・パラリンピック　パートナーシップ  – Chairperson Casey Wasserman氏  – US Olympic & Paralympic Properties John Slusher氏 世界的イベントでのパートナーシップを発表。 開催17日間で1200万枚のチケットの販売等にSnowflakeを活用。 世界最大のスポーツイベントにて、データ活用による最高の体験を提供したい。   Opening Keynoteを聴いて テーマとなっている、 “Build the future together with AI and APPs” について、 多くの仕事や活動は突き詰めると社会のため、人のためということになると思いますが、データによりそれを実現したい、データがそれを実現できるというメッセージ性をCEOのRamaswamy氏の言葉からも強調されるKeynoteだったと感じます。 普段、データを扱う業務を行う中で、目の前の課題に気を取られ本質を見失いがちです。 CEOのRamaswamy氏もCEOとして顧客やパートナーの声を聞くことに注力した一年だったと述べていましたが、技術の先の社会貢献であり、それは人の声に耳を傾けるからこそ本質を捉え、実現できることであると思います。 私もデータエンジニアの端くれとして、データの価値を高めると共に、その先に本質として社会貢献があることを忘れず、技術のアップデートはもちろん、サービス・ソリューションの提供をしていきたいと改めて感じました。 ❄️ Day1は主にCEOからのキーメッセージを中心としたKeynoteでした。 明日はいよいよ技術アップデートのKeynote・セッションとなります！！ どんなニュースが発表されるのでしょうか！？   おまけ 現地入りまでに、資格取得しました！ 今回のSnowflake summit参加にあたり、Snowpro Core資格を取得しました！！（2025/5/30取得←ギリギリすぎるだろ！！！） Snowflake Universityブースで資格取得を証明すると、以下のグッズを貰えました！ 資格の受験記は帰国後にゆっくり、こちらのブログに投稿したいと思います！ 今日はこの辺で！また明日もSnowflakeの世界にDeep Diveしたいと思います！ Have a good day:) [速報] Opening Keynote K1（Mon, June 03, 05:00 PM PDT） 概要 [現地写真] Keynote HALL会場の様子 セッションサマリー おまけ：現地会場（Moscone Center）の様子 最後に

こんにちは、SCSKの佐藤優音です！ 先日5月13日(火)、当社オフィスでAWS BuilderCardsを使ったイベントを開催してみました。 当社としては初めてのAWS BuilderCardsを用いた勉強会でしたが、当日はAWSのビギナーから猛者まで幅広い方々に参加いただき、想像以上に盛り上がりました！ 今回はその体験レポートと、実際に参加した方の率直な声をシェアしたいと思います。 そもそもAWS BuilderCardsって？ AWS BuilderCardsは、AWSのサービスやアーキテクチャをカード形式で学べるツールです。 オンプレミス環境のスターターカード、AWSサービスのビルダーカードを駆使してアーキテクチャを構築し、Well-Architectedカードを競って勝負する対戦型のゲームとなっています。 詳しいルールなどは過去にブログにてまとめておりますので、興味のある方はぜひご覧ください！ AWS BuilderCards のルールをわかりやすく解説してみた AWS BuilderCardsの遊び方を初心者にもわかりやすく解説。カードの種類、ゲームのセットアップ、ターンの進め方から勝利条件まで、丁寧に紹介します。 blog.usize-tech.com 2025.03.31   イベント企画のきっかけ 最近、IT以外のニュースでも「クラウド」という言葉を耳にする機会が格段に増えました。 それに伴いAWSに関する話題を耳にする機会も徐々に増えてきたように感じます。 でも、いざ「AWS学習を始めよう！」と思っても、どこから手をつけていいかわからないのが本音だと思います。 特にAWSに触れる機会のない人にとってはとんでもないハードルの高さではないでしょうか？ 従来の資格勉強や公式ドキュメントの読み込みなどもどうしても「お勉強感」が強くて、初心者向けの勉強会を開催してもなかなか参加率がよくないのが正直なところです。 そこで、ゲーム感覚で自然にAWSサービスに触れることができ、みんなでワイワイ楽しみながら学習の第一歩を踏み出せそうなAWS BuilderCardsに着目をしてイベントを企画いたしました。   実際のイベント内容 参加者とセットアップ 参加者：17名（社外からも４名参加いただきました！） 時間：2時間半を予定（長めにとったのですが、意外と時間ギリギリでした…！） 場所：当社会議室（定員100名程度） AWS BuilderCards経験者率：25% 事前準備として、BuilderCardsのプレイマットや簡易的なルールシートを印刷しておきました！ まだ日本語版のドキュメントがないのが残念ですが、このおかげでゲームが進めやすくなったのではないかと感じています！ ゲームの進行 BuilderCardsはゲームルールが意外と多くため、イベント冒頭にはざっくりとした説明をして、あとは実践していく中で適宜説明を加えていきました。 最初は探り探り進めていた参加者の方々も、30分も経つとベテランの方がビギナーの方にアーキテクチャ構築のアドバイスをしたり、気になった点を共有しあう場面が見られました！ 「わからないを認め、積極的に共有する」 ことをグランドルールとして冒頭に提示したこともあり、白熱したバトルが繰り広げられました！ 参加した方々からもご好評いただけました！ 参加いただいた方に実施したアンケートから、率直な感想を抜粋して掲載いたします！ AWSの各種サービスの機能やサービス同士のつながりについて、うろ覚え・曖昧だった部分を再確認するきっかけになった。 BuilderCardsでは幅広いサービスが登場するので、普段触らないサービスは意外と「なんだっけ…」となりがち。 アーキテクチャを構築する際にメンバーからのアドバイスを経て理解を深められるのもBuilderCardsのいいところなのかもしれません！   初心者からベテランまで分け隔てなく楽しむことができた。ベテランと初学者の交流を深めるとても良いイベントだった。 カードゲームかつ経験者が少ないという性質上、AWSの知識量のかかわらずコミュニケーションをとりながら楽しむことができたという声も多くありました。 AWSの学習となると一人で黙々とハンズオン…というイメージがあるかもしれませんが、コミュニケーションをとりながら学べる点gなカードゲームならではですね！ AWSを活用している他部署の方々と知り合うことが出来た。普段は案件業務関係者以外と関わる機会に乏しい為、他部署でAWSを活用している方々と知り合うことが出来たのが嬉しい。 今回のイベントは社内外から幅広い所属の参加者が集まっての開催となりました。そのおかげもあり初心者からベテランまでの縦のつながりだけでなく、部署・会社をまたいだ横のつながりを持つことができたという声もいただきました。   イベントを振り返って 本イベントを振り返って、コミュニケーションをとりつつAWS学習の促進ができる AWS BuilderCardsのポテンシャルを強く感じることができました。 AWS学習というと、どうしても堅いイメージがありますが、こういうカジュアルなアプローチも有効だと実感しています。 ですが、ゲームのルール理解に時間がかかる点や、イベント全体の進行など今後の課題も見つかったため、次回は多くの方によりスムーズな進行で楽しんでもらえるように改善をしていきたいです！ 次回の開催日程が決まりましたら、こちらのブログにも追記という形で告知いたしますのでお楽しみに！

Palo Alto Networks社が2025年2月13日、クラウドネイティブアプリケーション保護プラットフォーム(CNAPP)であるPrisma Cloudの次世代版として、 Cortex Cloud を発表 しました。Cortex Cloudは2025年度第3四半期後半に一般提供される予定とのことで、まだ利用はできません。 本記事では、 Cortex Cloudに関する記事 を読んで理解したことを前世代となるPrisma Cloudと比較しながら、違いを説明し、Cortex Cloudについて解説していきます。 なお、本記事ではCNAPP、CSPM、CDR自体の詳細な説明は行いません。必要に応じて、これらの用語の意味を確認ください。   Cortex CloudとPrisma Cloudの違い Cortex CloudではPrisma CloudのCNAPPに加えて、同社のCortex XSIAMで提供しているクラウド検知・対応(CDR)機能が利用できるようになります。具体的には、AI駆動型の優先順位付け機能、自動修復機能などが利用できるようになります。 Cortex CloudのAIと自動化を活用したCDRによってSOCチームが効率化され、リアルタイムのクラウドセキュリティ実現を目指せることがPrisma Cloudとの違いなのだと思いました。 項目 Prisma Cloud Cortex Cloud 位置付け CNAPP 左記に加え、 CDRを統合したプラットフォーム 主な機能 クラウドセキュリティ態勢管理(CSPM) クラウドインフラストラクチャ権限管理(CIEM) データセキュリティ態勢管理(DSPM) AIセキュリティ態勢管理(AI-SPM) Kubernetesセキュリティ態勢管理(KSPM) アプリケーションセキュリティ態勢管理(ASPM) クラウドワークロード保護(CWP) 脆弱性管理 左記に加え、 AI駆動型の優先順位付け機能 自動修復機能など 特徴 コードからクラウドまでのセキュリティをカバー マルチクラウド環境に対応 左記に加え、 AIと自動化を活用したCDR 対象ユーザー クラウドネイティブアプリケーションにおける セキュリティを強化したい企業 左記に加え、 SOCの運用効率を向上したい企業   Cortex Cloudの概要 Cortex Cloudは、リアルタイムでのクラウドセキュリティを実現するために設計された先進的なCNAPPです。このソリューションは、AI主導の自動化機能と統合されたデータを活用し、コードからクラウド、SOCまで包括的な保護を提供します。 主な特徴 : リアルタイムセキュリティ : 脆弱性や設定ミス、漏洩したIDなど、攻撃の可能性がある要素をリアルタイムで検出し、迅速な対策を実行します。 AIと自動化の活用 : 7000以上の検出機能と2400以上の機械学習モデルを駆使して高リスクの脅威を特定。これにより、迅速かつ正確な対応策を提供します。 統合データ管理 : 各種ソリューションの検出結果をCortex Cloudに統合。手作業を省き、意思決定に役立つリアルタイムのコンテキストデータを提供します。 Cortex Cloudは、脅威の検出や対策を効率化し、SOCチームがリスクを迅速かつ効果的に管理できる環境を整えます。また、Cortex XSIAMと連携し、クラウド特有の脅威をリアルタイムで検出するだけでなく、その対策を自動化することで、SOCチームの負担を軽減し、より積極的なクラウド防御を可能にします。   まとめ Prisma Cloudは、クラウドネイティブアプリケーションのセキュリティを提供するプラットフォームであり、コードからクラウドまでのセキュリティをカバーし、マルチクラウド環境にも対応しています。 Cortex Cloudは、上記Prisma Cloudの機能を強化し、Prisma CloudではできなかったリアルタイムのCDR、セキュリティ運用の自動化・統合を実現した次世代のクラウドセキュリティプラットフォームです。   さいごに 当社ではPrisma Cloud利用して、複数クラウド環境の設定状況を自動でチェックし、 設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。 興味のある方は是非、お気軽にお問い合わせください。 マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社

こんにちは！ SCSK株式会社　小鴨です。 皆さん、今年のゴールデンウィークはいかがお過ごしでしたか？ 私は日本を遠く離れ、アメリカのラスベガスへ行って参りました。 目的はただ一つ… ServiceNow最大級のイベント Knowledge 25 　 への参加です！！ Access Denied www.servicenow.com 業界の最前線が一堂に会し、技術の未来を語り合う様子はまるで大きな科学博覧会。 私もそのワクワクする雰囲気の中で多くを学び、たくさんの刺激を受けました。 その経験をここで皆さんと共有したいと思います。 長くなるので複数本立ての予定ですが、気楽にのんびりと読んでもらえればと思います。 概要 「Knowledge」 とは、ServiceNowが主催する年次イベントで 企業や専門家が集まり、最新のServiceNowプラットフォームの機能や革新について学ぶ場です。 …それだけ聞くと ふーん、まあよくある技術者の集いみたいなものか と思われるでしょう しかしことKnowledgeについては桁外れのスケールで開催されます。   まず全体参加者が 約20000人！ 実施されるセッション数は 1000以上！！ こうなってくると逆にイメージが付きにくい数字かもしれませんね。   そして今年のテーマは「Where AI gets to work」 なぜAIを使う必要があるのか なぜServiceNowなのか 我々は何をする必要があるのか こうした情報をこれでもかと詰め込まれる3日間でした！   Knowledge25参加への道のり 申し込み イベントに参加するには当然申し込みが必要！！ ということで公式サイトより申し込みへ！ 2195円！うーん非常にリーズナブル♪　さすが外国の企業は太っ腹ですね！ …なわけないです2195＄です。安く見積もっても30万円こえてます… 気を取り直して 宿も同じサイトから予約できるので早速確認！ いや、こんなお城みたいなとこじゃなくていいですよ本当に… カプセルホテルに毛布だけおいといてくれれば十分なので… 正直なところ、開催一か月前ですが早速プレッシャーを感じ始めてました。 しょうもない成果しか持って帰らなかったらどんな目に合うのだろうと。。。 セッション予約 申し込みが終わったら参加するセッションの予約から始めます。 学生時代の時間割を組むような気分で、興味のある公演を片っ端から予約しました！ 我ながら計画性の無さすぎる時間組…移動時間を考えなさい… やる気の表れということでご愛嬌です ポイントは２つ 1つはキーワードでセッションを絞ること！ 私は実業務では「ITSM」,「ITOM」を使用しているので それらと「AI」タグが盛り込まれているものを重点的に選択しました。 2つ目は同時通訳に対応していること！ 英語に自信がある方は問題ないですが、そうでない方はこれを積極的に選びましょう。 私は英語のみのセッションにもいくつか参加してみましたが 終盤は何を言っているのか分からな過ぎて、もう笑うしかないみたいな状態でした。   いよいよ出国 飛行機にすごい時間揺られていたこと、乗り換えの時間はとにかく眠かったこと 入国審査が怖かったことなど… 思い出はいくつもありますが、そんなミクロな思い出には皆さん興味ないでしょう！ アメリカじゃなくても起こりうることなので、その辺はぐっと飲みこみ割愛させていただきます！ さてついに到着したラスベガス！ あれ？カジノって空港にもあるの？     いろんなものが目につきながらもタクシーに乗り市街地へ 第一印象は騒がしい街だなぁといったところです。 街中には常に音楽が鳴り響き、ネオンが所狭しと輝いており、誰もが常に楽しそうです。 しかし同時に、どこか上品さを感じるような雰囲気もありました。 白が目立つからなのか、道路が広いからなのか、閉塞感のようなものがなく 同じ騒がしい街でも、新宿や池袋とは違うなあという印象でした！   さて、いよいよ予約したホテルが近づいてきました。 正直「実物は予約サイトより数段しょぼいだろうな」と思っていましたね。 日本では何度も騙された手口だし今更驚きはしないぞと。     おぉ…あぁ… 実物の方がすごいパターンは初めてでしたね。 なんていうか身の丈に合わない世界というか、夢の中のような景色に終始圧倒されました。 この日は色々と新たな世界に触れてみたい欲求はあったものの 時差ボケや環境変化のストレスに負けないよう早々に就寝し、ウェルカムレセプションの待つ明日に備えました。 次回予告 次回はKnowledgeが始まる前の前夜祭的なポジションの「JAPAN welcome reception」からお話しします。 ◆日本人交流の場なので英語は不要と油断していたら、英語より難しい言語で話す人たち ◆ServiceNowマイノリティであることを突き付けられた弊社 ◆400人中5位になった私 あたりを語るに始まり Knowledge初日の様子なんかも一気に話せればと思います。 その2からも是非、のんびりとお付き合いいただければと思います。

こんにちは。SCSKの山口です。 今回はBigQuery の外部テーブル機能についてのブログです。 BigQuery の外部テーブルとは？ 概要 外部テーブル機能は、簡単に言うと、Google Cloud Storage (GCS) や Google ドライブなどの 外部データソースに保存されているデータを、BigQuery のテーブルであるかのように直接クエリできる機能 です。 実際のデータは BigQuery の管理下に置かず、外部のストレージサービス上のデータを参照します。これにより、データを BigQuery にロードする手間なくデータ分析が可能といったメリットがあります。 サポートされているデータ形式 BigQuery の外部テーブルは、以下の主要なデータ形式をサポートしています。 CSV (Comma Separated Values) JSON (Newline-delimited JSON) Avro Parquet ORC Cloud Datastore のエクスポート Cloud Firestore のエクスポート 本記事のデモでは CSV 形式を使用します。   外部テーブルを作成する 今回は、Cloud Storage上のCSV形式のファイルを外部テーブルとして作成します。 あらかじめ、Cloud StorageのバケットにCSVファイルを配置しておきます。   BigQuery 画面で外部テーブルを作成 実際に外部テーブルを作成します。 対象のデータセットを選択し、「テーブルを作成」をクリックします。 下記を入力し、「テーブルを作成」をクリックします テーブルの作成元：Google Cloud Storage ファイルの形式：CSV プロジェクト：（プロジェクト名） テーブル：（テーブル名） テーブルタイプ： 外部テーブル これで作成完了です。   詳細を見ると、ソースのURIなどの詳細情報が表示されます。   外部テーブルのクエリ実行 ここから、外部テーブルに対して様々なクエリを実行してみます。 全データを取得してみる SELECT * FROM `yamaguchi_test_exttable.ext_table_GCS`; 問題なくデータが閲覧できました。 フィルタリングしてみる SELECT id, name, value FROM `yamaguchi_test_exttable.ext_table_GCS` WHERE value > 20   AND name LIKE '%e'; 数値型、文字型ともにフィルタリングできました。 集計関数を使ってみる SELECT AVG(value) AS average_value, MAX(value) AS max_value, MIN(value) AS min_value, COUNT(*) AS total_records FROM   `yamaguchi_test_exttable.ext_table_GCS`; 集計関数も問題なく使用できました。   外部テーブルでできない事 ここまで外部テーブルでできることを列挙してきましたが、ここからはできない事を書きます。 外部テーブルは読み取り専用であり、BigQuery を介して直接的にデータを変更することはできません。 具体的には、以下のデータ操作言語 (DML) ステートメントは外部テーブルに対して実行できません。 INSERT (データの挿入) UPDATE (データの更新) DELETE (データの削除) MERGE (データの結合と更新/挿入) TRUNCATE TABLE (テーブル内のすべての行を削除) 外部テーブルのデータに対する変更は、元の外部データソースに対して行う必要があります。例えば、GCS 上の CSV ファイルの内容を変更したい場合は、BigQuery ではなく GCS のファイルを直接編集する必要があります。 外部テーブルの主な用途は、 外部に存在するデータを BigQuery の強力なクエリエンジンを活用して分析すること です。データの永続的な保存や頻繁な更新を伴う用途には、BigQuery のマネージドストレージ（通常のテーブル）の利用が推奨されます。 実際に外部テーブルに対してDMLステートメントを実行しようとすると、 エラーではじかれます。   まとめ BigQuery の外部テーブル機能は、GCS 上のデータを BigQuery にロードすることなく、手軽に分析できる非常に強力なツールです。データの柔軟性、迅速な分析開始、コスト効率などのメリットがあり、データレイクとの連携や ETL パイプラインの一部としても有効に活用できます。 今回のデモを通じて、外部テーブルの作成からクエリ実行までの基本的な流れをご理解いただけたかと思います。ぜひ、BigQuery の外部テーブル機能を活用して、より効率的なデータ分析を試してみてください。