本記事は 新人ブログマラソン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クラウドにご興味を持たれた方は、ぜひ お問い合わせ ください。

本記事は  TechHarmony Advent Calendar 2024 12/16付の記事です 。 こんにちは。SCSKの上田です。 今回は、2024年6月にリリースされた Zabbix7.0 の 性能限界 を調査してみました。本内容は、2024年11月に開催された Zabbix Conference Japan 2024 において、弊社が発表した内容になります。 当日の発表を見ていただいた方も、見逃してしまった方も、是非ご覧ください。 Zabbix Conferenceとは？ Zabbix Conference とは、オープンソースの統合監視ソフトウェアであるZabbixのユーザー、開発者、パートナーが集まる公式イベントです。 最新のZabbixの機能や活用事例、ベストプラクティスなどを共有し、参加者同士のネットワーキングを促進することを目的としています。 Zabbix開発チームやパートナーによる講演、ユーザーによる事例発表、技術相談会など、Zabbixに関する様々な情報が集まるイベントとなっています。 毎年 SCSK もパートナーとして出展しており、今年は筆者の上田が登壇させていただきました。本記事では、登壇時に発表した内容について説明いたします。 タイトルは、「 ～限界シリーズ～　第 2 弾　   Zabbix7.0 のパフォーマンス限界調査編 」です。当日の資料は以下に掲載されておりますので、本記事とあわせてご確認ください。 Zabbix Conference Japan 2024 - Agenda 「Zabbix Conference Japan 2024」は、Zabbix社創設者兼CEOのAlexei Vladishevの基調講演や、Zabbixメンバーによる技術情報の提供、Zabbixユーザーの生の声の共有、関連ソリューションの紹... www.zabbix.com 背景 タイトルにある “限界シリーズ” とは、2年前に開催されたZabbix Conference Japan 2022で弊社が発表したシリーズです。 我々ITエンジニアは、常に「 お客様の要件に対して最適なアーキテクチャを設計する 」ということを生業にしています。 しかし、時には「 どこまで行けるのか ？」「 限界はどこなのか？ 」という 意味のないこと を追求したくなるのが、エンジニアの性というものです。 そんな考えから始まった、 “限界シリーズ” 。2年前は、当時最新バージョンで合ったZabbix6.0を使って、「 1台のZabbixサーバで何台まで遅延なく監視できるのか 」ということを検証しました。 ※当時の資料は以下に掲載されておりますので、是非ご覧ください。 Zabbix Conference Japan 2022 アジェンダ www.zabbix.com さて、今年の6月にZabbix7.0がリリースされ、以下のような新機能が追加されました。 Zabbix7.0の新機能 この機能は、ポーリング処理を行うPoller(ポーラー)プロセスが同期処理から非同期処理に変更になることで、監視処理の速度が向上しました。 ポーリング処理とは、Zabbixサーバが定期的に監視対象機器の状況を確認する（監視データを取得する）処理のことです。 要するに、監視データの収集速度が向上したということになります。 本機能の詳細については、以下の記事でも紹介しておりますので、そちらもご覧ください。 Zabbix 7.0 新機能検証 (ポーリングの高速化編) – TechHarmony この機能が追加されたことで、Zabbix6.0に比べて性能が急激に向上したと思われます。 そこで、 Zabbixの「新たなる限界」 を探るべく、 「Zabbix7.0の性能限界調査」 を行いました。 検証の概要 検証の概要を説明します。 検証の方針 Zabbix6.0と7.0の性能を検証し、比較 物理マシンはZabbix6.0アプライアンス（ZS-7600）を使用（7.0での検証時はバージョンアップを実施） 性能の限界は、「以下の条件のいずれかを満たすこと」と定義 Pollerプロセスのビジー率100% CPU使用率50%以上 メモリ使用率90%以上 キューが溜まり続けている CPU使用率を低く見積もっているのは、Web管理画面にリソースを使うため実質50%が限界だと考えたからです。 検証環境 検証環境は、以下のように用意しました。 複数台の仮想基盤サーバに対し、複数の仮想サーバを立てる 仮想サーバにzabbix-agentをインストール、それらに対して監視を行い性能検証 まず6.0で検証を行い、限界に達したら続いて7.0で検証 検証環境 なお、立てられる仮想サーバーの数には限りがあるため、今回は、 1つの仮想サーバを複数のホストとして登録する 形で検証を行っています。 設定パラメータ 以下のようにパラメータを設定しています。 対象 項目 デフォルト値 設定値 Zabbix Server6.0 StartPollers 3 1000 Timeout 3 20 Zabbix Server7.0 StartAgentPollers 1 30 Timeout 3 20 Zabbix Agent StartAgents 3 100 UserParameter ー sleep.3,sleep 3 && echo “finish“ Timeout 3 20 いくつか、設定の意図を解説します。 項目 意図 StartPollers Pollerプロセスの数を変更可能（6.0）。今回は最大値の1000で設定 StartAgentPollers Pollerプロセスの数を変更可能（7.0）。最大値は1000ですが、1プロセスのメモリ使用量が大きくチューニングして30に設定 StartAgents AgentがPollerプロセスを待ち受けるインスタンスの数を変更可能。今回の検証環境では1台の監視対象サーバを複数のホストとして登録して監視するため、Agent側でも効率的にポーラー処理に対応できるよう、最大値の100で設定 UserParameter 3秒待機してfinishの文字列を返すアイテムを定義。 今回の検証環境では、サーバーとエージェントが同じフロアの同じNW上にあり、遅延が全く発生しませんでした。実監視環境のNW遅延やサーバー負荷を考慮して、3秒のsleepを入れています。 なお、今回は1ホストにこのアイテムだけを設定して監視を行っています。 検証フロー 検証のフローは、以下の図のようになっています。 検証フロー 検証結果 それでは、ここから実際の検証結果を見ていきます。 Zabbix6.0の場合 6.0は、以下のような結果になりました。 限界ホスト数 21,000台 性能限界条件 Pollerプロセスのビジー率100% NVPS ※1秒当たりの監視データ数：New Value Per Second 334.7 ホスト数が 21,000台 の時に、 Pollerプロセスのビジー率が100% に達しました。 6.0の限界値 この時のNVPSは 334.7 でした。ZS-7600の監視推奨台数はNVPS 約333.3のため、ほぼ推奨値通りの値に落ち着きました。 この時、キューは最大30秒までたまり続けていて、とても監視できるような状態ではないことが分かります。 6.0性能限界時のキュー状況 Zabbix7.0の場合 続いて7.0です。6.0の限界に対して、いったいどれくらい限界が上がっているのでしょうか？ 6.0の限界値である21,000台で試してみると、Pollerプロセスのビジー率は約0.05%と、 6.0から約1/2000 まで落ちていました。 21,000台時点のPollerプロセスビジー率 ここから3,000台ずつホスト数を増やしていきましたが、ビジー率は全く上昇しません。 一気に飛んで・・・・117,000台を超えたところで、ようやくビジー率が1%を突破しました。この時点で1%なので、Pollerプロセスのビジー率では性能限界条件を満たすことは無さそう。。 ということで、この時のCPU使用率を調べてみると、約30%前後でした。どうやら、先にCPU使用率の限界が来そうです。 117,000台時点のCPU使用率 そして、さらにホスト数を増やしていき・・・ ホスト数 200,000台 の時点で、 CPU使用率が50%を超えて 限界を迎えました。 7.0の限界値 限界ホスト数 200,000台 性能限界条件 CPU使用率50%以上 NVPS ※1秒当たりの監視データ数：New Value Per Second 2,270 WEB管理コンソールを開いてみると、CPU使用率は90%前後になり、想定通りここが限界となりそうです。 この時のキューは6.0と同じく最大30秒までたまっており、とても監視できるような状態ではないことが分かります。 まとめ 最後に、検証全体のまとめです。 検証の結果 項目 Zabbix6.0 Zabbix7.0 限界時のホスト数 21,000台 200,000台 NVPS 334.7 2,270 性能限界条件 Pollerプロセスのビジー率100% CPU使用率50%以上 ホスト数上限は10倍、NVPSは7倍に向上 しています。 このことから、Zabbix7.0では、 Zabbixサーバ1台当たりの監視性能が飛躍的に向上 したことが分かります。 チューニングしたパラメーター 項目 デフォルト値 設定値 意図 StartAgentPollers 1 3０ 最大値(1000)にするとOSのメモリが不足したため CacheSize 128M 512M ホスト、アイテム数の増加により不足したため StartAgentPollers は、Pollerプロセスの数を変更するパラメーターです。7.0では並列処理ができるようになったことにより、1プロセスのメモリ使用量が大きくなっています。そのため、他のプロセスとの合計メモリ使用量が80%程度になるようにチューニングしました。 CacheSize は、コンフィグレーションキャッシュのサイズを変更するパラメータです。今回の検証ではホスト数63,000台を超えたあたりでConfiguration cacheが100%に近づいてしまいました。キャッシュが不足するとサービスの再起動が発生するため、余裕をもって、使用量が50%程度になるようにチューニングしました。 総括 Zabbix7.0では、Pollerプロセスの並列処理により、6.0から10倍近く性能が向上しました。 また、今回の性能限界はCPU使用率によるもののため、アプライアンスよりも高スペックのマシンを用意すれば、さらに多くの監視を実施することができると考えています。 但し、アプライアンスはデフォルトでカーネルパラメータ、DBなどをチューニングしており、 検証の中でもいくつかのパラメータを変更しているため、 性能を最大限に引き出すには 適切なチューニング が必要だと考えられます。 SCSK では、Zabbixに対して 適切なチューニング を行い、 最適な監視環境 を提供いたします。 Zabbix 7.0を活用した監視環境 をお求めの方は、ぜひ SCSK までお声掛けください！ 最後に 今回は、 Zabbix Conference Japan 2024 で発表した内容を記事にしてみました。 また、イベント当日は、現地・オンラインあわせて約200名の来場者の前で登壇させていただくという、大変貴重な経験ができました。ご来場いただいた方々、イベントを運営いただいたZabbix Japanのスタッフの方々には改めてお礼申し上げます。ありがとうございました！ 今後とも SCSK と Zabbix をよろしくお願いします。 弊社ではZabbix関連サービスを展開しています。以下ページもご参照ください。 ★SCSK Plus サポート for Zabbix★ SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします www.scsk.jp ★YouTubeに、SCSK Zabbixチャンネルを開設しました！★ SCSK Zabbixチャンネル 本チャンネルでは、SCSK株式会社でのZabbixに関するトレンド/事例紹介などを動画にまとめて取り上げております。最新のトピックについては、以下の弊社HPもしくはツイッターアカウントをぜひ参照ください。ツイッターアカウント： www.youtube.com ★X（旧Twitter）に、SCSK Zabbixアカウントを開設しました！★ https://x.com/SCSK_Zabbix

こんにちは、稲葉です。 Amazon CodeCatalystでTerraformを使用する方法を学習したのでご紹介いたします。 構築する環境 Amazon CodeCatalystで以下のようなパイプラインを作成します。 featureブランチからにpushされたとき、検証環境にリソースを作成するようにします。 mainブランチからにpushされたとき、本番環境にリソースを作成するようにします。 本記事では以下のようなVPCを作成します。 検証環境には検証VPCを作成し、本番環境には本番VPCを作成します。 また、検証VPCと本番VPCは同一AWSアカウントに作成しています。 Terraformコード Terraformコードは以下のようになります。 . ├── environments # 環境管理ディレクトリ │   ├── stg # 検証環境用ディレクトリ │   │   ├── stg.tfbackend # tfstateの管理場所を指定するファイル │   │   └── stg.tfvars # 変数に指定するパラメータを定義するファイル │   └── prd # 本番環境用ディレクトリ │       ├── prd.tfbackend # tfstateの管理場所を指定するファイル │       └── prd.tfvars # 変数に指定するパラメータを定義するファイル └─── main.tf # リソースを定義するファイル main.tf Terraformで作成するリソースを定義します。 terraform { backend s3 {} required_providers { aws = { source = "hashicorp/aws" version = "~> 5.57.0" } } } provider "aws"{ region = "ap-northeast-1" } variable name_prefix {} variable vpc {} variable public_subnet_1a {} variable private_subnet_1a {} variable public_subnet_1c {} variable private_subnet_1c {} # VPC resource aws_vpc vpc { cidr_block = lookup(var.vpc, "cidr_block") instance_tenancy = lookup(var.vpc, "instance_tenancy") enable_dns_support = lookup(var.vpc, "enable_dns_support") enable_dns_hostnames = lookup(var.vpc, "enable_dns_hostnames") tags = { Name = format("%s-%s",var.name_prefix, lookup(var.vpc, "name_tag")) } } # パブリックサブネット AZ-1a resource aws_subnet public_subnet_1a { vpc_id = aws_vpc.vpc.id cidr_block = lookup(var.public_subnet_1a, "cidr_block") availability_zone = lookup(var.public_subnet_1a, "availability_zone") tags = { Name = format("%s-%s",var.name_prefix, lookup(var.public_subnet_1a, "name_tag")) } } # プライベートサブネット AZ-1a resource aws_subnet private_subnet_1a { vpc_id = aws_vpc.vpc.id cidr_block = lookup(var.private_subnet_1a, "cidr_block") availability_zone = lookup(var.private_subnet_1a, "availability_zone") tags = { Name = format("%s-%s",var.name_prefix, lookup(var.private_subnet_1a, "name_tag")) } } # パブリックサブネット AZ-1c resource aws_subnet public_subnet_1c { vpc_id = aws_vpc.vpc.id cidr_block = lookup(var.public_subnet_1c, "cidr_block") availability_zone = lookup(var.public_subnet_1c, "availability_zone") tags = { Name = format("%s-%s",var.name_prefix, lookup(var.public_subnet_1c, "name_tag")) } } # プライベートサブネット AZ-1c resource aws_subnet _private_subnet_1c { vpc_id = aws_vpc.vpc.id cidr_block = lookup(var.private_subnet_1c, "cidr_block") availability_zone = lookup(var.private_subnet_1c, "availability_zone") tags = { Name = format("%s-%s",var.name_prefix,lookup(var.private_subnet_1c, "name_tag")) } } environments/stg/stg.tfbackend Terraformの状態を管理するファイル（tfstate）をどのように管理するかを定義します。 検証環境と本番環境のそれぞれで別のtfstateを作成し、このファイルでは検証環境のtfstateを担当します。 bucket = ＜tfstateを置くS3バケット名＞ key = ＜tfstateを置くS3バケットのキー＞ region = "ap-northeast-1" environments/stg/stg.tfvars 検証環境のパラメータを定義します。 name_prefix = "stg-codecatalyst-test" vpc = {   cidr_block              = "10.1.0.0/16"   instance_tenancy        = "default"   enable_dns_support      = true   enable_dns_hostnames    = true   name_tag                = "vpc" } public_subnet_1a = {   cidr_block              = "10.1.0.0/24"   availability_zone       = "ap-northeast-1a"   name_tag                = "public-subnet-1a" } private_subnet_1a = {   cidr_block              = "10.1.2.0/24"   availability_zone       = "ap-northeast-1a"   name_tag                = "privatec-subnet-1a" } public_subnet_1c = {   cidr_block              = "10.1.1.0/24"   availability_zone       = "ap-northeast-1c"   name_tag                = "public-subnet-1c" } private_subnet_1c = {   cidr_block              = "10.1.3.0/24"   availability_zone       = "ap-northeast-1c"   name_tag                = "private-subnet-1c" } environments/prd/prd.tfbackend Terraformの状態を管理するファイル（tfstate）をどのように管理するかを定義します。 検証環境と本番環境のそれぞれで別のtfstateを作成し、このファイルでは本番環境のtfstateを担当します。 bucket = ＜tfstateを置くS3バケット名＞ key = ＜tfstateを置くS3バケットのキー＞ region = "ap-northeast-1" environments/prd/prd.tfvars 本番環境のパラメータを定義します。 name_prefix = "prd-codecatalyst-test" vpc = {   cidr_block              = "10.0.0.0/16"   instance_tenancy        = "default"   enable_dns_support      = true   enable_dns_hostnames    = true   name_tag                = "vpc" } public_subnet_1a = {   cidr_block              = "10.0.0.0/24"   map_public_ip_on_launch = true   availability_zone       = "ap-northeast-1a"   name_tag                = "public-subnet-1a" } private_subnet_1a = {   cidr_block              = "10.0.2.0/24"   availability_zone       = "ap-northeast-1a"   name_tag                = "privatec-subnet-1a" } public_subnet_1c = {   cidr_block              = "10.0.1.0/24"   map_public_ip_on_launch = true   availability_zone       = "ap-northeast-1c"   name_tag                = "public-subnet-1c" } private_subnet_1c = {   cidr_block              = "10.0.3.0/24"   availability_zone       = "ap-northeast-1c"   name_tag                = "privatec-subnet-1c" } パイプラインの設定 Terraformの事前準備 事前にTerraformの状態を管理するファイル（tfstate）を管理するためのS3バケットが必要になります。 検証環境と本番環境用に2つS3バケットを作成します。 その後下記ファイルそれぞれで、作成したバケット名をbucketに、キーをkeyに指定します。 environments/stg/stg.tfbackend  environments/prd/prd.tfbackend Amazon CodeCatalystの事前準備 Amazon CodeCatalystの利用には下記のような事前準備が必要です。 AWS Builders IDの取得 Amazon CodeCatalyst Spaceの作成 Amazon CodeCatalyst用IAM Roleの作成 本記事では、事前準備は終了済みであることを前提としています。 参考記事 Amazon CodeCatalystを使ってblueprintでアプリを作るまで - Qiita CodeCatalyst挑戦の経緯仕事の案件とは全く関係ない趣味の範囲＆自主学習用にWebアプリを作っております。今までは作ったものをローカルで動作させて、DBもSQLiteで…みたいな感じで作… qiita.com Amazon CodeCatalyst で AWS Lambda の CI/CD 環境を構築する 2023年4月にGAとなった「CodeCatalyst」を触ってみたので、それについてお話ししようと思います。 blog.usize-tech.com 2024.05.24 パイプラインの作成 AWSコンソールのAmazon CodeCatalystから作成したSpaceを選択し、”Go to Amazon CodeCatalyst”ボタンを押すことで、CodeCatalystを使用できます。 プロジェクトの作成 まずAmazon CodeCatalystプロジェクトを作成します。 Start from scratchを選択して作成してください。 リポジトリの作成 その後リポジトリを作成します。 開発環境へアクセス、コードのリポジトリ登録 リポジトリにアクセスできる開発環境の設定を行います。 Code -> Dev Environments -> Create Dev Environment -> AWS Cloud9で開発環境を作ります。 AWS Cloud9に入れたら、リポジトリ名と同じフォルダにTerraformのコードを作成します。 その後リポジトリにPushします。 $ cd projects/＜リポジトリ名と同じフォルダ＞ $ git add main.tf $ git add environments/* $ git commit -m "first commit" $ git push デプロイ先の設定 次にデプロイ先の設定をします。 CI/CD -> Environments -> Create environment で設定を行います。 本番環境と検証環境のデプロイ先を設定しました。 IAM RoleはAWSコンソールのAmazon CodeCatalystスペースメニューで、 IAM roles available to CodeCatalystを探し、登録されているIAM Roleを選択してください。 Workflowの作成 Terraform用のWorkflowを2つ作成します。 CI/CD -> Workflows -> Create workflow で設定を行います。 featureブランチからにpushされたときのWorkflow 検証環境用のWorkflowを作成します。 Triggerをクリックし、下記のようにトリガーの設定を行います。   その後、Workflowページの左上のActionをクリックし、Buildを追加します。 下記のようにBuildの設定をします。 Inputsタブ Sources: WorkflowSource Configuration Compute type: EC2 Environment: stg   Shell commandsに以下のコードを貼り付けます。 下記コードでTerraformがインストールされて検証環境にVPCがデプロイされます。 - Run: wget https://releases.hashicorp.com/terraform/1.8.5/terraform_1.8.5_linux_amd64.zip - Run: yum install unzip -y - Run: unzip terraform_1.8.5_linux_amd64.zip - Run: mv terraform /usr/local/bin/ - Run: terraform -version - Run: terraform init -backend-config="environments/stg/stg.tfbackend" -reconfigure - Run: terraform plan -var-file="environments/stg/stg.tfvars" - Run: terraform apply -var-file="environments/stg/stg.tfvars" -auto-approve 貼り付け後、commitを押して保存します。 mainブランチからにpushされたときのWorkflow 本番環境にリソースを作成するようにします。 Triggerの設定は、mainブランチへのpush時を設定します。 その後のBuildの設定は、下記のように行います。 Inputsタブ Sources: WorkflowSource Configuration Compute type: EC2 Environment: prd Shell commandsには以下のコードを貼り付けます。 下記コードで本番環境にVPCがデプロイされます。 - Run: wget https://releases.hashicorp.com/terraform/1.8.5/terraform_1.8.5_linux_amd64.zip - Run: yum install unzip -y - Run: unzip terraform_1.8.5_linux_amd64.zip - Run: mv terraform /usr/local/bin/ - Run: terraform -version - Run: terraform init -backend-config="environments/prd/prd.tfbackend" -reconfigure - Run: terraform plan -var-file="environments/prd/prd.tfvars" - Run: terraform apply -var-file="environments/prd/prd.tfvars" -auto-approve 本来は承認フェーズを挟んでからデプロイする方法があるのですが、本記事では省きます。 貼り付け後、commitを押して保存します。 パイプラインを走らせる Code -> Dev Environments で開発環境にアクセスします。 開発環境と本番環境をそれぞれpushして、VPCがデプロイされるか確認します。 Readmeファイルなどを変更してpushすると、VPCがデプロイされるか確認します。 $ git add README.md $ git commit -m "更新: README.md" $ git push $ git branch feature/test $ git checkout feature/test $ git add README.md $ git commit -m "更新: README.md" $ git push --set-upstream origin feature/test 上記のコマンドを打つことで、Workflowが2つ走ると思います。 開発環境と本番環境の2つVPCが作成されていれば完了です。 最後に Amazon CodeCatalystでTerraformを使ってみましたが、Amazon CodeCatalystの情報が少なく難しかったです。 今回できなかったことなのですが、 Amazon CodeCatalystにはTerraform用のプリセットがあります。 使ってみたのですが、tfvarsファイルの情報を取得できずなかなかうまくいきませんでした。 次はこのプリセットを使えるようにしたいです。

本記事は TechHarmony Advent Calendar 2024 12/14付の記事です 。 こんにちは。SCSKの中山です。 今回はアドベントカレンダー企画ということで、ネタに困ってしまったので、ずっと放置してきたLDAP(AD)連携周りの検証をゆるーく検証し、まとめてみようかと思います。 実はCatoをご利用のお客様もほとんどがEntra IDを利用されていて、オンプレADを利用されているお客様は意外と少ないのですが、 定期的にオンプレADとCatoの連携について問い合わせが来ており、まだまだ利用されているお客様もいるかと思います。 そこで今回はADとのLDAP連携方法や問い合わせで来た注意点などを踏まえて記事を書いてみようかと思います。 まず最初に ADとのLDAP連携でできることを整理したいと思います。 普段ADといえば、社内のユーザ管理や認証を行っているイメージを持つ方が多いかと思います。 しかし、Catoとの連携だとEntra IDとは違い、あくまで”LDAP連携”のみのため、 ADによる認証・SSOはできません。 LDAP連携でできることはドメイン上のOUやグループ指定して、ユーザをまとめてプロビジョニングすることができます。 この時、グループとユーザをまとめてプロビジョニングするため、ユーザ管理のために追加グルーピングすることは不要で、Cato上でもドメイン上のグループ名でそのままユーザ制御することができます。そのため、AD上で部・課単位でグループを作成しているようであれば、Cato上でも部・課単位でネットワークのコントロールをすることができます。 LDAPでプロビジョニングしたユーザの認証については、手動で作成したモバイルユーザ同様になります。 ADよりユーザをプロビジョニングした後に各ユーザごとにCato側でパスワードを設定いただき、ユーザ＆パスワードを用いてCatoで認証を行います。 連携手順 Catoからも手順が出ておりますので、詳細はこちらをご覧ください。 https://support.catonetworks.com/hc/en-us/articles/13815828575133-Syncing-Users-with-LDAP 今回は公式手順でいう”Syncing with a local AD server(ローカルADとの連携)”の手順を紹介します。 ① ADサーバがあるサイトでHostsの登録を行う。   ② LDAPのドメイン情報を登録する。 Acceess > Directory Services >LDAP より新規でドメイン登録に必要な情報を入力します。 LDAP Authentication Detailsの項目にある”DN”はLDAP識別名と呼ばれるものでAD等のディレクトリサービスでオブジェクト表記する際に使用する表記になります。この表記を使ってユーザ、グループを入力します。 (ざっくりで言うとどこの誰(グループ)が分かるようにカンマ区切りで書きます。詳細が気になる方は調べてみてください。) Login DN：ログインするドメインのユーザ(※管理者権限が必要だと思うので、要検証) Base DN：Catoが参照する階層(グループ) 後続の手順でプロビジョニングするグループ・ユーザを選択することができるのですが、その際に関係する項目になります。 例えば、以下のような階層になっていて、赤枠のグループをプロビジョニングをしたい場合、以下のパターンで設定することができます。 1.Base DNで青枠のグループを選択し、④の手順で赤枠のグループを指定。 2.Base DNで赤枠のグループを指定。 2.の場合は、既に対象のグループが設定できているので、④での設定は不要になります。 1.の場合は、この後の④の手順を実施ください。   ③ ドメインコントローラの情報を登録する。 「Domain Controllers」のタブに移動して、①で登録したホストを登録します。   ④ ユーザグループを指定する ここではプロビジョニングするグループを指定します。この項目は選択しないことも可能ですが、選択しないと対象のグループの全ユーザがプロビジョニングされてしまうのでご注意ください。 上記を踏まえて先程の②の方法で、1.の青枠グループを選択している場合はここで赤枠グループを選択する必要があります。 2.の場合だと既に赤枠のグループが選択されているので、選択は不要です。 ここまででドメイン設定自体は完了です。 設定ができたら、「Test Connection」で接続を試してみましょう。   ⑤ 同期をしてユーザをプロビジョニングする 「Sync Now」で同期をして、「Submit」でユーザをプロビジョニングします。 プロビジョニングが成功して、少し時間を空けると指定したグループとユーザがCato側にもプロビジョニングされます。 この後は手動でSDPユーザを作った時と同じ手順ですが、ログインまで手順を書いておきます。   ライセンスが割り当てられたらClientをダウンロードし、ログインを行います。 ADからPWを持ってこれないので、Catoクライアントの初回ログイン時に初期設定の案内が出るので、 案内に従ってCato側にパスワード及びMFAを設定します。   登録後は設定したパスワード＆MFAを使用してログインできます。   設定するうえでの注意点 お客様からもLDAPに関する問い合わせが来ているのですが、似た問い合わせが多く来ており、同じような場面で躓かれているのかと思っております。 そこで弊社のFAQの内容と合わせて、その内容を紹介したいと思います。 LDAPでADからユーザ情報が連携されない LDAPからユーザー情報が連携されない | よくあるご質問 | Cato Cloud ケイトクラウド - SCSK LDAP連携は成功しており、グループの連携が可能にもかかわらず、ユーザー情報のみが同期されない場合、連携先(Active Directoryサーバなど)にて、ユーザー情報の以下のフィールドが空欄とな... cato-scsk.dga.jp FAQに記載しておりますが、LDAP連携自体は成功しているものの、ユーザが作成・同期されない状況の場合、AD側のユーザ情報をご確認ください。 以下項目が必須となっており、空欄がある場合にはユーザが同期されません。 ADの場合だとフルネームだけで登録されている場合やメールアドレスはADに登録していない場合があると思いますので、ユーザが作成・同期されないという事象が起きた場合にはご確認ください。 姓(LastName) 名(FirstName) メールアドレス LDAP接続ができない LDAP接続に失敗する | よくあるご質問 | Cato Cloud ケイトクラウド - SCSK LDAPサーバに疎通はするものの、LDAP接続テストを行うと以下のエラーが発生する。Failed to import LDAP data. Error Code:81 (server down)上記の場合、LDAPサーバと下記のCatoアド... cato-scsk.dga.jp こちらは本記事やナレッジの手順通りに実施してもLDAP接続ができない方向けになります。 LDAP接続ができない場合には、LDAPサーバからFAQに記載の以下IPアドレスに通信をする際にCatoを経由しているかをご確認ください。 よくあるパターンとしては、LDAPサーバへPingは通っていたけど実はCato経由ではなく既存のCatoを経由しない出口から疎通していたというパターンです。この場合はtracerouteを打鍵してみたりやNW設定を見直していただいて、Cato経由で通信するように修正する必要があります。 ちなみに本エラーとは違うのですが、本検証をしているときに私もLDAP接続ができない状態になったのですが、同様にCato(vSocket)への経路がらみを見直し・修正し解決しました。(エラーコードはキャプチャ取りそびれました。。) なので、LDAP接続ができないという方はとりあえず経路が正しいかをご確認いただくのが良いかと思います。   まとめ 今回はADを立ててLDAP連携によるユーザプロビジョニングをしてみました。 私はあまりADを触ったことがなく、”DN”など見慣れない言葉があったり、LDAP接続時のNW設定でちょっと詰まったりしましたが、Catoの設定自体は以外とスムーズにできました。 また、私も詰まったADからCatoへの疎通のところはFAQにも上げており、他の方も躓きがちなポイントかと思いますが、ドメコン周りのNWを変更するのは注意が必要ですので、変更は構成を踏まえてご検討いただければと思います。

SCSK 永見です。 私が管理しているAWS環境では、aws health aware ( https://github.com/aws-samples/aws-health-aware )で、health eventをメール送信しています。 その中で使われているAmazon Simple Email Service ( 以下「SES」) に、fromアドレスとして会社ドメイン(@scsk.jp)の自分自身のメールアドレスを指定しています。 そんな中、社内の迷惑メール対策として、DMARC対応をする動きがありました。 このままだとポリシーに違反するので、DKIM署名を有効化することでDMARC認証をパスできるよう設定しました。 結論 SESのIDタイプ：Eメールアドレス で、@scsk.jpのメールアドレスを登録する。 SESのIDタイプ：ドメインで、scsk.jpドメインを登録し、その際に指定されるDNSレコードを、会社のDNSサーバに登録してもらう。 そのうえで、@scsk.jpのメールアドレスをSESの送信に用いる。 前提事項 この記事における前提事項を2つ記載します。 SPF、DKIM、DMARCの理解 これらの説明は今回の本筋ではないため、これらの説明は省略します。最低限の理解として SPFという、IPアドレスを使った、メールの正当性を確かめる認証技術 DKIMという、電子署名を使った、メールの正当性を確かめる認証技術 アライメントという、SPF/DKIMで認証したドメインと、fromアドレスが一致しているかの確認 DMARCという、SPF認証・SPFアライメント、DKIM認証・DKIMアライメントが成功しているかの判定、および失敗した場合の処理を定めるメカニズム と押さえておいてください。 今回はDKIM認証・DKIMアライメントを成功させることで、DMARCの認証をパスできるようにします。 メールアドレスの設定 最初の結論で記載した「@scsk.jpのメールアドレスを登録する」についてです。 SESへ自分自身のメールアドレスを設定する作業は、先に完了している前提でこの記事を記載しています。 ドメインの登録とメールアドレスの登録、これらは順不同です。 DKIMを設定していないとどうなるか SESのコンソールからテストメールを送ってみましょう。「テストEメールの送信」から送ることができます。 Gmailの表記がわかりやすいので、試しにGmail宛てにテストメールを送ります。 ちなみに、追加設定 のReturn-pathやCcに、自分が受信できる別のメールアドレスを入れておくと 何か起きたときでも原因追及ができます。 Gmailにて受信したメールを開き 右上の三点リーダ → 「メッセージのソースを表示」を選択すると、DMARC認証に失敗していることがわかります。 「@amazonses.com」のDKIM認証は成功 DKIMアライメントに失敗 DKIM認証した「@amazonses.com」と、ヘッダfromである「@scsk.jp」が一致していないため という状態です。 DKIMの設定方法 EasyDKIMとBYODKIMの2つ方法があるので、それぞれ説明します。設定はどちらか一方で問題ありません。 ※検証時点に基づいた手順となります。最新の手順は公式ドキュメントを参照ください。 EasyDKIM： https://docs.aws.amazon.com/ja_jp/ses/latest/dg/send-email-authentication-dkim-easy.html BYODKIM： https://docs.aws.amazon.com/ja_jp/ses/latest/dg/send-email-authentication-dkim-bring-your-own.html 設定方法：EasyDKIM SES のコンソールからIDへ遷移します 「IDの作成」を選択し、以下のように設定をします。ポイントは ドメインは会社ドメインを記入します(青矢印部分)。 IDタイプはEasy DKIM を選択します。 DNS レコードの Route53 への発行 は 有効化のチェックを外します(赤矢印部分、会社DNSサーバにレコード登録するため) その後、IDステータスが「検証準備中」の状態で、3つのDNSレコード(CNAME)が表示されます。これらを会社の情シスなどDNS管理をしている部署に、登録依頼を出します。 一番下のdmarcにあるTXTレコードは、弊社会社全体でDMARCポリシーが決まっているので、今回は登録依頼を出しません。 登録が完了すると、IDステータスが「検証済み」となり、認証に成功した旨のメールがルートユーザのメールアドレス宛てに届きます。 設定方法：BYODKIM キーファイルを作成します。今回はCloudShellを使って作成します。 CloudShellにて下記コマンドを実行し、作成します。 キーファイルのファイル名(斜体)は任意です。 以下の説明では2048ビット、パブリックキーのファイル名をscsk-public.key、プライベートキーのファイル名をscsk-private.keyとして説明します。 openssl genrsa -f4 -out scsk-private.key  2048 openssl rsa -in scsk-private.key -outform PEM -pubout -out scsk-public.key アクション → ファイルのダウンロード から、scsk-private.key、scsk-public.key のキーファイルのファイル名を入力し、ローカルPCにダウンロードします。 いっぺんにダウンロードできないので、それぞれダウンロードしましょう。 SES のコンソールからIDへ遷移します。 「IDの作成」を選択し、以下ポイントを踏まえて設定をします。 ドメインは会社ドメインを記入します(青矢印部分)。 プライベートキーはscsk-private.keyをテキストエディタで開いて、以下の加工を施したのちに貼り付けます。 —–BEGIN PRIVATE KEY—– と —–END PRIVATE KEY—– を削除する。 改行を削除し、1行にする。 セレクター名はDNS レコード内で一意になるような任意の値を入れます(赤矢印部分)。 その後、IDステータスが「検証準備中」の状態で、DNSレコード(TXTレコード)が表示されます。これを会社の情シスなどDNS管理をしている部署に、登録依頼を出します。 p=customerProvidedPublicKey の customerProvidedPublicKey の値は、scsk-public.keyの中身を、以下の加工を施して入力します。 —–BEGIN PRIVATE KEY—– と —–END PRIVATE KEY—– を削除する 改行を削除し、1行にする。 255文字以上にならないよう、文字列を分割して指定する(“p=ab..cd” “ef..gh” のような形式) 一番下のdmarcにあるTXTレコードは、弊社会社全体でDMARCポリシーが決まっているので、今回は登録依頼を出しません。 登録が完了すると、IDステータスが「検証済み」となり、認証に成功した旨のメールがルートユーザのメールアドレス宛てに届きます。 設定が完了しているかの確認 DKIM署名が有効化されている状態で、テストメールを送ってみましょう。「テストEメールの送信」から送ることができます。 例によって、Gmail宛てにテストメールを送ってみましょう。 Gmailにて受信したメールを開き 右上の三点リーダ → 「メッセージのソースを表示」を選択すると、DMARC認証に成功していることがわかります。 「@amazonses.com」のDKIM認証は成功 DKIMアライメントに成功 DKIM認証した「@scsk.jp」と、ヘッダfromである「@scsk.jp」が一致しているため という状態です。 Tips 検証段階で調べて知ったことを2点補足します。 IDステータスがエラーの時は DNSの登録に時間がかかり、IDステータスがエラーになることがあります。 そんなときは、DNS登録完了後、CloudShellで下記を実行することで、再度認証処理をすることができます。 aws sesv2 get-email-identity --email-identity scsk.jp Gmail以外に送って設定確認をする Gmailに送る以外で設定確認する方法としては、メールヘッダーを確認する方法があります。 「メッセージのソースを表示」の下に書いてある、小難しい英字の羅列のことです。 これはどのメーラーでも表示することができるはずです。 ※確認方法はメーラーによって異なるので、お使いのメーラーでの確認方法を調べてみてください。 メールヘッダーを表示できたら、「dmarc=」という文字列を検索します。 成功しているのであればdmarc=pass となっているはずです(p、sp、disの値は異なります)。 dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=scsk.jp 一方で、失敗しているのであれば、dmarc=failとなっているはずです。 dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=scsk.jp re:結論 SESのIDタイプ：Eメールアドレス で、@scsk.jpのメールアドレスを登録する。 SESのIDタイプ：ドメインで、scsk.jpドメインを登録する。 会社のDNSサーバにレコードを登録してもらう。 の3ステップでDMARC認証の対応は完了します。   よきSESライフを！

こんにちは。SCSK池宮です。 今さらながら、先日Athenaデビューしました。 初心者にも非常に扱いやすいサービスですが、私と同じように「いざコンソールに入るとどこから始めていいか…」と悩んでしまう方向けに基本操作をまとめてみました。 お役に立ちましたら幸いです。 Amazon Athenaとは Amazon Athenaとは、S3上のデータに対し、サーバレスでクエリを行うことができるサービスです。 サーバレスのため事前にインスタンスやクラスターを用意する必要がなく、”使いたい時”に”使いたい分”だけクエリを実行できます。 S3に対しクエリが実行できるサービスというと、Redshift SpectrumやS3 Selectを思い浮かべる方も多いのではないでしょうか？ この2つのサービスとの違いについて、以下のようにまとめてみました。   Amazon Athena Redshift Spectrum S3 Select 概要 サーバレスのクエリサービス RedshiftからS3データに直接クエリできるサービス S3からデータ抽出するサービス ユースケース S3に置かれたデータに対し分析や複雑なクエリを行う。 S3に置かれたデータ更新などをクラスター外で行う。 高度な分析を行う。 S3に置かれたデータを効率的に抽出して他の処理に渡す。 メリット サーバレスで利用することができる。 既存Redshiftクラスターの負荷分散を行うことができる。 安価に利用できる。 コスト 5.00USD/TB （クエリごとの検索対象） USD 5.00/TB （クエリごとの検索対象） ※Redshift自体の料金は 別途かかる -（新規受付終了） クエリできるフォーマット parquet、orc、json、csv Parquet、ORC、RCFile TextFile、SequenceFile、RegexSerde、OpenCSV、AVRO、Ion、JSON -（新規受付終了） S3 Selectについては、残念ながら2024年7月に新規受付終了が発表がされました。 Athenaでは大規模データに対しても高速なクエリが可能、かつS3はスケーラブルなオブジェクトストレージである、ということから Athena＋S3の構成では、ストレージとコンピュート（クエリ実行）部分がそれぞれ独立したスケーラブルな仕組みになっています。 （「クエリでスキャンしたデータに対して従量課金」という特徴等もそうですが、AthenaはGoogle CloudのBigQueryの考え方に近い印象を受けました） Athenaの操作方法 AthenaはS3上のデータにクエリできるサービスですが クエリエディタでリアルタイムにクエリを実行するために、テーブル定義を行う必要があります。 今回は以下のようなCSVファイルをS3に置き、Athenaでデータを見ていこうと思います。 ID Name Price 101 いちご 500 102 もも 300 103 りんご 100 104 ぶどう 200 201 かぼちゃ 150 202 さつまいも 200 AWSコンソールからAthenaにアクセス コンソールの「分析」からAthenaを選択します。 「クエリエディタを起動」をクリックします。 テーブルを作成してみる 「テーブルとビュー」をクリックし、「S3バケットデータ」を選択します。   「テーブル名」で作成するテーブル名を入力し、テーブルを管理するデータベースを選択します（今回は既存のデータベースにテーブルを作成します）。 「データ形式」と「列の詳細」を選択します。今回は以下のように設定しました。 データ形式 テーブルタイプ Apache Hive ファイル形式 CSV 列の詳細 列名 列のタイプ id int name string price int 「テーブルクエリをプレビュー」を見ると、設定したテーブルを作成するためのクエリが自動で作成されています。一番下の「テーブルを作成」をクリックします。 先ほどのクエリが実行され、テーブルが作成されました。   これでテーブル作成は完了です！ クエリを実行してみる 早速、作成したテーブルにクエリを投げてみます！ select * from test_ikemiya.test_ikemiya_20241212 結果が取得できました！（Athenaはクエリデータ量に応じて課金が発生するため、”select *”を行う場合は十分注意して実行してください） 今回のFROM句では、”データベース名.テーブル名”を設定しています。 テーブル名だけでクエリを行う場合は、データベースが正しく設定されているか、ご確認ください！   今回は基本中の基本操作を行いました。 データベースを構築することなく使用できるAthenaはアドホックな分析に向いています。 データ分析には欠かせないサービスだと思いますので、積極的に利用していきたいと思います！ 最後までお読みいただきありがとうございました。