本記事は 新人ブログマラソン2024 の記事です 。 はじめまして！2024年入社新人の織田です。 今回業務にて、人生で初めてPowerShellスクリプトを書く機会がございましたので、今回のスクリプト作成にあたって、学んだことのまとめとして本記事を書かせていただこうと思います。 ただ、今回は基礎的な変数の宣言や、値の代入などの話は省かせていただき、今回私がエラーが発生するなどして躓いたポイントのみにフォーカスしたいと思います。 あまり業務でPowerShellスクリプトを書く機会は多くないかもしれませんが、同様の問題に遭遇した際に解決の一助になれば幸いです。 それでは、始めていきましょう！  動作環境 今回作成したスクリプトの動作環境は下記の通りとなります。 項目 値 実行環境OS Windows Server 2016 Datacenter PowerShell version 5.1 2024年現在、PowerShellの最新バージョンは7.5があり、動作環境によってはバージョンの差による違いもあるかもしれません。 こちらにMicrosoft公式がまとめた「 Windows PowerShell 5.1 と PowerShell 7.x の相違点 」のページがあります。 バージョン7.xを使用中の方はこちらも併せてご確認ください。 遭遇した問題と解決策 ここでは今回のスクリプト作成にあたり、遭遇した問題とその解決策についてまとめていきたいと思います。 章のタイトルを「 エラー 」ではなく「 問題 」としているのは、PowerShellではエラーとして検出されないものもあったためです。 ただ、私のこれまでの経験によって発生した問題なども含まれるため、参考にならない情報も多く含まれているかもしれない点はご了承ください。 今回作成したスクリプトは繰り返しの記述が多く、それらをできるだけなくすために今回は関数を使用しました。 その際、私が遭遇した問題点は下記の3つです。 関数の定義と関数の呼び出しの順番 関数呼び出し時の引数の渡し方 関数名の設定 それぞれについて、詳しく説明していきたいと思います。 関数の定義と呼び出しの順番 PowerShellスクリプト作成中、繰り返しの処理を関数としてまとめようとした際に遭遇した問題です。 一言で言えば、 関数の呼び出しの記述の前に関数を定義しておく必要がある ということです。 ■誤ったスクリプト func "test" function func($a) {   Write-Host $a } ■エラーメッセージ func : 用語 ‘func’ は、コマンドレット、関数、スクリプト ファイル、または操作可能なプログラムの名前として認識されません。名前が正しく記述されていることを確認し、パスが含まれている場合はそのパスが正しいことを確認してから、再試行してください。 発生場所 C:\Users\user-name\test.ps1:1 文字:1 + func “test” + ~~~~ + CategoryInfo : ObjectNotFound: (func:String) [], CommandNotFoundException + FullyQualifiedErrorId : CommandNotFoundException ※上記のエラーは「 func 」という名前の関数を定義される前に呼び出した場合のものになります。 正しくは下記の通り、関数を定義してから呼び出しを行う必要があります。 ■スクリプト function func($a) { Write-Host $a } func "test" ■実行結果 PS C:\Users\user-name> .\test.ps1 test まとめると、 原因：関数を定義する前に呼び出していた。 解決策：関数は定義後に呼び出す必要がある。 となります。 関数呼び出し時の引数の渡し方 PowerShellにおける関数の特徴として、定義した関数を呼び出す際の引数の渡し方があります。 PowerShellでは関数を呼び出す際に、「 関数名(引数1, 引数2) 」 や 「 関数名 値1, 値2 」 ではなく 、「 関数名 引数1 引数2 」 というように呼び出します。 この勘違いの厄介なところは、 エラーが出ない ということです。 より正確には、関数定義時に引数を必須しない場合、値が渡されなかった引数には「 $null 」が自動で入ります。 また、PowerShellでは「 (値1, 値2) 」や「 値1, 値2 」という書き方は配列としても認識されるため、上記の誤った呼び出しを行った場合、 一つ目の引数に2つの値が配列として代入され、二つ目の引数に「 $null 」が代入されることになります 。 例として、次のスクリプトの実行結果を挙げます。 ■スクリプト function func($a, $b) { Write-Host $a   Write-Host $b if($b -eq $null) { Write-Host "`$b is null." } else { Write-Host "`$b is not null." } } func ("test1", "test2") Write-Host "---------------------" func "test3", "test4" Write-Host "---------------------" func "test5" "test6" ■実行結果 PS C:\Users\user-name> .\test.ps1 test1 test2 $b is null. --------------------- test3 test4 $b is null. --------------------- test5 test6 $b is not null. となります。実際に、「 func (“test1”, “test2”) 」や「 func “test3”, “test4” 」という引数の渡し方をしたものは、2つ目の引数に値が入っていないことがわかります。 まとめると、 原因：関数を間違った呼び出し方をしてしまっていた。 解決策：原則関数を呼び出す際の引数の書き方は 「 関数名 引数1 引数2 …」 とする。 となります。 関数名の設定 一般的にプログラミングをしていると 予約語 というものに遭遇することがあると思います。 PowerShellにも、予約語は存在しており、変数名や関数名を設定する際には、それを避ける必要があります。 ただ、PowerShellの特徴は関数名を設定する際に、予約語以外にも注意する必要があるということです。 関数名を設定する際に追加で気を付ける必要があるものは、既存のPowerShellコマンドです。 通常、プログラミング言語でコーディングしている際には、予約語以外の既存関数などはインポートなどをしない場合、名前の衝突を気にする必要はありません。 しかし、PowerShellスクリプトやそのほかのシェルスクリプトでは、パスの通っているコマンドがスクリプト中で呼び出すことが可能であり、 PowerShellの場合は特に関数の呼び出し方とコマンドの呼び出し方が同じです 。 そのため、自分で新しく定義したはずの関数が既存のコマンドとして実行され、スクリプトが意図しない処理を実行してしまう恐れがあります。 ■誤ったスクリプト function move($a, $b) { Write-Host "Move", $a, "to", $b } move "test" "test2" ■エラーメッセージ move : パス ‘C:\Users\user-name\test’ が存在しないため検出できません。 発生場所 C:\Users\user-name\test.ps1:4 文字:1 + move “test” “test2” + ~~~~~~~~~~~~~~~~~~~ + CategoryInfo : ObjectNotFound: (C:\Users\user-name\test:String) [Move-Item], ItemNotFoundException + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.MoveItemCommand このエラーはPowerShellに「move」に該当するコマンドがすでに存在するため、定義したmove関数が実行されず、別のmoveコマンドが実行されましたが、引数で指定されたフォルダが存在しないため発生しています。 回避策としては、 同名のコマンドが存在しないことを調べてから関数名を設定する 方法が有効です。 具体的には下記のコマンドを使用します。 gcm <コマンド名> gcm は Get-Command コマンドの略になります 。 実際に gcm で「move」を調べてみると下記のような結果になります。 PS C:\Users\user-name> gcm move CommandType Name Version Source ----------- ---- ------- ------ Alias move -> Move-Item つまり、 Move-Item コマンドのAliasとして「move」が使用されているということです。 代わりの関数名として、例えば「move-alpha」を考えたとして、gcmで確認すると、「move-alpha」に該当するコマンドは存在していないため、 PS C:\Users\user-name> gcm move-alpha gcm : 用語 'move-alpha' は、コマンドレット、関数、スクリプト ファイル、または操作可能なプログラムの名前として認識されません。名前が正しく記述されていることを確認し、パスが含まれている場合はそのパスが正しいことを確認してから、再試行してください。 発生場所 行:1 文字:1 + gcm move-alpha + ~~~~~~~~~~~~~~ + CategoryInfo : ObjectNotFound: (move-alpha:String) [Get-Command], CommandNotFoundException + FullyQualifiedErrorId : CommandNotFoundException,Microsoft.PowerShell.Commands.GetCommandCommand という結果になります。 そのため、スクリプトにて「move」を「move-alpha」に変更すると、自分が定義した関数である、 move-alpha が実行できます。 ■スクリプト function move-alpha($a, $b) {   Write-Host "Move", $a, "to", $b } move-alpha "test" "test2" ■実行結果 PS C:\Users\user-name> .\test.ps1 Move test to test2 まとめると、 定義した関数名と同名のコマンドが存在する場合、コマンドの実行が優先される Get-Commandによって同名のコマンドが存在しないことを確認してから関数名を設定する となります。 参考サイト１： about_Reserved_Words – PowerShell | Microsoft Learn （予約語） 参考サイト２： Get-Command (Microsoft.PowerShell.Core) – PowerShell | Microsoft Learn まとめ 以上で今回私が遭遇した関数関係の問題は終わりです。 そのほか、PowerShellにおける関数の詳細な仕様を知りたい方は、下記参考サイトをご参照ください。 参考サイト： about_Functions – PowerShell | Microsoft Learn （関数）   おまけ ここでは今回のスクリプト作成にあたり、有益だと感じた要素をまとめます。 ログの保存 業務に関する処理はログを残しておき、あとから処理が正しく実行されていたかを確認する必要があります。 Start-Transcript と Stop-Transcirpt を使用することで、その間にPowerShellへ出力されたテキスト情報をファイルに保存することができます。 ■スクリプト Start-Transcript Write-Host "a" Write-Host "b" Write-Host "c" Write-Host "d" Stop-Transcript ■実行結果 PS C:\Users\user-name> .\test.ps1 トランスクリプトが開始されました。出力ファイル: C:\Users\user-name\Documents\PowerShell_transcript.device-name.b4xgbacx.20241224150409.txt a b c d トランスクリプトが停止されました。出力ファイル: C:\Users\user-name\Documents\PowerShell_transcript.device-name.b4xgbacx.20241224150409.txt ※今回はトランスクリプトの出力パスとファイル名を指定していないため、実行ユーザーのドキュメントフォルダに「PowerShell_transcript.<デバイス名>.<ランダムな文字列>.<実行日時（yyyymmddHHMMSS）>.txt」という名前でファイルが生成されています。 ■ログファイルの中身 ********************** Windows PowerShell トランスクリプト開始 開始時刻: 20241224150409 ユーザー名: device-name\user-name RunAs ユーザー: device-name\user-name 構成名: コンピューター: device-name (Microsoft Windows NT 10.0.22631.0) ホスト アプリケーション: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -ExecutionPolicy Bypass -Command Import-Module 'c:\Users\user-name\.vscode\extensions\ms-vscode.powershell-2024.4.0\modules\PowerShellEditorServices\PowerShellEditorServices.psd1'; Start-EditorServices -HostName 'Visual Studio Code Host' -HostProfileId 'Microsoft.VSCode' -HostVersion '2024.4.0' -BundledModulesPath 'c:\Users\user-name\.vscode\extensions\ms-vscode.powershell-2024.4.0\modules' -EnableConsoleRepl -StartupBanner "PowerShell Extension v2024.4.0 Copyright (c) Microsoft Corporation. `https://aka.ms/vscode-powershell Type 'help' to get help. " -LogLevel 'Normal' -LogPath 'c:\Users\user-name\AppData\Roaming\Code\User\globalStorage\ms-vscode.powershell\logs\1735016531-a08696d6-c03f-44f0-884a-6074e122f4c11735016528163' -SessionDetailsPath 'c:\Users\user-name\AppData\Roaming\Code\User\globalStorage\ms-vscode.powershell\sessions\PSES-VSCode-21068-641835.json' -FeatureFlags @() プロセス ID: 22968 PSVersion: 5.1.22621.4391 PSEdition: Desktop PSCompatibleVersions: 1.0, 2.0, 3.0, 4.0, 5.0, 5.1.22621.4391 BuildVersion: 10.0.22621.4391 CLRVersion: 4.0.30319.42000 WSManStackVersion: 3.0 PSRemotingProtocolVersion: 2.3 SerializationVersion: 1.1.0.1 ********************** トランスクリプトが開始されました。出力ファイル: C:\Users\user-name\Documents\PowerShell_transcript.device-name.b4xgbacx.20241224150409.txt a b c d ********************** Windows PowerShell トランスクリプト終了 終了時刻: 20241224150409 ********************** ※今回VSCode中で実行しているため、関連した出力が含まれています。 参考サイト１： Start-Transcript (Microsoft.PowerShell.Host) – PowerShell | Microsoft Learn 参考サイト２： Stop-Transcript (Microsoft.PowerShell.Host) – PowerShell | Microsoft Learn   サマリの出力 処理の内容をサマリとしてまとめて簡単に把握できるようにすると結果を確認するとき非常に便利です。 実現するには、 $Data = New-Object PSObject | Select-Object Data1, Data2, ... $Data.Data1 = "text1" $Data.Data2 = "text2" ... $Summary += $Data という書き方をし、配列として格納したのち、 $Summary | Format-Table とすることで、テーブル形式でデータを表示することができます。 ■スクリプト $Summary = @() $PrimeMinisters = (("Ishida", "Shigeo", 86), ("Kishimoto", "Fumi", 1095), ("Sugawara", "Yoshio", 385)) foreach ($PrimeMinister in $PrimeMinisters) {   $Data = New-Object PSObject | Select-Object FirstName, LastName, Days   $Data.FirstName = $PrimeMinister[1]   $Data.LastName = $PrimeMinister[0]   $Data.Days = $PrimeMinister[2]   $Summary += $Data } $Summary | Format-Table ■実行結果 PS C:\Users\user-name> .\test.ps1 FirstName LastName Days --------- -------- ---- Shigeo Ishida 86 Fumi Kishimoto 1095 Yoshio Sugawara 385 参考サイト１： New-Object (Microsoft.PowerShell.Utility) – PowerShell | Microsoft Learn 参考サイト２： Select-Object (Microsoft.PowerShell.Utility) – PowerShell | Microsoft Learn 参考サイト３： Format-Table (Microsoft.PowerShell.Utility) – PowerShell | Microsoft Learn

本記事は 新人ブログマラソン2024 の記事です 。 こんにちは。2024年度に入社した新人の曲渕です。 AWSの技術習得に向けて日々勉強している最中です。そんなAWSの知識があまりない私ですが、現在サーバーレスの案件に携わらせてもらっています。コンテナ周りのサービスは難しいイメージがあるので正直不安ですが、なんとかやり遂げられるよう頑張りたいです！ 今回の記事ではその案件の中で AWS Systems Manager で AWS Fargate のコンテナにログインする機会があったので、その備忘録として記事にしました。 私と同じようにAWSの勉強をされている方や来年入社される方の参考になれば幸いです。 構成図 今回やりたいこととしては、プライベートサブネットに配置されたECS クラスターのFargateのコンテナにSystems Managerでログインすることです。 実施手順の流れ 以下に今回行った手順の流れを記載します。 ①VPC、リポジトリ、IAMロールの作成 ②Dockerファイルを記述（ コンテナの設計図をつくる ） ③リポジトリにイメージを格納（ 作ったコンテナの設計図を保管 ） ④クラスターを作成（ コンテナを動かすための作業場を用意 ） ⑤タスク定義（ リポジトリに保管したコンテナの設計図を引っ張り出してリソースを割り当てて使えるようにする ） ⑥サービスの作成（ どのタスク定義を使用してコンテナを実行するか ） ⑦Systems ManagerのセッションマネージャーでFargateのコンテナにログイン VPC、リポジトリ、IAMロールの作成 VPCは10.0.0.0/16のCIDRブロックのものを使用し、NAT gatewayをパブリックサブネットに一つ配置します。 リポジトリはECRから作成します。作成が完了するとURIが表示されますが、このURIは後ほど使用します。画像の赤枠の部分はリポジトリの名前を入力します。 IAMロールはSystems ManagerでFargateのコンテナにログインできるように以下のものを設定しました。画像の備考にあるecsTaskExcutionRoleのIAMポリシーは既存のもので、下のtest-magarifuchi-roleのIAMポリシーはJSONファイルから記述しています。赤文字で アカウントID とある部分にはAWSアカウントのIDを記述します。test-magarifuchi-roleはタスクロール、ecsTaskExecutionRoleはタスク実行ロールで使用します。 Dockerファイルを記述 Cloud9を使用して以下のコマンドを順に実行しました。赤文字の部分はそれぞれAWSアカウントのIDと作成したリポジトリのURI、使用しているリージョンを入力します。 ①mkdir my-image（ 新しいフォルダを作成 ） ②cd my-image（ 作成したフォルダに移動 ） ③nano Dockerfile（ Dockerファイルの記述 ） ④touch entrypoint.sh（ entrypointシェルスクリプトファイルを作成 ） ⑤nano entrypoint.sh（ entrypointシェルスクリプトファイルを記述 ） ⑥docker build -t my-image:latest .（ イメージをビルド ） ⑦docker tag my-image:latest リポジトリのURI :latest（ イメージにタグ付け ） ⑧aws ecr get-login-password –region ap-northeast-1 | docker login –username AWS –password-stdin アカウントID .dkr.ecr. リージョン .amazonaws.com（ ECRにログイン ） ⑨docker push リポジトリのURI :latest（ イメージをリポジトリにプッシュ ） 以下に作成したDockerファイルを記載します。 このDockerファイルではPHP、Apache構成のコンテナを記述しています。緑の括弧で示した部分はSystems ManagerでログインできるようにSSMエージェントをインストールし、「#SSMエージェントとアクティベーション処理用のスクリプトを追加」の部分でコンテナが起動される際に実行されるentrypoint.shを指定しています。以下のファイルがentrypoint.shの内容です。 entrypoint.shでは「#コンテナのマネージドインスタンスへの登録」でSSMエージェントを使用して、FargateコンテナをSystems Managerに登録しています。これでコンテナがSystems Managerによって管理されるようになります。 リポジトリにイメージを格納 手順⑨を実行するとリポジトリにイメージが格納されるはずです。実際にリポジトリの中身を見てみるとイメージがあることが確認できました。 クラスターを作成 クラスターの作成では名前は任意のものを設定し、Fargateを選択します。 タスク定義 タスク定義では、先ほど格納したリポジトリのイメージURIからコンテナの詳細な設定を行います。タスク定義ファミリーは任意の名前を入力し、起動タイプはFargate、ロールは冒頭で作成したIAMロールを設定します。黒く塗りつぶしているところはアカウントIDになります。 サービスの作成 作成したクラスターに移動してサービスの作成を行います。先ほど作成したタスク定義を選択し、サービス名を任意の名前で入力します。VPCの選択では構成図に従ってプライベートサブネットを選択します。セキュリティグループは新しく作っていますが、既存のものから選択することもできます。また、オートスケーリングの設定やロードバランサーの選択などもサービスの作成で行えますが、今回は赤枠以外のところはすべてデフォルトのままです。 クラスターの「タスク」タブのタスクを選ぶと、以下の画像のようにコンテナが実行されていることが確認できます。 Systems ManagerのセッションマネージャーでFargateのコンテナにログイン 実際にSystems Managerのセッションマネージャーに移動すると、Fargateのコンテナが表示されていることが確認できました。 表示されたターゲットインスタンスを選択し、「Start session」を選ぶと以下の画面のようになります。コマンドを打つと応答が返ってきたことからログインが成功しているのが確認できました。 おわりに 今回はSystems ManagerでFatgateのコンテナにログインしましたが、調べてみるとECS Execというものを利用してコンテナにログインする方法もあるようです。機会があれがそちらも試してみようと思います。 最後まで読んでいただきありがとうございました！ 参考サイト

こんにちは、SCSKの木澤です。 去る2024/12/2～12/6に米国ラスベガスで開催されたAWS最大のカンファレンス、 re:Invent 2024に参加してきました 。 今回は私が現地で参加したセッションで感じたことや主観をまとめたいと思います。 概要 re:Inventは AWSによるクラウドコンピューティングに関する世界最大規模の「学習型」カンファレンス で、というくだりは一昨年にも書いたので詳細は省略したいと思います。 AWS re:Invent 2022レポート ～概要編～ 去る2022/11/28～12/2に 米国ラスベガスで開催されたAWS最大のカンファレンス、re:Invent 2022に参加してきました。 本記事では参加体験の概要をレポートとしてまとめたいと思います。 blog.usize-tech.com 2022.12.12 今年は世界中からの 現地参加者60,000人 （オンライン視聴者400,000人）、 日本からの現地参加者も1,700名超 で日本人の方も多く見かけました。ラスベガス市内 6つの会場で約3,500人から提供される約2,000のセッションが提供されており…　といっても規模感のイメージは難しいかもしれません。 私は2022から連続して3回目の参加となりますが、 初回参加(2022)の際は とにかく圧倒されてしまった といった印象 で、2回目からやっと自分のペースで参加できています。 今年の大きな変更は、会期が1週間後ろ倒しになったくらいで、あとは会場レイアウトの変更くらいであったかと思います。 （Badge PickupとSWAGが別部屋になった、Funブースがマンダレイベイからシーザーズフォーラムに変更になった等）   参加したセッションについて 私は今年、業務や資格取得などでre:Inventに気持ちを切り替えるのが遅れ、セッション予約が後手に回ってしまいました。 （参加者が増えた影響からか、今年は例年以上に人気セッションが埋まるのが早かった印象です） そのため、今年はキーノートやワークショップ、新サービスに関するブレイクアウトセッションを中心に組み立てました。 特にワークショップを5件と多めに入れました。 今回は受講したセッション・ワークショップをかいつまんでご紹介したいと思います。 [SEC235-NEW] Accelerate security analytics across hybrid environments with AWS Amazon Security LakeがAmazon OpenSearch ServiceとのZero-ETL統合ができるようになった よ、というアップデートです。 Amazon Security Lakeは昨年のre:Inventで発表されたものの、ツール側の対応途上であることからか、まだ導入事例は多くないと感じます。各種セキュリティ製品のログ・分析の一元化に繋がるので期待したいですね。 SecurityLake側でサブスクライバを作成した後、OpenSearch側でデータソースとして指定するだけで、自動的にでダッシュボード及び関連クエリーまで作成されます。 ダッシュボードの利用デモンストレーションもありました。格好良い見た目ですね。 ぜひ時間を作って触ってみたいと思います。 [NET217-NEW] Accelerate data transfer to the cloud with AWS Data Transfer Terminal 新サービスであるAmazon Data Transfer Terminal に関するセッション。 なんとこれは、AWSが Direct Connect(100G)に繋がる部屋を貸してくれる 、というサービスです。 マイグレーションやデータ解析等で大容量のデータをAWSに移行する場合、AWS Snowball Edge等が従来から提供されていましたが、現在Snowballは注文しても大幅に納期が掛かる状況になっていると聞いています。（※最新の状況はAWSにお問い合わせください） こういった状況もあるので、新しいサービスを作ったという背景のようです。 接続としては、Direct Connect Gatewayに直結するイメージとなります。 利用申請（予約）はマネジメントコンソール上から行い、その後メールで通知が届きます。 予約日に機器を持ち込み、自身のAWSアカウントのクレデンシャルを用いてS3等にアップロードとの流れになるようです。 部屋はこんな感じ、いや本当でしょうか？w まずは米国（オレゴン）のリージョンからGAとなり、東京リージョンは「ポテンシャル枠」との表現でした。 ただし、プレビューを利用した日本企業の方のコメントも掲載されていたため、可能性としてはあるかもしれません。 [SEC306] Securing your generative AI applications on AWS Amazon Bedrockの機能を用いて、生成AIの応答を制御する方法を学ぶワークショップでした。 ワークショップでは、医療現場にて患者のカルテのデータから情報を返答するチャットボットアプリを例に設定を行いました。 医師と受付のスタッフが利用しており、医師のみに血液型等の機微な情報を開示するよう設定してあるのですが、受付スタッフにおいても「急ぎ」などとプロンプトを工夫することで患者の機微な情報にアクセスできてしまうという脆弱性があります。 Amazon Bedrockのガードレール機能やデータソースの権限分離を行うことで不正アクセスから防御する手法を理解できました。 解像度を高めるため、機会があればまた受講したいですね。 以下、適宜追加します   全般的な感想 基調講演(KeyNote) CEOがMatt Garmanに代わったということで注目されたDay2のKeyNoteですが、冒頭にAWS Heroを含むコミュニティへの感謝から入ったのは印象的でした。 AWSは古くから支持する熱狂的なファンに支えられてここまで来たものと思いますし、CEOが新しくなってもそれらコミュニティへのコミットメントは変わらないという意思を示したのかと私は考えています。 また、メッセージングは全般的にアグレッシブであった印象を持ちました。 他社との協調についても控えめで、Amazon Novaなど新機能リリースで攻めの姿勢であったように感じます。 Amazon Nova Amazon Novaの発表では初代CEOのAndy Jassyが登壇し会場を沸かせ、Amazon Novaへの並々ならぬ意気込みを感じました。 その他アップデート 他にもMattの基調講演では以下のようなアップデートの発表がありました。 今後もユーザーニーズに応じて全方位的にサービスを提供していくということなのでしょう。 AWS Trainium3　AI用プロセッサ。学習用⇒推論にも利用可能 Amazon S3 Tables　Apache Iceberg互換の分析ワークロードのために最適化されたストレージ Amazon Aurora DSQL　マルチリージョンの分散データベース Amazon Bedrockの進化 Model Distillation（LLMモデルの”蒸留”⇒小型高速化） Automated Reasoning checks（自動検証） multi-agent collaboration（複数エージェントの連携機能） Amazon SageMakerのリブランディングとAmazon Qの進化 Amazon SageMakerのリブランディングによってデータ活用の範囲を取り込むとの発表もありました。 また、Amazon Qの新機能として.NETアプリケーション / VMware環境 からのマイグレーションサポート機能が発表されました。 つまりAWSの方向性としては、あらゆるユーザー支援機能をAmazonQに統合する方向性＝「Amazon Qが全てを包含する」世界を目指しているのだと理解しました。将来的には今後はAWSアカウント上にある、あらゆる情報 AWSアカウントの利用状況 各サービスの設定 マイグレーションの支援 ユーザーデータ これらをAmazon Qにて問い合わせできるような世界観になるのでしょう。 また、今までデータ活用にはDWHを構成するにあたり少々ノウハウが必要でしたが、データ分析とのAnalyticsの融合により、AWSに集まったデータを気軽にAIで分析する世界を実現しようとしているのはワクワクするなと思いました。   その他現地での体験 AWS Partner Award 2024 – Industry Partner of the Year ‐ Retail, APJ 受賞 今回、SCSKはAWS Partner Award にて Industry Partner of the Year ‐ Retail, APJ  の表彰を頂戴することができました。 Announcing the 2024 Geo and Global AWS Partners of the Year | Amazon Web Services Each year, we honor members of the AWS Partner Network (APN) from around the globe that play key roles in helping custom... aws.amazon.com 弊社のお知らせ にも記載しておりますが、当社では、住友商事をはじめ多数のお客様でのAWSクラウド活用及びモダナイゼーションの推進を行っており、本表彰はこれら弊社の実績を評価いただいたものとなります。 なお私も表彰式後のパーティにご招待いただき、滅多にない経験をすることができました。 会場の雰囲気はAWS公式の動画がわかりやすいと思いますので、こちらをご覧下さい。 現地でのボランティア、交流、おまけ 今回、初の試みとしてAPNブースのボランティアスタッフを担当しました（30分のみですが） 長い時間はご一緒できませんでしたが、AWS Ambassadorsの皆様との交流も楽しめました。   最後に こうして振り返ってみると、やはり今年はセッション予約が後手に回ったことが失敗だったなと反省ですね。 それでも、今年もre:InventはAWSに関わる人々にとって刺激となるイベントであり、私も期間中ずっとハイテンションとなっておりました。（レポートが遅れました） なお、参加者向けのアドバイスを１点付け加えるとすれば（他の方のレポート同様となりますが）やはり現地でしか体験できないプログラム、WorkShopやGameDay、Fun Event（re:play、etc）を優先した方が良いかと私も思います。 また、アウトプットを予定しているのであればそれを踏まえた行動計画を立てると良いでしょう。 この記事が来年訪問される皆様のきっかけになれば幸いです。 ありがとうございました。 re:Invent2024振り返りウェビナーのご紹介 2025/1/20に、トレノケート株式会社と共同でre:Invent2024の振り返りイベントを開催いたします。 私も登壇いたします。 新時代のクラウド活用方法を語る ～AWSプレミアパートナーと共創する、自社のクラウド活用力の高め方～ 2024年12月に米国ラスベガスで開催されるAWS最大のグローバルイベント「AWS re:Invent 2024」を振り返りイベントを開催いたします。クラウドを効果的に活用するために自社が持つべき知見、インテグレーターとの協力の進め方、そし... www.scsk.jp ぜひご参加頂ければと思います。よろしくお願いします。

本記事は TechHarmony Advent Calendar 2024 12/25付の記事です 。 こんにちは、SCSKでAWSの内製化支援『 テクニカルエスコートサービス 』を担当している貝塚です。 re:Invent 2024で『VPC LatticeがTCPによるアクセスをサポート』というアナウンスがありました。 VPC Lattice now includes TCP support with VPC Resources - AWS Discover more about what's new at AWS with VPC Lattice now includes TCP support with VPC Resources aws.amazon.com PrivateLinkの機能追加 とあわせて、AWSのネットワークまわりに大きな変化がありそうです。 ……と言っておきながら、実は私、VPC Latticeを使ったことがありません。というのも、VPC Latticeはコンテナと合わせて語られることが多く、あまりコンテナと関わってこなかった私にとっては、そのうち勉強しようと思っているけれどなかなかその機会に恵まれないサービスだったのです。 そういうわけで、re:Inventで発表された機能を使ってみる前に、とりあえずVPC Latticeを使ってみよう、というのが本記事の趣旨になります。 検証構成 今回は、まずは基本を抑えねばということで、新機能の検証ではなく、従来通りのVPC Latticeを試してみることにしました。図にすると以下のようになります。 VPC Latticeがどういうものかというと、ALBに近いものをイメージすればよさそうです。今回の機能拡張前は、HTTPとHTTPSのみの対応であったという点もALBに似ています。 Service NetworkがALB本体のようなもので、接続元となるVPCに関連付ける必要があります。 Serviceは、ALBのリスナーとターゲットグループをひとまとめにしたようなものです。リスナーとターゲットグループという用語はALBそのままですね。何番ポートで通信を待ち受けて(リスナー)、どこ(どのIP/どのインスタンス、など)に転送するか(ターゲットグループ)を設定します。 環境構築 マネジメントコンソールでは、『VPC』→ 『PrivateLink and Lattice』のメニューから設定を進めていきます。 ターゲットグループの作成 まずは接続先を定義するターゲットグループから作成していきます。 メニューから『ターゲットグループ』を選択し、『ターゲットグループの作成』をクリックします。 ターゲットタイプの選択では、インスタンスよりIPアドレスの方が汎用性が高い使い方ができるだろうということで、IPアドレスを選択しました。 ターゲットグループ名、プロトコル、ポート、IPアドレスタイプ、接続先側のVPC、プロトコルバージョン、ヘルスチェックを指定します。今回はつながりさえすればよいというのを目標にしているので、HTTP(80番ポート)でEC2に接続し、ヘルスチェックもデフォルトのまま( / へのHTTPによるヘルスチェック)にします。 次の画面に進むと、ターゲットの登録をすることになります。VPCを選択し、接続先のIPとポートを指定して、『保留中として以下を含める』をクリックするとターゲットとして登録されます。 ターゲットが登録されたら『ターゲットグループの作成』をクリックしてターゲットグループの作成を完了させます。 サービスの作成 メニューから『Lattice services』を選択し、『サービスを作成』をクリックします。とりあえずつながることを目指しているので、カスタムドメイン設定、サービスアクセス、Share service、モニタリングはデフォルトのまま進みます。 次へ進み、『ルーティングを定義』というところでリスナーの設定をします。プロトコルをHTTPに、ポートを80に設定します。リスナールールは設定せず、リスナーのデフォルトアクションとして『ターゲットグループへ転送します』を選び、ターゲットグループとして先ほど作成したターゲットグループを選択します。 次にサービスネットワークの関連付けの画面が出ますが、まだサービスネットワークは作成していないので、飛ばします。『確認と作成』画面が出るので、『VPC Latticeサービスを作成』をクリックしてサービスを作成します。 サービスネットワークの作成 メニューから『サービスネットワーク』を選択し、『サービスネットワークを作成』をクリックします。 サービスの関連付けのところで、先ほど作成したサービスを選択します。VPCの関連付けのところで、接続元のVPCを指定し、適用するセキュリティグループを選びます。他はデフォルトのままでサービスネットワークを作成します。 接続確認 設定はこれで完了ですが、先ほど登録したターゲットは生きていると判定されているでしょうか。作成したターゲットグループを選び、『ターゲット』タブを確認します。ヘルスステータスが正常になっているので、うまくいったようです。 さて、接続確認を実施したいのですが、どこにアクセスすればよいのでしょうか？答えは、「サービス」の詳細のところにあります。 「ドメイン名」を確認し、接続元VPCのEC2から接続してみます。 接続できました！ 考察 接続できましたが、どのような仕組みになっているのか気になるところです。 まずは、ドメイン名を名前解決するとどうなるか確認してみます。 169.254. から始まるリンク・ローカル・アドレスが返ってきました。 接続元EC2が存在するサブネットのルートテーブルを確認してみます。 129.224.0.0/17と169.254.171.0/24が登録され、ターゲットがVpcLatticeとなっています。 129.224.0.0/17はどこで使われるのでしょうね？これは今後気が向いたら調べることにします。 次に、接続を受ける側のEC2で、どこから通信が来ているのかtcpdumpを使って確認してみます。 / にはいくつかのIPから通信が来ていて紛らわしいので、/test にアクセスしてみました。169.254.171.194から来ていることが分かります。こちらもリンク・ローカル・アドレスということですね。 接続先側のルートテーブルも確認してみます。 169.254.171.0/24が登録され、ターゲットがVpcLatticeとなっています。 今回、説明を端折りましたが、169.254.から通信が来るので、接続先EC2のセキュリティグループで169.254.のCIDRを許可してやる必要があります。 接続元側は169.254.xx.xxのIPに接続し、接続先側は169.254.xx.xxから通信が来ているように見えるということは、もし別のVPCから利用したいという場合には一工夫する必要がありそうです。もっとも、一工夫するのではなく素直に接続元VPCにLatticeを構築するのが正攻法だと思います。 まとめ VPC Latticeの新機能を試す前に、まずはこれまでのVPC Latticeがどういうものなのか知らなくては、という動機でこの記事を書き、なんとなくどういうものなのか分かってきました。 次は、新機能の検証に進みます。

SCSKの畑です。初投稿です。 現在携わっている複数の案件において、サーバレスアーキテクチャにおける WEB アプリケーション（フロントエンド/バックエンド双方）の構築・開発を行っています。これらの案件において、苦労した点や工夫した点などを中心に記載していく予定です。 アーキテクチャ概要 主にデータベース/ DWH 上のテーブルデータをメンテナンスする WEB アプリケーションを作成しています。案件ごとに差異はありますが、概ね以下のようなアーキテクチャで開発を行っています。下図の場合は、メンテナンス対象の DWH が Redshift となっています。 正直なところ、AWS 上におけるサーバレスアーキテクチャとしては王道というか、特に珍しくない構成だと思いますが。。。 本題 さて、アプリケーション開発の本筋から少し離れたトピックとなるのですが、実際に構築・開発を行うAWS環境がどのように管理・運用されているかというのは案件ごとに異なるところだと思います。今回、お客さん側の組織で主体的に管理されている1つの AWS アカウント環境上で構築する必要があり、使用するサービスの種類、必要なリソースの個数や IAM 権限などについてもある程度明確にした上で申請し、お客さん側に作成等を対応頂く流れとなっていました。また、各種 AWS サービスやリソースの構築・実装についても、 AWS CLI 等は使用できず、全てAWS マネジメントコンソール上から実施する必要がありました。 もちろん、全てをお客さん側で対応頂くというのは色々な観点から現実的ではないので、例えば Lamdba の場合は関数の作成までをお客さん側に実施頂き、ソースコード実装を含む詳細な設定を我々で実施するような棲み分けで権限管理がなされていました。他サービスについても概ね似たような棲み分けで構築を進めることができたのですが、AWS AppSync については一筋縄ではいきませんでした。 ご存じの通り、AWS AppSync における構成単位は API となり、その配下に同 API を構成する各種リソース（スキーマ、データソース、関数など）が紐付いています。つまり、先述したような権限管理の考え方に則ると、APIまでをお客さん側に作成してもらい、配下のリソースについては我々で編集できるような IAM 権限を付与頂くという棲み分けが妥当と考え、お客さんにそのような依頼をしたところ・・ なんと NG をもらってしまいました。詳細を確認した所、対象の IAM 権限（ appsync:StartSchemaCreation など）がリソースタイプの指定に対応しておらず、IAM 権限を付与した場合他の API 配下のリソースについても編集可能となってしまうためとのことでした。 なお、本案件についてはお客さんの AWS 環境で Amplify を使用することがポリシー上 NG であったため、自社環境において Amplify を使用して開発したものをお客さん環境に持ち込む、という段取りで進めていました。 そんなバカなことある！？と慌ててドキュメントを確認したところ、確かにそのような記載になっています。（表内のリソースタイプ列に記載がないため、リソースタイプでの許可がサポートされていない） AWS AppSync のアクション、リソース、および条件キー - サービス認可リファレンス Word へのアクセスを制御するために IAM ポリシーで使用できるサービス固有のリソースやアクション、条件キーを一覧表示します AWS AppSync。 docs.aws.amazon.com 念のため原著（US版）も確認したのですが同じ内容。うーん、万事休すか。。。 Actions, resources, and condition keys for AWS AppSync - Service Authorization Reference Lists all of the available service-specific resources, actions, and condition keys that can be used in IAM policies to c... docs.aws.amazon.com よって、作成したい各種リソースの詳細な内容をお客さんに伝えて作成頂くように・・ と、普通なら引き下がるのですが今回は易々と引き下がれない事情がありました。理由は明白で、API については言うまでもなくアプリケーションの開発領域であるためです。 つまり、アプリケーションのリリースが完了するまでの開発期間はもちろん、リリース後の機能追加なり不具合修正も含めて、API 配下のリソースに変更がある場合はその反映をお客さんにお願いしないといけない、ということになってしまいます。対象となるスキーマのパイプラインや関数の個数も多く、これをそのままお客さんにやってもらう場合にどれくらいの時間・コストが必要かを考えると、いや無理でしょうという結論になりました。 そもそも API の実行（ appsync:GraphQL ）についてはちゃんとリソース指定できるようになっているのに、編集はできないというのはどういうことなのか？ AWS の各種サービスにおける権限管理があれだけしっかりとした設計思想の元で作られているのに、API という単位で明確に分割できる AWS AppSync についてそのようなことができないような設計になっているとは思い難い などと悶々とした結果、自分で試してみないと納得できなくなったので、手元の環境で試してみました。 検証 AWS マネジメントコンソールから AWS AppSync の API 配下のリソースを編集できる IAM ポリシーを、IAM ユーザに付与できるかどうか、というのが検証の内容となります。対象の IAM 権限は複数ありますが、一番分かりやすいところでまずはスキーマを編集できる権限（ appsync:StartSchemaCreation）について検証してみることに。 以下検証においてはスクリーンショットに表示されている以外の IAM 権限エラーも複数表示されていましたが、検証目的から外れる内容のものは省略しています。ご了承ください。 まず、確認用の AWS AppSync API 「AppSync-API-test」を作成した上で、スキーマ編集画面をエラーなく開くための以下 IAM ポリシーを付与した IAM ユーザで、AWS マネジメントコンソールからスキーマの編集画面を開いてみます。  ちなみに、「appsync:ListSourceApiAssociations」についてもドキュメント上はリソース指定に対応していませんでしたが、「 appsync:GraphQL」と同じような ARN パスでリソース指定ができたので、他の権限についてもできるのではなかろうかという楽観的予測が芽生えつつありました。 { "Version": "2012-10-17", "Statement": [ { "Sid": "1", "Effect": "Allow", "Action": [ "appsync:ListGraphqlApis" ], "Resource": "*" }, { "Sid": "2", "Effect": "Allow", "Action": [ "appsync:ListSourceApiAssociations" ], "Resource": "arn:aws:appsync:${Region}:${Account}:apis/${GraphQLAPIId}/*" } ] } もちろんこの時点では「ロード中」の文字がフォーム内に残ったままになっており権限不足なことは明白ですが、この状態から適当なスキーマ定義を入力してみると、 このように「appsync:ListResolvers」権限に関するエラーが発生。最終的にはこの権限も必要になるでしょうが、一旦スルーしてスキーマを保存してみます。 すると、狙い通りに「 appsync:StartSchemaCreation 」権限に関するエラーが発生したので、こちらに対してリソース設定をしてみようということでエラーメッセージの内容を見たところ、リソースの ARN パスが「appsync:ListSourceApiAssociations」のものと少し異なることが判明。よく見ると 「appsync:ListResolvers」も同じようなARNパスになっており、以下の通り「 /v1/ 」が追加されているのが分かります。 arn:aws:appsync:${Region}:${Account}:apis/${GraphQLAPIId}/<対象リソース名> arn:aws:appsync:${Region}:${Account}: /v1/ apis/${GraphQLAPIId}/<対象リソース名> しかもこの「 /v1/ 」が入ったリソースの ARN パス、ドキュメントに記載がないんですよね・・ Actions, resources, and condition keys for AWS AppSync - Service Authorization Reference Lists all of the available service-specific resources, actions, and condition keys that can be used in IAM policies to c... docs.aws.amazon.com ということで、ちょっときな臭い感じがするものの、普通にこの ARN パスをそのまま設定すれば良いのではないか？と推測して以下のようにポリシーを変更してリトライ。「appsync:GetSchemaCreationStatus」についても必要そうだったので合わせて追加しています。 { "Version": "2012-10-17", "Statement": [ { "Sid": "1", "Effect": "Allow", "Action": [ "appsync:ListGraphqlApis" ], "Resource": "*" }, { "Sid": "2", "Effect": "Allow", "Action": [ "appsync:ListSourceApiAssociations" ], "Resource": "arn:aws:appsync:${Region}:${Account}:apis/${GraphQLAPIId}/*" }, { "Sid": "3", "Effect": "Allow", "Action": [ " appsync:StartSchemaCreation ", "appsync:GetSchemaCreationStatus" ], "Resource": "arn:aws:appsync:${Region}:${Account}:/v1/apis/${GraphQLAPIId}/*" } ] } すると、エラーが出力されずにスキーマの保存が完了しました！！ 後は必要となりそうな各種 IAM 権限を調べてお客さんに伝えてクローズ！と進めたいところなのですが、ドキュメントに記載されていない内容であるため AWS サポートに裏取り。マニュアルに記載されていない以上は想定されない挙動（≒不具合）の可能性もあり、そのような結論にならないことを願っていたのですが・・ AppSync の StartSchemaCreation アクション等でリソースレベルのアクセス制御が可能となっている事象につきまして、想定された動作であることを確認いたしました。 そのため、ご連絡いただきましたようなポリシーにて特定の AppSync API のみスキーマ、リゾルバ、関数を更新いただくことが可能でございます。 ドキュメントやビジュアルエディタ等に本動作が反映されていない点につきましては、製品担当部署にフィードバックを実施いたしました。 ドキュメントについては、本日時点ではまだ反映されていないようでした。 上記回答の通り、無事に想定された動作であることを確認できたので、改めて上記内容及び追加設定頂きたい IAM ポリシーをお客さんに伝えてクローズと相成りました。最後に、実環境に設定した IAM ポリシーを記載しておきます。 データソースについてはスキーマやパイプライン、関数などと比較して変更のタイミングが限定的であるため、権限付与しない方針としています。（今考えると付与してしまっても良かった気はしますが・・） AWS マネジメントコンソールからクエリを実行して動作確認を行うことがあるので、それができるように「 appsync:GraphQL 」権限を追加しています。 { "Version": "2012-10-17", "Statement": [ { "Sid": "1", "Effect": "Allow", "Action": [ "appsync:ListGraphqlApis" ], "Resource": "*" }, { "Sid": "2", "Effect": "Allow", "Action": [ "appsync:GraphQL", "appsync:ListSourceApiAssociations" ], "Resource": [ "arn:aws:appsync:${Region}:${Account}:apis/${GraphQLAPIId}/*" ] }, { "Sid": "3", "Effect": "Allow", "Action": [ "appsync:GetSchemaCreationStatus", "appsync:GetResolver", "appsync:GetFunction", "appsync:GetApiCache", "appsync:ListFunctions", "appsync:ListResolvers", "appsync:ListTypes", "appsync:ListDataSources", "appsync:ListResolversByFunction", "appsync:StartSchemaCreation", "appsync:CreateResolver", "appsync:UpdateResolver", "appsync:DeleteResolver", "appsync:CreateFunction", "appsync:UpdateFunction", "appsync:DeleteFunction", "appsync:ListApiKeys" ], "Resource": [ "arn:aws:appsync:${Region}:${Account}:/v1/apis/${GraphQLAPIId}/*" ] } ] } まとめ ドキュメントなどの公式情報の内容を抑えておくというのはもちろんですが、実環境での検証も同じくらい大事だということを改めて実感できました。私自身はむしろ後者が先行しがちなのですが、バランスが大事ですね。 本記事のようなシチュエーションに遭遇する機会はそれほど多くないと想像しますが、どなたかの役に立てば幸いです。

本記事は 新人ブログマラソン2024 の記事です 。 こんにちは。SCSKの新人、黄と申します。 最近、業務で Rubrik のサービスを扱う機会がありましたが、TechHarmonyにはRubrikに関する記事があまり見当たりませんでした。そこで、今回Rubrikについてご紹介したいと思います。 本稿では、Rubrikおよび同社が提供する主要製品とその特徴的な機能についてご紹介します。 Rubrikとは Rubrikは、2014年1月に設立され、 バックアップ&復元からバックアップデータの活用までデータ管理 に特化したIT企業です。本社はアメリカのカリフォルニア州パロアルトにあり、世界中に拠点を持っています。2024年4月にニューヨーク証券取引所での新規株式公開（IPO）で、企業価値は約56億ドルに達しました。 同社はクラウド・オンプレミス環境に対応したバックアップデータを管理できるソリューションを提供し、主に以下のような機能を備えています： シンプルな運用 直感的なインターフェースとポリシーベースの管理により、複雑なデータ管理を効率化します。 即時データアクセス 災害発生時やランサムウェア攻撃後の迅速な復元を実現します。 ポリシードリブンな自動化 バックアップ、アーカイブ、復元などのプロセスを自動化し、運用負荷を軽減します。 これらの特徴を支える製品として、 Rubrik Cloud Data Management 、 Rubrik Security Cloud が主要な柱となっています。 製品ラインナップ Rubrik Cloud Data Management Rubrik Cloud Data Management （以下、Rubrik CDM）は、クラウドやオンプレミス環境におけるデータ管理を根本から簡素化する、 Rubrikの中心的なソリューション です。 以下の3つの特徴が特に注目されています： 多機能性：すべてを1つのプラットフォームで実現 Rubrik CDMは、データ管理に必要な主要機能を1つの統合プラットフォームで提供します： バックアップと即時復元 ：システム障害やデータ損失時に迅速に対応可能 データアーカイブ ：過去のデータも安全に保管し、長期的な保存ニーズに対応 レプリケーションとコンプライアンス ：多拠点間のデータ同期や規制要件への対応を簡素化 すべてが1つのプラットフォームで統合するため、複雑なデータ運用が劇的に効率化されます。 柔軟性：どんな環境にも対応 Rubrik CDMは、下記の図に示したように、さまざまな環境に適応可能な柔軟性を備えています： 多様な対応範囲 ：主要なOS（Windows、Linuxなど）、仮想化環境（VMware、Hyper-V）、クラウド（AWS、Azure、Google Cloud）などに対応 SaaSアプリの保護 ：Microsoft 365などの主要なSaaSプラットフォームをサポート ベンダーロックイン回避 ：特定のクラウドプロバイダーに縛られることなく、自由に環境を選択可能 複雑化するITインフラにも柔軟に対応し、運用の選択肢を広げます。 拡張性：企業の成長を支える設計 Rubrik CDMはス ケールアウト型アーキテクチャ を採用しており、サーバーを増やすことで、データ量の増加や企業の成長に応じてシステムを無理なく拡張できます： スムーズな性能拡張 ：必要に応じて筐体を追加だけで容易に容量とパフォーマンスをスムーズに向上。 運用の安定性 ：スケールアップしても管理が複雑にならない設計。 優れた拡張性により、現在のニーズだけでなく将来的な運用にも対応できます。 Rubrik CDMがあれば、どんどん複雑になっていくIT環境でも、データ管理って意外と簡単にできるよね そう！しかも、CDMには2つの展開形態があって、導入環境に合わせて選べるんだよ。 Rubrik CDMの展開形態 Rubrik CDMは、導入環境に応じて以下の2つの展開形態を選択可能です： アプライアンス（Appliance） Rubrik CDMを搭載した一体型ハードウェアデバイスとして、小規模から大規模環境まで柔軟に対応できる拡張型フラッシュアプライアンスが用意されています。（詳しくは Rubrikを漫画で分かりやすく解説！【ネットワールド】 をご覧ください。） 特徴： 即時導入が可能な「即插即用」型ソリューション 高性能な専用ハードウェアでのデータ管理 ソフトウェア版（Software Edition） Rubrik CDMのソフトウェア版であり、既存のハードウェアやクラウド上に導入可能で、柔軟な運用をサポートできます。 特徴： 既存のハードウェアやクラウド環境の活用可能 Remote Office/Branch Office（ROBO）など拠点が分散した環境や、クラウドを中心に運用する環境にも柔軟に対応可能 Rubrik CDMって本当に便利そうだね！ ところで、Rubrik Security Cloudってどんなものなの？ Rubrik Security Cloud Rubrik Security Cloud（以下、RSC）は、複数のRubrik CDMを統合して、効率的かつ一元的に管理できるSaaSです。 クラウドやオンプレミス、複数拠点にまたがる環境を統合し、以下の特徴を備えています： 複数のCDMシステムの統合管理 RSCは、クラウドやオンプレミスに分散された複数のRubrik CDMを一つのインターフェースで効率的に統合管理します。 全体可視化とモニタリング RSCは、複数のCDMシステムにまたがるデータ保護の状況や運用状況をリアルタイムで可視化します。 操作とポリシーの一貫性 複数のCDMにわたるポリシーの統一管理を実現し、複雑な環境でも効率的なデータ保護運用を可能にします。 SaaSによる軽量な運用 RSCはSaaSとして提供されているため、専用のサーバーやソフトウェアの保守が不要で、手間を大幅に削減できます。 なるほど！RSCがあれば、いろんな場所にあるバックアップデータをまとめて管理できるんだね！ RSCとRubrikCDMを組み合わせて、異なる規模や環境のバックアップデータをしっかり管理できるね！ また、Rubrikはこの2つの主力製品以外にも、他にも役立つサービスを提供しているんだよ。 付加サービス：Rubrikのさらなる可能性 NoSQLデータベース対応 NoSQLデータベース は、柔軟なデータ構造と高い拡張性が特長で、大量のデータを扱う分散システムを利用したアプリケーションで広く採用されています。しかし、分散された環境ならではの 下記のような課題 も存在します： ノード（サーバー）間でデータの整合性を確保する方法 高負荷な状況でも十分な速度でバックアップを行う手段 障害が発生したとき、素早く復元できる仕組み このような課題を解決するために、 Rubrik Mosaic というNoSQLデータベースに特化したデータ保護ソリューションが提供されています。 Rubrik Mosaicの特徴 NoSQLデータのネイティブサポート MongoDBやCassandraなどの主要NoSQLデータベースに対応し、分散ノード間にまたがるデータを一貫性を保ちながらバックアップと復元できる機能を提供します。 CODRエンジンによる一貫性管理 CODR（Consistent Orchestrated Distributed Recovery）エンジンを活用することで、障害発生時にも分散ノード間のデータ整合性を維持し、アプリケーションをすばやく復旧可能です。 分散環境向けの最適化設計 ノード間の通信遅延や高負荷時の処理など、分散システム特有の課題に対応し、安定性と効率性を向上させます。 効率的なストレージ利用 分散データの特性を踏まえつつストレージを最適化し、増え続けるデータの保管コストを抑えながらも、高いパフォーマンスを実現します。 ランサムウェア対策 ランサムウェア攻撃が日常化する中、Rubrikは独自のアプローチでデータ保護を進化させています。 不可変バックアップによりデータ改ざんを防ぎ、機械学習を通じて異常を即座に検知します。 不可変バックアップ（Immutable Backup） Rubrik CDMは、バックアップデータを変更不可能な形式で保存します。これにより、ランサムウェアがバックアップを暗号化または削除するリスクを完全に排除します。                     適用範囲 ：オンプレミスやクラウド環境のいずれにも対応。 長期保存 ：安全なデータ管理が可能なため、コンプライアンス要件にも適合。 異常検知と脅威監視 Rubrikは、Rubrik CDMとRSCを連携させることで、機械学習を活用してデータの異常な変化を検知します。Rubrik CDMはデータの収集と管理を担い、RSCはそのデータを基に高度な分析を行い、ランサムウェア特有の挙動を迅速に感知して被害を最小限に抑えることが可能です。               検知方法 ：通常のデータ操作パターンを学習し、大量の暗号化やファイルの急激な削除など、ランサムウェア特有の挙動を感知します。 通知と可視化 ：異常が検知された場合、即座にアラートを出し、影響を受けたデータ範囲をわかりやすいレポート形式で提示します。 上記の方法により、オンプレミスでもクラウドでも同じ安心感を提供し、企業が抱えるセキュリティリスクを大きく軽減します。 多様なAPI活用 Rubrikは、幅広いツールやAPIとの連携を提供します。 たとえば ServiceNowのようなITSM（ITサービス管理）や運用プロセスの自動化を強化する運用管理ツールと組み合わせることで、日々の作業負荷を大幅に軽減できます。また、APIを通じて自動化を推進し、DevOpsやインフラ自動化戦略への柔軟な組み込みを可能にします。 こうした連携と自動化のしやすさが、現代のIT運用において大きな付加価値をもたらします。 Rubrikの付加サービスは、単なる補助にとどまらず、データ管理の可能性をしっかり広げてくれる！ Rubrik Mosaicやランサムウェア対策機能、そしてAPI活用が、それぞれのニーズに応えながら、企業のデータ管理を次のステージへと進めてくれる。 まとめ 今回の紹介では、Rubrikの主要な製品や機能について、基本的な部分を中心にお伝えしました。 Rubrik Cloud Data Management（CDM） や Rubrik Security Cloud（RSC） の統合管理機能、 Rubrik Mosaic を活用したNoSQLデータベース対応、そして ランサムウェア対策 や API活用 といったサービスの一端をご紹介しました。 しかし、Rubrikの魅力はこれだけではありません！実際には、ここで触れた以外にもさまざまな機能やユースケースがあり、もし興味があれば、 公式サイト などをチェックしてみてください。 内容をご覧いただき、ありがとうございました。今回の内容が、Rubrikをより深く理解するためのきっかけとなれば幸いです。

本記事は TechHarmony Advent Calendar 2024 12/24付の記事です 。 こんにちは！２０２４年度入社の野上です。 私は現在MySQLのレプリケーションを実装する案件に携わっており、勉強の毎日です。 初めて聞く用語も多く、用語をMySQLの公式ドキュメントで調べてみては、また知らない用語が現れることが多々。 レプリケーションの方式がたくさんある。。。何が違うんだろう。。。 そんな私が、初心者ながらレプリケーションの方式をまとめて記事にしました。 MySQLで初めてレプリケーションを実装される方が、方式を選ぶ際のご参考になれば嬉しいです。   レプリケーションとは まずレプリケーション （英：replication)は、日本語で「複製」という意味です。 ここでMySQLのレプリケーションとは、MySQLのデータベースを 違うサーバに複製するということを指します。   レプリケーションの目的 なぜレプリケーションが必要になるのか。それは、以下のような目的があります。 可用性の向上 ソースサーバ（メインで使用するDBサーバ）に障害が発生した際に、レプリカサーバ（複製されたDBサーバ）を参照先とすることでシステムの稼働が停止することを防ぎます。 負荷分散 複数のサーバからの参照を分散させることで、処理時間の短縮が期待できます。   レプリケーションの動作 レプリケーションという概念は理解できたと思いますが、実際にレプリケーションはどのような動作が行われているのかはわかりづらいと思います。 以下にレプリカサーバにデータの変更がレプリケーションされるまでの動作を説明します。   ソースサーバに対してトランザクションのコミットが実行される トランザクションとは、 データベース操作の複数の処理をまとめて１つの処理単位としたものです。　　 トランザクションを開始後、複数の処理を行い、「コミット」を実行することで、そのトランザクションに含まれる処理がデータベースに反映されます。 コミットを実行したトランザクションがバイナリログに書き込まれる バイナリログとは、データベース内で行われたすべての変更の記録を保持するログファイルのことです。 レプリカサーバ上のI/Oスレッドがソースサーバの変更を検知してリレーログに書き込む I/Oスレッドとは、レプリカサーバで動作するプロセスのことで、バイナリログを読み取り、レプリカサーバのリレーログへ書き込む処理を行います。 リレーログとは、ソースサーバから転送されたログを記録するファイルのことです。 SQLスレッドがリレーログを読み取りレプリカサーバのデータベースに適用する SQLスレッドとは、レプリカサーバで動作するプロセスのことで、リレーログを読み取ってソースサーバと同様の変更をデータベースに反映させる処理を行います。   レプリケーション方式 MySQLではソースとレプリカのレプリケーションの方式を選択することができます。 方式は、 レプリカ上のI/Oスレッドがソースの変更をリレーログに書き込む処理を、コミットの完了までに含むかどうか で異なります。 連続するトランザクション処理では、処理時間に差が生まれます。処理をコミット完了までに含まない場合は処理時間短縮できます。 しかし、この処理をコミットの完了までに含まない場合、障害発生時にソースとレプリカの整合性が保たれない場合があります。 つまり、方式を選択することで、 パフォーマンスや可用性が変化する ということです。 よって、方式はシステムの要件に合わせて決定する必要があります。 本記事では、以下の方式について違いを説明します。 非同期レプリケーション 準同期レプリケーション グループレプリケーション   非同期レプリケーション MySQLのデフォルトのレプリケーション方式です。 トランザクションに含む処理は以下の通りです。 ① 　コミットを実行する ② 　ソースで「データの更新」と「バイナリログの更新」を行う ③ 　コミットが完了する 以下の流れはトランザクションの処理に含まれません。 ❶　ソースのバイナリログの更新を検知し、I/Oスレッドが更新を受け取ってレプリカのリレーログに書き込む ❷　SQLスレッドがリレーログの内容をデータに反映させる ここでは、レプリカサーバでの処理が、トランザクションの処理に含まれていません。 これが「非同期」と呼ばれる所以です。   ここで非同期レプリケーションのメリット・デメリットをまとめます。 メリット パフォーマンス レプリカへの更新反映を待たずにコミットを完了させるため、他の方式と比較して処理時間が短いです。 デメリット 可用性の不安 レプリカへの更新反映前にソースで障害発生すると、障害発生前の変更がレプリカに反映されません。   準同期レプリケーション 準同期レプリケーションは、トランザクションに含まれる処理が非同期レプリケーションと異なります。 トランザクションに含む処理は以下の通りです。 ① 　コミットを実行する ② 　ソースで「データの更新」と「バイナリログの更新」を行う ③ 　ソースのバイナリログの更新を検知し、I/Oスレッドが更新を受け取ってレプリカのリレーログに書き込む。 ④　コミットが完了する 以下の流れはトランザクションの処理に含まれません。 ❶　SQLスレッドがリレーログの内容をデータに反映させます。 準同期レプリケーションでは、レプリカへのログの転送を待ってからコミットが完了するのです。   ここで準同期レプリケーションのメリット・デメリットをまとめます。 メリット 可用性 レプリカへログが転送されるのを待ってからコミットが完了するため、ソースで障害が発生してもコミットが完了したデータの変更をレプリカが失いません。 デメリット パフォーマンス レプリカへログが転送されることを待つため、コミットが完了するまでの応答速度が遅くなります。   グループレプリケーション グループレプリケーションは３台以上のDBサーバで構成される際に使用されます。 全てのサーバが、プライマリ（グループレプリケーションでは書き込みが行われるサーバを『ソース』ではなく『プライマリ』と呼ぶ）やレプリカにもなり得るため、トランザクションの実行有無の管理が大変です。 この方式は 『GTID（グローバルトランザクションID）』 が導入されたことで、可能となりました。 GTID とは・・・ 　発生元のサーバー (ソース) でコミットされた各トランザクションに関連付けられる一意の識別子です。 この識別子は、レプリケーション構成内のすべてのサーバーで一意です。 　GTIDを使用することで、どのサーバにどのトランザクションまで実行してあるのかがわかるため、レプリケーション設定時に レプリケーションを始める トランザクションを自動で設定 してくれます。   トランザクションに含む処理は以下の通りです。 ① 　コミットを実行する ② 　プライマリで「データの更新」と「バイナリログの更新」を行う ③ 　プライマリのバイナリログの更新を検知し、プライマリ以外のサーバのI/Oスレッドが更新を受け取ってリレーログに書き込む ④　コミットが完了する 以下の流れはトランザクションの処理に含まれません。 ❶　プライマリ以外のサーバのSQLスレッドがリレーログの内容をデータに反映させます。 プライマリ以外のサーバにログを転送してからコミットが完了する点は準同期レプリケーションと同様ですが、 グループレプリケーションでは すべてのサーバへログの転送が行われたことを待ってからコミット完了 されます。   ここでグループレプリケーションのメリット・デメリットをまとめます。   メリット 可用性 ２つ以上のサーバにレプリケーションを行うため、２台構成のレプリケーションと比較して可用性が向上します。 レプリカが1台の準同期レプリケーションよりも可用性が高いです。 負荷分散 全てのサーバがプライマリになることができるため、負荷を分散させることが可能です。 デメリット パフォーマンス グループ内すべてのサーバへ更新を転送することを待つため、処理速度が低下します。 準同期よりも処理速度は遅くなります。   まとめ 本記事ではMySQLのレプリケーション方式について、各方式の利点をまとめました。 実際、レプリケーション方式はシステムが求める要件によって選択する必要があります。 この記事にまとめたような各方式の利点を軸に、レプリケーション方式を選択してみてください！

本記事は TechHarmony Advent Calendar 2024 12/23付の記事です 。 こんにちは。ひるたんぬです。 2024年も残すところ約1週間。今年も色々なことがありましたね。。 皆さんは年末年始をどのようにお過ごしになりますか？ 昨年のとあるアンケートの結果によりますと、年末年始は「自宅・自宅周辺で過ごす」という方がおよそ6割だったようです。 しかも5年連続で最も多かったということなので、お家で過ごす年末年始が定番となりつつあるのですかね。 出典： 日本生命保険相互会社「ニッセイ インターネットアンケート ～「2023年の振り返りと新年への期待」について～」 そんな年末年始に行うことの一例として、大掃除が挙げられるのではないでしょうか。 今回は、そんな大掃除の中でも「AWS環境における大掃除」を行う機会があったので、記事にしようと思います。 AWSにおける大掃除の定番ツール 家の大掃除に様々な便利ツールがあるように、AWSの大掃除にも目的や用途によって多種多様な大掃除ツールがあります。 例えば、AWS CloudFormationのスタックを何が何でも削除してくれる「 delstack 」、S3バケットの中身やバケット本体の削除を容易にする「 cls3 」など… 上記に挙げたツールはAWS HEROに選出された後藤さんが開発に携わられているようです！すごい… 参考： 後藤さんの紹介記事 特定の用途において使えるツールもとても魅力的ですが、今回は何でも消しちゃうよ！！でおなじみの「aws-nuke」を使ってみようと思います。 aws-nukeについては初代Jr. Championsの方々も多く記事を執筆されています。 私も二代目としてその流れを継いだ…というのは後付けの理由です。 私が観測した初代Jr. Championsの皆様のaws-nukeに関する記事の一部 → aws-nukeで作るマルチアカウントのお掃除機能 → aws-nukeとBubbleで「リソース全削除ボタン」を作る 先人の知恵を借りてaws-nukeを使おう！…？ 上記の通り、aws-nukeは既に多くの方が利用しており、日本語でも数多くの記事がありました。 それらの記事も参考にさせていただいていると、ほとんどの記事は下記GitHubのリポジトリのソースコードを使っていたので、「さすが有名なOSSだなぁ〜」と何気なく見てみることに。 GitHub - rebuy-de/aws-nuke: Nuke a whole AWS account and delete all its resources. Nuke a whole AWS account and delete all its resources. - rebuy-de/aws-nuke github.com …すると、上部に？？と思う表記を見つけました。そう、「 Public archive 」です。 AWSは更新が活発である上、他のブログ記事ではこのaws-nukeも活発に更新が行われている…と思ったのでアーカイブなのはなにか妙だと思い読み進めると、 This repository for aws-nuke is no longer being actively maintained. We recommend users to switch to the actively maintained fork of this project at  ekristen/aws-nuke . We appreciate all the support and contributions we’ve received throughout the life of this project. We believe that the fork will continue to provide the functionality and support that you have come to expect from aws-nuke. Please note that this deprecation means we will not be addressing issues, accepting pull requests, or making future releases from this repository. Thank you for your understanding and support. 引用元： README.md なんとaws-nukeがフォークされ、以降はそちらでメンテナンス（更新など）がされると記載されております。 つまり、今まで多くの方が愛用されてきたrebuy-de氏によるaws-nukeはもう更新されることはなく、以降はekristen氏によるaws-nukeを使ってね！ということのようです。 Public archiveとなったのは 2024年10月15日です。 新しい「aws-nuke」 では、ekristen氏によるaws-nukeは何が変わったのでしょうか？ 大きな内部の変化の一つとして「 libnuke 」という共通モジュールを使用するようになった点が挙げられます。 このlibnukeの開発にはrebuy氏、rebuy氏のaws-nukeの存在がなければできなかったようです。感慨深いですね… libnukeの共通モジュールを用いることにより、AWSのリソース削除「aws-nuke」はもちろん、Azureのリソース削除「 azure-nuke 」が短期間で実装できたと書かれています。 Google Cloud向けの削除ツールについては現時点で開発中のようです。 参考： https://github.com/ekristen/gcp-nuke 使い方の観点で見た違いですが、こちらについては以下の記事で既に分かりやすくまとめられていましたので、参考記事として掲載させていただきます。 aws-nuke の GitHub リポジトリがアーカイブされていたので状況を整理する - Qiita はじめにaws-nuke とは rebuy.de により開発されていたオープンソースの AWS リソース削除ツールです。AWS アカウントのお掃除に活用されている方も多いのではないでしょうか。h… qiita.com 使ってみよう！！ というわけで早速使ってみました。 今回は偶然にも合法的に大掃除を許可された環境を提供されたので、そこで検証をしてみました。 AWS版「バルスボタン」をつくろう 「バルスコマンド」と言えばピンとくる方もいらっしゃるのでは無いでしょうか？ ご存じない方は是非検索してみてください。ただし興味深くても実行するのはおすすめしません。 今回は、手軽にAWS環境のお掃除（大掃除）ができるように、Amazon CodeCatalystのワークフローを用いて実装してみました。 Amazon CodeCatalystの本来の用途とは異なっているような気もしますが…私がAmazon CodeCatalyst好きなので。 以降で紹介するものはAWSの環境を大きく変更（破壊）しうるものが含まれます。 実際に使用される際には慎重に行ってください。私は責任を取れません。。 今回は新規プロジェクトを作成しました。 またSource repositoryも新規で作成し、その中にaws-nukeのconfigファイルを「nuke-config.yaml」という名前で配置します。ファイルの内容については下記公式ドキュメントを参考に、掃除したい範囲（リージョン）や種類（リソース）を記入してください。 Overview - AWS Nuke AWS Nuke is a tool to clean up your AWS account by nuking (deleting) all resources within it. ekristen.github.io なお、公式ドキュメントにはある程度整理された雛形もあるので、こちらをベースに作成しても良いと思います。 Starter Config - AWS Nuke AWS Nuke is a tool to clean up your AWS account by nuking (deleting) all resources within it. ekristen.github.io 次にWorkflowです。こちらが今回のメインとなります。 内容としてはシンプルで、まず「nuke-dry-run」にて、削除候補のリソースを抽出します。 次にApprovalにてその内容を確認し、承認するかどうか判断します。 承認された場合は、「nuke-run」により、リソースの削除が実施される、といった流れとなっています。 このフローのYAMLファイルを以下に示します。 Name: Workflow_8340 SchemaVersion: "1.0" # Optional - Set automatic triggers. Triggers: - Type: Push Branches: - main # Required - Define action configurations. Actions: nuke-dry-run: # Identifies the action. Do not modify this value. Identifier: aws/build@v1.0.0 # Specifies the source and/or artifacts to pass to the action as input. Inputs: # Optional Sources: - WorkflowSource # This specifies that the action requires this Workflow as a source Outputs: # Optional; Automatically discover reports for popular test frameworks AutoDiscoverReports: Enabled: true # Use as prefix for the report files ReportNamePrefix: rpt # Defines the action's properties. Configuration: # Required - Steps are sequential instructions that run shell commands Steps: - Run: nuke_ver=`curl -s https://api.github.com/repos/ekristen/aws-nuke/releases/latest | jq -r .tag_name` - Run: curl -L https://github.com/ekristen/aws-nuke/releases/download/${nuke_ver}/aws-nuke-${nuke_ver}-linux-arm64.tar.gz -o aws-nuke.tar.gz - Run: tar -zxvf aws-nuke.tar.gz - Run: ./aws-nuke nuke --config nuke-config.yaml --force --quiet | tee nuke-list.txt Container: Registry: CODECATALYST Image: CodeCatalystLinuxLambda_Arm64:2024_03 Compute: Type: Lambda Fleet: Linux.Arm64.Large Environment: Name: cleanup-resource-env Approval: # Identifies the action. Do not modify this value. Identifier: aws/approval@v1 Configuration: ApprovalsRequired: 1 DependsOn: - nuke-dry-run nuke-run: Identifier: aws/build@v1.0.0 Inputs: Sources: - WorkflowSource Outputs: AutoDiscoverReports: Enabled: true ReportNamePrefix: rpt Configuration: Steps: - Run: nuke_ver=`curl -s https://api.github.com/repos/ekristen/aws-nuke/releases/latest | jq -r .tag_name` - Run: curl -L https://github.com/ekristen/aws-nuke/releases/download/${nuke_ver}/aws-nuke-${nuke_ver}-linux-arm64.tar.gz -o aws-nuke.tar.gz - Run: tar -zxvf aws-nuke.tar.gz - Run: ./aws-nuke nuke --config nuke-config.yaml --force --quiet --no-dry-run | tee nuke-result.txt Container: Registry: CODECATALYST Image: CodeCatalystLinuxLambda_Arm64:2024_03 Compute: Type: Lambda Fleet: Linux.Arm64.Large Environment: Name: cleanup-resource-env DependsOn: - Approval Workflowを作成する際に工夫した点としては、以下の二点です。 常に最新のaws-nukeバージョンを取得する点 → GitHubのAPIよりバージョンの値が格納されているタグの情報を取得し、それをcurl先のURLに代入しています aws-nukeの実行環境としてLambdaを選択している点 → EC2での実行に比べ、スタートアップにかかる時間を大きく削減することができます ということで…バルス！！！ 実際に動かしてみました。今回はConfigファイルにてシンガポールリージョンに限定し検証をしました。 実際に削除候補は下記のようなログで確認が可能です。 確認し、問題なければ承認をします。これにより本番のバルスが始まります。 最終的に実行が完了し、WorkflowがSucceededになりました。 これだけで大掃除完了です。簡単ですね！！ 以降はWorkflow上の「New run（通称：バルスボタン）」を押す、もしくはConfigファイルを更新してリポジトリにプッシュすることで簡単に実行することができます。 改善したい点 現在は削除するリソースの一覧をログから確認することしかできない状況です。 そのため、リソースの量が多くなってしまった場合、確認作業が大変になってしまいます。 承認プロセスなどで簡単に確認できるようにできれば…と思いましたが、現時点では実現が難しそうです。 おわりに 今回は、年末ということでデジタル空間の大掃除グッズをご紹介しました。 アナログ空間もデジタル空間もどちらもスッキリし、新年を迎えたいですね！

本記事は TechHarmony Advent Calendar 2024 12/22付の記事です 。 こんにちは。今回がTechHarmony初投稿の、SCSK新人の さと です。 「TechHarmony Advent Calendar 2024」および「新人ブログマラソン 2024」のダブルエントリーでお届けします。 突然ですが、皆さんが初めて出会ったAIはなんでしょうか？何をもってAIとするか （あるいは、そもそも知能とは何か） は議論の余地はありますが、私が人生で初めて触れた「AIらしいAI」といえばSiriですね。アプリを開いたりタイマーをセットしたり、ジョークも言える、そんなアシスタントが電話の中にいるのが面白くて、家電量販店に入り浸っていた小学生時代を思い出します。 時は流れて2022年の末にはChatGPTが登場し、世間に衝撃を与えました。あれからさらに2年が経ち、モデルを大きくすることによる性能向上に限界が見えてきたなどもと言われている生成AIの技術ですが、今もなおRAG（検索拡張生成）や組み込みによるCoT（思考の連鎖）などによる機能強化が続いていますね。 そんな中、先日の re:Invent 2024 においてAmazon Bedrockから新たに AIエージェント同士を連携させる という機能が発表されましたので、今回はそのご紹介です。 新発表！Amazon Bedrock Multi-Agent Collaborationの概要 そもそもAIエージェントって…？ とはいえ、そもそもエージェントって何でしょう？私自身、それが具体的に何を指すかなどかは考えたことがありませんでした。いろいろと定義はあるようですが、ここでは説明にあたり、AWSの言葉を借りようと思います。 人工知能 (AI) エージェントは、 環境と対話 し、 データを収集 し、そのデータを使用して 自己決定タスクを実行 して、 事前に決められた目標を達成 するためのソフトウェアプログラムです。目標は人間が設定しますが、その目標を達成するために実行する必要がある最適なアクションは AI エージェントが独自に選択します。 AI エージェントとは何ですか? – 人工知能のエージェントの説明 – AWS エージェントでないAIと大きく違うところというと、自律的に環境と相互のやり取りができる点でしょうか。Bedrockのエージェントでは、これらはLambda関数の実行やRAGによるデータ取得といった仕組みによって実現されています。 新機能でできるようになったこと Amazon Bedrock now supports multi-agent collaboration - AWS Discover more about what's new at AWS with Amazon Bedrock now supports multi-agent collaboration aws.amazon.com さて、今回の発表ではMulti-agent collaboration（複数エージェントによる協調）機能が発表されました。その概要は以下の通りです。 * 画像は AWS公式ブログ に掲載のものを基に作成   スーパーバイザーエージェントとサブエージェントによる分担 ユーザーから受けとったリクエストをスーパーバイザーがタスクへと切り分け、サブエージェントに割り当てて指揮をとる。 サブエージェントは各領域の専門家として振る舞い、データ取得や分析の結果をスーパーバイザーへ返す。 スーパーバイザーは各サブエージェントから受け取った結果をまとめ直し、ユーザーへの回答とする。 設定の容易さ 数クリックで既存のエージェントをサブエージェントとして設定し、より複雑なワークフローに対応可能 ルーティング付きスーパーバイザーのオプション このオプションをオンにすると、スーパーバイザーは単純なリクエストが来た場合、これを直接サブエージェントへ受け渡すことで処理効率を最適化する。複雑な処理に対しては、スーパーバイザー側で切り分け処理を行ったうえでサブエージェントへ割り当てる。 実際に動かしてみる それでは、早速このMulti-agent collaboration機能を使っていきましょう。 今回は、上で紹介した AWSの公式ブログ でのデモンストレーションを参考に、エージェントを作成します。 エージェント構成 今回は、複数のエージェントで協調してBedrock質問回答ボットを実現します。 右図のように、一方のサブエージェントがWebからAmazon Bedrockに関する情報を取得、もう一方のサブエージェントは予め登録した対象読者の年齢別スタイルガイドから文章の書き方に関する情報を提供し、それらをスーパーバイザーエージェントがとりまとめるという構成です。   サブエージェントの作成 まずは、専門家として働くサブエージェントを2つ設定していきましょう。この作業は、これまでの単独で動くエージェントを設定するときと同じものです。 AWSナレッジ取得エージェント ナレッジベースの設定 情報を取得するエージェントを作成するにあたり、先にナレッジベースを設定する必要があります。ナレッジベースの設定画面からデータソースとしてWeb Crawlerを選択します。 次に、クローリングを行うURLを入力します。今回は、 Amazon Bedrockのユーザーガイド のページを指定しました。埋め込みモデルにはAmazonのTitan Embeddings G1を選択し、その他の設定はデフォルトのままとします。 データソースを登録したら、 同期処理 （データをベクトル埋め込みに変換し、クエリ可能な状態にする処理）を行う必要があります。データソース一覧から「同期」ボタンを押し、しばらく待ちます。数分から数時間かかるという表示が出ますが、今回は10分弱で完了しました。 ナレッジベースをエージェントに追加 ナレッジベースの作成が完了したので、次はこれをエージェントに追加します。「Amazon Bedrock」>「エージェント」から「エージェントを作成」ボタンを押し、エージェントビルダーを開きます。 ナレッジベースの設定項目から、作成したナレッジベースを登録して完了…かと思いきや、次のような表示が出てしまいました。 エラーメッセージ ナレッジベースを追加する前に、エージェントリソースロールを定義してエージェントを保存する必要があります。 どうやら、一旦エージェントの設定を保存してからナレッジベースを設定する必要があるようです。保存ボタンを押し、その後再度ナレッジベースを登録することでエラーは解消しました。その他の設定はデフォルトのままにしました。 エージェントを単独で試してみる AWSの情報を取得するエージェントの設定が終わったので、一旦ここで検索機能が正しく働いているか試してみましょう。画面上部の「準備」ボタンを押すと、チャット形式でエージェントを試すことができるようになります。 元のモデルにないはずの最新の機能に関する回答が、ソース付きで返ってきました。バッチリですね。 比較のため、ナレッジベースを接続していない基盤モデルに対しても質問してみます。 マルチエージェントに関しては知らないものの、学習時点の知識でマルチエージェント機能を実現する方法について教えてくれました。 スタイル取得エージェント 同様に、スタイルを取得するエージェントの設定を進めます。読み込ませるスタイルガイドはChatGPTに書いてもらいました。 年齢別説明スタイルガイド（抜粋） 1. 小学生（6～12歳） 難易度 : 初級 目指すスタイル : シンプルで具体的な言葉を使い、短い文で説明する。興味を引く比喩や例を活用。 ポイント : – 難しい言葉は避け、もし使用する場合は必ずその意味を説明する。- 親しみやすい例を挙げる（例: 「S3バケットはデータを保存するための大きな箱みたいなもの」）。 – 1つの文で1つのアイデアだけを伝える。 具体例 : – 「コンピューターにデータを保存する場所をバケットと呼びます。バケットはたくさんのファイルをしまえる箱のようなものです。」 – 「バケットを作るには、名前を決めてクリックするだけです！」 2. 中学生（13～15歳） 難易度 : 初級～中級 目指すスタイル : 少し複雑な言葉を使いながらも、文を短めに保ち、具体例や現実世界との関連を強調する。 ポイント : – 少し抽象的な概念も具体例とセットで説明。 – 「なぜその作業が必要なのか」を簡単に補足。 – 手順を順序立てて、明確な指示を出す。 具体例 : – 「Amazon S3は、データを安全に保存できるオンラインの倉庫のようなものです。例えば、写真や動画を保管するために使えます。」 – 「バケットを作るには、まず名前を決めます。その名前は、ほかの誰とも同じではないユニークなものにしてください。」 […] 残りの手順は基本的にAWSのナレッジを取得するエージェントと変わらないため詳しい説明は割愛しますが、こちらのデータはテキスト形式で保存し、カスタムデータソースとして直接取り込むことでナレッジベースに登録しました。 スーパーバイザーエージェントの作成 最後に、これらのエージェントを取りまとめるスーパーバイザーエージェントを設定していきましょう。エージェントビルダーからMulti-agent collaborationをオンにし、Agent Collaboratorとしてサブエージェントを追加していきます。今回は、ルーティング機能はオフとしています。 エージェントを追加する設定画面は上の通りです。協調するエージェントのほかに、 Agent alias （エージェントの特定のバージョン）、 Collaborator Name （スーパーバイザー側で用いる呼び名）がすべて必須項目となっており、このため一度それぞれのサブエージェント側の設定に戻り、エイリアスを作成する必要がありました。2つのサブエージェントの呼び名はそれぞれaws-expert, style-coachとしました。 最後に、エージェントのプロンプトを入力して完成です。 ユーザーからAmazon Bedrockに関する質問を受け、サブエージェントaws-expertから情報を取得します。もし、ユーザーが対象読者の年齢を明示した場合は、追加でサブエージェントstyle-coachから説明の書き方に関する情報を取得し、説明を適切に翻訳してからユーザーに回答します。 完成！果たして… エージェントが完成したので、試してみましょう。まずは、年齢を指定せずに質問をしてみます。 スーパーバイザー、サブエージェントを通じて、情報が返ってきました。回答の下部にある「トレースを表示」から、どのようにエージェントが動いたのかタイムライン形式で見てみましょう。 上のように、サブエージェントはAWSの情報を取得するエージェントだけが稼働していたことが確認できます。では、年齢層を指定して質問した場合はどうなるでしょうか。 読み込ませたスタイル通り、比喩や例が多く用いられていることが確認できます。こちらでも、トレースを見てみましょう。 ちゃんと、2つのサブエージェントが起動しています。スーパーバイザーエージェントによって、タスクに応じた適切な振り分けがなされていることが分かります。ついでに、中学生向けの説明もお願いしてみましょう。 説明を通して比喩を多く使っていた小学生向けの説明に対し、より具体的な説明になりました。 おわりに いかがでしたか？Bedrockに触れるのは今回が初めてでしたが、GUIでシンプルに設定を進められる印象でした。今回は簡単のためにLambdaとの連携は行いませんでしたが、工夫次第では単独のエージェントよりもずっと複雑なタスクを実行できる可能性を感じました。 最後までお読みいただき、ありがとうございました。良いクリスマス＆新年をお迎えください！

本記事は TechHarmony Advent Calendar 2024 12/21付の記事です 。 どうも。現在の生成AIの流行を踏まえたAIもののSF小説を面白がって読んでいる寺内です。 re:invent 2024 で発表されたAmazon SageMaker Unified Studio の紹介記事の続きとなります。 【re:Invent 2024発表】次世代 Amazon SageMaker Unified Studio に触ってみた 2024年のre:Inventで発表された次世代機械学習モデル開発IDEである、Amazon SageMaker Unified Studio。触ってみたので、使い始める最初のステップをご案内します。 blog.usize-tech.com 2024.12.04 この記事で書くこと SageMaker は機械学習モデルを作成するための統合IDE環境を提供します。機械学習モデルの作成のためには、その学習データや学習アルゴリズムの選択のためにデータ分析を行う準備段階があります。そのため、データ分析ツールとして使ってみるということをやります。 分析を行うことが目的ではなく、この新しいSageMaker Studio でどのような作業の流れになるのかを把握することが目的です。 この記事は前編として、データの準備をして、Amazon SageMaker Unified Studio でSQLクエリを実行してみるところまで行います。 後編では、JupyterNotebookを使った実際の分析を行います。   分析シナリオ 世の中には多くのデータセットが官公庁や大学などの研究機関で公開されています。また機械学習学習者向けのデータセットも公開されています。しかしこの記事では、SageMaker Unified Studio を使った流れを把握することを目的としているため、難しいデータセットは使わず、簡単なCSVを作りそれを使います。 データセットは、生徒の5教科のテスト結果のリスト500人分を乱数から作ります。そのCSVをSageMaker に読み込ませて教科間の相関があるかを分析します。   作業の流れ 大雑把な作業な流れは以下となります。 CSVデータの作成 SageMaker Lakehouse にCSVデータのアップロード クエリエディタの起動 SQLを実行 では順番にやっていきましょう。   CSVデータの作成 以下のpython プログラムを create_score.csv というファイル名で保存して実行します。実行場所は、ローカルPCでもCloudShellでもJupyter notebook でもかまいません。 import random import csv def generate_normal_random(mu, sigma, lower_bound, upper_bound): while (True): x = random.gauss(mu, sigma) if lower_bound <= x <= upper_bound: return int(x) # 作成する生徒の人数 n=500 # 生徒の名前のリストを作成します。 names = [] for i in range(n): name = c h r(65 + (i//26)//26 ) + c h r(65 + (i//26) ) + c h r(65 + (i%26) ) # c h r() とスペースを入れています。実行する時は文字間のスペースを除去してください。 names.append(name) # テストの点数のリストを作成します。 subjects = ["Japanese", "Math", "Science", "Social", "English"] scores = [] for i in range(n): japanese=generate_normal_random(50, 15, 1, 100) math=generate_normal_random(50, 15, 1, 100) science=generate_normal_random(50, 15, 1, 50)+math//2 social=generate_normal_random(50, 15, 1, 100) english=generate_normal_random(50, 15, 1, 50)+japanese//2 score = [japanese,math,science,social,english] scores.append(score) # CSV ファイルにデータを書き込みます。 with open("test_scores.csv", "w", newline="", encoding="utf-8") as csvfile: writer = csv.writer(csvfile) writer.writerow(["Name"] + subjects) for i in range(n): writer.writerow([names[i]] + scores[i]) すると exam_scores.csv というファイルが create_score.csv と同じディレクトリに作られます。 exam_scores.csv をローカルPCにダウンロードしてください。 生徒の名前は、AAA、AAB、AACと変わり、AAZまでいくと次の人はABAという名前になります。 テストの点数は、国語、数学、理科、社会、英語と並んでおり、1点から100点の範囲です。 24行目から28行目が各教科の点数を作っているところです。 単純な乱数になっていないことがわかります。 テストの点数分布は、多くの生徒を集めるとおおよそ正規分布になると思います。24行目の国語の点数のところをみていただく、一様分布の乱数ではなく、正規分布に則った乱数としています。 最初の引数の50は平均値、次の15は標準偏差、そして点数の最小と最大を指定しています。 そして28行目の英語の点数の生成では、乱数を50点までとし残りの50点を国語の点数の半分を与えるとしています。これは相関分析した時に国語と英語に相関を出すためです。同様に数学と理科を同じ関係にしています。 非常に恣意的なデータですが、学習用としてご容赦ください。   SageMaker Lakehouse にCSVデータのアップロード ローカルPCにダウンロードした exam_scores.csv をAWSマネージメントコンソールを使ってSageMaker Lakehouse にアップロードします。 マネージメントコンソールのサービス検索で、SageMaker platform にアクセスします。そこでドメイン作成、プロジェクト作成を行います。この手順については、前回のブログ『 【re:Invent 2024発表】次世代 Amazon SageMaker Unified Studio に触ってみた 』に記載していますので、ここでは省略します。 プロジェクトを作成したあと、そのプロジェクトポータルの画面になります。その左にあるサイドメニューから「データ」を選択します。 すると真ん中のデータ一覧のカラムに「Lakehouse」「Redshift」「S3」の3つのカテゴリがあり、「Lakehouse」が展開されているはずです。「Lakehouse」の中には「AwsDataCatalog」があります。 ファイルをアップロードするには、検索窓の右にある+ボタンを押します。 すると「add data」のインタラクティブウィンドウが開きますので、「Upload data」を選択します。 そしてアップロードするファイルをドラッグ・アンド・ドロップで指定すると、データフォーマットなどのパラメータを良しなに決定してくれます。そのままUploadボタンを押します。 完了すると、CSVファイルがLakehouseに取り込まれています。 これでデータのアップロードが完了です。   クエリエディタの起動 このCSVデータにSQLを発行します。そのためにクエリエディタというものが提供されています。 クエリエディタの開き方は複数あり、以下の2つが主たるところです。 データベースを指定して開く さきほどのデータ一覧のツリーを展開し、 exam_scores テーブルを選択します。右の三点メニューを押すと以下のように開き方の選択肢が出ます。 Query with Athena Query with Redshift JupyterLab ノートブックで開く Lakehouse にあるデータは、S3 にあろうがRedshift にあろうが統一的にアクセスできるのが、Unified Studio の特徴です。 ここでは「Query with Redshift」で開きましょう。 すると以下のように行頭10行を自動で検索してくれます。 クエリエディタもノートブックと同じセル形式の入力と出力を繰り返すインターフェースです。 SQLを書き換えるなり、「Add SQL」をしてセルを追加するなりして作業をしていきます。 メニューからクエリエディタを起動する 次に、テーブルを指定するのではなく直接クエリエディタを起動するやり方です。 プロジェクトポータルにある上部のメニューから「Build」を開きます。すると、真ん中の列に「Query Editor」というのがあるので、それを選択します。 初めてクエリエディタを起動したら、データベースが選択されていません。右上にある「Chose database」のプルダウンを押し、以下のようにデータベースを選択します。 ここでは以下を選択しています。 CONNECTIONS: Redshift (Lakehouse) DATABASES: awsdatacatalog SCHEMAS: glue_db_XXXXXXXXX そして入力セルにSQLを入力し、セルの左上にある三角マーク(再生ボタン)を押すことで、SQLを実行できます。   SQLの実行 単純な検索と可視化 ではまず単純にデータを表示してみましょう。 select * from "awsdatacatalog"."glue_db_43g5jgitm5jkex"."exam_score" ORDER BY math limit 50; すぐに検索結果が出たと思います。RedshiftといってもRedshift Serverlessですので、料金面ではあまり心配がありません。 ではこの結果をグラフで可視化してみます。 結果の右上にある棒グラフボタンを押します。 こんな画面が出ると思います。 グラフのX軸は name が指定されています。Y軸は指定されていません。数学の点数 math を選択してみましょう。SQLでは、 ORDER BY でソートしているので昇順で50人分の結果が出ています。 グラフがリアルタイムに描画されたと思います。 「Type」を変えると、いろいろなグラフを描くことができます。 ちょっと複雑なSQL では、この数学の点数の分布を見てみます。 点数の範囲を10点ごとに人数を数え、それを棒グラフにしてみましょう。 以下のSQLを実行します。 SELECT CASE WHEN math between 1 AND 10 THEN ' 1-10' WHEN math between 11 AND 20 THEN '11-20' WHEN math between 21 AND 30 THEN '21-30' WHEN math between 31 AND 40 THEN '31-40' WHEN math between 41 AND 50 THEN '41-50' WHEN math between 51 AND 60 THEN '51-60' WHEN math between 61 AND 70 THEN '61-70' WHEN math between 71 AND 80 THEN '71-80' WHEN math between 81 AND 90 THEN '81-90' WHEN math between 91 AND 100 THEN '91-100' END AS 範囲, Count(*) AS 人数 FROM awsdatacatalog.glue_db_43g5jgitm5jkex.exam_score GROUP BY 範囲 ORDER BY 範囲 以下のように実行できました。 グラフで可視化してみます。 グラフの「Type」を棒グラフ「Bar」を選択します。Y軸には「人数」を選択します。 すると以下のようになります。 数学の点数の人数分布が正規分布になっていることがわかります。これはデータ作成時に以下のように指定していたためです。 math=generate_normal_random(50, 15, 1, 100) では同じく理科についても分布をみてみましょう。SQLは以下です。 SELECT CASE WHEN science between 1 AND 10 THEN ' 1-10' WHEN science between 11 AND 20 THEN '11-20' WHEN science between 21 AND 30 THEN '21-30' WHEN science between 31 AND 40 THEN '31-40' WHEN science between 41 AND 50 THEN '41-50' WHEN science between 51 AND 60 THEN '51-60' WHEN science between 61 AND 70 THEN '61-70' WHEN science between 71 AND 80 THEN '71-80' WHEN science between 81 AND 90 THEN '81-90' WHEN science between 91 AND 100 THEN '91-100' END AS 範囲, Count(*) AS 人数 FROM awsdatacatalog.glue_db_43g5jgitm5jkex.exam_scores GROUP BY 範囲 ORDER BY 範囲 こうなります。 数学と比べると明らかに中央値が下がっています。 これはデータ生成にて、理科の点数は25点を平均となる50点までの乱数に、数学の半分の点数を足した構成になっているからです。 science=generate_normal_random(25, 15, 1, 50)+math//2 以上がSQLでの簡単なデータ分析でした。 可視化ツールのほうでヒストグラムのグラフを作ることもできるので、もっと簡単なSQLで行けそうな気もします。 ということで、データの作成からLakehouse へのアップロード、そしてSQL実行と可視化の手順を見てきました。 慣れると非常に早くデータを取り扱うことのできるツールです。機械学習をやらないから、ということで使わないのは勿体ないくらいです。 次回は、Jupyterノートブックとの連携にトライします。 ではまた。

こんにちは、広野です。 AWS Amplify は以前はカスタムドメインに Zone Apex を設定できなかった記憶があるのですが、今ではできるようになっていました。(※私の勘違いかもしれませんが) そして、マネジメントコンソールでは簡単に設定できますが、AWS CloudFormation ではどのように設定すればよいのかわかりませんでした。AWS 公式ドキュメントにも掲載がなく、ネット上の情報もなかったので、ここで紹介しておきます。 参考: マネジメントコンソールでの設定方法 ストレートに Zone Apex の設定方法が書かれていないのですが、「ルートを除外する」だと Zone Apex を登録しない、「ルートを含む」だと Zone Apex を登録するようになっています。 Managing subdomains - AWS Amplify Hosting Describes how to manage the subdomains for an app deployed in Amplify that is connected to a custom domain. docs.aws.amazon.com 設定すると、AWS が自動でデプロイした Amazon CloudFront ディストリビューションをターゲットにした Amazon Route 53 エイリアスレコードが作成されました。モザイクで隠していますが、レコードは Zone Apex です。この Amazon CloudFront ディストリビューションは AWS 管理下にあり、このドメイン名に対してさらにエイリアスレコードを作成しようとしても、拒否されました。 AWS CloudFormation による設定方法 カスタムドメインは AWS::Amplify::Domain のリソースとして設定します。 公式ドキュメントでは、その中の Prefix という項目でサブドメインを設定できます。例えば www.domain.com であれば Prefix に www を設定します。では、URL を Zone Apex (この場合、domain.com) にしたい場合はどう書くのか？は掲載されていませんでした。 AWS::Amplify::Domain SubDomainSetting - AWS CloudFormation The SubDomainSetting property type enables you to connect a subdomain (for example, example.exampledomain.com) to a spec... docs.aws.amazon.com 実のところ簡単で、 Prefix に空文字 “” を指定すればよい だけのことでした。 以下、AWS CloudFormation テンプレートの抜粋です。 AmplifyDomainProd: Type: AWS::Amplify::Domain Properties: AppId: !GetAtt AmplifyConsole.AppId DomainName: xxxxxx.xxx CertificateSettings: CertificateType: CUSTOM CustomCertificateArn: !Ref CertificateArn SubDomainSettings: - BranchName: main Prefix: "" EnableAutoSubDomain: false これにて、マネジメントコンソールで設定したときと同じ状態にすることができました。 まとめ いかがでしたでしょうか。 今回はニッチな情報でしたが必要な方には必要なものだと思います。 本記事が皆様のお役に立てれば幸いです。

はじめに システムを構築していると、パフォーマンスチューニングの必要な状況に直面することはかなり多いと思います。ただ、パフォーマンスチューニングを行うにはどの処理で何秒かかっているのかを測定して、ボトルネックとなっている箇所を特定しなければなりません。 そんな際に X-Ray をお手軽に使ってみませんか？　というご提案です。 お手軽設定 AWS X-Ray には、いろいろと機能がありますが、AWSのベストプラクティスにもあるように まずはスモールスタートで開始することにします。 Lambda 好きの私としては Lamba関数 のパフォーマンスチューニングのネタとして計測に使いたいのでLambda関数内の処理の時間計測で使用したいと思います。 ライブラリのインポート Python の環境へのインストールは  pip install aws-xray-sdk で行います。 AWS Serverless Application Model (AWS SAM) などを利用して構築している場合には、 requirements.txt の中に aws-xray-sdk を追加します。 ソースコード側では、こんな感じで xray_recoreder や patch_all を aws_xray_sdk.core から import します。 参考:  AWS X-Ray – 開発者ガイド – AWS X-Ray SDK for Python AWS X-Ray SDK for Python - AWS X-Ray X-Ray SDK for Python を使用して Python アプリケーションを計測します。 docs.aws.amazon.com aws-xray-sdk-python /README.md aws-xray-sdk-python/README.md at master · aws/aws-xray-sdk-python AWS X-Ray SDK for the Python programming language. Contribute to aws/aws-xray-sdk-python development by creating an acco... github.com サブセグメントの作成 Lambda関数の場合は、セグメントの定義を抜かして、いきなり subsegment から書けます。どうやら親となる segment は Lambda の Trace を ON にしたときからAWS側で作ってくれているようです。 下のように、ソースコードの計測したい箇所の前後を xray_recorder.begin_subsegment と xray_recorder.end_subsegment サブセグメントとして定義することで、そのサブセグメント内にかかる時間を測定します。 ちなみに Lambda 関数内でセグメントの開始を定義( xray_recorder.begin_segment() )すると WARNING メッセージが出ますが、WARNINGなので処理は継続します。 Stack overflow – AWS Xray: Cannot create segments inside Lambda function and segment not found AWS Xray: Cannot create segments inside Lambda function and segment not found A really strange behaviour I was experiencing, I am following online documentation and while creating a segment to work ... stackoverflow.com 測定結果確認 Management Console で CloudWatch > 左のメニューの X-Ray トレース > トランザクション検索  から、結果を検索します。 Filter spans by: の下の空欄を選択すると候補がズラッと表示されるので、 attributes.aws.lambda.name 　を選んで = を選択、右側の空白に自分のLambda関数名を入力してクエリ実行ボタンを押します。スパンの下に traceId の一覧が出るのでそこをクリックします。 （正直ここにたどり着くまで迷いました） 2024/12/18 時点でこのBlogを作成している最中に Management Console のレイアウトが変わっていました… X-Ray トレースの下から、 Application Signals の下に移ったようです。 （レイアウトが変更されてまた迷いました…） ここから、サービスマップのイケてる図や 本命のトレース詳細が出ます。こんなわかりやすくてかっこいい図を出してくれるんですよ！ これを見てみると、先程ソースコードで囲ったサブセグメントに 284ms かかったことがわかります。 これで、これらの分析を利用してパフォーマンスのボトルネックになっている箇所を特定できるようになりました。 X-Ray なしでボトルネックを分析しようとすると、ひたすら CloudWatch などのログから解析という大変な状況から比べると、とても楽に分析できるようなったと感じます。 おわりに いかがでしたでしょうか。X-Ray をよくわからないからとか、面倒そうだとかの理由で触らないのはもったいなく感じてきたのではないでしょうか。あなたも是非、今日から X-Ray でパフォーマンス分析を！

本記事は 新人ブログマラソン2024 の記事です 。 皆さんこんにちは！入社して間もない新米エンジニアの佐々木です。 前回は、Snowflake CortexAIを使ってドキュメント検索アシスタントを構築するチュートリアルに挑戦し、その様子を記事にまとめさせていただきました。多くの方々に読んでいただき、大変嬉しく思っています。 まだ読めていないという方は、以下の記事をまずは読んでいただけると幸いです！！ 新米エンジニアが挑む！Snowflake CortexAIでドキュメント検索アシスタントを構築してみる – TechHarmony さて今回は、前回の記事の続編かつ応用編という立ち位置で、Snowflakeの公式チュートリアルに再度挑戦してみました！ 前回は基本的なドキュメント検索アシスタントを構築しましたが、 今回はより高度なチャットボットバージョンのドキュメント検索アシスタントの構築 に踏み込んでみたいと思います。 それでは早速行きましょう！！ 前回の振り返り 前回は、以下の公式チュートリアルをハンズオン形式で実践し、 Snowflake Cortex AIのベクトル埋め込み機能を利用して、ドキュメント検索アシスタントを構築 しました！ Build A Document Search Assistant using Vector Embeddings in Cortex AI 具体的には以下の大きく3つの手順で構築を進めました。 データ準備と前処理:  検索対象となるドキュメントデータの準備、データベース、スキーマ、ウェアハウスの作成、ドキュメント分割関数の作成を行います。 ベクターストアの構築:  CortexAIを用いて各ドキュメントを数値ベクトルとして表現し、ベクターストアの作成を行います。 チャットUIおよびロジック構築:  前工程で作成したベクターストアを利用して、誰でも簡単に文書検索ができるように、SnowflakeのStreamlitを使用して簡単なフロントエンドの作成を行います。 これらの手順を進めることで、最終的に以下のようなアプリを構築することができました！ これは、 SnowflakeのCortexAIを使ってドキュメントの内容に基づいてユーザーの質問に答えてくれるシンプルなアプリ となっています。 特に重要になるのが、左側にある「Use your own documents as context?」というチェックボックスです。これは回答の生成に事前に取り込んだドキュメントを使用するか否か、つまりRAGを使用するか否かを選択するためにあります。 例えば、チェックボックスを選択しないで質問を投げかけると、LLM（Large Language Model：大規模言語モデル）による一般的な回答のみが得られ、逆に選択して質問を投げかけると、事前に取り込んだPDFのコンテキストを使用して回答を作成するため、ドキュメントに関連したより詳細な回答を得られることが分かりました。 大雑把な説明とはなってしまいましたが、詳細が気になる方は前回の記事をぜひご覧ください！！ 今回実施するチュートリアルの概要 前回実施したチュートリアルでは前述したとおり、ユーザーの質問に対してLLMを用いて回答するシンプルなアプリを構築しました。 しかし、これはあくまで一問一答形式となっており、前の質問を記憶して会話できるような状況ではありません。これはLLMがステートレスであり、過去のやり取りやコンテキストを記憶しておらず、各リクエストを独立したイベントとして処理するためです。 そこで、 ユーザーとの会話内容を記憶して、チャットボットのように会話できるドキュメント検索アシスタントを構築していきたいと思います！ 実際に挑戦してみた！！ 前回と同様に、SnowflakeのStreamlitを使用して会話可能なチャットボットUIを作成していきます。 Streamlit構築 まず、Streamlitでアプリを作成します。今回は「CC_CORTES_CHATBOT_APP」というアプリ名にしました。 ここで選択しているデータベースやスキーマは前回作成したものとなります。 次に、作成したStreamlitアプリのコードを以下のように変更します。 import streamlit as st # Import python packages from snowflake . snowpark . context import get_active_session session = get_active_session () # Get the current credentials import pandas as pd pd . set_option ( "max_colwidth" , None ) ### Default Values #model_name = 'mistral-7b' #Default but we allow user to select one num_chunks = 3 # Num-chunks provided as context. Play with this to check how it affects your accuracy slide_window = 7 # how many last conversations to remember. This is the slide window. #debug = 1 #Set this to 1 if you want to see what is the text created as summary and sent to get chunks #use_chat_history = 0 #Use the chat history by default ### Functions def main (): st . title ( f ":speech_balloon: Chat Document Assistant with Snowflake Cortex" ) st . write ( "This is the list of documents you already have and that will be used to answer your questions:" ) docs_available = session . sql ( "ls @docs" ). collect () list_docs = [] for doc in docs_available : list_docs . append ( doc [ "name" ]) st . dataframe ( list_docs ) config_options () init_messages () # Display chat messages from history on app rerun for message in st . session_state . messages : with st . chat_message ( message [ "role" ]): st . markdown ( message [ "content" ]) # Accept user input if question := st . chat_input ( "What do you want to know about your products?" ): # Add user message to chat history st . session_state . messages . append ({ "role" : "user" , "content" : question }) # Display user message in chat message container with st . chat_message ( "user" ): st . markdown ( question ) # Display assistant response in chat message container with st . chat_message ( "assistant" ): message_placeholder = st . empty () question = question . replace ( "'" , "" ) with st . spinner ( f "{st.session_state.model_name} thinking..." ): response = complete ( question ) res_text = response [ 0 ]. RESPONSE res_text = res_text . replace ( "'" , "" ) message_placeholder . markdown ( res_text ) st . session_state . messages . append ({ "role" : "assistant" , "content" : res_text }) def config_options (): st . sidebar . selectbox ( 'Select your model:' ,( 'mixtral-8x7b' , 'snowflake-arctic' , 'mistral-large' , 'llama3-8b' , 'llama3-70b' , 'reka-flash' , 'mistral-7b' , 'llama2-70b-chat' , 'gemma-7b' ), key = "model_name" ) # For educational purposes. Users can chech the difference when using memory or not st . sidebar . checkbox ( 'Do you want that I remember the chat history?' , key = "use_chat_history" , value = True ) st . sidebar . checkbox ( 'Debug: Click to see summary generated of previous conversation' , key = "debug" , value = True ) st . sidebar . button ( "Start Over" , key = "clear_conversation" ) st . sidebar . expander ( "Session State" ). write ( st . session_state ) def init_messages (): # Initialize chat history if st . session_state . clear_conversation or "messages" not in st . session_state : st . session_state . messages = [] def get_similar_chunks ( question ): cmd = """ with results as (SELECT RELATIVE_PATH, VECTOR_COSINE_SIMILARITY(docs_chunks_table.chunk_vec, SNOWFLAKE.CORTEX.EMBED_TEXT_768('e5-base-v2', ?)) as similarity, chunk from docs_chunks_table order by similarity desc limit ?) select chunk, relative_path from results """ df_chunks = session . sql ( cmd , params =[ question , num_chunks ]). to_pandas () df_chunks_lenght = len ( df_chunks ) - 1 similar_chunks = "" for i in range ( 0 , df_chunks_lenght ): similar_chunks += df_chunks . _get_value ( i , 'CHUNK' ) similar_chunks = similar_chunks . replace ( "'" , "" ) return similar_chunks def get_chat_history (): #Get the history from the st.session_stage.messages according to the slide window parameter chat_history = [] start_index = max ( 0 , len ( st . session_state . messages ) - slide_window ) for i in range ( start_index , len ( st . session_state . messages ) - 1 ): chat_history . append ( st . session_state . messages [ i ]) return chat_history def summarize_question_with_history ( chat_history , question ): # To get the right context, use the LLM to first summarize the previous conversation # This will be used to get embeddings and find similar chunks in the docs for context prompt = f """ Based on the chat history below and the question, generate a query that extend the question with the chat history provided. The query should be in natual language. Answer with only the query. Do not add any explanation. <chat_history> {chat_history} </chat_history> <question> {question} </question> """ cmd = """ select snowflake.cortex.complete(?, ?) as response """ df_response = session . sql ( cmd , params =[ st . session_state . model_name , prompt ]). collect () sumary = df_response [ 0 ]. RESPONSE if st . session_state . debug : st . sidebar . text ( "Summary to be used to find similar chunks in the docs:" ) st . sidebar . caption ( sumary ) sumary = sumary . replace ( "'" , "" ) return sumary def create_prompt ( myquestion ): if st . session_state . use_chat_history : chat_history = get_chat_history () if chat_history != []: #There is chat_history, so not first question question_summary = summarize_question_with_history ( chat_history , myquestion ) prompt_context = get_similar_chunks ( question_summary ) else : prompt_context = get_similar_chunks ( myquestion ) #First question when using history else : prompt_context = get_similar_chunks ( myquestion ) chat_history = "" prompt = f """ You are an expert chat assistance that extracs information from the CONTEXT provided between <context> and </context> tags. You offer a chat experience considering the information included in the CHAT HISTORY provided between <chat_history> and </chat_history> tags.. When ansering the question contained between <question> and </question> tags be concise and do not hallucinate. If you don´t have the information just say so. Do not mention the CONTEXT used in your answer. Do not mention the CHAT HISTORY used in your asnwer. <chat_history> {chat_history} </chat_history> <context> {prompt_context} </context> <question> {myquestion} </question> Answer: """ return prompt def complete ( myquestion ): prompt = create_prompt ( myquestion ) cmd = """ select snowflake.cortex.complete(?, ?) as response """ df_response = session . sql ( cmd , params =[ st . session_state . model_name , prompt ]). collect () return df_response if __name__ == "__main__" : main () 上記のコードを見ても分かりにくいですよね、、自分自身も理解に苦しみました（笑） そこで簡単ではありますが、内容をまとめてみました。 特に、 それぞれの関数がどのような包含関係でどの順に呼び出され、どのような処理を行っているのかについてまとめました！ ①main() ：メイン関数 　　　②config_options() ：サイドバーの設定を表示 　　　③init_messages() ：チャット履歴を初期化 　　　④complete(myqusestion) ：LLMを使って質問に回答 　　　　　　⑤create_prompt(myquestion) ：LLMへのプロンプトを作成 　　　　　　　　　⑥get_chat_history() ：過去のチャット履歴を取得 　　　　　　　　　 ⑦summarize_question_with_history(chat_history, question) ： チャット履歴とユーザーの質問を要約 　　　　　　　　　⑧get_similar_chunks(question) ：ユーザーの質問に関連するドキュメントチャンクを取得 上記でそれぞれの関数を階層構造で表現している理由は、関数同士の包含関係を示すためです。ここで⑦の処理は、⑥の処理で過去のチャット履歴が存在した場合のみ実行されます。そのため、 今回のように過去のチャット履歴を汲み取って会話できるチャットボットとして機能するためには、特に⑦の処理が重要だと言えます！   よりコードの詳細を知りたい方は以下の補足説明をぜひ読んでみてください！興味がなければ飛ばしてもらってOKです！！ 1行目～7行目： import streamlit as st # Import python packages from snowflake . snowpark . context import get_active_session session = get_active_session () # Get the current credentials import pandas as pd pd . set_option ( "max_colwidth" , None ) StreamlitやPandasといった必要なライブラリをインポートしています。 9行目～14行目： ### Default Values #model_name = 'mistral-7b' #Default but we allow user to select one num_chunks = 3 # Num-chunks provided as context. Play with this to check how it affects your accuracy slide_window = 7 # how many last conversations to remember. This is the slide window. #debug = 1 #Set this to 1 if you want to see what is the text created as summary and sent to get chunks #use_chat_history = 0 #Use the chat history by default 今回構築するチャットボットのデフォルトの設定値を定義しています。具体的に各変数がどのような意味を持っているのかを以下に示します。 model_name： 使用するLLMの名前を示しています。 デフォルト値としてMistral-7Bというモデルが設定されています。この値は、 config_options() 関数内の st.sidebar.selectbox によって、ユーザーが実行時に変更できるようになっています。 つまり、ユーザーはサイドバーから異なるLLMモデルを選択することができます。 num_chunks： ドキュメントから抽出する関連するテキストチャンクの数を示しています。 Snowflake Cortexは、ユーザーの質問に対する回答を生成する際に、関連するドキュメントの断片（チャンク）を利用します。この値が3の場合、最も関連性の高い3つのチャンクがLLMに提供されます。 この値を調整することで、コンテキストの量を制御し、回答の精度や効率に影響を与えることができます。 値を大きくすると、より多くのコンテキストが考慮されますが、処理時間が長くなる可能性があります。 逆に、値を小さくすると、処理速度は向上する可能性がありますが、回答の精度が低下する可能性があります。 slide_window： チャット履歴において考慮する過去の会話の数を示しています。指定した個数分の直近の会話が、次の質問に対する回答生成に利用されます。例えばこの値が7の場合、直近7回の会話の履歴がコンテキストとして考慮されます。この値を増やすと、より多くの過去の会話が考慮されるため、よりコンテキストに富んだ回答が期待できますが、メモリ消費量が増加する可能性があります。逆に値を小さくすると、メモリ消費量は少なくなる一方で、コンテキストが不足して回答の精度が低下する可能性があります。 debug： デバッグモードのオンオフを切り替えるための変数です。 値が1の場合（真）、 summarize_question_with_history() 関数が生成した、過去の会話履歴と現在の質問を要約したテキストがサイドバーに表示されます。これは、LLMに渡されるチャンクを確認し、モデルの動作をデバッグする際に役立ちます。 通常はコメントアウトされており、デフォルトではデバッグモードは無効になっています。 use_chat_history： チャット履歴を使用するかどうかを制御するための変数です。 値が0の場合（偽）、チャット履歴は考慮されません。 値が1の場合（真）、チャット履歴が考慮されます。これは、 config_options() 関数内の st.sidebar.checkbox によって、ユーザーが実行時に変更できるようになっています。 デフォルトではコメントアウトされ、 config_options 内で value=True に設定されているため、初期状態ではチャット履歴が使用されます。 18行目～56行目： def main (): Streamlitアプリを動作させるための主要な処理がまとめられているメイン関数です。 59行目～79行目： def config_options(): Streamlitのサイドバーを設定するための関数です。 具体的には、LLMモデルの選択、過去のチャット履歴の使用、デバッグモードの有効化、会話のリセットボタンなどを配置する処理を行っています。 82行目～86行目： def init_messages (): チャット履歴を初期化するための関数です。 具体的には、セッションがクリアされた場合、または messages がセッション状態に存在しない場合に、空のリストを st.session_state.messages に設定する処理を行っています。 89行目～113行目： def get_similar_chunks (question): 入力された質問に最も類似したチャンクをドキュメントから取得するための関数です。 具体的には、Snowflake Cortexの VECTOR_COSINE_SIMILARITY 関数を使って、質問ベクトルと各チャンクベクトルのコサイン類似度を計算し、類似度の高い上位 num_chunks 個分のチャンクを取得し、文字列として結合して返す処理を行っています。 116行目～125行目： def get_chat_history(): 過去のチャット履歴を取得するための関数です。 具体的には、st.session_state.messages、つまりStreamlitのセッションから最新のslide_window個分のチャット履歴を取得し、リストとして返す処理を行っています。 128行目～157行目： def summarize_question_with_history(chat_history, question): 過去のチャット履歴と現在の質問をLLMに渡し、それらを要約したクエリを生成するための関数です。 また、デバッグモードが有効な場合、生成された要約をサイドバーに表示することができます。 159行目～197行目： def create_prompt (myquestion): LLMに渡すプロンプトを作成するための関数です。ユーザーが指定することで、チャット履歴を組み合わせてプロンプトを作成することも可能です。 具体的には、チャット履歴を使用する場合は、前述の summarize_question_with_history 関数を呼び出してクエリを取得し、さらに前述の get_similar_chunks 関数を用いて関連するドキュメントのチャンクを取得します。そしてそれらの情報を含めてプロンプトを作成する処理を行っています。 200行目～208行目： def complete(myquestion): ユーザーの質問に対する回答を取得するための関数です。 具体的には、前述のcreate_prompt関数を呼び出して得られたプロンプトとLLMモデルをSnowflake CortexAIのsnowflake.cortex.complete関数に渡して呼び出すことで、ユーザーの質問に対する回答を生成する処理を行っています。   長々と話してきましたが、結局のところコードを実行することで無事以下のようなアプリが表示されました！ 検証 では実際に作成したアプリを実行して検証をしてみたいと思います！ 今回投げかける質問としては以下の3つがあります。 ①What is the name of the ski boots?（スキーブーツの名前は何ですか） ②Where have been tested?（どこでテストされましたか） ③What are they good for?（何に適していますか） なぜこのような質問を投げかけるかというと、②、③の質問は①のチャット履歴を記憶していないと具体的な回答ができないため、チャット履歴の記憶の有無を検証する上では最適だからです。 チャット履歴を記憶する場合 まずは、サイドバーの「Do you want that I remember the chat history?」がチェックされた状態、つまり チャット履歴を記憶した状態 で質問を投げかけてみたいと思います。 投げかけた結果、以下のような回答が返されました。 上記のチャット内容を日本語に訳すと以下の通りです。ここで、黒文字が質問、赤文字が回答となります。 ①スキーブーツの名前は何ですか？ 提供された情報によると、スキーブーツの名前はTDBootz Specialです。ただし、一般的にスキーブーツの名前はブランドやモデルによって様々であることに注意する価値があります。 ②どこでテストされましたか？ TDBootz スキーブーツは、スペイン北部にあるセルレルスキーリゾートで広範囲にテストされました。 ③何に適していますか？ TDBootz スキーブーツは、オフピステでの高性能を求めるアドベンチャースキーヤーに適しています。 上記を見てわかる通り、①の回答で得られたTDBootz Specialというスキーブーツの名前を、後続の質問②、③も引き継いで質問に回答していることが分かります。つまり、チャット履歴を記憶して会話できていると言えます！ チャット履歴を記憶しない場合 次に、サイドバーの「Do you want that I remember the chat history?」のチェックが外された状態、つまり チャット履歴を記憶しない状態 で質問を投げかけてみたいと思います。 投げかけた結果、以下のような回答が返されました。 上記のチャット内容を日本語に訳すと以下の通りです。ここで、黒文字が質問、赤文字が回答となります。 ①スキーブーツの名前は何ですか？ スキーブーツの名前はTDBootz Specialです。 ②どこでテストされましたか？ TDBootz スキーブーツは、スペイン北部のセルレルスキーリゾートで広範囲にテストされました。Ultimate Downhill Bike Rincon del Cieloバイクは、ダッシュ、ジュリアン、カルロスという専門のライダーによってテストされました。 ③何に適していますか？ Ultimate Downhill Bike Rincon del Cieloは、ダウンヒルマウンテンバイク用に設計されています。雪上スポーツと自転車に乗ることに長けたスキルを持つことで知られる、ダッシュ、ジュリアン、カルロスという専門のライダーによってテストされました。 上記を見てわかる通り、①ではTDBootz Specialというスキーブーツの名前を得られたにも関わらず、②、③ではUltimate Downhill Bike Rincon del Cieloというバイクに関する回答をしており、それぞれの質問に対する回答は独立しています。つまり、チャット履歴を記憶していないと言えます！ まとめ 本記事では、 Snowflake CortexAIを使って独自のドキュメントに対して質問できるチャットボットUIを構築する方法、特に以前の会話を記憶させる方法について解説 しました。ハンズオンを通して、当初構築が難しそうだと感じたチャットボットを比較的容易に実装できることを身に染みて実感しました！ 特に、セッション変数を利用した会話履歴の管理は、より自然で文脈を理解した回答を実現する上で非常に重要だと感じました。単純な一問一答ではなく、過去のやり取りを踏まえた上でユーザーの意図を汲み取れるため、より人間らしい応対が可能になると感じました。この手法は、カスタマーサポートや社内ナレッジベースへのアクセスなど、様々な場面での応用が期待できると思います！ 一方で、セッション管理やプロンプトエンジニアリングなど、更なる改善の余地も感じました。例えば、会話履歴の保存期間やトークン数の制限、より効果的なプロンプトの設計など、実運用においては考慮すべき点がいくつかあります。これらの課題に取り組むことで、より洗練された、実用的なチャットボットを構築できると思います。 引き続き、Snowflake CortexAIの最新情報に注目し、その進化を追い続けていきたいと思います！

本記事は TechHarmony Advent Calendar 2024 12/19付の記事です 。 皆さんこんにちは。UGです。 忙しくない日だからと資格試験を申し込んだ25日がクリスマスであることを上司に指摘されて思い出した悲しい人間です。 皆さんは良いクリスマスが過ごせそうでしょうか？ 自分はせめて合格がクリスマスプレゼントになるように頑張りたいと思います。。。 さて本題ですが、AWS Step Functionsを利用していてタイムアウトをちゃんと設定しないといけないなと思った出来事があり、タイムアウトの設定について調査・検証をしたのでその結果をまとめてみました。 背景 Choiceステートの分岐を利用したループ処理があるStep Functionsの検証をしていました。（以下はあくまでイメージ図です） そんな時、ある条件下で無限ループが発生してしまうことを確認しました。 無限ループを放置してしまうと、もちろんその分の料金が発生してしまいます。(無限ループによって物凄い課金が発生したという記事も…) [AWS Step Functions] ステートマシンが無限ループして148ドルも課金が発生した話 | DevelopersIO 雑なEventBridgeのイベントパターンを設定したことを後悔しています。 dev.classmethod.jp ですので、ちゃんとタイムアウトを設定して思わぬ無限ループが発生した場合にタイムアウトさせる、といった処理が必要となります。 そのため、Step Functionsのオプション設定として存在する 『TimeoutSeconds』 と 『TimeoutSecondsPath』 について調査・検証をしてみました。 Task workflow state - AWS Step Functions Learn how to use the Task workflow state to represent a single unit of work performed by a state machine in your Step Fu... docs.aws.amazon.com TimeoutSeconds まず先に調査・検証結果を述べますが、TimeoutSecondsは ステートマシン全体 アクションステート の2つに設定することができ、 『ステートマシン全体』に設定した場合は、『 ステートマシンが実行開始されてから終了するまでのタイムアウト値 』となり、 『アクションステート』に設定した場合は、『 アクションステートが実行開始されてから終了するまでのタイムアウト値 』となります。 また、 『ステートマシン全体』に設定してタイムアウトが発生した場合は、ステータスは『 タイムアウト 』となり、 『アクションステート』に設定してタイムアウトが発生した場合は、ステータスは『 失敗 』となります。 では、各設定についてご説明していきます。 『ステートマシン全体』に設定した場合 ステートマシン全体に設定するには、[ワークフロー]フォームパネル → [TimeoutSeconds – オプション] で設定ができます。 ステートが選択されている場合はステート以外のところをクリックすることで [ワークフロー]タブが出てきます。 オレンジの領域をクリックすると[ワークフロー]フォームパネルが表示される 5秒待機させるWaitステートと、5秒待機させたのちHelloと返すだけのLambdaを使用して実験してみます。 まずはTimeoutSecondsに1秒を設定して実行してみます。 Waitステートでタイムアウトが発生して停止されました。 ステータスとしては『タイムアウト』と表示されていました。 次にTimeoutSecondsに6秒を設定して実行してみます。 Lambdaステートでタイムアウトが発生してキャンセルされました。 こちらもステータスは『タイムアウト』と表示されていました。 ここでLambdaのログを確認してみると、「Hello」が記録されていたのでLambdaは最後まで実行されていることがわかります。 TimeoutSecondsはあくまでステートマシンのタイムアウトとなるため、ステートマシン外で動いているLambdaには影響がないようです。 しかし、ステートマシンはキャンセルされているため、Lambdaの実行結果の戻り値はステートマシンには返されません。 以下のサイトの調査も参考にさせていただきました！ Step Functions ステートマシンのタイムアウト設定して、タイムアウトで処理がキャンセルされたときの動作を確認してみた | DevelopersIO Step Functions の Wait stateでテストしていたらつまづいたので記録に残しました。 dev.classmethod.jp 『アクションステート』に設定した場合 アクションステートに設定するには、アクションステートを選択した場合に表示されるフォームパネル → [エラー処理]タブ → [TimeoutSeconds – オプション] → [TimeoutSecondsを入力]で設定ができます。 まずはTimeoutSecondsに1秒を設定して実行してみます。 Lambdaステートでタイムアウトが発生して失敗しました。 ステータスとしては『失敗』と表示されていました。 [ エラー処理 ]タブで設定していることから、タイムアウトというよりもエラーとして処理をするために、ステータスが『 失敗 』となるのだと思います。おそらく。 今回もLambdaのログを確認してみました。 結果、「Hello」が記録されていたのでLambdaは最後まで実行されていることがわかります。 こちらもLambdaの実行時間に干渉しないことは同じのようです。 次にTimeoutSecondsを6秒に、またLambdaの後に5秒待機するWaitステートを追加して、TimeoutSecondsがLambdaステートのタイムアウト値であることを確認します。 問題なく成功し、今回設定したTimeoutSecondsは 設定したアクションステートのタイムアウト時間 であることがわかりました。 TimeoutSecondsPath TimeoutSecondsPathは、入力データからタイムアウト時間を 動的 に取得することができます。利用例としては、Step Functionsでデータ処理を実施していて、データのサイズごとにタイムアウト時間を変更したいなどのシナリオで利用されるかと思います。 TimeoutSecondsPathは、アクションステートに設定することができるため、静的か動的かの違い以外は アクションステートに設定するTimeoutSecondsと同じ結果 になります。 つまり、TimeoutSecondsPathを設定してタイムアウトが発生した場合は、ステータスは『 失敗 』となります。 では、実際に設定して試してみます。 TimeoutSecondsPathは、アクションステートを選択した場合に表示されるフォームパネル → [エラー処理]タブ → [TimeoutSeconds – オプション] → [実行時に、状態入力からTimeoutSecondsを取得]で設定できます。 設定値としてJSONPathを設定する必要があるため、今回は [$.TimeoutSecondsPath] を設定し、実行時の入力データとして”TimeoutSecondsPath”:1を与え実行します。 Lambdaステートでタイムアウトが発生して失敗しました。 ステータスとしては『失敗』と表示されていました。 ログは割愛しますがLambdaの実行についてもTimeoutSecondsと同様の結果でした。 注意点 「TimeoutSeconds」と「TimeoutSecondsPath」を設定する際の注意点を以下にまとめますので利用の際は気を付けてください。 「TimeoutSeconds」と「TimeoutSecondsPath」共にタイムアウト値は 正の整数（0は含めない） であること 同じアクションステート に設定できるのは「TimeoutSeconds」か「TimeoutSecondsPath」どちらかのみ ※以下の図のように「TimeoutSeconds」と「TimeoutSecondsPath」を組み合わせることは可能      HTTPタスクのタイムアウトは、「TimeoutSeconds」や「TimeoutSecondsPath」の値がHTTPタスクのタイムアウトの値を 超えた場合でも最大60秒 （例：TimeoutSecondsを120秒で設定していたとしてもHTTPタスクは60秒でタイムアウトする） 　HTTPタスクのタイムアウトとは、HTTPリクエストを送信してレスポンスを受信するまでの時間 タイムアウトをEventBridgeで取得するには タイムアウトを設定したのならもちろんタイムアウトが発生した際に通知させたり、自動的にエラーハンドリングさせたりしたいと思うはずです。というか必ずすべきだと思います。 なので、EventBridgeでStep Functionsのエラー情報を取得する方法を簡単にご紹介します。 方法は簡単で、以下のようにEventBridgeのイベントパターンにおいて、[特定のステータス] を選択し、取得したいステータスを選択するだけです。 各ステータスは以下の通りです。 RUNNING・・・ステートマシンが現在実行中の場合 SUCCESSDED・・・ステートマシンが正常に完了した場合 FAILED・・・ステートマシンがエラーによって失敗した場合 TIMED_OUT・・・ステートマシンの実行が設定された時間を超えてしまったため、タイムアウトして終了した場合 ABORTED・・・ステートマシンの実行が中断された場合 何か問題が発生した時で考えると、『FAILED』、『TIMED_OUT』、『ABORTED』の3つを選択しておけば問題ないかと思います。 もし絞りたいといった場合は、本記事でお話した通りタイムアウトでもステータスが『失敗』となる場合があるため、ステータスの選択には十分に注意してください。 例えば、アクションステートに設定した「TimeoutSeconds」や「TimeoutSecondsPath」でのタイムアウトは『失敗』となるため、『FAILED』を設定する必要があります。『TIMED_OUT』ではございません。 Step Functionsのステートマシンを選択した画面の[アクション]からEventBridgeルールの作成画面へ遷移できます まとめ 調査を開始する前は、TimeoutSecondsが「ステートマシン全体の実行時間のタイムアウト」しかないと思っていたので、エラー処理のタブにTimeoutSecondsがあったときは？？？でした。かつ Timeout Secondsという名前でありながらステータスが「失敗」と表示されたときも？？？でした笑 同じように考えてしまう人がいらっしゃるのではないかと思いますので、本記事が皆様の助けになれば嬉しい限りです。 最後までお読みいただきありがとうございました！！

本記事は、 Japan AWS Ambassador Advent Calendar 2024 の 2024/12/20 付記事です。 こんにちは、広野です。 最近、社内でメールに DKIM 署名をする対応をしてまして、その機に Amazon SES (Simple Email Service) のメール送信ログアーキテクチャを見直しました。 DKIM 署名の記事 は後輩に任せましたので、私は Amazon SES のログ取得・通知について書きます。 アーキテクチャ Amazon SES はデフォルトでは送信ログ取得・通知機能を用意してくれていません。そのため、AWS サービスを組み合わせてデプロイする必要があります。 これ一択、とは言いませんが、安価でスケーラブルなログ取得アーキテクチャは以下がスタンダードなアーキテクチャになると考えております。AWS CloudFormation を活用してデプロイできるようにしました。一部、手環境によって構成が変わると思ったところを手動作業にするようにしています。 Amazon SES のログ取得は、設定セットを利用します。ログの出力先として Amazon Data Firehose を指定した設定セットを Amazon SES の ID で手動選択する仕様になっています。 Amazon SES のバウンス通知は、フィードバック通知を使用します。通知先として Amazon SNS を手動選択する仕様になっています。Amazon SNS からの通知方法は管理者が選択できるようにするため、設定はしていません。図ではメールでの通知を想定して書いております。 Amazon Data Firehose が受け取ったログは Amazon S3 バケットに保存されます。それらを Amazon Athena からクエリしやすいよう、External Table としてカタログ化しておきます。 AWS CloudFormation テンプレート とりあえず以下のテンプレートを流すと、赤枠のリソースがデプロイされます。手動作業については後述します。 AWSTemplateFormatVersion: 2010-09-09 Description: The CloudFormation template that creates a S3 Bucket, a Data Firehose delivery stream with dynamic partition support for collecting SES logs, a SNS topic and an Athena WG. Parameters: # ------------------------------------------------------------# # Input Parameters # ------------------------------------------------------------# LogRetentionInDays: Type: Number Description: The retention period (days) for SES logs. Enter an integer between 35 to 540. Default: 400 MaxValue: 540 MinValue: 35 TagValue: Type: String Description: Tag value for Cost key. Default: SES MaxLength: 30 MinLength: 1 Resources: # ------------------------------------------------------------# # S3 # ------------------------------------------------------------# S3BucketSesLogs: Type: AWS::S3::Bucket Properties: BucketName: !Sub ses-logs-${AWS::AccountId}-${AWS::Region} PublicAccessBlockConfiguration: BlockPublicAcls: true BlockPublicPolicy: true IgnorePublicAcls: true RestrictPublicBuckets: true OwnershipControls: Rules: - ObjectOwnership: BucketOwnerPreferred LifecycleConfiguration: Rules: - Id: AutoDelete Status: Enabled ExpirationInDays: !Ref LogRetentionInDays Tags: - Key: Cost Value: !Ref TagValue # ------------------------------------------------------------# # SES invoke Data Firehose Role (IAM) # ------------------------------------------------------------# SesFirehoseRole: Type: AWS::IAM::Role Properties: RoleName: !Sub SesFirehoseRole-ses-logs-${AWS::AccountId}-${AWS::Region} Description: This role allows SES to push logs to Data Firehose. AssumeRolePolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Principal: Service: - ses.amazonaws.com Action: - sts:AssumeRole Path: / Policies: - PolicyName: !Sub SesFirehosePolicy-ses-logs-${AWS::AccountId}-${AWS::Region} PolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Action: - firehose:PutRecord - firehose:PutRecordBatch Resource: !Sub "arn:aws:firehose:${AWS::Region}:${AWS::AccountId}:deliverystream/ses-logs-${AWS::AccountId}-${AWS::Region}" - Effect: Allow Action: - logs:PutLogEvents Resource: !GetAtt LogGroupFirehoseSesLogs.Arn # ------------------------------------------------------------# # Data Firehose Role (IAM) # ------------------------------------------------------------# FirehoseRoleSesLogs: Type: AWS::IAM::Role Properties: RoleName: !Sub FirehoseRole-ses-logs-${AWS::AccountId}-${AWS::Region} Description: This role allows Data Firehose to delivery logs in S3. AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: Service: - firehose.amazonaws.com Action: - sts:AssumeRole Path: / Policies: - PolicyName: !Sub FirehosePolicy-ses-logs-${AWS::AccountId}-${AWS::Region} PolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Action: - "s3:AbortMultipartUpload" - "s3:GetBucketLocation" - "s3:GetObject" - "s3:ListBucket" - "s3:ListBucketMultipartUploads" - "s3:PutObject" Resource: - !Sub "arn:aws:s3:::${S3BucketSesLogs}" - !Sub "arn:aws:s3:::${S3BucketSesLogs}/*" - Effect: Allow Action: - "logs:PutLogEvents" Resource: - !Sub "arn:aws:logs:${AWS::Region}:${AWS::AccountId}:log-group:/aws/firehose/*" DependsOn: - S3BucketSesLogs # ------------------------------------------------------------# # Data Firehose delivery stream # ------------------------------------------------------------# FirehoseStreamSesLogs: Type: AWS::KinesisFirehose::DeliveryStream Properties: DeliveryStreamName: !Sub ses-logs-${AWS::AccountId}-${AWS::Region} DeliveryStreamType: DirectPut ExtendedS3DestinationConfiguration: BucketARN: !Sub "arn:aws:s3:::${S3BucketSesLogs}" Prefix: "partitioned/!{partitionKeyFromQuery:EventType}/!{timestamp:yyyy/MM/dd}/" ErrorOutputPrefix: "errorLog/!{firehose:error-output-type}/dt=!{timestamp:YYYY}-!{timestamp:MM}-!{timestamp:dd}/" BufferingHints: IntervalInSeconds: 300 SizeInMBs: 128 CompressionFormat: GZIP RoleARN: !GetAtt FirehoseRoleSesLogs.Arn DynamicPartitioningConfiguration: Enabled: true RetryOptions: DurationInSeconds: 300 CloudWatchLoggingOptions: Enabled: true LogGroupName: !Ref LogGroupFirehoseSesLogs LogStreamName: S3Delivery ProcessingConfiguration: Enabled: true Processors: - Type: MetadataExtraction Parameters: - ParameterName: MetadataExtractionQuery ParameterValue: '{EventType: .eventType}' - ParameterName: JsonParsingEngine ParameterValue: JQ-1.6 Tags: - Key: Cost Value: !Ref TagValue DependsOn: - S3BucketSesLogs - LogGroupFirehoseSesLogs # ------------------------------------------------------------# # Data Firehose LogGroup (CloudWatch Logs) # ------------------------------------------------------------# LogGroupFirehoseSesLogs: Type: AWS::Logs::LogGroup Properties: LogGroupName: !Sub /aws/firehose/ses-logs-${AWS::AccountId}-${AWS::Region} RetentionInDays: !Ref LogRetentionInDays Tags: - Key: Cost Value: !Ref TagValue LogStreamFirehoseSesLogs: Type: AWS::Logs::LogStream Properties: LogGroupName: !Ref LogGroupFirehoseSesLogs LogStreamName: S3Delivery DependsOn: - LogGroupFirehoseSesLogs # ------------------------------------------------------------# # SES Configuration Set # ------------------------------------------------------------# ConfigurationSet: Type: AWS::SES::ConfigurationSet Properties: Name: !Sub ses-logs-${AWS::AccountId}-${AWS::Region} DeliveryOptions: TlsPolicy: REQUIRE ConfigurationSetEventDestination: Type: AWS::SES::ConfigurationSetEventDestination Properties: ConfigurationSetName: !Ref ConfigurationSet EventDestination: Name: !Ref FirehoseStreamSesLogs Enabled: True MatchingEventTypes: - send - delivery - reject - bounce - complaint - renderingFailure - deliveryDelay - subscription KinesisFirehoseDestination: DeliveryStreamARN: !GetAtt FirehoseStreamSesLogs.Arn IAMRoleARN: !GetAtt SesFirehoseRole.Arn DependsOn: - ConfigurationSet - FirehoseStreamSesLogs - SesFirehoseRole # ------------------------------------------------------------# # Athena WorkGroup # ------------------------------------------------------------# AthenaWorkgroup: Type: AWS::Athena::WorkGroup Properties: Description: !Sub Athena Workgroup for SES logs Name: !Sub ses-logs-${AWS::Region} RecursiveDeleteOption: true State: ENABLED Tags: - Key: Cost Value: !Ref TagValue WorkGroupConfiguration: EnforceWorkGroupConfiguration: false PublishCloudWatchMetricsEnabled: true RequesterPaysEnabled: false ResultConfiguration: OutputLocation: !Sub s3://${S3BucketSesLogs}/athenaAdhocQueries/ # ------------------------------------------------------------# # Glue Database # ------------------------------------------------------------# GlueDatabase: Type: AWS::Glue::Database Properties: CatalogId: !Ref AWS::AccountId DatabaseInput: Description: !Sub Glue database for SES logs Name: !Sub ses-logs-${AWS::Region} # ------------------------------------------------------------# # SNS Topic # ------------------------------------------------------------# SNSTopic: Type: AWS::SNS::Topic Properties: TracingConfig: PassThrough DisplayName: !Sub ses-logs-${AWS::Region} FifoTopic: false Tags: - Key: Cost Value: !Ref TagValue 手動作業 AWS CloudFormation テンプレートでデプロイした後、以下の作業をする必要があります。 Amazon SES の対象 ID への設定セット割当 Amazon SES の通知設定 Amazon SES の対象 ID への設定セット割当 AWS CloudFormation テンプレートにより、ses-logs- AWSアカウント番号-リージョン名 の名前で SES 設定セットが出来上がります。これを、ログを取りたい ID のデフォルト設定セットに割り当てます。これで Amazon SES から Amazon Data Firehose にログが送信されます。 Amazon SNS の通知設定 AWS CloudFormation テンプレートにより、おそらく ses-logs-から始まる名前の Amazon SNS トピックが作成されます。これを、ログを取りたい ID のフィードバック通知に設定します。これでバウンス、苦情があったときに Amazon SNS に通知されます。 ただし、この Amazon SNS トピックには通知先は設定されていませんので、メールアドレスなどでサブクスライブする作業をお忘れなく。 Amazon S3 ログの確認方法 Amazon S3 に送られたログは JSON 形式になっており、Amazon Data Firehose のコントロール下でバッファリングされたログデータが順次書き込まれていきます。ファイル名もランダムな名前になっており、直接ファイルを操作して検索するのは至難の業です。そのため、Amazon Athena で検索するのが最も効率的です。 検索を効率化するために、Amazon Athena External Table (Amazon S3 などのデータソースを検索しやすくするビューのようなもの) を AWS CloudFormation でデプロイしてあるので、そこに対して Amazon Athena から SQL でクエリします。 以下のように、Amazon Athena のクエリエディタでデータベース ses-logs-リージョン名、テーブル seslogs が作成されているのでそれに対してクエリを打ちます。   あまり出力結果を成型できていませんが、以下のサンプル SQL でとりあえずログは見られます。適宜、SQL は変えてみて欲しいです。 ある特定の日の配送ログ SELECT * FROM seslogs where event_type = 'Delivery' and day = '2024/07/08'; event_type を Bounce や Complaint に変更すれば、バウンスや苦情のログを検索できます。すみませんが出力は成型できていません。 ある特定の期間のバウンスログ(成型済) バウンスログについては若干成型したものがあります。 SELECT bounce.bounceType as bouncebounceType , bounce.bouncesubtype as bouncebouncesubtype , bounce.feedbackid as bouncefeedbackid , bounce.timestamp as bouncetimestamp , bounce.reportingMTA as bouncereportingmta , mail.messageId as messageid , mail.timestamp as timestamp , mail.source as source , mail.commonHeaders.subject as subject , mail.commonHeaders.to as to , element_at(mail.headers,2) as replyto , mail.tags.ses_source_ip as ses_source_ip , mail.tags.ses_outgoing_ip as ses_outgoing_ip FROM seslogs where event_type = 'Bounce' and day between '2024/11/01' and '2024/11/30'; 表形式で結果が見られます。   まとめ いかがでしたでしょうか。 以前は Amazon OpenSearch Service でログ保管していたので、かなり課金額が安くなりました。AWS CloudFormation テンプレート化したことで他のアカウント、リージョンでもすぐに使用できるようになり、便利になりました。 正直、バウンスは「存在しないメールアドレス」宛てに送られたメールがほとんどです。通知が来たら送信者を突き止めて、入力したメールアドレスが間違ってますよ、と伝える運用をしています。 本記事が皆様のお役に立てれば幸いです。

本記事は TechHarmony Advent Calendar 2024 12/19付の記事です 。 こんにちは。ヒエログリファー Masedatiです。 はじめに、私からお伝えしたいことがございます。 はじめに 申し訳ございませんでした。 前提知識 本ブログでは以下について語っています。 Amazon Bedrock AWSの生成AI サービス “Fine-tuning”, “Pre-training”, “RAG”等を使用して、回答精度向上が可能 Fine-tuning 既に学習済みの機械学習モデルを特定のタスクや目的に合わせてさらに調整し、性能を向上させるプロセス Amazon Bedrockでの料金体系 学習コスト＋学習済モデル使用料 等 ​ 経緯 今年8月に以下のブログを発表しました。 𓀥 Amazon BedrockのFine-tuningでヒエログリフを創作する 𓀥 Amazon Bedrockで画像のFine-tuningを実験しました。 blog.usize-tech.com 2024.08.19 内容としては、Amazon BedrockのFine-tuningを用いた生成画像のチューニング検証です。 Fine-tuningモデルを使用するためには、「カスタマイズ」と「プロビジョンドスループット」の購入が必要なため、 さらっと 公式ページ にて「料金の例」を確認しました。 カスタマイズ (微調整と継続的な事前トレーニング) の価格設定 アプリケーション開発者は、1000 組の画像とテキストを使用して Amazon Titan Image Generator モデルをカスタマイズします。トレーニング後、開発者はカスタムモデルでプロビジョニングされたスループットを 1 時間使用して、モデルのパフォーマンスを評価します。微調整されたモデルは 1 か月間保存されます。評価後、開発者はプロビジョニングされたスループット (1mo commit) を使用してカスタマイズされたモデルをホストします。 微調整にかかる月額費用は次のとおりです。微調整トレーニング (0.005 USD* 500* 64)。ここで、0.005 USD は表示される画像あたりの価格、500 USD はステップ数、64 はバッチサイズ + 1 か月あたりのカスタムモデルストレージ (1.95 USD) + 1 時間のカスタムモデル推論 (21 USD) = 160 USD + 1.95 USD + 21 = 182.95 USD プロビジョンドスループットの料金 アプリケーション開発者は、テキスト要約のユースケースとして、Titan Text Express の 2 つのモデルユニットを 1 か月契約で購入します。 発生する月間コストの合計: 2 モデルユニット x 18.40 USD/時間 x 24 時間 x 31 日間 = 27,379.20 USD アプリケーションデベロッパーは、Amazon Titan Image Generator の基本モデルのモデルユニットを 1 か月契約で 1 ユニット購入します。 発生した総費用 = 1 モデルユニット* 16.20ドル* 24時間* 31日間 = 12,052.80ドル 引用： 基盤モデルを使用した生成 AI アプリケーションの構築 – Amazon Bedrock の料金 – AWS ブログ記載のとおり、一旦検証は終了したので、カスタマイズの終了・プロビジョンドスループットの購入を即日終了しました。 事件 年末も近づいていたため、AWS Cost Explorerを使ってAWSのコストを確認しました。 なにこれ 検証自体は8月で終了していたので、9月以降の課金は発生しないはずです。 原因 再度AWS料金体系を確認したところ以下の記述がありました。 Amazon Bedrock を使用すると、データを使用して FM をカスタマイズし、特定のタスクやビジネスコンテキストに合わせてカスタマイズされた応答を提供できます。 ラベル付けされたデータを使用してモデルを微調整することも、ラベル付けされていないデータで継続的な事前トレーニングを行うこともできます。 テキスト生成モデルのカスタマイズでは、モデルが処理したトークンの数 (トレーニングデータコーパス内のトークン数 x エポック数) に基づいてモデルトレーニング費用が課金されます。 また、モデルのストレージはモデルごとに毎月課金されます。 エポックとは、微調整プロセス中にトレーニングデータセットを 1 回完全に通過することを指します。 カスタマイズされたモデルを使用した推論は、プロビジョニングされたスループットプランに基づいて課金され、プロビジョニングされたスループットを購入する必要があります。カスタマイズされたモデルでは、1 つのモデルユニットが契約期間なしで、推論に使用できます。この単一モデルユニットがカスタムモデルの推論に使用した時間数に対して課金されます。スループットを 1 つのモデルユニットを超えて増やしたい場合は、1 か月または 6 か月の契約期間を購入する必要があります。 引用： 基盤モデルを使用した生成 AI アプリケーションの構築 – Amazon Bedrock の料金 – AWS コストが継続的に発生していた理由は記載のとおり、「モデルのストレージ料金」が月額課金されていたことです。 つまり、Amazon Bedrock Fine-tuningは以下のコストが発生し、利用終了後はモデルの削除が必要となります。 学習コスト（カスタマイズ） 学習済モデル使用料（プロビジョンドスループット） モデルのストレージ料金 モデルの削除方法 原因としては上記のとおりですが、作成した私に責任があります。 Amazon Bedrockの ​ 料金体系を確認しなかった ​長期にわたってコストを確認していなかった 教訓 個人環境でしたら自己責任ですが、そうでない場合は、以下を順守しましょう。 AWS リソース使用前に ​ 料金体系はしっかり確認し、理解しよう AWS Pricing Calculator を使用して、コストの見積もりをするとより安心ですね。 定期的(週次・月次)にAWS Cost Explorerでコストを確認しよう 週次・月次で環境を確認し、（最低限）自身のリソース・コストを追跡しましょう。 組織全体でコスト削減を行いたい場合は、組織内で定期的にミーティングを設定し、中・短期的なコスト削減施策を検討しましょう。 AWS Well-Architected フレームワーク コスト最適化の柱でも、定期的なミーティングは推奨されています。 ​ Cost タグは必ずつけよう 今回Costタグを付与していたので犯人（私）がわかりましたが、つけていなければ事件解決まで時間がかかったでしょう。 未使用リソースは削除しよう ​ 私との約束です。 おわりに うわっ…私の検証コスト、高すぎ…？

本記事は TechHarmony Advent Calendar 2024 12/18付の記事です 。 本投稿は、「TechHarmony Advent Calendar 2024」に加えて、 「ServiceNow アドベントカレンダー2024」18日目参加記事のダブルエントリーとなります。   ServiceNow - Qiita Advent Calendar 2024 - Qiita Calendar page for Qiita Advent Calendar 2024 regarding ServiceNow. qiita.com   はじめに 2024年12月をもってServiceNow認定資格である メインライン資格（計20個 ※2024年12月時点）を全て取得しました 。 今回はメインライン資格の全冠に取り組んだきっかけ、学習スタイル、所感を記事にしていきます。   Webassessor上ではメインライン資格が表示されなくなり、残るは最上位のCTAのみとなります。   メインライン資格の全冠に取り組んだ目的・きっかけ 様々なところで目にする「The world works with ServiceNow」について、その真髄に少しでも近づいてみたいと思ったのがきっかけです。 Knowledge2024に初参加した際、Keynoteや各Expo、セッションの盛り上がり、各国参加者の熱気を肌に感じ、グローバルでとても勢いがある製品なのだと再認識しました。結果、自分自身もServiceNowのことをもっと良く知りたいと思うようになりました。 一方で、ServiceNowは非常に多様な機能を持っているため、まずはメインライン資格をゴールとした各製品のラーニングパスに従って学習を進めていくことにしました。 実務ですべての製品に触れることは難しいですが、Now Learningで用意されているトレーニングであれば、自身が参画するプロジェクトに関係なく、短期間で効率的に、かつ多領域の知識を身に付けることができる良い手段だと思いました。 おまけに、資格取得という目に見える成果もあるのでモチベーションが保ちやすいというメリットもあります。 これらの理由から、ServiceNowの全体像、各製品がどのように連携し動作するのか、その結果どのような価値が生み出されるのか等々の知識を身に付けるべく、メインライン資格全冠に取り組みました。 メインライン資格一覧と取得順 2024年12月時点でメインライン資格の位置づけにある資格は全部で20種類あります。 以下に資格の一覧を実際の受験順に記載しました。 同じ製品群（ITOM、ITAMなど）を連続で学習することで、製品間の繋がりが見えてくるのでより理解を深めることができました。 これらの中で一番印象に残っているのは、6番目に受験した「Certified Implementation Specialist – Human Resources」です。 ラスベガスで開催されたKnowledge2024の会場で受験した為、試験管、受験者が全て海外の方という普段とは全く異なる環境での受験でした。イベント会場全体のにぎやかな雰囲気と比較して、とても静かで受験者の緊張が伝わってくる少し独特な空間でした。 No. 試験名 受検日 1 Certified System Administrator 2022年 2 Certified Implementation Specialist – IT Service Management 2022年 3 Certified Implementation Specialist – Risk and Compliance 2023年 4 Certified Application Developer 2024年2月 5 Certified Implementation Specialist – Strategic Portfolio Management 2024年3月 6 Certified Implementation Specialist – Human Resources 2024年5月　@Knowledge2024, Las Vegas 7 Certified Implementation Specialist – Vulnerability Response 2024年6月 8 Certified Implementation Specialist – Security Incident Response 2024年6月 9 Certified Implementation Specialist – Third-Party Risk Management 2024年7月 10 Certified Implementation Specialist – Service Provider 2024年7月 11 Certified Implementation Specialist – Customer Service Management 2024年9月 12 Certified Implementation Specialist – Field Service Management 2024年9月 13 Certified Implementation Specialist – Hardware Asset Management 2024年9月 14 Certified Implementation Specialist – Software Asset Management 2024年10月 15 Certified Implementation Specialist – Application Portfolio Management 2024年10月 16 Certified Implementation Specialist – Discovery 2024年11月 17 Certified Implementation Specialist – Service Mapping 2024年11月 18 Certified Implementation Specialist – Event Management 2024年11月 19 Certified Implementation Specialist – Cloud Provisioning and Governance 2024年12月 20 Certified Implementation Specialist – Platform Analytics 2024年12月   個人的学習スタイル 以降の内容は、前述したような「短期間で効率的にServiceNowの全体像を学んでいきたい」という目的のもとで行った、個人的学習スタイルとなります。 「資格を取得する」「現場で即戦力となる実践的スキルを身に着ける」など、目的によって学習スタイルは異なると思いますので、参考までのご紹介となります。 ラーニングパス、試験概要（Blueprint ）を確認する 受検する資格が決定したら、ラーニングパスを確認して受講すべきトレーニングを確認します。 そして、試験概要（Blueprint ）にも目を通して試験の出題範囲を確認することで、学習漏れが発生しないようにします。 英語で学習する ご存じの通り、ServiceNowはアメリカに本社をおく企業です。 「 ServiceNowをより理解するためには現地の言語だ！ 」ということで、英語で学習しました。 脳内で日本語⇒英語という変換が発生すると余計な労力がかかるので、Now Learningアカウントの言語は英語に切り替え、オンデマンドトレーニング、資格ともに英語で取り組みました。 テキストを繰り返し読み込む 個人的には、以下のイメージでテキストを3周ほど読み込むと、資格受験に挑める理解度に達することができた感覚でした。 【1周目（トレーニング受講）】 製品の全体像を把握することを意識しました。 この段階では、詳細な部分まで覚えようとすることはせず、スピード重視で進めます。 【２周目】 実装方法や各機能などの詳細部分まで理解すること重視で読み進めます。 自分の口で説明できる程度の理解度となるように学習する為、2周目が一番時間がかかります。 【３周目】 最終確認のイメージで、自身の理解度を確認しながら読み進めます。 理解できている部分は時間をかけず、理解が足りていないと感じる部分は理解できるまで重点的に学習しました。 ハンズオン Now Learningのトレーニングでは、ラボインスタンスとハンズオンのシナリオが用意されています。 実際に操作することで、開発者としてどのように実装していくのか、エンドユーザーとしてどのようにServiceNowを利用するのかをかなり明確にイメージすることができます。 ServiceNowを今後の業務で利用する、もしくは現在進行形で利用しているという方の場合は、是非ハンズオンを実施することをお勧めしたいです。 各製品がターゲットとする業務課題、導入事例を調べる ServiceNowは幅広い業務領域にわたる機能があるため、自身の業務に馴染みのない製品も多くあります。 その結果、テキストを呼んでも実際の利用イメージがつかず、ただの暗記作業になってしまいます。 （あくまでも製品理解が目的だったので）各製品の導入が想定される業界、業務領域の抱える課題を調べたり、実際の製品導入事例を確認することで、その製品を導入することによるユーザーの価値が理解できるように意識していました。 自分を追い込む （飲み会や雑談のなかで）今年中にメインライン資格を全部取る予定です、と周囲の人に宣伝します。 さらに、学習の初期段階で受験予約することで、受験料を無駄にはできないというプレッシャーを自分にかけます。   所感 「メインライン資格を全て取得したころには、ServiceNowを完璧に理解できているだろう」とどこかで思っていましたが考えが甘かったです。 冒頭に述べたように「The world works with ServiceNow」の真髄に近づくために始めたこの取り組みですが、全て取得した直後の感情としては、やっとスタートラインに片足を乗せた（言い過ぎかもしれないので、謙虚に片足の小指を乗せた）という気持ちです。 取り組みを始める前よりも、むしろ学びたいと思うことが増えました。それだけ、様々な機能をもち、様々な可能性を持っていると感じさせられました。 以下、一部ですが個人的ネクストアクション、学びたい事を記載します。 CMDBとCSDMの理解を深める 色々な製品のトレーニングで登場し、毎回大活躍している。もっとよく知りたい。 現場経験を積む & SNUG（ServiceNowユーザー会）への積極的な参加 トレーニングでは学べない、現場での経験から得られるノウハウも非常に貴重だと思いました。 また、2024年度は数回SNUGに参加しましたが、様々な業界の方の現場での体験談を聞くことができ、良い学びの場になりました。来年はより積極的に参加したいです。 Now Assistの機能も学ぶ 新バージョンがリリースされるたびに、各製品に対してNow Assist（生成AI）機能が追加されています。 Now Learningに用意されているNow Assistのトレーニングを受講してキャッチアップしていきたいです。 エキスパートプログラム（にいつかチャレンジ） 単なるServiceNowの各機能を理解するだけでなく、ガバナンス、セキュリティ、パフォーマンス、インテグレーションなど様々な観点において最適なアーキテクチャを設計しインプリできるようになりたいと思いました。 現場での経験をもっと積んだらCTAなどにもチャレンジしていきたいです。 また、以下は資格を20個取得して良かったことです。 全体像が見えてきたことにより、もっと深堀していきたいとさらに 学習意欲が増した （上記の通り） 各製品の仕組み、 各製品が どのように連携し動作するのかを明確にイメージできるようになった 未経験の製品だったとしても、 自身を持ってプロジェクトに取り込むことができる （プロジェクト参画に向けた良い事前準備となる） 最後に せっかく取得した資格を失効しないよう、年明けに控えているデルタ試験頑張ります（20個弱？）

本記事は TechHarmony Advent Calendar 2024 12/17付の記事です 。 どうもSCSK齋藤です。 今回は Amazon API Gateway と AWS Lambda を結びつけた際の、Lambdaプロキシ統合の利用有無によって変わる入出力の違いを書いていきたいと思います。 なお、本ブログで解説するAPI Gatewayは、「input」というパスパラメータでAPIに情報を連携し、Lambda側でステータスコードと一緒にパスパラメータの値をそのまま返却するものを例とします。 プロキシ統合ありの場合 まず、以下にプロキシ統合の場合のLambdaのソースコードを記します。 import json def lambda_handler(event, context): 　　print(event) 　　return { 　　　'statusCode': 200, 　　　'body': json.dumps(event['pathParameters']['input']) 　　} 次にプロキシ統合の場合で、上記Lambdaが動いた場合の、APIの入出力結果を見てみたいと思います。 まずは、パスパラメータ（input）に渡す入力値です。 出力結果は下記の通りです。 入出力についてそれぞれポイントを記載します。 入力：eventの中身の構造に注意する！ 重要なのは、「json.dumps(event[‘pathParameters’][‘input’])」の部分です。 Lambdaの入力値であるeventから、その配下の辞書形式でpathParametersという辞書のキーを取得しております。さらにその配下に今回のパスパラメータである「input」の情報を取得しております。 Lambdaプロキシ統合の場合、eventに渡されるデータ形式は決まっているため、その形式から必要なデータを取得してLambda関数で処理する必要があります。 AWSのドキュメントにて、データ形式は公開されておりますので、下記を参照してみると良いと思います。 API Gateway での Lambda プロキシ統合 - Amazon API Gateway API Gateway で Lambda プロキシ統合リクエストと統合レスポンスを設定する方法を学びます。 docs.aws.amazon.com 下記は先ほどのAPIを実行した際に、Lambdaに渡されたeventをそのまま出力したログです。（一部情報はマスクしております。） 形式的にも、先ほどのAWSのドキュメントに記載のものと同様だとわかります。 出力：statusCodeとbodyはマスト！構造的な出力が必要！ 先ほどのLambdaの返却値には、statusCodeとbodyを含めていました。 この２つはLambdaプロキシ統合を使った際には必ず必要な情報です。 Lambdaプロキシ統合を使った際の返却値は、構造化された状態にする必要があります。 詳しくは下記のドキュメントをご参照ください。 API Gateway での Lambda プロキシ統合 - Amazon API Gateway API Gateway で Lambda プロキシ統合リクエストと統合レスポンスを設定する方法を学びます。 docs.aws.amazon.com 試しに、必要な構造化がされていない返却値を設定したらどうなるでしょうか？ 下記Lambdaで試してみたいと思います。 import json def lambda_handler(event, context): 　　print(event) 　　return json.dumps(event['pathParameters']['input'] 入力値は先ほどと同じでtestとしてみましたが、下記のエラーがAPIで出ました。 なお、Lambdaのログを見ても、エラーは出ておりません。 これはLambdaが正しく処理しているにも関わらず、構造化された返却値になっていない影響でAPIGateway側で発生したエラーとなります。 Lambdaプロキシ統合を使う際は、返却値は必ず構造化されたものを返却するようにしましょう！   プロキシ統合なしの場合 入力：マッピングテンプレートを定義する！ プロキシ統合なしの場合、何もせずにいるとAPIGateway→Lambdaに情報は適切に渡されません。 必ずマッピングテンプレートを定義する必要があります。 マッピングテンプレートは、APIの統合リクエストを編集する画面で設定できます。   どのような形式でLambdaに渡すかのテンプレートを定義することができます。今回は、標準で用意してある「メソッドリクエストのパススルー」を選択したいと思います。これは、APIに関するリクエスト情報がほぼそのままに渡されるようなテンプレートです。 テンプレート本文は下記のようなイメージです。この状態で保存します。 なお、マッピングテンプレートに用いることができる情報などは下記ドキュメントに記載されています。 Amazon API Gateway API リクエストおよびレスポンスデータマッピングリファレンス - Amazon API Gateway Amazon API Gateway で API メソッドリクエストからメソッドレスポンスパラメータへのデータマッピングを設定する docs.aws.amazon.com それでは、実際にテストしてみたいと思います。 今回のLambdaのソースコードはこのような感じで、ステータスコードと入力値である「event」をそのまま返します。 なお、あえてステータスコードは定義しません。 import json def lambda_handler(event, context): 　　print(event) 　　return { 　　　'body': json.dumps(event) 　　} 前の例と同じく「test」と入力し、挙動を確認します。 下記の結果が出ました。（一部情報はマスクしております。） マッピングテンプレートで記載した通りの構文が入力値として渡されているのがわかります。 パスパラメータを取得したい場合は、赤枠で囲った部分である「params」→「path」→「input」から情報を取得するようなコードを書くと良いかと思います。 マッピングテンプレートを定義しなかったらどうなるか？ もしマッピングテンプレートを定義しなかったら、返却値は下記になります。（なお、入力値は同じくtestという文字列です。） bodyの部分は空辞書が返却されています。 今回のLambdaは、受け取った内容をそのまま返却するというソースコードなので、空辞書が渡されているのがわかります。 もしAPI構築中にこのような辞書に見舞われたら、マッピングテンプレートが定義できていないのだと考えてください。 出力：Lambdaの返却値そのままに返却される。 先ほどの入力の例でもすでにお見せしてますが、Lambdaで定義した返却値がそのままに返却されています。 return { 　　'body': json.dumps(event) } 上記のような返却値だったため、実際のAPIの結果もbodyで始まり、入力値の内容がが返却されました。 Lambdaプロキシ統合の時と違い、ステータスコードなどの情報がなくてもエラーにはならず、ステータス200として返却されます。 返却値が自由に設定できるという意味では柔軟性は高いということがわかります。 まとめ 今回は、API GatewayのLambdaプロキシ統合がどのような入出力の違いを生むかを解説しました。 個人的な所感としては、Lambdaプロキシ統合は入出力の型が決まっているので、それについて考えずにAPI構築に集中できるため、基本的に使った方が開発生産性は上がると考えております。 逆にLambdaプロキシ統合を使わないケースとしては、入出力を完全にコントロールしたい場合が該当するのではないでしょうか。ただ、マッピングテンプレートの例を見てもらうとわかる通り、for分やif文などがあるため、場合によってはテストケースを作成してロジックが正しいか確認する必要もあることは念頭においた方が良いと考えます。 このブログが、皆さんのAPI Gateway開発の何かに役立てば幸いです。

こんにちは、SCSK株式会社の谷川です。 このたび、SCSKはZabbix のパートナーミーティングでPartner of the Year 2024を受賞致しました！！ 「Zabbix Conference Japan 2024パートナーミーティング」で、Partner of the Year 2024を受賞 　　　 Partner of the Yearとは オープンソースの監視ソフトウェアベンダーであるZabbix Japan LLC (以下 Zabbix社)が開催したパートナーイベント「Zabbix Conference Japan 2024 パートナーミーティング」において、「Zabbix Japan Partner of the year 2024」を受賞しました。 この賞は、Zabbix社が日本国内のパートナー企業の中で、特に優れた実績を上げた企業に贈られるものです。Zabbix ビジネス拡大、認知度向上、新規案件の創出において顕著な成果を上げたことが評価され、このたび初めてのZabbix社パートナーアワードを受賞しました。   Zabbix Japan LLC エンドースメント この度は、「Zabbix Japan Partner of the Year 2024」※の受賞、誠におめでとうございます。 今回のアワード受賞の理由は、Zabbix プレミアムパートナーとして高い基準の中でご活躍いただく中、前年比150%以上という素晴らしい売上実績を達成された点にございます。さらに、Zabbix の各種イベントへのご参加やご協賛を通じて、Zabbix の日本国内における認知度向上に大きく寄与していただいただけでなく、Zabbix の海外ビジネス拡大に伴うアジア地域での活動にもご協力を賜り、多岐にわたる Zabbix ビジネスの拡大に尽力いただいたことを高く評価いたします。2025 年度においても同等以上のパフォーマンスを発揮していただけるよう、期待しております。 ※ 本アワードは、2024年度におけるZabbix関連サービスの売上やZabbixの認知度向上のためのプロモーション活動に貢献されたパートナー様を、Zabbix社独自の基準に基づき選出し、表彰するものです。   ＳＣＳＫの「Zabbix」における実績と強み １．豊富な販売実績 2017年よりZabbixの取り扱いを開始し、現在までに150社以上のお客様にご利用いただいています。 また、よくある構築内容をパッケージ化することで、手軽にZabbixシステムを導入可能です。 ２．高い技術力と豊富な導入実績 Zabbix の効果的な活用方法や最新バージョンに関する技術情報を独自に提供し、新規構築や他製品からの移行、現行Zabbix環境のバージョンアップも実施しています。金融業、製造業をはじめ、多種多様な業界、規模、構成に対応し、多数の実績があります。 ３．充実した保守サポート これまでの設計・構築、サポートの豊富なノウハウを駆使し、問題発生時の原因究明や、利用方法に関するお問い合わせに対応しています。独自のサポートレベルの設定と、ＳＣＳＫの総合力を生かしたサポートを行っています。 ４．教育サービス Zabbix 社の認定トレーナーを擁し、トレーニングの個別開催や、研修受講や資格試験のバウチャーチケットの販売を行っています。   関連リンク ＳＣＳＫ Plus サポート for Zabbix | ＳＣＳＫ株式会社 Zabbix Zabbix構築～導入後のシステム運用サービス・運用改善支援まで、お客様のニーズに合わせ最適なサービスをご提供します。 www.scsk.jp ＳＣＳＫ Plus サポート for Zabbix SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします www.scsk.jp ＳＣＳＫ 技術ブログ（TechHarmony） Zabbix 「Zabbix」の記事一覧です。 blog.usize-tech.com

Catoクラウドの2025年2月より適用される価格改定について解説しています。記事内で実際のCatoクラウド価格についての記載はございません。   はじめに 今回の価格改定については、昨年同様 Cato Networks社から2024年11月に Pricing Update としてパートナーへアナウンスが行われたものとなります。 昨年も同時期に価格改定があったので、今後は毎年実施される可能性があります。 昨年（2024年）の価格改定について Catoクラウド 2024年の価格改定（Pricing Update）について 2023年11月にアナウンスされたCatoクラウドの価格改定（Pricing Update）について現行サービス体系との差異を中心に解説します。※実際の価格については記載していません。 blog.usize-tech.com 2023.12.25 昨年は、リージョンからグループへの変更や、セキュリティオプション統廃合など大きな変更がありましたが、今回はそれほど大きな変更はありません。   価格改定の概要 それでは、今回の価格改定（Pricing Update）と新製品（New Products）について解説を行います。 IoT/OT Security Catoクラウドにおける新しいオプションとなる IoT/OT Security についての価格体系のアナウンスがありました。 このセキュリティ機能は、SASEベースの保護を、IoT/OT環境まで拡張し、デバイスの可視化とセキュリティ強化を実現するものです。 本オプションは、Site（およびPooled）のみに適用されます 。 Catoクラウドではこれまで、Siteとモバイルユーザは必ずセットでオプション契約が必要でしたが、IoT/OTセキュリティオプションについては、Site（およびPooled）にのみ適用されるオプションとなります。 本オプションは、すでに正式サービスリリースされており、12月時点で、すでにご利用することが可能となっております。 すでに、Catoクラウドをご利用のお客様は、[Resources]>[Device]（旧CMA：[Assets]>[Device Inventory]）での表示となります。 IoT/OTデバイス自動検出し、Internet FirewallやWAN Firewallのルールのデバイス条件として追加することが可能となります。   Advanced Threate Prevention（ATP） これまでの脅威防御（ Threate Prevention ）とは別に、高度な脅威防御（ Advanced Threate Prevention ）が追加されました。 Threate Prevention（TP） ※現行オプション ・パターンファイルマッチングのアンチマルウェア（ Anti-Malware ） ・機械学習エンジンを用いた振る舞い検知を含む次世代型アンチマルウェア（ Next Generation Anti-Malware ） ・侵入防御システム（ IPS ） ・不正なドメインへのアクセスをブロックする DNS Protection ・不審なアクセスをモニタリングする Suspicious Activity Monitoring（SAM） Advanced Threate Prevention（ATP） ※上記TPに加えて ・ Remote Browser Isolation（RBI） ・ サンドボックス（Sandbox） RBIについては、すでに販売されているセキュリティオプションとなりますが、2025年2月以降は、単体のセキュリティオプションとしてRBIを購入できなくなります。そのため、現在RBIをご契約いただいているお客様については、次回の契約更新時には、ATPを契約いただくか、RBIを解約するかを選択いただく必要があります。 サンドボックスについては、Cato Networks社のこれまでの方針は、昨今の俊敏な企業ニーズには合致しないとし、その代わりとして、ゼロデイ脅威や、脅威を含む未知のファイルを防ぐための、異なるアプローチを取っていましたが、多くのお客様のニーズに応じて、機能提供を開始したということになります。 サンドボックス（Sandboxing）機能について | よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Catoクラウドは、サンドボックス（Sandboxing）の機能は提供しておりません。Cato Networks社は、サンドボックスのテクノロジーは、昨今の俊敏な企業ニーズには合致しないと考え、その代わり... cato-scsk.dga.jp サンドボックスは、通常ファイル（プログラム）を保護・隔離された環境で、システムやデータに影響を与えずに実行し、マルウェア検出やプログラムの動作検証を行うものですが、Catoのサンドボックスは、俊敏性を阻害する事前予防処理を行うのではなく、並行で処理を行い、事後に動作検証報告を行うものとなります。   モバイルが、SDPからZTNAへ名称変更 Catoクラウドのモバイルユーザは、これまでSDP（Software Defined Perimeter：ソフトウェア定義境界）としていましたが、世間一般的には、ZTNA（Zero Trust Network Access）の方がメジャーなので、名称をZTNAへ変更することになりました。 Catoだけが、ZTNA ではなく SDP と言っていたので非常に良いと思います。   ZTNA 価格体系変更 SDPから名称変更されたZTNAの価格体系の変更となります。 ZTNA（旧:SDP）は、契約ユーザ数毎に価格が異なっていました。いわゆるボリュームディスカウントがされていましたが、課金方法が変更になりました。 以下のZTNA価格は説明のために仮に価格設定をしたもので、 実際のCatoクラウドの価格ではありません 。 現行価格体系 ZTNAユーザ数 価格（仮設定） 10～500ユーザ 1,000円/月 501ユーザ～1,000ユーザ 900円/月 1,001ユーザ～5,000ユーザ 800円/月 1,500ユーザの場合 ・500 x 1,000円 = 500,000円 ・500 x 900円 = 450,000円 ・500 x 800円 = 400,000円 ・500,000円+450,000円+400,000円 = 1,350,000円 新価格体系 ZTNAユーザ数 価格（仮設定） 10～500ユーザ 1,000円/月 501ユーザ～1,000ユーザ 950円/月 1,001ユーザ～5,000ユーザ 900円/月 1,500ユーザの場合 ・1,500 x 900円 = 1,350,000円 上記のように、価格の計算方法がシンプルになりました。 すでに、Catoクラウドをご利用のお客様については、契約ユーザ数により値下がりになる場合も、値上がりになる場合もあります。   プレミアムサポートパッケージ（Premium Support Packages） Catoクラウドのラインセンスを契約すると、標準で管理ポータル（CMA）上からチケットによる問い合わせが可能です。 ただし、現在サポートされているのは英語のみとなります。 この標準のサポートを Standard として位置づけ、新しく Gold 、 Platinum のサポートサービスが追加されました。 詳細は以下に比較表を掲載していますが、単なる問い合わせのサポートレベルの違いだけではなく、RMA（Return Merchandise Authorization：返品保証）、つまりSocketのハードウェア障害時の発送にも差がでていますので注意が必要です。 Catoクラウドのサポートは、現状英語のみがサポートとなりますので、SCSKでは日本語での問い合わせを”サポート窓口”サービスとして提供しております。 問い合わせは、問い合わせシステムでの受け付けとなっており、サポート窓口のご契約で、FAQサイトでの契約社アカウントも発行しておりますので、FAQサイトで一般公開していない詳細情報、当社作成の各種手順書等もご提供を行っております。 さらに、SCSKでは、Cato Networks社より「 Cato Distinguished Support Providers（CDSP） 」認定を受けておりますので、他のパートナーと異なり、サポートエンジニアはTier1ではなく、Tier2/3レベルと直接やり取りを実施しておりますので、プレミアムサポートパッケーの Gold、Platinumレベルのサポート（問い合わせ回答）品質を提供することで、回答時間の大幅な短縮を図ることができています（まったく違います） CatoクラウドのCDSP（Cato Distinguished Support Providers）認定を取得 Catoクラウドの戦略的パートナーとしてのCDSP（Cato Distinguished Support Providers）認定取得と、お客様におけるメリットについて解説しています。 blog.usize-tech.com 2024.03.04   カスタマーサクセスエンジニア（Customer Success Engineer、CSE） Cato Networks社にて、 テクニカルアカウントマネージャー（TAM） が提供されていましたが、今後TAMの役割に代わるマネージドサービス担当として、 カスタマーサクセスエンジニア（CSE） サービスが追加されました。 CSEサービスは、プレミアムサポートパッケージとは、別の追加サービスとして提供されます。 CSEは、プレミアムサポートパッケージ以外のあらゆる追加ニーズに対応できるよう設計されており、CSEは、Catoアーキテクチャの専門知識を有し、お客様の環境の積極的な分析を行い、より実践的な技術ガイダンスを含めたお客様の支援を行います。 CSEは、お客様がCatoのソリューションを十分に活用し、完全な導入を成功させるための戦略的な知見を提供します。   Data Lake Storage（DLS） すでに、11月11日のアップデート情報でアナウンスが実施されていますが、 1時間あたりの最大イベント数が200万イベントから250万イベントへと変更 となっています。 DLSの有料ストレージ期間については変更はなく、従来通り、3ヵ月、6ヵ月、12ヵ月の3種類となります。 Catoクラウドの標準のログ保管期間は3ヵ月です。 価格の変更もなく、全てのお客様に関してすでに適用済みとなっています。 Catoクラウドアップデート情報（2024年11月11日） | よくあるご質問 | Cato Cloud ケイトクラウド - SCSK □新機能と機能強化・TLSインスペクション用の新しいCatoデフォルト証明書　TLSインスペクションポリシーと脅威防止（Threat Prevention）エンジンで使用されているデフォルトのCato証明書は2... cato-scsk.dga.jp   価格適用のスケジュール 新価格は、2025年2月より適用されます。 契約期間中のお客様についても、2025年2月以降のライセンス追加時（拠点追加・拠点帯域増速・モバイルユーザ追加）は、すべて新価格が適用されることになります。 現行価格体系については、2025年1月末までのお見積り提示分（ご注文が2月末まで）が最終 となります。 なお、Catoクラウドのご利用開始月（課金開始月）については、最長で2025年5月まで延長することが可能ですので、例えば、1月末見積り提示、2月末までにご注文の場合、5月利用開始（課金開始）も可能となっています。 また、これから新規にCatoクラウドをご契約するお客様については、契約期間（最低契約期間は1年）を複数年（2年以上）契約へすることも可能です。   まとめ 今回は、2025年2月の価格改定の変更部分を中心に解説していますが、2025年の新サービス体系については、来年（2025年1月）に改めて記事にする予定です。 Catoクラウドは、全世界（中国本土を含む）90以上の都市に自前PoP（Point of Presence）を設置し、ネットワーク接続を拠点まで保証するエッジデバイス（Socket）をサービス提供し、クラウドネイティブでゼロから開発されたアーキテクチャで、圧倒的な使いやすさ・シンプルさが、他のソリューションとは異なる大きなメリットを持つソリューションです。 日本国内でも、SASE普及期となり、SASEの知名度が上がるにつれ、誇張されたマーケティングが横行しています。 「 海外のSASEは高額で中小・中堅企業には向かない 」→ × 「 SASEはそもそもマルチベンダーでしか実現できない 」 → × 「 統合型（Unified）SASEソリューション 」 → × 「 （SSEなのに）SASEソリューション 」 → × SASEを提唱したガートナーも、ベストオブブリードのマルチベンダーの組み合わせた SASE より、単一のベンダー（シングルベンダーSASE）を導入すべきであるとしています。 SASE のサブセットである SSE では、ゼロトラストは実現できません（SSE は、境界型防御の”境界”クラウドリフトです） シングルベンダーSASEは、世界初のSASEソリューションであるCatoクラウドを、ぜひ一度ご検討ください。Catoクラウドにご興味を持たれた方は、ぜひ お問い合わせ ください。