こんにちは、皆さん。 LifeKeeperの記事ではこれまで、製品に関する機能や利用用途についてご紹介してきました。 今回はそんなLifeKeeperとミドルウェアを組み合わせて、ミドルウェアにおけるニーズの高まりと 運用における可用性向上の方法についてご紹介していきたいと思います！   ミドルウェアにおける可用性ニーズについて 皆様は現在のパブリッククラウド環境において可用性の仕組みをどのように導入しており、 また、どんなミドルウェアの可用性を高めたいと考えておりますか。 先日、システム運用の関係者へWebアンケート（ITmedia）を実施した際、 このような結果がでました。 パブリッククラウド環境で可用性向上の仕組みを導入しているか？ という質問に対して、70%近くのお客様が可用性を導入している、と回答がございました。 システムの稼働が止まってしまっては大変ですから、大半のお客様は可用性を高めているといった結果でした。   続いて、可用性を更に高めるためには具体的なミドルウェアの選定も重要となってきます。 そこで、特に可用性を高めたいと考えているミドルウェアは何でしょうか？と質問したところ、 Microsoft SQL Server、Oracle Database、MySQL といった重要なデータ基盤である データベース関連の可用性向上のニーズが高いことが判りました。   一方で、ここ５年くらいの傾向として ・JP1/AJS ・Zabbix ・HULFT ・SVF などの共通基盤系といったミドルウェアの可用性向上ニーズの広がりを感じています。 このような傾向があるミドルウェアの中でも、 今回は 「HULFT」 について 「LifeKeeper」で可用性を高める方法をご紹介していきます！   HULFTについて まず、HULFTについてご紹介いたします。 HULFTとは、主に企業間やシステム間でのデータ転送やファイル転送を行うためのミドルウェア製品です。 特徴としては5つあります。 1. 高い信頼性 データ転送の確実性が高く、エラーが発生した場合のリトライ機能や転送状況の確認機能を備える 2. セキュリティ データ暗号化や認証機能により、安全なデータ転送を実現 3. 多様なプラットフォーム対応 Windows、Linux、Unixなど、さまざまなOSに対応 4. 簡単な操作性 GUIを利用して簡単に設定や管理が可能であり、利用が簡易 5. 高いパフォーマンス 大容量データの転送や高速なデータ処理が可能   このような特徴を持つHULFTは、金融機関や製造業をはじめとする多くの業界で利用されており、 企業内外でのデータ連携を効率化するための強力なツールとして評価されています。   HULFT × LifeKeeper データ連携ツールであるHULFTはシステム全体において重要な役割を担っており、 運用において高い可用性が求められます。   運用中はサーバーの障害やソフトウェアの障害など、24時間ｘ365日起こりうる障害への対策が必要となります。 そのため、障害対策として自動で検知し自動で復旧する事が望ましいです。   HULFTとLifeKeeperを組み合わせた構成イメージとしては以下のようになります。 このように、LifeKeeperを用いた高可用性ソリューションを組み合わせることで、 基幹系システムに求められるレベルの可用性の実現が可能となります。   製品ページ SCSKでは、上記で紹介したHULFT、そしてLifeKeeperの製品ページをご用意しております。   HULFT www.scsk.jp   「LifeKeeper」で安定稼働を実現 ｜ SCSK株式会社 「LifeKeeper」は、システム障害時にあなたのビジネスを守るＨＡクラスターソフトウェアです。オンプレ環境だけでなく、パブリッククラウド環境での安定稼働の実現にも最適です。長年培ったSCSK独自のノウハウでお客様の課題解決に向け最適なご... www.scsk.jp   ご参考までに、HULFT8のライセンス価格と技術サポート一年パックの価格表（サポート種別ごと）の定価について掲載いたします。 待機系のライセンス価格につきましては、稼働系ライセンス価格の 半額 となっております。 ■ライセンス価格 対象OS 稼働系 待機系 Linux \650,000 \325,000 Windows \400,000 \200,000   ■通常技術サポート 対象OS 稼働系 待機系 Linux \98,000 \49,000 Windows \60,000 \30,000 ※通常技術サポート窓口の対応時間として、 月曜日～金曜日9：30～17：00（祝祭日及び年末年始を除く）   ■24/365技術サポート 対象OS 稼働系 待機系 Linux \196,000 \98,000 Windows \120,000 \60,000 ※24/365技術サポートサービスとして、24時間365日をサポート   最後に 今回は、ミドルウェアの可用性ニーズが高まってきていること そして、そのミドルウェアの中の「HULFT」という製品をご紹介させていただきました。 HULFTにLifeKeeperを用いることで高可用性が実現でき、業務の安定稼働に向けて一役買うことができたらと思います。

こんにちは。磯野です。 Cloud RunでPythonプログラムを実行する際、ログレベルをCloud Loggingへ反映させる方法をご紹介します。 はじめに Cloud Runのログは自動的にCloud Loggingへ反映される Cloud Runのログは、print文やloggingライブラリを使用して標準出力に文字列を出力すると 自動的に Cloud Logging に記録  されます。 しかし、このままだとすべてログレベルがデフォルトとなってしまいます。（下記画像参照） ↑WARNINGやERRORレベルのログも、デフォルトとして表示されている このままではエラー調査やフィルタの活用が難しくなってしまう、ということで、本記事ではログレベルの反映方法をご紹介します。 方法１：公式ドキュメントの記載方法を利用 下記を参考に設定します。 Python 用 Cloud Logging の設定  |  Google Cloud cloud.google.com コードの記載方法 ログの設定方法 import google.cloud.logging client = google.cloud.logging.Client() # 実行中の環境に基づいて Cloud Logging ハンドラを取得し、 # このハンドラを Python のログモジュールと統合します。 # デフォルトでは INFO レベル以上のすべてのログをキャプチャします。 client.setup_logging() ログの出力 import logging text = "Hello, world!" logging.warning(text) Cloud Loggingへの出力結果 無事にログレベルが反映されました。 ところが… 該当のCloud Runジョブ画面 ＞ログ という画面遷移であればログが表示されたのですが 該当のCloud Runジョブ画面 ＞ 該当の実行ID ＞ ログという画面遷移だと、ログが表示されませんでした。 labelsに”run.googleapis.com/execution_name”が付与されておらず、ジョブ単位にログをフィルタすることができなかったのが原因のようです。ジョブ単位にログをフィルタする必要がある場合は、方法2を推奨します。 ※こちらGoogleの不具合のようで、googleapiのgithub上で本件 issue になっていました。 追って解消されるかもしれません。 方法2： StructuredLogHandler ()を使用する コードの記載方法 ログの設定方法 import logging import google.cloud.logging from google.cloud.logging_v2.handlers import StructuredLogHandler logger = logging.getLogger() handler = StructuredLogHandler() logger.setLevel(logging.INFO) logger.addHandler(handler)   ログの出力 出力方法は方法１と同じため、割愛します Cloud Loggingへの出力結果 ログレベルの反映・labelsの付与ができました。   まとめ ログレベルの反映に苦労したので、記事にしました。 参考になれば幸いです。

こんにちは。SCSK株式会社の上田です。 今回は、Zabbixの監視で利用できる”正規表現”という機能の使い方を紹介します。正規表現を使うことで、複雑な条件にマッチするログの監視をすることが可能です。 正規表現とは 正規表現 とは、 文字列のパターンを表現するための記法 です。特定の文字列を検索したり、置換したりする際に使われます。 例えば、電話番号やメールアドレスのフォーマットに一致する文字列を抽出したり、 Sysログ等の大量の文字列の中から特定のキーワードを含む行を検索したりするときに、正規表現が使われます。 Zabbixにおける正規表現 Zabbixでは、 Perl互換の正規表現（PCRE、PCRE2） がサポートされています。これにより、柔軟なパターンマッチングが可能になっています。 Zabbixで主に使用される正規表現をいくつか紹介します。 正規表現 意味 . 任意の一文字 * 直前の文字の0回以上の繰り返し + 直前の文字の1回以上の繰り返し ? 直前の文字の0回または1回の出現 ^ 行の先頭 $ 行の末尾 [abc] a,b,cのいずれか一文字 [^abc] a,b,c以外 | いずれかの文字列に一致 \ エスケープ文字（直後の文字を、正規表現ではなく普通の文字列とする） これらを組み合わせることによって、文字列のパターンを表現します。 とはいえ、この表だけではピンとこないと思いますので、いくつか例を挙げてみます。 【 .* 】は、 任意の一文字 ＋ それの0回以上の繰り返し ということで、 任意の0文字以上の文字列 を表します。 【 ^ zabbix .* test $ 】という正規表現は、 “ zabbix”で始まり”test”で終わる行 を表します。 【 \ [hoge \ ] 】という正規表現は、 “[hoge]”という文字列 を表します。ここで、 “[]” はそのままだと正規表現文字のため、 “[]” という文字自体にマッチさせたい場合はエスケープ文字の” \ “を使います。もしエスケープ文字が無ければ、 h,o,g,eのいずれか一文字 とマッチしてしまいます。 Zabbixでの正規表現の設定方法 ここまで正規表現とは何かについて説明してきました。続いてZabbixで正規表現を使う方法について説明します。 Zabbixでは、 アイテムキーに直接正規表現を書き込んだり 、 ユーザーマクロで正規表現を使ったり 、いろいろな場所で正規表現を使えます。 今回は、その中から グローバル正規表現 の使い方を説明します。グローバル正規表現の設定画面では、 ある文字列が作成した条件式にマッチするかのテストが実施できる ので、正しく正規表現が書けているかチェックできて便利です。 グローバル正規表現の設定方法 グローバル正規表現設定画面を開くには、ZabbixのWEBコンソールから 【管理　＞一般設定　＞正規表現】 と選択します。 正規表現の設定画面 デフォルトでいくつか正規表現が作成されています。 新しく正規表現を作成するために、右上のボタンをクリックします。 正規表現の作成画面 このような設定画面が開きます。 「文字列が含まれる」「いずれかの文字列が含まれる」「文字列が含まれない」 は、その名の通り入力した文字列が含まれるか含まれないかの条件を追記できます。 「結果が真」「結果が偽」 を選択すると、正規表現を使うことができます。 ここで、先ほど例示した正規表現を条件式に書いてみましょう。 条件式作成後の画面 これで、 【^zabbix.*test$】にマッチ し、かつ 【\[hoge\]】にマッチしない　 という条件の正規表現が作成できました。 想定通りの条件になっているかテストしてみましょう。 以下の3つの文字列を考えます。 　1：zabbixにおける正規表現のtest 　2：zabbixにおける正規表現のtestです。 　3：zabbixにおける[hoge]のtest これらは、作成した正規表現にマッチするでしょうか？ 1は、 【^zabbix.*test$】にマッチ し、かつ 【\[hoge\]】にマッチしない ので、 マッチします。 ※最終結果が真ならマッチしている、偽ならマッチしていないことを表します。 テスト①   2は、 【^zabbix.*test$】にマッチしない ので、 マッチしません。 テスト②   3は、 【^zabbix.*test$】にマッチ しますが、 【\[hoge\]】にもマッチする ので、 マッチしません。 (hogeのテストって何だろう。。。) テスト③ トリガー条件式への正規表現の適用 これで正規表現が作成できたので、これをトリガー条件式に適用してみましょう。 正規表現を使いたいトリガーの設定画面を開きます。条件式に、以下のように記入します。 find (/host/key,,"regexp","@正規表現名") find関数は、アイテムから一致する値を見つける関数です。 通常では、第1パラメーターにホスト名とアイテムキーを指定し、第4パラメータに一致させたい値を入力しますが、第3パラメータに “regexp” を指定することで、第4パラメータで正規表現が使用できます。 正規表現を指定ときは、頭に “@” を付けます。 今回は、ホスト「Zabbix server」の/var/log/messagesを監視するアイテムに対してトリガーを設定してみます。 トリガーの設定画面 これで、作成した正規表現に一致するログが出力されたら障害を検知するトリガーが作成できました。 障害検知テスト 実際にログを出力させてみて、障害検知するか確認してみましょう。 監視対象ログに、正規表現に一致するログを出力させてみます。 # echo zabbixにおける正規表現のtest >> /var/log/messages 出力したログが、アイテムとして取得されると。。。 ログアイテムの取得状況 想定通り、障害検知しました！ 障害検知結果 まとめ 今回は、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アカウントを開設しました！★ x.com X.com

こんにちは、ひるたんぬです。 最近は耐え難い暑さが続いておりますね… 私はとても暑さに弱い生物なので、ひと月ほど前からエアコンの恩恵にあずかっているのですが、エアコンの設定温度ってとても難しいなと思っています。 というのも期待した温度にならないのです。28℃に設定してるのに25℃近くになったり、逆に30℃くらいになったり… エアコンも暑さでおかしくなってしまったのでしょうか…？今夏を乗り越えてくれるよう切に願っています。 さて、今回は業務でSDK(boto3)に触れている中で、ふと気になった点について調査をしました。 気になったこと Secrets Managerからシークレットを取得したい！と思った際、マネジメントコンソールでは各言語でのサンプルコードを示してくれています。（とても親切！！）例えば、Python3(boto3)の場合は以下のようになっています。 # Use this code snippet in your app. # If you need more information about configurations # or implementing the sample code, visit the AWS docs: # https://aws.amazon.com/developer/language/python/ import boto3 from botocore.exceptions import ClientError def get_secret(): secret_name = "SECRET_NAME" region_name = "REGION_NAME" # Create a Secrets Manager client session = boto3.session.Session() client = session.client( service_name='secretsmanager', region_name=region_name ) try: get_secret_value_response = client.get_secret_value( SecretId=secret_name ) except ClientError as e: # For a list of exceptions thrown, see # https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html raise e secret = get_secret_value_response['SecretString'] # Your code goes here. このコードを見て、私は「 boto3.session.Session()ってなんぞや？ 」と思いました。 そう、この記述とはここで会ったのが初めてだったのです。 boto3のSessionとは こういうときに役に立つのは、やはり公式ドキュメントですね。 Boto3の公式ドキュメントには次のように記載があります。 A session stores configuration state and allows you to create service clients and resources. 引用：AWS 「 Boto3 1.34.146 documentation -Session reference- 」 つまり、アクセスキーやシークレットキーなどの認証情報を一つのオブジェクトとしてまとめて生成し、それをクライアントやリソースオブジェクトの生成時に引数として指定することで使い回すことができる、という仕組みのようです。複数のクライアントやリソースオブジェクトを生成する際に、いちいち認証情報を入力しなくて済むので、これは便利な機能ですね。 さらなる疑問 Sessionについて調べる中で、公式ドキュメント内でSessionを以下のように使っている場合もありました。 # Explicitly create a new Session for this thread session = boto3.Session() dynamodb = session.resource('dynamodb')   Python と Boto3 による Amazon DynamoDB のプログラミング - Amazon DynamoDB Python で DynamoDB をプログラミングする方法に関するさまざまな概念について説明します。 docs.aws.amazon.com そうです、”session”が一つ欠けているのです。こういうのすごく気になってしまうんですよね… こちらについては、結論から言いますと同じオブジェクトを指しておりました。 せっかくなので、boto3のソースコードを見て確認してみましょう。 今回は執筆時点での最新バージョンである「1.34.146」のコードで確認しています。 GitHub - boto/boto3 at 1.34.146 AWS SDK for Python. Contribute to boto/boto3 development by creating an account on GitHub. github.com boto3.session.Session()と記載する場合 この場合は、boto3フォルダにある”session.py”を参照し、Sessionクラスを呼び出しています。 boto3.Session()と記載する場合 この場合は、boto3フォルダにある”__init__.py”を参照します。 するとこのファイルの17行目に from boto3.session import Session と記載があります。これによって、boto3フォルダにある”session.py”を参照し、Sessionクラスを呼び出していることが分かりましたね。 おわりに 細かいところが気になってしまう性分なのでしっかり調べました。 こういうことを一つずつ知るたびに成長しているなぁ…と実感できて嬉しいです。 余談ですが、botoの名前の由来は「アマゾン川に自生する淡水イルカ（アマゾンカワイルカ）」だそうです。 アマゾンカワイルカ｜海棲哺乳類データベース www.kahaku.go.jp また、Boto 3 の数字はライブラリのメジャーバージョン（3番目）を示しているようです。 下記サイトに載っていたのですが、なぜDynamoDB上のドキュメントにBotoの由来などが記載されているのでしょうか…謎は深まるばかりですね。 Python と Boto3 による Amazon DynamoDB のプログラミング - Amazon DynamoDB Python で DynamoDB をプログラミングする方法に関するさまざまな概念について説明します。 docs.aws.amazon.com

  Cato Networks社が、2024年7月3日に発行された ガートナー（Gartner™）のマジック・クアドラント（Magic Quadrant™）のシングルベンダー SASE 部門においてリーダーに認定されました 。 ガートナーのマジック・クアドラントの調査レポートについては、以下のCato社のサイトから閲覧することが可能ですが、後日、Cato Networks社が日本語訳した調査レポートを無償公開する予定になっています。 Cato Networks named a Leader in the 2024 Gartner® Magic Quadrant™ for Single-Vendor SASE Cato named a Leader in the Gartner® Magic Quadrant™ for Single-Vendor SASE. Want to learn more? Download the full report... www.catonetworks.com   日本語記事 Cato Networks、2024年 Gartner Magic Quadrantのシングルベンダー SASE 部門においてリーダーに認定 Cato Networks株式会社のプレスリリース（2024年7月16日 10時00分）Cato Networks、2024年 Gartner Magic Quadrantのシングルベンダー SASE 部門においてリーダーに認定 prtimes.jp Cato Networks、2024年 Gartner Magic Quadrantのシングルベンダー SASE 部門においてリーダーに認定 Cato SASE クラウド プラットフォームは、引き続きエンタープライズ セキュリティ市場を形成 www.catonetworks.com   昨年（2023年）のマジック・クアドラントはチャレンジャー認定でした、今年は晴れてリーダーに認定されました。 特に日本の企業では、ソリューションの検討・採用時に、ガートナーのマジック・クアドラントを重要視されるケースが非常に多いので、とりあえずリーダーの認定されて一安心と言ったところです。   2024年にガートナーが、Secure Access Service Edge（SASE、サッシー）を提唱する以前（2015年）にCato Networks社は創業しており、Catoクラウドは、当初からSASEの概念で、クラウドネイティブなプラットフォームを構築しており、SASEの市場を新たに開発し、牽引した革新的なパイオニアとして評価されています。 また、企業買収（M&A）によるセキュリティ機能統合を行っていないことから、「統一されたプラットフォーム」が高い評価を得ており、単一で、シンプルなUIの提供が、ユーザにも高く指示されています。 その結果、ユーザエクスペリエンス（UX）についても、他ベンダーと比較して高い評価を得ています。 他ベンダーを比較し、（都度ベンダーに設定を依頼するのではなく）お客様ご自身で、設定・運用を行うことができるソリューションとしても、高い評価を得ています。    IT専門家やテクノロジー意思決定者による偏りのない評価とレビューである ガートナーのピア・インサイト（Gartner Peer Insights™） においても、Cato クラウド プラットフォーム は、シングルベンダー SASE の総合評価で 5 点満点中 4.7 点を獲得しており、検証済みレビューが 183 件あり、シングルベンダー SASE マジック・クアドラントに選出されたすべてのリーダーの 10 倍以上の評価レビュー数になります。   ガートナーの市場予想では、シングルベンダーSASEは、2024年の 20% から、2027年までに新しくSD-WAN購入する 65%がシングルベンダーSASEを採用するされており、今後、シングルベンダーSASE市場が大きく拡大するとされていますので、是非、Cato Networks社、Catoクラウドをご検討ください。   Cato Networks社、Catoクラウド（Cato Cloud/Cato SASE Cloud）については、以下の記事を是非ご参照ください。 Catoクラウド エンジニアブログまとめ記事 Catoクラウドのエンジニアブログ（TechHarmony）でのまとめ記事となります。 blog.usize-tech.com 2024.02.27 Catoクラウドにご興味をもられましたら、サービス紹介やデモ等を行いますので、お気軽に お問い合わせ ください。

皆様、いつもお仕事お疲れ様です。 今夏、Zabbix Jpanが主催する Zabbix全国5都市キャラバン2024 が開催されます！！ このイベントでは、Zabbixを知らない人から既にご利用いただいている方まで幅広い方を対象としたイベントとなっております。特に、Zabbixの導入をご検討されている方には有意義なイベントであると思います！ イベント概要 Zabbix全国5都市キャラバン2024では、 Zabbix Japan及びZabbixパートナー企業によるセミナー が行われます！Zabbixについての最新情報やパートナー企業のZabbixソリューションについて知ることができます！ イベントではセミナーと併せて テクニカル相談会 も実施されます！！相談会ではZabbix Japanのエンジニアやパートナー企業エンジニアが、導入やアップデート、運用に関する不明点や困りごとについて相談に乗ります。相談ごとのある方はぜひこの機会をご利用ください╭( ・ㅂ・)و ̑̑ ｸﾞｯ   開催日と会場は下記のとおりです。複数日程ございますので、都合のいい日程・会場でご参加いただければと思います。 2024年8月2日  （東京会場　：品川フロントビル会議室） 2024年8月23日（名古屋会場：AP名古屋） 2024年9月13日（大阪会場　：グランフロント大阪　カンファレンスルーム） 2024年9月20日（福岡会場　：JR博多シティ会議室） 2024年9月27日（札幌会場　：HOTnet共創空間 Akallabo）   Zabbix全国5都市キャラバン2024の来場登録は「 Zabbix5都市キャラバン2024 」からお願いします。 ホームページでは、セミナーの講演内容も記載されていますので、興味のある講演内容を探してみてください！   SCSKのセミナーについて SCSKは Zabbixへのスムーズな乗り換え – SCSK Plus サポート for Zabbixのご紹介 と題して、SCSKが今夏にローンチする Quick Start Package for Zabbix についてお話しさせていただきます。 本サービスは、弊社にて2017年よりZabbix構築サービスを提供してきた中で、よくある構築環境をパッケージ化したサービスとなります。サーバ環境や構築サービス、サポート等で複数のコースを用意しており、それらを組み合わせるバイキング形式のパッケージとなっております。 お客様環境に合わせて最適な組み合わせが可能となっております！！！ SCSKは上記5会場全てにおいて講演いたしますので、どこかの会場でお会いできることを楽しみにしてます！   さいごに 最後までお読みいただきありがとうございます。 ちなみにですが、ここまでZabbix全国5都市キャラバン2024について熱く語ってきましたが、筆者は5会場いずれにも参加しません。 本ページ見てイベントに参加しようと思った方は、筆者の分も楽しんできてくださいね！   本当のさいごのさいごに、弊社では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アカウントを開設しました！★ x.com x.com

こんにちは。SCSKの吉田です。 初めてのブログ投稿となります。今後、ServiceNowに関する様々な情報をアウトプットしていきたいと思いますのでよろしくお願いします！ 2か月前のことになりますが、5月にServiceNowの年次ビッグイベント 「Knowledge 2024」 に参加してきました。 イベントの概要は以下の通りです。 日程：5月7日～5月9日の3日間 階催場所：米国ラスベガスのThe Venetian Convention & Expo Center 参加人数：グローバルで20,000人弱（うち日本からは300名以上が参加） 内容：KeyNote(基調講演)、Expo(展示会)、Session、オンサイトミーティングなど 今回は現地での体験談をお伝えします！ ラスベガスで認定資格取得にチャレンジ！ まずは自己紹介もかねて個人のお話から。 こちらはKnowledge 2024で実施された、イベント会場でServiceNowメインライン認定資格の受験にチャレンジする取り組みです。 今回、人事領域アプリケーションの導入者向け資格である「Certified Implementation Specialist – Human Resources」を受験し、見事合格することができました！ さらに本イベントには 日本から唯一の参加者 ということもあり、最終日のJapan Closing Sessionで紹介していただけました。 （自称：初代ラスベガスでServiceNow認定資格を取得した人） 試験後に合格したことをスタッフに伝えると記念のピンバッジを頂けました。 試験開始前に他の受験者と「緊張するね」と会話したり、イベント会場でバッジを見た人から「これは何？」と聞かれて立ち話が始まったりと、思いがけず海外の方とも交流できて非常に良い経験となりました。   KeyNote KeyNoteでは、Bill Mcdermott氏による講演や、製品ロードマップ、ライブデモなどが行われました。 特に生成AIに関する発表が多く、ServiceNowがビジネス変革のためのAIプラットフォームへと進化している点が強調されていました。 会場へは入りきれないほどの参加者が集まり、講演中は都度、歓声が上がるなどすごい盛り上がりでした。 KeyNoteを通じて、参加者全員のServiceNow、生成AIに対する熱気を改めて感じることができました。   Session・Expo イベント期間中は、多数のセッションが同時に開催され、各自が興味のあるセッションを予約して参加する形となります。 私は主に以下のセッションに参加してきました。 ServiceNowの活用事例 生成AIを活用する上でのTipsや機能紹介 製品ロードマップ ServiceNowの生成AI機能がリリースされてから数カ月にも関わらず、開催されたセッションのうち、生成AIに関するセッションが多くを占めていたのがとても印象的でした。   また、Expo会場では各企業の展示ブースがあり、ServiceNowを活用しているデモを見たり、企業の担当者と会話することができます。 IoTやAIとServiceNowを組み合わせた体験型のブースも数多くあり、会場全体で非常に盛り上がっていました。   最後に 以上、Knowledge 2024の現地体験レポートでした。 今回、初めての参加でしたが、個人として感じたことは主に以下3点となります。 ServiceNowに関わる全ての人の熱気がすごい ビジネスにおいてAIの活用が前提となっている時代となりつつある 個人としてAIを活用しきれていないことに対する危機感 また、ServiceNowに関わる者としてServiceNowをさらに盛り上げていこうというモチベーションをより上げることができたのが、一番の収穫でした。 今後もServiceNowに関する情報をアウトプットしていきたいと思います！  

こんにちは、SCSKでAWSの内製化支援『 テクニカルエスコートサービス 』を担当している貝塚です。 AWSサービスに接続するためのVPCエンドポイント(ssm.ap-northeast-1.amazonaws.com など)がVPCごとに作られていくのは管理上よろしくないと考える方はいらっしゃるようでして、VPCエンドポイントを1か所に集中させたいというご要望を頂くことがございます。 これを実現するうえで重要なのは、DNS名前解決をどのように行うか、です。本稿では、マルチアカウント環境において、AWSサービス用のVPCエンドポイント(ssm.ap-northeast-1.amazonaws.com など)を一つのVPCに集約した場合のDNS名前解決パターンについて考察します。 ※VPC間の接続にTransit Gatewayを何の説明もなく使用していますが、Transit Gatewayをよく知らないという方でも、VPC間を接続するサービスということだけ理解していれば本稿を読み進めるのに支障ありません。 プライベートホストゾーンを使う案 対象ドメイン(例：ap-northeast-1.amazonaws.com)のプライベートホストゾーンを作成し、各アカウント・各VPCに関連付けることで、ハブVPC上のVPCエンドポイントの名前が返るようにします。 アーキテクチャ図は以下の通りです。 プライベートホストゾーンではハブVPC上のDNS名とIPアドレスを対応付けるAレコードを作成しておきます。スポークVPCでAmazon Provided DNS(デフォルトで設定されるDNS)にDNSクエリを発行すると、プライベートホストゾーンに登録されたハブVPC上のIPアドレスが返ってきます。 こちらの構成は、クラスメソッドさんの下記記事で既に解説されていますので、本稿では気づいた点を何点か述べるに留めます。 複数VPCで名前解決を集約・共有する方法を試してみた | DevelopersIO 複数のVPCで名前解決をいい感じに共有または集約する方法を試してみました。今回シングルアカウント内のVPCで試していますが、大枠の考え方はマルチアカウントでも利用できると思います。 dev.classmethod.jp ap-northeast-1.amazonaws.com や amazonaws.com でプライベートホストゾーンを作成しようとすると、既にAWSに予約されているという理由でエラーになるので、bedrock.ap-northeast-1.amazonaws.com や kendra.ap-northeast-1.amazonaws.com のようにサービス名ごとにプライベートホストゾーンを作成する必要がある。 プライベートホストゾーンを他アカウントのVPCに関連付ける作業はマネジメントコンソールからは実行できず、CLI等から実施する必要がある。 名前解決したいホスト名の数 × 関連付けたいVPCの数 だけ関連付け作業を実施する必要があるので、規模が多くなってきたらスクリプト化・IaC化必須である。 ドメイン名 ap-northeast-1.amazonaws.com のゾーン作成はエラーになる プライベートホストゾーン設定例(kendra.ap-northeast-1.amazonaws.comゾーンのレコード作成) 他のアカウントのVPCにプライベートホストゾーンを関連付ける手順についても以下のクラスメソッドさんの記事で解説されていますので、そちらをご参照ください。 [Route 53]他のAWSアカウントのVPCにプライベートホストゾーンを関連付ける | DevelopersIO Route 53で作成したプライベートホストゾーンを他のAWSアカウントのVPCに関連付ける方法をご紹介します。 dev.classmethod.jp なお、この手順で関連付けられたホストゾーンは、マネジメントコンソールから確認することができず、CLIの route53 list-hosted-zones-by-vpc などで確認する必要があるようです。 DHCPオプションセットを使う案 スポークVPCにDHCPオプションセットを適用して、(EC2などが)参照するDNSサーバのIPアドレスにハブVPC上のRoute 53 Resolverインバウンドエンドポイントを指定する方法です。 アーキテクチャ図を描くと以下の通りです。 こちらも先ほどご紹介したクラスメソッドさんの記事で既に解説されていますので、本稿では詳しい説明を割愛します。 複数VPCで名前解決を集約・共有する方法を試してみた | DevelopersIO 複数のVPCで名前解決をいい感じに共有または集約する方法を試してみました。今回シングルアカウント内のVPCで試していますが、大枠の考え方はマルチアカウントでも利用できると思います。 dev.classmethod.jp ハブVPC内のRoute 53 Resolverインバウンドエンドポイントは、同じVPC内にあるVPCエンドポイント(この例の場合は bedrock.ap-northeast-1.amazonaws.com)の名前解決時にプライベートIPアドレスを返しますので、プライベートホストゾーンを作成する必要はありません。 スポークVPC(内のEC2等)が参照するDNSサーバがハブVPC上にあるため、スポークVPC独自の名前解決をさせたいときに難易度が上がります。例えばできる限りSession Managerがネットワーク障害の影響を受けないようにする目的で、Session Manager用のVPCエンドポイントだけはスポークVPC内に作成したい(他のVPCエンドポイントはハブVPC内に置きたい)となった場合に、対応ができません。 スポークVPCにRoute 53リゾルバ アウトバウンドエンドポイントを置く案 私が無い知恵をふりしぼって最初に考えた構成です。ハブVPCにRoute 53リゾルバ インバウンドエンドポイントを作成し、スポークVPCにはRoute 53リゾルバ アウトバウンドエンドポイントを作成します。スポークVPCで発行されたap-northeast-1.amazonaws.comドメインのDNSクエリは、リゾルバ転送ルールを使用してハブVPCのインバウンドエンドポイント(のIPアドレス)に向けてやります。 図にするとこのようになります。   この構成は動作します。しかし、VPCごとにRoute 53リゾルバ アウトバウンドエンドポイントが必要になり、冗長構成が必須であることも考慮するとそれだけで月180ドルの料金がかかってしまいますので、今回の目的に照らし合わせると没案と言わざるを得ません…。 Resource Access Managerでリゾルバルールを共有する案 私が費用対効果の悪い案をひねり出すより前に、AWSからとっくに以下のようなアーキテクチャが公開されていました。 複数の VPC から中央のAWS のサービスエンドポイントにプライベートにアクセスする - AWS 規範ガイダンス docs.aws.amazon.com リンク先にも示されていますが図にすると以下のようになります。(リンク先とは図が若干異なりますが、私なりに同じものをより分かりやすく示そうとした結果です) 構成を細かく分解して説明すると以下の通りです。 ハブVPCに、Route 53リゾルバ インバウンドエンドポイントだけではなく、Route 53リゾルバ アウトバウンドエンドポイントも作成する リゾルバ転送ルールを作成し、ap-northeast-1.amazonaws.comドメインの名前解決をRoute 53リゾルバ インバウンドエンドポイント(のIPアドレス)に転送するように設定する リゾルバ転送ルールをResource Access Manager (RAM)を使ってスポークアカウントと共有する スポークアカウント側で、リゾルバ転送ルールをスポークVPCに関連付ける 上記の通り構成することで、スポークVPC側にRoute 53リゾルバ アウトバウンドエンドポイントがなくても、Amazon Provided DNSは、ap-northeast-1.amazonaws.comドメインの名前解決DNSクエリを ハブVPCのRoute 53リゾルバ インバウンドエンドポイントへと転送してくれます。 構築時のポイント ハブアカウント側、リゾルバ転送ルールの作成 今回の目的は、ap-northeast-1.amazonaws.comドメイン(AWSサービスのVPCエンドポイント)の名前解決をハブVPCに転送することなので、ルールの作成画面でドメイン名にap-northeast-1.amazonaws.comを指定します。 VPCは指定する必要がありません。 ターゲットIPアドレスに、Route 53リゾルバ インバウンドエンドポイントのIPアドレスを指定します。 ルール作成画面 Resource Access Manager (RAM)を使用した転送ルールの共有 Resource Access Manager (RAM)メニューの「自分が共有: リソース共有」から「リソース共有を作成」ボタンを押します。 そこから先の設定は、以下にスクリーンショットを載せました。 「リソース – オプション」のところで「リゾルバルール」を選び、対象のルールをチェックします。 マネージド型アクセス許可は、デフォルトのまま変更しませんでした。 プリンシパルタイプは、「AWSアカウント」を選択し、スポークアカウントのアカウントIDを入力します。 また、スクリーンショットは載せていませんが、スポークアカウント側でResource Access Manager (RAM)メニューの「自分と共有: リソース共有」から「リソース共有を承認」する必要があります。 リゾルバ転送ルールをスポークVPCに関連付け 共有された転送ルールは、Route 53 > リゾルバー > ルール のルール詳細から、「VPCを関連付ける」をクリックし、スポークVPCを関連付けます。 VPC関連付け後の転送ルール(スポークアカウント側) 名前解決確認 以上で設定は完了です。スポークVPCのEC2からdigコマンドでssm.ap-northeast-1.amazonaws.comの名前解決を実行すると、ハブVPCのssmエンドポイントのIPアドレスが返ってきました。 DNSクエリの通信経路はどうなっている？ この構成で、DNSクエリ(UDP 53番ポートの通信)は実際にどのように行われているのでしょうか。調べてみることにします。 アーキテクチャ図再掲 この構成なら、スポークVPCのAmazon Provided DNS(10.1.0.2)からRoute 53リゾルバ インバウンドエンドポイント(10.0.33.153, 10.0.34.129)へのIP通信が発生しているのではないか？と推測しました。 しかし、DNSクエリログと照らし合わせながらVPCフローログを調べて行きますが、スポークアカウント側に該当するログはありません。それどころか該当の時間帯に、UDP 53番ポートの通信は一切発生していませんでした。 スポークアカウント側のDNSクエリログ スポークアカウント側のVPCフローログ。srcPortでDNSクエリログと照らし合わせを試みるが、該当ログなし 次に、ハブアカウントを見ていきます。 ハブアカウント側のDNSクエリログを見ると、上記と同時刻に同内容のDNSクエリが確認できるので、スポークVPCで発生したDNSクエリが、ハブVPCまで到達し、ハブVPC側で応答を返したと考えられます。以下がそのログです。 ハブアカウントのDNSクエリログ ハブアカウント側のVPCフローログも調べて行きます。スポークVPCからのUDP 53番ポート通信は発見できませんでしたが、該当時間帯に以下のログを発見しました。 ハブアカウントのVPCフローログ DNSクエリログのタイムスタンプと若干ずれがありますが、srcPortが一致(46161)していることから、同じ通信のことを指しているとみて間違いないでしょう。 srcAddrの10.0.34.254は、Route 53リゾルバ アウトバウンドエンドポイントのIPアドレス(のひとつ)です。スポークVPCで発生したDNSクエリは、Route 53リゾルバ アウトバウンドエンドポイントで一種のNATのようなものが行われてハブVPCにやって来たと推測できます。 dstAddrの10.0.34.129は、Route 53リゾルバ インバウンドエンドポイントのIPアドレス(のひとつ)です。ここまで到達して、Route 53による名前解決が行われたと考えられます。 以上の情報をまとめると、下図青色実線矢印の通信が確認できたことになります。 青色破線矢印の部分がどのように行われたか、ですが、VPC側のフローログを確認しても該当するログは発見できませんでしたので、AWSインフラ側を通る通信であり、ユーザ側(VPC)からは見えないようになっているのだと考えられます。 まとめ 本稿では、AWSサービス用VPCエンドポイントをひとつのVPCに集約したい場合のDNS名前解決アーキテクチャとして以下の4つを概観しました。 プライベートホストゾーンを使う案 DHCPオプションセットを使う案 スポークVPCにRoute 53リゾルバ アウトバウンドエンドポイントを置く案 Resource Access Managerでリゾルバルールを共有する案 また、第4案について、構築時のポイントを解説するとともに、DNSクエリの通信を追ってみた結果、通信の一部がAWSインフラ側を通っていると考えられることを示しました。 本稿の内容がDNS設計のお役に立てば幸いです。

本記事では、Catoクラウドを運用するにあたって、特に知っておくべきIT用語をピックアップして解説していきます。 Catoクラウドの運用においては、多くのネットワーク・セキュリティに関する専門用語が登場します。 これらの用語を知識として持っている方も多いかと思いますが、具体的にCatoでどのように扱われているか、実例を交えながらご説明します。 今回は【ネットワーク編】と題して、ネットワーク用語を取り上げてご説明していきます。 今後【セキュリティ編】【応用編】を随時公開予定です。 そもそもSASEとは、Catoクラウドとは何か、が知りたい方は以下の記事をご覧いただければと思います。 ・ 世界初のSASEプラットフォーム Catoクラウドとは？ – TechHarmony (usize-tech.com) それでは早速、用語解説を始めていきます。 パケット パケット(Packet)とは、データ転送において、効率よくデータを送るために小分けした単位のことです。 Catoでは、パケットがネットワーク上できちんと転送できているか、パケットロス率としてモニタリングできます。 ネットワーク運用で起こりうるケースとして、通常はスループットに比例してパケット数も増えるものですが、スループットは低いがパケット数が多いケースがあります。 小さなパケットを大量に送信している状態です。 この状態のとき、ルータやスイッチなどの性能制限によって、一定時間に処理できるパケット数に上限があり、期待した性能が出ないことがあります。 パケットロスと似た用語に、Catoではディスカードがあります。 ディスカードは、拠点の最大帯域を超えた通信が発生し、Socketがパケットを破棄したときに発生します。 ディスカードが多い時には、後程解説するスループットと合わせて最大帯域の増速をご検討いただければと思います。 トラブル時など性能グラフを見るときは、スループットだけでなくパケット数やディスカードも確認ポイントとなります。 フロー フロー(Flow)とは、ある特定のデータ通信の流れを指します。 これは、特定の送信元と受信先の間でやり取りされる一連のパケットを意味します。フローの具体的な要素としては、IPアドレス / ポート番号 / プロトコルの情報で構成されています。 Catoでは、フロー数のモニタリングも可能になっています。 また、ホストごとにもフロー数を見ることができ、特定のホストだけが異常な値を検出している場合にはセキュリティインシデントが発生している可能性も考えられます。 そういった調査観点でもフロー数をモニタリングすることは重要と言えます。 従来のネットワーク機器では、フロー数に比例してメモリを利用しています。ネットワーク機器上で、フローごとにNATや動的なFWルールの管理をしているため、機器のメモリ量に依存して同時に通信可能なフロー数に上限があります。 ただし、Catoではソフトウェアによってこれらの機能を実現しスケールアウトしています。Catoでは実質的なフロー数の上限は存在していないとも言えます。 トラフィック・スループット トラフィック(Traffic)とは、回線・ケーブルを流れるデータやその総量のことを言います。 また、トラフィックと近しい言葉に、スループット(=帯域)があります。 トラフィックがデータ総量であるのに対して、スループットは単位時間あたりに流れるデータ量のことを言います。 一般的なモバイル通信におけるトラッフィクの平日の一日の推移としては、お昼時間帯や帰宅時間帯がピークになり、深夜から早朝にかけた時間帯が少ない傾向にあります。 また、企業においては、勤務開始の午前9時前後がピークになった後なだらかになり、お昼時間帯には再度Youtubeなどへのアクセスが増えるためやや上昇、勤務終了以降の18時ごろから段々と少なくなるという傾向にあります。 さらに、回線・ケーブルごとに利用可能な最大帯域が決められています。 これは、ISPとの契約時に回線ごとに決めるもので、最大帯域を大きくするほど費用もそれに応じて高くなります。 最大帯域を超えると、パケットの破棄や通信遅延が発生してしまうため、想定される帯域と予算を天秤にかけながら、ネットワーク設計者は契約帯域を決定する必要があります。 Catoクラウドでは、スループットをモニタリングできます。 通信が不安定になった際には、こちらのグラフで最大帯域を超過していないか確認いただくのも1つの切り分け方法と言えます。 スループットが最大帯域に張り付いているような状況の際には、契約帯域の増速をご検討いただければと思います。 QoS QoS（キューオーエス）とは、「Quality of Service」の略称で、日本語では「サービス品質」と訳されます。 インターネットや社内ネットワークなどで、データを送受信する際の品質を確保するための仕組みです。 QoSは、重要なデータが遅延したり止まったりしないように、どのデータを優先して送るかを決めて品質を確保します。 通常、回線の最大帯域を超えるトラフィックが発生すると、通信機器で遅延やパケットの破棄が発生します。 このような問題を解決する仕組みがQoSです。QoSには優先制御や帯域制御といった制御の種類があります。 優先制御であれば、例えばWeb会議のような即時性が求められる通信に対して優先度を高く設定することが多いです。 一方で、メールのような急がない通信では、優先度を低く設定することがあります。 この制御によって、Web会議の快適な通信を実現できます。 CatoクラウドでもQoSの仕組みが導入されています。詳細を知りたい方は、以下の記事をご覧ください。 ・ CatoクラウドのQoSについて – TechHarmony (usize-tech.com) ルーティングテーブル ルーティングテーブルとは、主にルータやL3スイッチなどのネットワーク機器がデータをどこに送るかを決定するために使用するテーブルのことです。 また、ネットワーク機器に限らずPCやサーバのようなIPアドレスで通信する、ほぼ全ての機器がルーティングテーブルを持って通信しています。 例えば皆さんお使いのPC上で、Windowsであれば、コマンドプロンプトで route print というコマンドを打てばルーティングテーブルを見られます。 ルーティングテーブルは、基本的には次の要素で構成されています。 • 宛先IPアドレスもしくはサブネット：最終的なデータ転送先のIPアドレスもしくはサブネット。 • ゲートウェイ：データが次に送られる中間地点のIPアドレス。 • 出力インターフェース：データが送信されるネットワーク機器のポート • メトリック：ルートの優先順位を示す値。小さいほど優先度は高くなる。 Catoに限らず、ルーティングテーブルはネットワーク構成を考えるうえで、まず最初に検討を始める部分と言えます。 DHCP DHCPは、「Dynamic Host Configuration Protocol」の略称で、ネットワーク管理プロトコルの一つです。 ネットワーク内の機器に自動的にIPアドレスを割り当てる際に主に使用されます。 DHCPはIPアドレスの他、IPアドレスのサブネットマスク、ネットワーク内で利用可能なDNSサーバのIPアドレス、外部ネットワークとの出入り口であるデフォルトゲートウェイのIPアドレス、割り当てられたアドレスのリース期間（使用期限）などの情報を通知します。 DHCPの利点は、機器利用者が手動で設定することなく、ネットワーク管理者が適切な設定を自動で適用できることです。 DHCPは、ネットワーク管理者にとって、IPアドレスの管理負担軽減のため有効なプロトコルとなっています。 ドメイン名・FQDN ドメイン名とは、ネットワーク上に存在するコンピュータやネットワークを識別するための名前のことです。 コンピュータやネットワークを識別する際、IPアドレスが利用されますが、単なる数字の羅列のため人間が覚えづらく識別しづらいです。 そのため、識別しやすいように、文字・記号を組み合わせたドメイン名をつけることができます。 例えばGoogleであれば、「www.google.co.jp」にアクセスします。 上図のように、ドメインは実世界の住所表示のように広い領域を指す名前から順に範囲を狭めていく階層構造になっています。 各階層の識別名を「.」で区切って表記されています。 一番右が最上位階層で、左に向かって階層が下がっていきます。 それぞれ右からトップレベルドメイン(jp)、セカンドレベルドメイン(co)、サードレベルドメイン(google)呼ばれます。 また、特に実際にアクセス先となる「www.google.co.jp」は「FQDN」（完全修飾ドメイン名）とも呼ばれます。 なお、Catoでは、FWルールを設定する際、ドメイン名とFQDNを区別して設定する仕様になっています。 仮にgoogle.co.jp配下のサブドメインをすべて制御したい場合はDomainを選択、www.google.co.jpを完全一致で個別に制御したい場合にはFQDNを選択します。 このように、Catoに限らず用語ごとの設定仕様をよく確認することも実際の設定作業において重要になります。 DNS DNSとは、「Domain Name System」の略称で、上記で説明したドメイン名とIPアドレスの対応関係をネットワーク上で管理しているシステムのことです。 外部からのドメイン名の問い合わせ解決するサーバをDNSサーバと呼びます。 反対にDNSサーバへ問い合わせするコンピュータをDNSクライアントもしくはDNSリゾルバと言います。 また、ドメイン名とIPアドレスの対応関係をサーバへの問い合わせによって明らかにすることを「名前解決」と呼びます。 ドメイン名から対応するIPアドレスを求めることを「正引き」、逆にIPアドレスからドメイン名を割り出すことを「逆引き」と呼ばれます。 ネットワーク設計において、特に社内ネットワークなどでFQDNを使った通信がある場合には、どのDNSサーバへ問い合わせするかを意識して設計することが必要です。 まとめ いかがでしたでしょうか。 すでに理解できていた用語もあれば、人によってはあいまいに理解して誤用していた用語もあったのではないでしょうか。 本記事では、ネットワーク設計・運用において特に重要な用語を取り上げています。 Catoクラウドの初期設定や障害調査で用語の意味が理解できない場面で、ぜひ本記事に立ち戻ってご活用いただければ幸いです。 今後続編として、【セキュリティ編】【応用編】の投稿も予定しています。

こんにちは、SCSKの齋藤です。 今回はAWSサービスのモックを作成し、プログラムをテストする方法の簡単な例をブログにしました。   モックとは？ ソフトウェアテストを行う際に、代用する下位モジュールスタブの一種です。 プログラムを作成した際に、作成したプログラムから別のモジュールを呼び出したりする際に、別のモジュールの代用品として理想的な値を返すようなオブジェクトです。 例えば、AWSリソースを操作するようなLambdaのソースコードをテストする場合、AWSリソースの部分を代用品としてモックを使うことで、ソースコードが正しく動作するかをテストできます。   AWSのモックツール 代表的なものとして、motoがあります。 Moto: Mock AWS Services — Moto 5.0.12.dev documentation docs.getmoto.org これを用いると、開発環境のPC上などで擬似的にAWSリソースを作成することができます。 全てのAWSリソースは網羅されていないらしいのですが、Lambdaと連携されるような代表的なサービス（S3、SQS、DynamoDB、STSなど）は、含まれております。   motoを使ってPythonのテストをしてみた！ 今回は実際にmotoを使ったモックによるテストを行ってみます。 今回私が検証した環境は下記になります。 マシン：Mac Book Pro IDE：Visual Studio Code 仮想環境構築 今回は、プログラムを実行するための仮想環境から構築していきたいと思います。 仮想環境構築の前に、プロジェクトフォルダの作成を行います。 PC上のどこでも良いので、空のプロジェクトフォルダをまず作成します。中身は何も作成しません。   その次に、ターミナルを開いて、下記コマンドを入力し、仮想環境をPython３代で作成します。 仮想環境名は各自で命名してください。（今回は、myvenvで作成しました。） $ cd プロジェクトフォルダ名 $ python3 -m venv 仮想環境名   仮想環境を構築後、下記コマンドで仮想環境をアクティベートします。 ・Linux・Mac $ source 仮想環境名/bin/activate もしくは、 $ . 仮想環境名/bin/activate ・Windows $ .\仮想環境名\Scripts\activate 仮想環境に切り替わったため、Pythonのバージョン確認をします。 (仮想環境名)$ python -V 先頭に仮想環境名が付与され、Python３代がインストールされているのを確認できます。 そのまま、仮想環境にパッケージのインストールを行います。 今回インストールするのは、AWS SDK for Pythonであるboto3、モックツールのmoto、Pythonのテストツールのpytestの３点です。 pip install boto3 pip install moto pip install pytest あくまで仮想環境上でのインストールなので、仮想環境を閉じれば、これらのツールは使えません。 VSCodeでのフォルダ・ファイル作成 VSCode上で、先ほどのプロジェクトフォルダを開きます。 まだ空のフォルダしか作成されていないので、その中にさらにフォルダとファイルを作成していきます。 今回は、下記画像のようなフォルダ構成とすることを目標とします。 このフォルダを実現するために、新たに作成するフォルダは「 src 」フォルダと「 tests 」フォルダです。 それ以外のフォルダについては自動で作成されます。 srcフォルダとtestsフォルダ内で作成するファイルをそれぞれ解説いたします。   srcフォルダ app.py メインのソースコードをこのファイルに書きます。 boto3を用いて、S3のバケットの情報を取得して、返却する処理を実行します。 今回は簡略的に、取得したバケットの1つ目の情報のみを返却します。 boto3でのS3へのリクエストやレスポンスの形は、boto3のドキュメントを参照してください。 https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/s3/client/list_buckets.html import boto3 def list_bucket(): s3=boto3.client('s3') response=s3.list_buckets() bucket_info=response['Buckets'][0] return bucket_info   testsフォルダ 本フォルダはテストに必要なファイル類を定義します。 __init__.py テスト対象のファイルがsrcフォルダにありますが、これをtestsフォルダのファイルが読み込めるようにしなければなりません。 そのため、testフォルダのファイルにパス情報を渡す必要があります。 その処理を、下記のコードで実現します。 import os import sys sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..', 'src'))) 上記コードで何をしているか内訳を見てみると、 1. os.path.dirname(__file__)・・・開いているファイル（__init__.py）のディレクトリ名を取得します。 （/Users/usename/Desktop/sample-project/tests） 2. os.path.join()関数により、1で取得したディレクトリに、”..”と”src”という文字列を連結します。 （/Users/usename/Desktop/sample-project/tests/../src） 3. os.path.abspath()関数により、2で連結したパスを正規化します。 （/Users/usename/Desktop/sample-project/src） 4. sys.path.append()関数により、3で正規化されたパスをpytestに渡しています。   conftest.py このファイルが本記事の要である、モックをしている箇所になります。 環境構築の際にインストールしたmotoから、mock_awsというツールをインポートしています。 このmock_awsというツールが、ローカル上で、仮想的なAWS環境を実現してくれます。 この仮想的な環境に、「test_bucket」という名前のS3バケットを作成します。 import pytest from moto import mock_aws import boto3 @mock_aws @pytest.fixture def setup_s3(): with mock_aws(): s3=boto3.client('s3') s3.create_bucket( Bucket='test_bucket', CreateBucketConfiguration={ 'LocationConstraint': 'ap-northeast-1', },) yield s3 test_app.py これまで作成したファイルを元に、実際にテストを行うファイルです。 テストの関数に、conftest.pyのsetup_s3関数を継承させます。 これにより、このテストコードはsetup_s3関数内のモックしたS3を使うことができます。 この状態で、テスト対象である、srcフォルダのapp.pyのlist_bucket関数を実行します。 そして、モック化した際に「test_bucket」という名前でS3を作成しているので、その名前が取得できているのかをassert文で評価します。 import app def test_list_bucket(setup_s3): response=app.list_bucket() assert response['Name']=='test_bucket' テストの実行 VSCodeのターミナルを立ち上げて、下記コマンドを入力します。 python -m pytest テストが合格してます！ これによりモック化して作成したS3バケット「test_bucket」の情報を、正しく取得できたことを確認できました。 モックしないとどうなるか？ 今回conftest.pyでモックを作成しました。 しかし、それを作らずにテストした場合は、環境上にセットされているAWS CLIの情報を元に、実際にAWS環境にアクセスされてしまいます。 大規模な開発などの場合、まだAWS環境が用意されていないが、Pythonのソースコードを開発しなければならない場合などはあり得ます。 そうした場合、AWS環境に接続せずとも、正しく動作されていることをテストするには、モックというのがどうしても不可欠になりますね。 そもそも、単体テストというのは、作成したプログラム自身が正しいかどうかを確認するプロセスのため、それ以外のものについては正しい値が返却されるという想定で、モックを作って実施するのは当然かと考えられます。 実際にAWSリソースへのアクセスをしてプログラムが正しく動くかどうかは、機能テストなどの段階で検証するため、単体テストでは適切にモックを使うことを意識すると良いと思います。 まとめ 今回はPython上で、AWSリソースのモックのやり方を簡単に紹介しました。 motoは、大変便利なツールですので、単体テストを行う際はぜひ使うようにしましょう！

はじめに Cato クラウドを利用のお客様から、ときどき次のようなお問い合わせが来ることがあります。 Web ページ内の動画を再生できない Web ページは開けるが正常に表示されない Cato クラウドに接続しなければ正常に Web ページが表示されるのであれば、上記のような問題は Cato クラウドによって引き起こされていると考えられます。 このような場合、ブラウザのデベロッパーツールを利用すればお客様自身で素早く解決できる可能性がありますので、そのトラブルシューティング方法をご紹介します。 トラブルの原因 Cato クラウドに接続しなければ正常に Web ページが表示されるのに、Cato クラウドに接続するとおかしくなるという問題が起きた場合、お客様自身で Web ページへのアクセスに関するイベントを確認し、Internet Firewall で許可したり TLS Inspection をバイパスしたり、他にもいろいろと試されるのですが、解決できずにお問い合わせいただくことがあります。 表示がおかしくても Web ページ自体は開けているのであれば、その Web ページへのアクセスは Cato クラウドによって制限されることなく行えていることを意味します。しかし、表示がおかしくなるということは、その Web ページから参照されている他の Web サイトへのアクセスがブロックされている可能性があります。 世の中の多くの Web ページでは、そこにアクセスしたとき、ブラウザのURL欄に表示される FQDN (ドメイン名) 以外の Web サイトへのアクセスも行われ、JavaScript、CSS、画像や動画、その他リソースの読み込みが行われます。それらの読み込みがブロックされると、結果として Web ページ内の一部が表示されない、レイアウトが崩れる、一部機能が動作しないといった事象に繋がります。 例として、弊社の Web ページ (https://www.scsk.jp/) を挙げてみます。この Web ページでは、サイト内検索機能を実現するために “c.marsflag.com” というドメインにアクセスして JavaScript などを読み込むようになっています。試しに Cato クラウドの Internet Firewall を用いてこのドメインをわざとブロックするようにしてみると、次の図のように検索機能が利用できなくなってしまいました。 ドメインをブロックしていない場合（正常な表示） 一部ドメインをブロックした場合（検索ボックスが無くなって使えなくなっている） こういった問題の原因は Web ページを見るだけではわかりづらく、お客様に通信のキャプチャを取得していただいたうえで弊社や Cato のサポートにて解析・調査しているのですが、ブラウザのデベロッパーツールを利用すればお客様自身で素早く解決できる可能性があります。 トラブルシューティング方法 ここでは一般的によく利用される PC 用ブラウザで、デベロッパーツールを利用してトラブルシューティングする方法を説明します。先ほどの例のまま “c.marsflag.com” ドメインをブロックしている状態で試しています。 Google Chrome の場合 Google Chrome では、キーボードの「Ctrl + Shift + I キー」を押すとデベロッパーツールが表示されます。あるいは、メニューの「その他のツール」の中から「デベロッパーツール」を選択して表示することもできます。 上図のブラウザ画面の右のほうの領域を占めているのがデベロッパーツールです。このうち「Network」タブがトラブルシューティングの肝です。デベロッパーツールを表示してから Web ページを表示 (F5 キーで再読み込み) すると、ブラウザと Web サーバとの間で行われる多数の HTTP 通信の内容が全て表示されます。 一覧では HTTP 通信の Name, Status, Type などが表示されていますが、Cato クラウドをお使いの場合は通信先のドメイン名が重要ですので、一覧のヘッダ部分を右クリックして「Domain」も選択して表示させるようにするのがお勧めです。 すると、”c.marsflag.com” というドメインへのアクセスで HTTP ステータスコード 403 のエラーとなっていることが一目でわかります。 この 403 エラーとなっている行を選択し、右クリックして “Open in new tab” を選択してその URL を別のタブで開いてみると、たしかに Cato クラウドのブロック画面が表示されました。 これにより、”c.marsflag.com” というドメインの URL へのアクセスが Cato クラウドによってブロックされていることがわかりましたので、あとはイベントログを確認しつつ、実際にブロックしている機能 (Internet Firewall など) のルールを変更すればアクセスできるようになります。Cato クラウドのブロック画面以外が表示されるようであれば、おそらく Web サイト側の問題の可能性が高いです。 また、Web ページが表示されるのが遅いという場合、デベロッパーツールの各行の「Time」を見ると、どのリソースへのアクセスでどれだけ時間がかかったのかわかります。Cato クラウドを使わない場合は素早く表示されるのに Cato クラウド経由だと遅くなるような場合には、時間がかかっているアクセスの URL を特定できれば、原因特定や改善にも役立ちます。 Microsoft Edge の場合 Microsoft Edge も Google Chrome と同様に、キーボードの「Ctrl + Shift + I キー」を押すか、メニューの「その他のツール」の中から「開発者ツール」を選択すれば、デベロッパーツールを表示できます。 表示が日本語化されていたり、ツールの名称が「Microsoft Edge DevTools」や「開発者ツール」となっていたりしますが、デベロッパーツールの利用方法や機能は Google Chrome とほぼ同じです。 Mozzila Firefox の場合 Mozzila Firefox もキーボードの「Ctrl + Shift + I キー」を押すか、メニューの「その他のツール」の中から「ウェブ開発ツール」を選択すれば、デベロッパーツールを表示できます。 見た目は Google Chrome などと異なりますが、同様に利用してトラブルシューティングを行えます。 まとめ 本記事では、ブラウザのデベロッパーツールを用いたトラブルシューティング方法の一例を説明しました。 Web ページの一部の表示がおかしいときのトラブルシューティングとして記載していますが、他の問題が起きたときもデベロッパーツールが役立ちますので、ぜひご活用ください！

Catoの運用支援をしていると「WEBサイトへ アクセスできなくて困っている 」という問い合わせをいただくことが多いです。 今回は、上記のようなトラブルが発生した際に CMAのEvents機能から切り分けを行う方法  をご紹介します。 画⾯は2024年7⽉時点のものです。 機能アップデート等で変わる場合がありますので、あらかじめご了承ください。 Eventsとは 「Events」は、Catoクラウド利用時のログが一元的に確認できる機能です。 基本的な操作方法は、以下の記事をご参照ください。 Catoクラウド Eventsの確認方法 CatoクラウドのEvents画面の見方、ログの絞り込み方について解説します。 blog.usize-tech.com 2023.08.22   注意！！Eventsに表示されない通信 Eventsの確認をする前に、以下の設定をしている通信はEventsに表示されませんのでご注意です。 トラブルが発生している通信が当てはまっていないかをまず確認ください。 １）Internet/WAN Firewall等のセキュリティルールの設定の際に[Event]の項目をTrackにしていない Trackにすることで、設定したルールにより許可もしくはBlockされた通信をEventsで確認できるようになります。 ２）BypassやSplit Tunnelを利用している通信 ３）Off-Cloudを利用した拠点間の通信 BypassやSplit Tunnel、Off-CloudでCatoを経由させていない場合に発生するトラブルは、Catoを経由していないためCato起因である可能性が低いです。利用しているネットワーク環境等の確認をまず実施ください。   トラブルシューティングの際によく使うField Eventsでのトラブルシュートは、主にフィルタリングを利用して問題に関連する通信を絞り出すことから始まります。 しかし、Eventsには多くのFieldが存在するため、問題が起きた際はどれを見ればよいの？という事態に陥ってしまうかもしれません。 以下に私がトラブルシューティングの際によく確認するFieldについて紹介します。 ※トラブルの内容にもよりますが、以下はWebサイトが見れない事象が起きた場合によく見ているFieldです。 Field名 内容 Action Catoの機能により実行された動作がわかる 例）Monitor、Allow、Block、Alertなど Sub-type Catoの機能。上記の[Action]がどの機能で実施されているのかがわかる 例）Internet/WAN Firewall、TLS、IPS、App Security Rule [Sub-type]のどのルールにマッチしているのかがわかる Category 通信がどのカテゴリに分類されているのかがわかる PoP Name 通信を行う際に入り口となるPoP名がわかる Source IP 送信元IPアドレス Source is Site or SDP User 送信元がSocket配下か、SDPユーザかがわかる Domain Name 通信先のドメイン名 Full Path URL 通信先のフルパスURL Destination IP 宛先IPアドレス Network Rule どのNetwork Ruleにマッチしているかがわかる Public Source IP トラフィックの送信元であるPoP によって割り当てられたグローバルIPアドレス Network RuleによりEgress IPにNATされている場合も表示される Source Site Socket配下の場合はSite名、SDPユーザの場合はユーザ名が表示される User Email 送信元ユーザのメールアドレス TLS Inspection TLS Inspectionで検査を行っているかがわかる 「1」の場合は検査済み、「0」の場合は検査なし 上記は、ざっくりとした説明ですが、すべてのFieldの意味については以下のCatoのKnowledgeサイトを参照ください。 https://support.catonetworks.com/hc/en-us/articles/5131416221085-Explaining-the-Event-Fields   Eventsを利用したトラブルシューティング手順 次に、実際にお問合せの多い「Webサイトにアクセスできない問題」を例に、Eventsでの切り分け手順について説明します。 問題が発生したらまず以下の手順で実際にトラブルシューティングを実施してみましょう。   手順①　Eventsでログを確認する前に以下の情報を事前に確認しておきましょう。 ・いつ：問題が発生した日時 ・どこで：Socket配下からのアクセス、もしくはリモートからのアクセスか ・誰が：送信元のIPアドレス、もしくはユーザ情報(メールアドレス) ・宛先情報：宛先IPアドレスやWebサイトのURL ・何の通信：プロトコルやポート番号、アプリケーション 上記を確認出来たらEventsを使ってトラブルシューティングを実施してみましょう。   手順②　どこから通信を行ったかを絞る Socket配下からのアクセスか、リモート(SDPユーザ)からのアクセスかがわかる場合は、初めに絞ってしまいましょう。 ・Socket配下からのアクセスの場合 [Network]>[Sites]から拠点を選択し、[Site Monitoring]>[Events]をクリック ・SDPユーザからのアクセスの場合 [Access]>[Users]からユーザを選択し、[User Monitoring]>[Events]をクリック ・上記が特に決まっていない場合 [Monitoring]>[Events] 上記のようにEventsはユーザ単位、Site単位で確認することが可能です。   手順③　問題が発生した時刻に絞る Eventsの右上にあるカレンダーボタンをクリックし、問題が発生した日時を絞り込みましょう。   手順④　宛先を絞る アクセス先をドメインもしくは宛先IPアドレスで絞りましょう。   手順⑤　Actionを確認 [Fields]からActionを選択し、対象の通信がBlockされていないか確認しましょう。 Actionの中にBlock以外の項目が複数ある場合があります。 今回はBlockのEventsを確認したいので、以下○枠の「⊕」をクリックしてさらに絞り込みましょう。   手順⑥　Sub-Typeを確認 手順⑤でBlockされていた場合、次にSub-typeからCatoのどの機能でBlockされているのかを確認しましょう。 上記の画像でいうと、通信をBlockしているのは、Internet Firewallだということがわかります。   手順⑦　Ruleを確認 手順⑥で、Blockを実行している機能が分かりましたら、どのルールでBlockされてしまったのかを確認しましょう。 これでBlockを実行しているルールが判明しました。 原因であるCatoの機能、ルールが確認できたらCMA側で設定変更を行い問題を解消しましょう。 原因別の対応例 EventsでBlockが確認できた場合 上記の手順でEventsからCatoの機能によるBlockが確認できましたら、アクセスができるように設定変更を行いましょう。 例として以下パターン別の対応例をご紹介します。 パターン１　Internet/WAN FirewallでBlockされていた よくあるのが、Internet Firewallで意図せずBlockされていたパターンです。 「通信が間違ったカテゴリに分類されていた」や「そもそも上位のルールでBlockされていた」といった事例が多いです。 解決方法としては上記の手順⑦にてBlockしているルールを確認し、それに合わせて設定の変更を行いましょう。 ▼ 上位のルールにブロックされていた 上記手順の⑦番で、どのルールによりBlockされていたのかを確認できたとします。 確認ができたら、上位に許可ルールを作成することで問題が解消します。 ▼間違ったカテゴリに分類されていた 上記手順の⑦番で、Blockしているルールの内容を確認し、通信が間違ったカテゴリに分類されていることがわかった場合。 対象のドメインのカテゴリを変更することで問題が解決します。 カテゴリ変更の方法につきましては、以下の技術ブログを参考ください。 Catoで業務通信がブロックされてしまう事象の解決策！～SWGで誤分類されたサイトを管理者で修正する機能～ Catoを使っていると、業務でアクセスするドメイン（URL）が誤ったカテゴリに分類され、通信できない！ということがあります。今回は、そんな問題が発生した場合の新しい回避策「カテゴリの手動修正」を紹介します。 blog.usize-tech.com 2024.02.22 上記のようにカテゴリの変更で解決する場合もありますが、Internet FirewallもしくはWAN Firewallで該当の通信を許可してしまった方が早くて確実です。 アクセスができなくて困っている場合は、まずはFirewallルールでの許可設定を行いましょう。   パターン２　IPSやAnti-MalwareでBlockされていた CatoのIPSやAnti-Malware機能によってBlockされていたというケースもあります。 Blockされていた通信が問題ないと判断できる場合は、Allow Listを作成することで問題を回避できます。 なお、Allow Listは[Security]>[IPS]の[Allow List]タブから作成できますが、Eventsの画面からでも作成が可能です。 例として、IPSでBlockされていた際にEvents画面からAllow Listを作成する方法について記載します。 手順①：「4.Eventsを利用したトラブルシューティング手順」で、IPSによるBlockを確認 手順②：表示されたEventsの「＋」をクリックして詳細を展開 手順③：詳細が展開されたら[Signature ID]をクリック 手順④：Allow Listの作成画面が画面右から展開されるので、環境に合わせて設定し、[Apply]をクリック Allow Listの作成手順は以上です。 ※Anti-Malwareの場合も同様の手順でAllow Listを作成できます。 Signature IDによっては、CMAからAllow Listを作成しても許可されない場合があります。 その場合はCatoのバックエンド側でホワイトリストに登録してもらわなくてはいけないため、Catoのサポートチームへ依頼してください。 EventsでBlockではなくMonitorと表示されていた場合 これまではEventsでBlockされていた(Catoの機能でBlockされていた)ケースについてご紹介しました。 しかし、Webサイトにアクセスできない状況なのに、Eventsで見ると通信はBlockされずにMonitorと表示されているケースもあります。 これは、宛先への通信はCatoを通過していることを表しており、宛先側で何かしらのアクセス制限がされている可能性があります。 そういった場合は、TLSインスペクションのBypass設定やCatoを迂回させる設定などをお試しください。 設定方法などの詳細につきましては以下の技術ブログを参照ください。 Cato経由でのWebサイト接続のトラブル例とその対処法 Cato経由でのWebサイトの接続トラブルについて、事例とその対処法についてご紹介します。 blog.usize-tech.com 2024.04.19   例外事例 上記のように、通信がMonitorと表示されているとEventsから原因を特定することは難しいですが、例外事例もあるのでご紹介します。   事例：Webサイトにアクセスすると「プライバシーが保護されません」ページが表示される どのWebサイトへアクセスをしても以下画像のように「プライバシーが保護されません」と表示されてしまうといった事例があります。 原因の一つとして、TLS Inspection機能を有効にしているにも関わらず、端末にCatoのルート証明書を導入していないことが挙げられます。 上記の事象が証明書のインストール有無が原因かどうかは、Eventsから特定することができますのでご紹介します。 TLS Inspection機能の詳細につきましては、以下の技術ブログをご参照ください。 CatoクラウドのTLS Inspection機能で躓く証明書の仕組み Cato クラウドでHTTPS通信のセキュリティ対策を行うためのTLS Inspection機能で躓くことの多いTLS証明書関連の仕組みや課題について解説します。 blog.usize-tech.com 2023.10.06 ▼確認手順 手順①：日時やドメイン情報などで絞り、アクセスしたWebサイトへの通信をEventsで表示させる 手順②：Actionを確認する ここでは、Block表示はありませんでしたが、Monitorの他にAlertがあるので「⊕」を押して絞ります。 手順③：Eventsの詳細を展開する Sub-typeがTLSであることがわかります。 Sub-typeがTLSの場合は、「TLS Error Description」からAlertとなった理由が確認できます。 実際に検証も行ってみましたが、端末にCatoのルート証明書が入っていない場合は「certificate unknown」と表示されます。 同様のEventsが確認できた場合は、Catoのルート証明書がインストールされていないことが原因の可能性があります。   まとめ 本投稿では、トラブル時のEventsの見方や対処法について一例をご紹介しました。 トラブルでお困りの方のお役に立てれば幸いです。 なお、弊社の FAQ サイトでは 、よくあるご質問やCato クラウドのアップデート情報を公開しておりますので、是非ご参照ください！

こんにちは、広野です。 最近、AWS Lambda 関数から AWS Elemental MediaConvert の API を呼び出そうとしたときに気付いたことを話します。API エンドポイントが変わっていました。いつから変わっていたのかわからないのですが。 そもそも MediaConvert って？ ひとことで言うと、動画をエンコードしてくれるサービスです。動画処理ソフトウェアができることに近いです。私は MP4 のデータをストリーミング可能な形式 HLS に変換する目的で使用しています。ユーザがアプリ UI からアップロードした動画データを自動的にエンコードするのに便利です。 What is AWS Elemental MediaConvert? - MediaConvert AWS Elemental MediaConvert is a file-based video processing service that provides scalable video processing for content ... docs.aws.amazon.com 変更点 本題です。 今現在の AWS Elemental MediaConvert のマネジメントコンソール画面です。左側のメニュー、矢印の位置に「アカウント」という設定があったのですが、無くなっていました。 実はこのアカウントの設定には、アカウントかつリージョン固有の MediaConvert API エンドポイントの URL が表示されており、API を呼び出すときにはその URL を使用しなければならない、という仕様がありました。 例えば AWS Lambda 関数 (Python) では、以下のようにエンドポイントを打ち込んでいました。 client = boto3.client('mediaconvert', region_name='ap-northeast-1', endpoint_url='https://xxxxxxxx.mediaconvert.ap-northeast-1.amazonaws.com' ) マネジメントコンソールからアカウントの設定が無くなったことを受けて AWS ドキュメントを確認したところ、以下のように DescribeEndpoints は不要になったと書いてありました。これがアカウントかつリージョン固有の API エンドポイントだったはず。 Note that DescribeEndpoints is no longer required. We recommend that you send your requests directly to the regional endpoint instead. Endpoints - AWS Elemental MediaConvert API Reference /2017-08-29/endpoints Operation ID: DescribeEndpoints 200 response The service can't process your request because of a p... docs.aws.amazon.com 結論 試してみたら、AWS Lambda 関数からの MediaConvert API 呼出は API エンドポイント指定 なし で動きました。 client = boto3.client('mediaconvert') 従来の方法で作成済みの AWS Lambda 関数が動くかは未確認です。過去に作成していたリソースを削除してしまったため。ですが互換性維持のため、動くのではないかと想像します。 まとめ いかがでしたでしょうか？ この変更についてアナウンスがあったのかわからず、変更に気付いたときは戸惑いました。 短いですが、本記事が皆様のお役に立てれば幸いです。

どうも、Catoクラウドを担当している佐々木です。 今回は Catoクラウドの「Header Injection」   について紹介します。   最近、Microsoft365やGoogleアカウントについて、許可していないアカウントを利用させないようにしたい、といった いわゆる「 テナント制御 」に関する問い合わせを多くいただきます。 Catoクラウド経由でテナント制御する際に利用する機能の一つ、それが「Header Injection」です。   画⾯は2024年7⽉時点のものです。 機能アップデート等で変わる場合がありますので、あらかじめご了承ください。 「Header Injection」を利用するためには、セキュリティオプションのCASBが必須になります。   テナント制御とは テナント制限とは、会社や管理者が許可したアカウントのみWEBサービスを利用できるようにすることです。 ※MicrosoftやGoogleで、会社のアカウントによるアクセスはOKだけど、個人アカウントでのアクセスはNG、を実現する機能です。   どうやってやってるの？ クライアントとインターネットの間にあるプロキシなどで、通信ヘッダーや認証プロセスを操作することで実現しています。 例： Microsoft365の場合 クライアント端末からAzure ADに対する認証の通信をプロキシ経由させます。 そのプロキシから送信されるパケットに許可対象の Azure AD テナントの情報を付与します（HTTPヘッダーとして付与）。 Microsoft365側での上記で挿入したヘッダーの値を参照することで、許可したテナントへのアクセスのみ許可され、 それ以外はブロックされるといった動作をします。      ※Catoクラウド利用者は、上記のプロキシ＝Catoクラウドと置き換えてください。 ※Microsoftの仕様については、以下の公式サイトを参照ください。   テナント制限を使用して SaaS アプリへのアクセスを管理する - Microsoft Entra ID 自社の Microsoft Entra テナントに基づいて、テナント制限を使用しアプリにアクセスできるユーザーを管理する方法。 learn.microsoft.com   つまり、プロキシ（＝Catoクラウド）で実施しているのは、ヘッダーを挿入することです。 ブロックする/しないなどの「アクセス制御」は、 Microsoft365など WEBサービスがやっています。 Catoクラウドがブロックしている、と誤解される方が多いのですが、 Header Injection機能では一切アクセス制御はしていません！！！   Catoクラウドでの実現方法 Catoクラウドを経由してテナント制御する場合、以下の機能を利用します。   Header Injection機能 設定した条件（アプリケーションやアカウント等）にマッチする通信が発生した際、パケットのヘッダーに任意の文字列を挿入します。 アクセス先のWEBサービス側で、任意の文字列がヘッダーに含まれるパケットのみ許可し、それ以外をブロックするなど、 といった制御をさせることで、テナント制御を実現します。   TLSインスペクション トラフィックを検査するためTLSインスペクションを有効にする必要があります。 TLSインスペクションが有効でも、Bypassしている通信に対して「Header Injection機能」は動作しません。   その他 過去のブログ記事「 Catoクラウドでアプリケーションを制御するには 」でも紹介があった通り、 Catoクラウドの「Application Control」機能でもテナント制御は可能です。 気になる方は上記記事をご確認ください。   動作イメージ 例えば、Microsoft365へのテナント制御を実施する場合、以下のような動作をします。 ① ユーザーがMicrosoft365にアクセスし、サインインを試みます。 ② トラフィックは「Catoクラウド」に送られ、CMAで設定したヘッダー（ Microsoft 365が指定したもの） を挿入します ⇒これがHeader Injectionの機能です。 ③ Catoクラウド経由でトラフィックをMicrosoft365に転送します。 ④ Microsoft365で、ヘッダー値を検索します。 ⑤ 正しいヘッダー値を持っている場合、アクセスが許可され、正しくない場合、アクセスに失敗します。   Microsoft365へのテナント制御をやってみた 今回は、問い合わせが多い「Microsoft365へのテナント制御」をテストしてみました。   注意事項 ここから読み始めた方もいるかもしれないので再掲します。 Catoクラウドで実施しているのは、ヘッダーを挿入することです。 ブロックする/しないなどの「アクセス制御」は、 Microsoft365など WEBサービスがやっています。 Catoクラウドがブロックしている、と誤解される方が多いのですが、 Header Injection機能では一切アクセス制御はしていません！！！   テスト条件 テスト内容：Microsoft365について、アカウントAのアクセスはOKで、アカウントA以外はアクセスさせない 端末：Windows 11 Catoクライアント：5.10.34.2284   Catoの設定 CMAで「 Security 」＞「 Application Control 」＞「 Header Injection 」から以下のように設定します。 ▼「Header Injections」の有効化 左上のHeader Injections Enabledをクリックして、バーが緑色になるようにしてください。   ▼ルール1（Microsoft365_テナント制御1） ログインを許可したいアカウントを定義 しています アプリケーションは「 Azure Active Directory 」を選択してください 「Injected Headers」で以下の設定をしてください Header Name： Restrict-Access-To-Tenants 　／　Header Value： Microsoftアカウントのprimary domainを入力 Header Name： Restrict-Access-Context 　／　Header Value： Microsoftアカウントのテナント IDを入力   MicrosoftアカウントのテナントIDなどがわからない方は、以下を参考に調べてみてください。 ※管理者権限がないと確認できません。 Microsoft 365 テナント ID を見つける   ▼ルール2（Microsoft365_テナント制御2_コンシューマーアカウントをブロックする設定） コンシューマー向けのアカウントをブロックするための設定です。 アプリケーションは「 Microsoft Live 」を選択してください 「Injected Headers」で以下の設定をしてください Header Name： sec-Restrict-Tenant-Access-Policy 　／　Header Value： restrict-msa   最後に設定を保存して完了です。 ※TLSインスペクションを有効にしていない場合、有効化してください。   Catoのバージョンアップに伴い、アプリケーション名などが変わる可能性がございますのでご注意ください。 ヘッダー値や動作は、Microsoftの仕様に依存しますので、思うように動作しない場合、Microsoftの仕様をご確認ください。   テスト結果 許可しているアカウントでのアクセスは許可されましたが、許可していないアカウントでのアクセスは以下のようにブロックされました。   ▼許可していないアカウントでアクセスした結果   ▼コンシューマー向けアカウントでアクセスした結果 　※ちょっと画面が違ったので一応共有します。 まとめ 意外と簡単な設定でテナント制御ができました。 挿入するヘッダー値は変わりますが、GoogleやSlackなど他のアプリケーションでも同じように設定することで制御可能です。   ・Catoクラウドでもテナント制御が可能 ・Microsoft365、Gmail、Slcakなど多くのアプリケーションに対応 ・Catoクラウドではヘッダーを挿入しているだけで「実際の振る舞い」はWEBサービス側に依存 ・Header Injectionだけではなく、TLSインスペクションも有効しないとダメ   上記以外の情報についても弊社の 「Catoに関するFAQサイト」 に多数情報ございますのでご参考にください。 よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Cato SASE Cloud Platform. powered by SCSK cato-scsk.dga.jp   最後に、SCSKではPoCから導入、運用まで幅広くCatoに関する支援を行っております。 本番構成への移行を見据えたPoC構成や、PoCでつまづきやすい点のサポートなど、豊富な導入実績を基にご支援いたします。 ぜひお声がけください！

AWS JAPAN APNブログ にて 2024 Japan AWS Ambassadors / 2024 Japan AWS Top Engineers / 2024 Japan AWS Jr. Champions の受賞者が発表されました。 今年度は、SCSKより過去最多の表彰者が選出されました！SCSKから選出された計10名の社員を今回はご紹介します！ 2024 Japan AWS Ambassadors 「 2024 Japan AWS Ambassadors 」は、2024 Japan AWS Top Engineers のうち、卓越した技術力を持ち、社内外への情報発信やその深い専門知識を基に、アマゾン ウェブ サービス（AWS）のソリューションアーキテクトと協力してお客様のAWS導入・活用にあたり大きく貢献・支援したメンバーが選出されます。（各社最大2名まで） SCSKからは広野と木澤の2名が選出されました。 広野 祐司 ソリューション事業グループ クラウドサービス事業本部 クラウドサービス第二部 第二課 ソリューション事業グループ ソリューション事業グループ統括本部 統括部 タレントマネジメント第二課 Ambassador 3 年目となりました。 私は社内クラウド技術者育成や、社外のお客様または社内のエンジニア向けの AWS 技術支援を担当しております。AWS サーバーレスサービス、React によるモダン Web アプリケーション開発が得意領域です。 社員向けクラウド学習用 e-Learning サイトの開発、コンテンツ作成をしながら、その e-Learning サイトを学習教材に仕立て、DevOps、CI/CD、アジャイルソフトウェア開発を体験できる研修も提供しております。 当社 AWS 認定資格数はちょうど 2,500 を超えたところです。知識的な育成だけでなく、人材育成施策の過程で得た実戦経験を社内外への技術支援に活用するサイクルも徐々にできるようになってきたと感じています。 今年度当社 Top Engineer は増えましたが、今後継続的に Top Engineer や次期 Ambassador の育成サイクルを回していけるようになれたらと思っています。 引き続き、どうぞよろしくお願いいたします。 ★ 広野のTechHarmony記事一覧は こちら 木澤 朋隆 ソリューション事業グループ クラウドサービス事業本部 事業推進部 事業企画課 ソリューション事業グループ クラウドサービス事業本部 クラウドサービス第二部 第二課 2021年からJapan AWS Ambassadorsを拝命しております。 自身の活動方針として「クラウドに強いSCSKの実現」と「それをアピールすることによる当社のプレゼンス向上」を挙げ活動してまいりました。それに伴い立ちあげた本エンジニアブログTechHarmonyも記事数が500を超え、認知度が高まってきていることを嬉しく思います。 私は新卒で入社以来、お客様先での常駐やWebシステム開発のインフラ構築で幅広い経験を積んでまいりました。2013年にAWS上での大規模構築案件を担当したことでクラウドサービスの将来性を感じ、2016年よりクラウド提供部署に異動して現在に至ります。 現在の業務は、クラウドアーキテクトとしての案件支援やマーケティングのリーダーとして各種イベントの企画や運営・登壇、社内外向けの情報発信などを担当しております。 なお表彰制度は活かしてこそと思っておりコミュニティイベントにも参加や発表を行い積極的に交流するようにしておりますが、そこでの交流は人生の糧になっていると感じております。皆様ありがとうございます。 そうした活動を通じ、今後も「クラウドに強いSCSK」の実現に邁進していく所存です。 よろしくお願いします。 ★ 木澤のTechHarmony記事一覧は こちら   2024 Japan AWS Top Engineers 「 2024 Japan AWS Top Engineers 」は、AWSパートナーネットワーク(APN) 加入のAWSパートナー企業に所属し、AWSに関する高い技術力を発揮した活動を行ったメンバーが選出されます。 8つのカテゴリ（Services、Software、Networking、Security、Analytics、Database、Machine Learning、SAP on AWS）が用意されており、 SCSKからはServicesで広野/木澤/寺内の3名（※）、Databaseで丸山/潮の2名、Analyticsで安彦/三上の2名、Nerworkingで貝塚の1名が選出されました。 ※広野/木澤は前項で紹介済みのため本項では割愛 （2024 Japan AWS Top Engineers　SCSKメンバー8名）   ★ 2024 Japan AWS Top Engineers (Services) 寺内 康之 ソリューション事業グループ　クラウドサービス事業本部　クラウドサービス第二部　第二課 四半世紀以上前にネットワークエンジニアとして社会人になり、サーバエンジニアを経由して現在AWSを専業でやっております。 2007年、EC2が発表され、あまりに簡単にLinuxマシンが手に入ることに感動して以来、AWSのファンです! 現在は、お客様の内製を技術面、教育面で総合的に支援する「テクニカルエスコートサービス」を提供しています。こちらはアプリケーションから基盤およびネットワークなど幅広く、AWSの範疇にとどまらなず幅広く相談を受け付ける総合IT支援サービスとなっておりますので、是非お気軽にお問い合わせください。 今回、AWS Top Engineersとしてご評価いただいたことは、長年”AWS愛”を育んできた私としてとても嬉しく光栄に思います。チームのみなさまと協力し得られた成果ですので、引き続きチーム力で貢献したいきます。 さて、個人的にはSF小説やアニメが大好きで、わりと妄想したり夢見がちです。VUCAの時代、SFプロトタイピングなどもやってみたいと常々思っております。関係の方々、よろしくお願いします。 ★ 寺内 のTechHarmony記事一覧は こちら   ★ 2024 Japan AWS Top Engineers (Database) 丸山 祐佳 ソリューション事業グループ　クラウドサービス事業本部　クラウドサービス第二部　第三課 SCSKに入社以来、MySQLを中心としたDB技術者として、設計・構築をはじめ、サポートやチューニングサービス、研修講師などを担当していました。 その後、当社ERPパッケージであるProActiveのデータベースをOracle DBからMySQLへ移行するプロジェクトをきっかけとし、AWS環境への異種DBマイグレーションサービスを立ち上げ、PostgreSQLやAmazon Auroraへの移行案件に携わり、現在に至ります。 この度、昨年に続き2024 Japan AWS Top Engineers (Database)にも選出いただき大変光栄です。異種DB移行は、技術難易度やその複雑性から決して一人でできるものではなく、チームとして協力しあってこそ成功するサービスです。今回の選出についても、これまで異種DB移行に携わってきた方々のおかげです。大変感謝申し上げます。 おかげさまでお客様からの相談も多く少しずつ実績も増え、また移行後も快適にDBを利用できるようチューニングなどのサービス拡大を行っております。 AWS環境におけるDB分野のサービスを継続的に進化・拡大することで、今後もよりAWSの普及に寄与できるよう努めて参りたいと思います。 ★ 丸山 のTechHarmony記事一覧は こちら 潮　雅人 ソリューション事業グループ　クラウドサービス事業本部　クラウドサービス第二部　第三課 新卒でSCSKに入社して以来、5年ほどMySQL関連の設計構築や性能問題対策を担当していました。その後、ニューヨークに1年半、ジャカルタに8か月ほどの駐在を経て、現在はお客様の異種データベースマイグレーションプロジェクトをご支援し、Oracle DatabaseからAmazon Auroraへの移行案件等に携わってきました。 異種データベース移行は、移行する際の規模の予測が難しく、かつ移行前後のデータベース両方の知識が必要とされるため、ハードルが高いと考えられ、実際ハードルは高い傾向にあるのですが、運用費用節減やクラウド活用による柔軟性の確保等、得られるメリットも大きい活動です。 今回Top Engineersの選出に際しては、この異種データベース移行の活動によるお客様のビジネスへの貢献、また、海外でのAWS利用拡大に向けた活動がご評価頂けたものと考えております。 今回のTop Engineers選出をきっかけとして、より高いレベルでのAWS上DBの理解と利用普及に貢献して参ります。 ★ 潮 のTechHarmony記事一覧は こちら   ★ 2024 Japan AWS Top Engineers (Analytics) 安彦 洋樹 ソリューション事業グループ　クラウドサービス事業本部　データ＆ＡＩソリューション部　第一課 SCSKに入社以来、アプリケーション開発する部署と基盤を構築する部署を渡り歩き、主にDA/DBAとして様々な大規模プロジェクトを経験してきました。 その中でオンプレ環境でDWHシステムを構築するプロジェクトも何度か経験しており、面白い領域だなぁと思っていたところ、2018年にAmazon Redshiftを中心とした顧客情報基盤構築プロジェクトでアーキテクトリーダを担当したことをきっかけに、AWSのAnalytics系のサービス(Amazon Redshift、Amazon QuickSight、AWS Glue等)を使ったデータ活用システム構築のプロジェクトを主に担当することになりました。 そこで培った経験を活かし、2023年には「クラウドデータ活用サービス」を開発し、そのサービスを使って現在はAWS様主催のセミナーに登壇させて頂いたり、データ活用システムの構築プロジェクトを数多く推進しております。 このような活動をAWS様に評価頂き、2024 Japan AWS Top Engineers (Analytics) に選出して頂きました。 これからも、AWSのAnalytics系のサービスを活用して、お客様のDX推進やデータドリブン経営の支援に努めていきたいと思います。 ★ 安彦 のTechHarmony記事一覧は こちら 三上 晶子 産業事業グループ　産業ソリューション第二事業本部　エンタープライズソリューション第二部　第二課 新卒でSCSKに入社し、今年で入社6年目になります。 入社当初はデータベース専門部隊としてOracleやMySQLのデータベース構築案件を担当しており、その後はデータ活用案件と並行して、SCSKクラウドデータ活用サービスの企画からプロモーションを担当しました。現在はInformaticaの主管部署として、引き続きデータ活用案件やサービス開発に従事しております。 この度、2024 Japan AWS Top Engineers (Analytics)に選出いただきました！これまでのYouTubeを利用したプロモーション活動やセミナーでの登壇が選出に繋がったと考えております。YouTubeやセミナーなど表に見えているのは私一人ですが、その裏には多くの優秀な技術者がおり皆様にたくさんの支援をいただいております。大変感謝申し上げます。 現在はInformatica部隊ではありますが、AWSとの親和性を活かしAWS部隊との懸け橋となりビジネス拡大に貢献してまいります。 ★2024/7/26に大阪でデータ活用に関するセミナーを実施します！ぜひ興味のある方はご参加ください★ トヨタ紡織様事例から学ぶ、社員を幸せにするDXの第一歩 現在、DX（デジタルトランスフォーメーション）やデータ活用という言葉をよく目にしますが、多くの企業が「どのようにDXに取り組めば良いか分からない」「データ活用を進めたいが、何をしたら良いか分からない」といったお悩みを抱えています。 こうした... www.scsk.jp ★ 三上 のTechHarmony記事一覧は こちら   ★ 2024 Japan AWS Top Engineers (Networking) 貝塚 広行 ソリューション事業グループ　クラウドサービス事業本部　クラウドサービス第二部　第二課 新卒でSCSKに入社後、数年間は自社データセンターをはじめとする各種ネットワークの設計・構築・運用を担当していました。その後、Linuxやサーバ仮想化技術の調査・開発、自社クラウド基盤（IaaS）の設計・構築・運用を経て、AWS関連の開発にも携わるようになりました。 さらにその後の約4年間は他業務を経験し、1年ほど前からはAWSの内製化・技術支援を提供するテクニカルエスコートサービスに従事しています。 AWSに関わること自体に数年のブランクがあった上、ネットワークについてもさらに長いブランクがあったため、今回のJapan AWS Top Engineers (Networking)受賞には驚いています。 手探りの中で、AWSのアーキテクチャ関連ドキュメントを読み込み、明確には分からないことを細かい部分まで検証し試行錯誤したこと、それらを社内外に発信できたことが選出につながったのだと思います。 今後も経験と実績を積み重ね、社内外へのAWSの普及に努めてまいります。 ★ 貝塚 のTechHarmony記事一覧は こちら   2024 Japan AWS Jr. Champions 「 2024 Japan AWS Jr. Champions 」は、APN加入のAWSパートナー企業に所属する社会人歴 1～3 年目で、AWSについて突出した活動実績がある若手エンジニアを対象とした、今年度より新設された日本独自の表彰制度です。 AWSを積極的に学び、アクションを起こし、周囲に影響を与えている若手エンジニアが選出されます。 SCSKからは福地 と蛭田の2名が選出されました。 2024 Japan AWS Jr. Champions　SCSKメンバー2名（左右） ※AWSでJr.Championsを主管するYukki(髙橋 敏行)さんと一緒に 福地 孝哉 ソリューション事業グループ　クラウドサービス事業本部　クラウドサービス第二部　第一課 2021年にSCSKに入社しました。 業務経歴は、オンプレミスからAWSへのマイグレーション支援、データ利活用のためのデータ連携基盤の設計・構築業務をしています。 2024 Japan AWS Jr. Champions選出にあたり、3つのContributionカテゴリに対してAWSエンジニアとして水準を満たしているか評価されます。 私の場合は以下の活動を評価いただきました。 Challenge：サーバレス技術を組み合わせたシステム設計、案件リード Influence：Techharmonyでの発信活動 Output：社内エンジニア向けの研修プログラムの企画・運営・講師 また、2023-2024 Japan AWS All Certifications Engineersとして認定資格を継続的に取得し、積極的にインプットに取り組んできました。 今回の選出について、協力いただいた皆様には感謝申し上げます。 このブログを読んでいるあなた！SCSKで次世代のJr. Championsを目指しませんか？？ SCSKの代表としてAWSビジネスの発展に貢献できるよう精一杯頑張りますのでどうぞよろしくお願いします！ ★ 福地 のTechHarmony記事一覧は こちら 蛭田 悠介 ソリューション事業グループ　クラウドサービス事業本部　クラウドサービス第二部　第一課 2023年に新卒で入社しました。 半年間の研修を経て昨年10月よりAWSの主管部署に配属されております。 業務内容としては、福地さんと同じチームにてAPI基盤構築プロジェクトに配属後から現在まで参画しています。 入社してからは一年余り、AWSに触れ始めてからはまだ一年が経過していないため、最初は周囲の方々の知識のすごさに圧倒されておりました。 そのため、少しでもそのような方々に追いつく・追い越すべく、業務以外の場面においても「これってAWSで構築できるかなぁ…」と思ったことは自分で調べながら構築してみて、その取り組みをTechHarmonyにて発信するという活動をしてまいりました。 この活動によって社内で声を掛けていただき、この度2024 Japan AWS Jr. Championsに選出いただきました。 今まで以上にインプット、そしてアウトプットをし、社内外の若手に刺激を与えられる存在になれるよう努めてまいります。 （ちなみに写真の手は「S3」の「3」です。） ★ 蛭田 のTechHarmony記事一覧は こちら   最後に 2024 Japan AWS Ambassadors / 2024 Japan AWS Top Engineers / 2024 Japan AWS Jr. Champions に選出されたSCSK社員10名をご紹介しました。今回ご紹介した10名以外にもSCSKにはAWS認定資格取得者が多数在籍しております。 AWS導入・DX推進をお考えの方は、 ぜひSCSKにお気軽に お問い合わせ ください。 弊社の SCSKクラウドサービス（AWS） では AWS の導入から運用改善まで、お客様のAWS活用をご支援するサービスをご提供しております。 今後もお客様のAWS案件を強力にご支援出来るよう、技術力の向上や情報発信などの活動に努めてまいります。

こんにちは、SCSK株式会社の小寺崇仁です。 先日、安藤さんから バージョンアップ方法の紹介 がありました。 補足情報として、バージョンアップの注意点をご紹介したいと思います。 関連モジュールの依存関係について OSについて ZabbixOSは公式HPのダウンロードメニューより対応しているか確認します。 Zabbix7.0で対応していますが、OSのサポート終了（EOL）にご注意ください ■Zabbix Download https://www.zabbix.com/download OS バージョン EOL（AI調べ） Red Hat Enterprise Linux 9 2032年5月（メンテナンスサポート終了） 8 2029年5月（メンテナンスサポート終了） 7 2024年6月（メンテナンスサポート終了） 6 2017年5月（メンテナンスサポート終了） Alma Linux 9 2032年5月 8 2029年5月 Rocky Linux 9 2032年5月 8 2029年5月 Ubuntu 24.04 (Noble) 情報未定 22.04 (Jammy) 2027年4月（標準サポート終了）、2032年4月（ESM終了） 20.04 (Focal) 2025年4月（標準サポート終了）、2030年4月（ESM終了） 18.04 (Bionic) 2023年4月（標準サポート終了）、2028年4月（ESM終了） 16.04 (Xenial) 2021年4月（標準サポート終了）、2026年4月（ESM終了） ミドルウェアについて Zabbix7.0のミドルウェア要件として公式マニュアルに以下の記載があります ■Zabbix7.0 Requirements https://www.zabbix.com/documentation/current/en/manual/installation/requirements Apache 2.4 or later Nginx 1.20 or later PHP 8.0.0 – 8.3.X MySQL 8.0.30-8.4.X MariaDB 10.5.00-11.4.X PostgreSQL 13.0-16.X OSのリポジトリに対応のミドルウェアがあるか？ 各MWの導入にdnf,aptコマンドを使用してインストールすると思います。 OSの種類ごとに2024年7月7日時点の最新のバージョンをまとめました。   Zabbix7.0 （要件） RHEL 9.4 RHEL 8.10 Ubuntu 24.04 Ubuntu 22.04 Ubuntu 20.04 Apache 2.4 or later httpd-2.4.57 2.4.37-65 2.4.58 2.4.52 2.4.41 Nginx 1.20 or later 1.20 1.14 1.24.0 1.18.0 1.17.10 PHP 8.0.0 – 8.3.X 8.0.30 7.2.24 8.3 8.1 7.4 MySQL 8.0.30-8.4.X 8.0.36 8.0.36 8.0.36 8.0.28 8.0.19 MariaDB 10.5.00-11.4.X 10.5.22 10.3.39 10.11.7 10.6.7 10.3.22 PostgreSQL 13.0-16.X 13.14 10.23 16+257 14+238 12+214 まとめ RHEL系もUbuntu(Debian)系もOSも合わせてアップグレードが必要になりそうです   バージョンアップの時間について Zabbixのバージョンアップはdnfやaptコマンドを使用して、プログラム（パッケージ）の更新を行います。 Zabbix-serverのサービスを起動する際に、データベースの更新処理が行われます。 データ量の多い、ヒストリー、イベントテーブルに更新があると、更新に時間がかかり、監視の停止時間が長くなります。 バージョン5からバージョンアップした際に、テーブル構造の変更があるか調査しました。 history系テーブルのIndexからPRIMARY KEY への変更 Zabbix5.0 CREATE TABLE `history` ( `itemid` bigint(20) unsigned NOT NULL, `clock` int(11) NOT NULL DEFAULT 0, `value` double NOT NULL DEFAULT 0, `ns` int(11) NOT NULL DEFAULT 0, KEY `history_1` (`itemid`,`clock`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin Zabbix7.0 CREATE TABLE `history` ( `itemid` bigint(20) unsigned NOT NULL, `clock` int(11) NOT NULL DEFAULT 0, `value` double NOT NULL DEFAULT 0, `ns` int(11) NOT NULL DEFAULT 0, PRIMARY KEY (`itemid`,`clock`,`ns`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin まとめ history、history_uint、history_str、history_log、history_textでプライマリキーに変更されていました。 データ容量やディスクの速度によって、時間が変わりますが、感覚的に時間がかかりに思います。 ヒストリデータを破棄してから更新するのもアリかもしれないです。   ZabbixProxyを利用している場合について ZabbixProxyを使用している場合、Zabbix7.0では下位互換があります。バージョンアップの際に活用できるか、別途検証してブログ記事にしたいと思います。   仕様の変更について Zabbixの5.0からバージョンアップをすると機能が大きく変わっています。 大きな変更点をご紹介します。 ダッシュボードの変更 メニューが左側になりました。 バージョンが上がる度に改良されていきます。 トリガー条件式 条件式の記述方法が大きく変わっています。 バージョンアップの際に自動で更新されます。 監視プロセスの最適化 Pollerプロセスが分割されます。 別途チューニングが必要となります。 ユーザ役割 ユーザの役割にて、権限が詳細設定可能になります。 監視対象のサーバ管理者にユーザを払い出している場合、注意が必要です。 監査ログ バージョンアップ時に既存の監査ログのレコードは削除されます。 サポートされるDBバージョンの確認 起動前にデータベースのバージョンを確認し、サポート範囲外のバージョンの場合は起動しないようになりました。 参考 https://www.zabbix.com/documentation/6.0/jp/manual/introduction/whatsnew600 https://www.zabbix.com/documentation/current/en/manual/introduction/whatsnew700   最後に 弊社では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アカウントを開設しました！★ 【公式】SCSK Zabbix (@SCSK_Zabbix) / Twitter SCSKが提供するZabbixサービスのオフィシャルアカウントです。 #Zabbix #SCSKPlusサポートforZabbix #監視 #SCSK twitter.com  

こんにちは、広野です。 Amazon GuardDuty の設定は機能ごとに有効/無効にできるのですが、それを AWS CloudFormation で設定しようと試みたときにハマりました。 もし同じエラーが出た方には役立つかもしれません。そもそも AWS CloudFormation で Amazon GuardDuty の設定をする人ってあまりいないかもですが・・・。 ハマったこと 始まりは、AWS CloudFormation IaC ジェネレーターを使用したこと IaC ジェネレーターは、既存のデプロイ済みリソースをスキャンして、CloudFormation テンプレートにしたいリソースを選択すると、そのテンプレートを出力してくれるというスゴイやつです。 IaC ジェネレーターを使用して既存のリソースのテンプレートを生成する - AWS CloudFormation Infrastructure as Code (IaC) テンプレートを、CloudFormation で管理されていないアカウントにデプロイされた AWS リソースタイプから生成します。 docs.aws.amazon.com 今回、Amazon GuardDuty を AWS マネジメントコンソールからボタンぽちっとな、で有効にしたものを IaC ジェネレーターでテンプレート化して、他のアカウントにデプロイしようとしました。 IaC ジェネレーターが出力したテンプレートはこちら。↓ ここに、ハマり要素が潜んでいました。 注意！動きません。 --- Metadata: TemplateId: "arn:aws:cloudformation:ap-northeast-2:xxxxxxxxxxxxx:generatedTemplate/a4c6ba10-b002-47b3-bee2-587defc7921a" Resources: GuardDutyDetector0082c84d2d1e796541ecd974b782ea181600qtDWT: UpdateReplacePolicy: "Delete" Type: "AWS::GuardDuty::Detector" DeletionPolicy: "Delete" Properties: FindingPublishingFrequency: "SIX_HOURS" Enable: true DataSources: MalwareProtection: ScanEc2InstanceWithFindings: EbsVolumes: true S3Logs: Enable: true Kubernetes: AuditLogs: Enable: true Features: - Status: "ENABLED" Name: "CLOUD_TRAIL" - Status: "ENABLED" Name: "DNS_LOGS" - Status: "ENABLED" Name: "FLOW_LOGS" - Status: "ENABLED" Name: "S3_DATA_EVENTS" - Status: "ENABLED" Name: "EKS_AUDIT_LOGS" - Status: "ENABLED" Name: "EBS_MALWARE_PROTECTION" - Status: "ENABLED" Name: "RDS_LOGIN_EVENTS" - Status: "DISABLED" AdditionalConfiguration: - Status: "DISABLED" Name: "EKS_ADDON_MANAGEMENT" Name: "EKS_RUNTIME_MONITORING" - Status: "ENABLED" Name: "LAMBDA_NETWORK_LOGS" - Status: "DISABLED" AdditionalConfiguration: - Status: "DISABLED" Name: "EKS_ADDON_MANAGEMENT" - Status: "DISABLED" Name: "ECS_FARGATE_AGENT_MANAGEMENT" - Status: "DISABLED" Name: "EC2_AGENT_MANAGEMENT" Name: "RUNTIME_MONITORING" Tags: [] IaC ジェネレーターの出力を参考にして作成したテンプレート ※注意！動きません Amazon GuardDuty は機能ごとに有効/無効を設定できるものがあるので、私が必要な機能だけ有効にするように設定したつもりでした。 AWSTemplateFormatVersion: 2010-09-09 Description: The CloudFormation template that enables GuardDuty per region. Parameters: # ------------------------------------------------------------# # Input Parameters # ------------------------------------------------------------# TagValue: Type: String Description: Tag value for Cost key. Default: GuardDuty MaxLength: 30 MinLength: 1 Resources: # ------------------------------------------------------------# # GuardDuty # ------------------------------------------------------------# GuardDutyDetector: Type: AWS::GuardDuty::Detector Properties: FindingPublishingFrequency: SIX_HOURS Enable: true DataSources: MalwareProtection: ScanEc2InstanceWithFindings: EbsVolumes: true S3Logs: Enable: true Kubernetes: AuditLogs: Enable: false Features: - Status: ENABLED Name: CLOUD_TRAIL - Status: ENABLED Name: DNS_LOGS - Status: ENABLED Name: FLOW_LOGS - Status: ENABLED Name: S3_DATA_EVENTS - Status: DISABLED Name: EKS_AUDIT_LOGS - Status: ENABLED Name: EBS_MALWARE_PROTECTION - Status: DISABLED Name: RDS_LOGIN_EVENTS - Status: DISABLED AdditionalConfiguration: - Status: DISABLED Name: EKS_ADDON_MANAGEMENT Name: EKS_RUNTIME_MONITORING - Status: ENABLED Name: LAMBDA_NETWORK_LOGS - Status: DISABLED AdditionalConfiguration: - Status: DISABLED Name: EKS_ADDON_MANAGEMENT - Status: DISABLED Name: ECS_FARGATE_AGENT_MANAGEMENT - Status: DISABLED Name: EC2_AGENT_MANAGEMENT Name: RUNTIME_MONITORING Tags: - Key: Cost Value: !Ref TagValue ハマり その1 DataSources と Features の設定を両方入れるとエラーになる IaC ジェネレーターが出力したテンプレートを全面的に信じてテンプレートを作成したわけですが、実際にテンプレートを流すと以下のエラーメッセージでスタック作成が失敗しました。 Resource handler returned message: “Invalid request provided: AWS::GuardDuty::Detector” まず最初に気付いたのは以下のドキュメントでした。 GuardDuty API changes in March 2023 - Amazon GuardDuty The GuardDuty APIs configure protection features that don't belong to the list of . A feature object contains feature de... docs.aws.amazon.com どうも、GuardDuty の機能ごとに有効/無効を設定するには DataSources ではなく Features の設定を使用することを推奨していました。そして、両方記述するとエラーになるようです。 解決: DataSources の設定は削除しました。 ハマリ その2 EKS_RUNTIME_MONITORING と RUNTIME_MONITORING の設定も その1 の修正をしただけでは状況が変わりませんでした。エラーメッセージも その1 と同じです。テンプレートのどこに問題があるかわからず、AWS CloudTrail の API ログを確認したところ、以下のメッセージを発見しました。 The request was rejected because EKS_RUNTIME_MONITORING and RUNTIME_MONITORING cannot be provided in the same request.  EKS_RUNTIME_MONITORING と RUNTIME_MONITORING の設定を両方記述するとエラーになる ようです。 これについては、以下のドキュメントの冒頭に書いてありました。後から気付きました。 DetectorFeatureConfiguration - Amazon GuardDuty Contains information about a GuardDuty feature. docs.aws.amazon.com 解決: EKS_RUNTIME_MONITORING の設定は RUNTIME_MONITORING に含まれるようなので、EKS_RUNTIME_MONITORING の方を削除しました。 ハマり その3 指定した機能の名前が正しくない その2 の修正をしても状況は変わりませんでした。エラーメッセージも その1 と同じです。テンプレートのどこに問題があるかわからず、AWS CloudTrail の API ログを確認したところ、以下のメッセージを発見しました。 The request failed because the provided feature names are invalid: [FLOW_LOGS, DNS_LOGS, CLOUD_TRAIL]. テンプレートの中に記述している、これら 3つの機能の名前が正しくないと言っています。 後から気が付いたのですが、 設定変更可能な機能としてこれらは含まれていませんでした。 その2 で紹介した公式ドキュメントにしっかり書いてありました。 DetectorFeatureConfiguration - Amazon GuardDuty Contains information about a GuardDuty feature. docs.aws.amazon.com 解決: これら 3つの機能の設定は削除しました。 完成した AWS CloudFormation テンプレート ※動きます いろいろとハマりましたが、動作したテンプレートはこれです。有効にしたい機能は ENABLED にする必要があります。 IaC ジェネレーターを使用せずに最初から公式リファレンス読んで作成した方が早かったかも・・・。 AWSTemplateFormatVersion: 2010-09-09 Description: The CloudFormation template that enables GuardDuty per region. Parameters: # ------------------------------------------------------------# # Input Parameters # ------------------------------------------------------------# TagValue: Type: String Description: Tag value for Cost key. Default: GuardDuty MaxLength: 30 MinLength: 1 Resources: # ------------------------------------------------------------# # GuardDuty # ------------------------------------------------------------# GuardDutyDetector: Type: AWS::GuardDuty::Detector Properties: FindingPublishingFrequency: SIX_HOURS Enable: true Features: - Status: ENABLED Name: S3_DATA_EVENTS - Status: DISABLED Name: EKS_AUDIT_LOGS - Status: ENABLED Name: EBS_MALWARE_PROTECTION - Status: DISABLED Name: RDS_LOGIN_EVENTS - Status: ENABLED Name: LAMBDA_NETWORK_LOGS - Status: DISABLED AdditionalConfiguration: - Status: DISABLED Name: EKS_ADDON_MANAGEMENT - Status: DISABLED Name: ECS_FARGATE_AGENT_MANAGEMENT - Status: DISABLED Name: EC2_AGENT_MANAGEMENT Name: RUNTIME_MONITORING Tags: - Key: Cost Value: !Ref TagValue AWS CloudTrail のログが有用だった AWS CloudFormation テンプレートのスタック作成時エラーはメッセージから原因がわかることが多いのですが、GuardDuty に関しては Resource handler returned message: “Invalid request provided: AWS::GuardDuty::Detector” このメッセージ一辺倒だったので困りました。以下のドキュメントにあるように、AWS CloudTrail のイベント履歴から AWS CloudFormation のエラーメッセージを探すことで、原因を突き止められました。 コンソールで最近の管理イベントを表示する - AWS CloudTrail CloudTrail コンソールを使用して、アカウントで過去 90 日間の管理イベントを表示、フィルタリング、ダウンロードします。管理イベントは、単一の属性と時間範囲でフィルタリングできます。 docs.aws.amazon.com まとめ いかがでしたでしょうか？ AWS CloudFormation テンプレートを IaC ジェネレーターで作成し始めたことからハマってしまいましたが、これに懲りずに他のリソースのテンプレート作成も引き続き試してみたいと思います。きちんと検証することの重要さや、AWS CloudTrail の有用性にも改めて気づかされました。 本記事が皆様のお役に立てれば幸いです。

こんにちは、広野です。 以下の記事と同じ理由で、AWS Summit Japan 2024 のセッションを聞いてインスピーレーションを受けまして、Amazon API Gateway と Amazon DynamoDB を AWS Lambda 関数抜きで直接連携しました。似たような記事は世の中に多いのですが、本記事では AWS CloudFormation でデプロイしています。 Amazon API Gateway から Amazon SES API を直接叩いてメール送信する (AWS Lambda 不使用) AWS Summit Japan 2024 でとあるセッションを聞いてインスピレーションを受けまして、Amazon API Gateway と Amazon SES を直接連携させてみました。 blog.usize-tech.com 2024.07.04 やりたいこと 以下の Amazon DynamoDB テーブルから、GetItem API を使用して指定のデータを 1件取得します。パーティションキーは pkey、ソートキーは skey です。属性として attr があります。 Amazon API Gateway REST API を使用します。AWS Lambda 関数は使用しません。 AWS Lambda 関数で行っていた Amazon DynamoDB API の呼び出しは、Amazon API Gateway の統合リクエストマッピングテンプレートで代用します。Amazon API Gateway の統合タイプは、AWS になります。 Amazon API Gateway の認証はありません。CORS 設定はあります。本記事では簡略化のため “*” を使用して設定します。 テストでは、”pkey”: “test1”, “skey”: 1 のパラメータを指定してデータ取得してみます。 マッピングテンプレートをどう書くか AWS Lambda 関数でやっていたことを Amazon API Gateway のマッピングテンプレートに肩代わりさせるので、そこが肝になります。イメージしてもらいやすくするため、AWS Lambda 関数と対比して紹介します。 AWS Lambda 関数 書き方はいくつかありますが、以下のような AWS Lambda 関数 (Python) で Amazon DynamoDB GetItem API を呼び出すと思います。 import json import boto3 dynamodb = boto3.resource('dynamodb') table = dynamodb.Table('extable-xxxxxxxxxx-hirono') def lambda_handler(event, context): input = json.loads(event['body']) res = table.get_item( Key={ 'pkey': input['pkey'], 'skey': input['skey'] } ) return { "isBase64Encoded": False, "statusCode": 200, "body": json.dumps(res) } マッピングテンプレート マッピングテンプレートだと、以下のように VTL を使用して書きます。統合リクエストマッピングテンプレートに定義します。 ## API Gateway が受け取った引数を $inputRoot に格納する #set($inputRoot = $input.path('$')) { "TableName": "extable-xxxxxxxxxx-hirono", "Key": { "pkey":{ "S": "$inputRoot.pkey" }, "skey":{ "N": "$inputRoot.skey" } }, "ConsistentRead" : false } Amazon DynamoDB GetItem API に渡すフォーマットは同じだと思いました。 冒頭で、Amazon API Gateway が受け取ったパラメータを $inputRoot という変数に格納しています。面倒なのは項目ごとに “N” や “S” などデータ型を明示的に書かないといけないことです。 Amazon DynamoDB テーブルに渡すパラメータの仕様は以下の公式リファレンス通りだったので、Amazon DynamoDB の他の API でも同様に応用できるものと想像します。 GetItem - Amazon DynamoDB The GetItem operation returns a set of attributes for the item with the given primary key. If there is no matching item,... docs.aws.amazon.com 実際の動作 実際に API へのリクエストを AWS CloudShell からコマンドを打って試してみます。以下のコマンドを打ちます。 curl -X POST 'https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/prod/Dynamodb' -H 'Content-Type: application/json' -d '{"pkey": "test1", "skey": "1"}' 以下の結果が返ってきます。 {"Item":{"attr":{"S":"attr1"},"pkey":{"S":"test1"},"skey":{"N":"1"}}} ↓整形すると { "Item": { "attr": { "S":"attr1" }, "pkey": { "S":"test1" }, "skey": { "N":"1" } } } 今回、Amazon API Gateway REST API の統合レスポンスマッピングテンプレートをパススルーにしたので、Amazon DynamoDB から返ってきたデータがそのまま表示されました。 レスポンスから余計な “N” や “S” を消そうと思ったら、統合レスポンスマッピングテンプレートで戻りを加工する必要がありますが、属性が固定ではない場合は難しいかもしれません。 本記事の例ではソートキーのデータ型が Number になっています。このケースでは、API に数値を文字列として渡さないとエラーになります。Amazon DynamoDB API の仕様です。”skey”:{“N”:”1″} となっている部分のことです。また、戻ってくる値も数値は文字列として返されます。 他にも Amazon API Gateway の設定はあるのですが、メインはマッピングテンプレートでしたので、AWS CloudFormation テンプレートから読み取るか、それを実行してデプロイされた現物をご確認頂けたらと思います。 AWS CloudFormation テンプレート 本記事で紹介した Amazon DynamoDB テーブルと Amazon API Gateway REST API を一式デプロイする AWS CloudFormation を貼り付けます。執筆時点で動いたことは確認済みです。 AWSTemplateFormatVersion: 2010-09-09 Description: The CloudFormation template that creates a DynamoDB table and an API Gateway. # ------------------------------------------------------------# # Input Parameters # ------------------------------------------------------------# Parameters: SubName: Type: String Description: System sub name. (e.g. example) Default: example MaxLength: 10 MinLength: 1 Resources: # ------------------------------------------------------------# # DynamoDB # ------------------------------------------------------------# DynamodbExample: Type: AWS::DynamoDB::Table Properties: TableName: !Sub extable-${AWS::AccountId}-${SubName} AttributeDefinitions: - AttributeName: pkey AttributeType: S - AttributeName: skey AttributeType: N BillingMode: PAY_PER_REQUEST KeySchema: - AttributeName: pkey KeyType: HASH - AttributeName: skey KeyType: RANGE PointInTimeRecoverySpecification: PointInTimeRecoveryEnabled: false Tags: - Key: Cost Value: !Ref SubName # ------------------------------------------------------------# # API Gateway # ------------------------------------------------------------# RestApiDynamodb: Type: AWS::ApiGateway::RestApi Properties: Name: !Sub dynamodb-${SubName} Description: !Sub REST API to call DynamoDB GetItem API for ${SubName} EndpointConfiguration: Types: - REGIONAL Tags: - Key: Cost Value: !Ref SubName RestApiDeploymentDynamodb: Type: AWS::ApiGateway::Deployment Properties: RestApiId: !Ref RestApiDynamodb DependsOn: - RestApiMethodDynamodbPost - RestApiMethodDynamodbOptions RestApiStageDynamodb: Type: AWS::ApiGateway::Stage Properties: StageName: prod Description: production stage RestApiId: !Ref RestApiDynamodb DeploymentId: !Ref RestApiDeploymentDynamodb MethodSettings: - ResourcePath: "/*" HttpMethod: "*" LoggingLevel: INFO DataTraceEnabled : true TracingEnabled: false Tags: - Key: Cost Value: !Ref SubName RestApiResourceDynamodb: Type: AWS::ApiGateway::Resource Properties: RestApiId: !Ref RestApiDynamodb ParentId: !GetAtt RestApiDynamodb.RootResourceId PathPart: Dynamodb RestApiMethodDynamodbPost: Type: AWS::ApiGateway::Method Properties: RestApiId: !Ref RestApiDynamodb ResourceId: !Ref RestApiResourceDynamodb HttpMethod: POST AuthorizationType: NONE Integration: Type: AWS IntegrationHttpMethod: POST Credentials: !GetAtt ApigDynamodbInvocationRole.Arn Uri: !Sub "arn:aws:apigateway:${AWS::Region}:dynamodb:action/GetItem" PassthroughBehavior: WHEN_NO_TEMPLATES RequestTemplates: application/json: !Sub | #set($inputRoot = $input.path('$')) { "TableName": "${DynamodbExample}", "Key": { "pkey":{ "S": "$inputRoot.pkey" }, "skey":{ "N": "$inputRoot.skey" } }, "ConsistentRead" : false } IntegrationResponses: - StatusCode: 200 ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: "'*'" - StatusCode: 400 ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: "'*'" - StatusCode: 403 ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: "'*'" - StatusCode: 404 ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: "'*'" - StatusCode: 500 ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: "'*'" - StatusCode: 503 ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: "'*'" MethodResponses: - StatusCode: 200 ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Origin: true method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true - StatusCode: 400 ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Origin: true method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true - StatusCode: 403 ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Origin: true method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true - StatusCode: 404 ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Origin: true method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true - StatusCode: 500 ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Origin: true method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true - StatusCode: 503 ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Origin: true method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true DependsOn: - ApigDynamodbInvocationRole RestApiRequestModelDynamodb: Type: AWS::ApiGateway::Model Properties: ContentType: application/json RestApiId: !Ref RestApiDynamodb Schema: |- { "$schema": "http://json-schema.org/draft-04/schema#", "title": "Dynamodb", "type": "object", "properties": { "pkey": { "type": "string" }, "skey": { "type": "integer" } }, "required": ["pkey", "skey"] } RestApiMethodDynamodbOptions: Type: AWS::ApiGateway::Method Properties: RestApiId: !Ref RestApiDynamodb ResourceId: !Ref RestApiResourceDynamodb HttpMethod: OPTIONS AuthorizationType: NONE Integration: Type: MOCK Credentials: !GetAtt ApigDynamodbInvocationRole.Arn IntegrationResponses: - ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: "'*'" ResponseTemplates: application/json: '' StatusCode: 200 PassthroughBehavior: WHEN_NO_MATCH RequestTemplates: application/json: '{"statusCode": 200}' MethodResponses: - ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true method.response.header.Access-Control-Allow-Origin: true StatusCode: 200 # ------------------------------------------------------------# # API Gateway DynamoDB Invocation Role (IAM) # ------------------------------------------------------------# ApigDynamodbInvocationRole: Type: AWS::IAM::Role Properties: RoleName: !Sub ApigDynamodbInvocationRole-${SubName} Description: This role allows API Gateways to invoke DynamoDB GetItem API. AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: Service: - apigateway.amazonaws.com Action: - sts:AssumeRole Path: / ManagedPolicyArns: - arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess Policies: - PolicyName: !Sub ApigDynamodbInvocationPolicy-${SubName} PolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Action: - "dynamodb:GetItem" Resource: - !GetAtt DynamodbExample.Arn DependsOn: - DynamodbExample # ------------------------------------------------------------# # Output Parameters # ------------------------------------------------------------# Outputs: APIGatewayEndpointDynamodb: Value: !Sub https://${RestApiDynamodb}.execute-api.${AWS::Region}.${AWS::URLSuffix}/${RestApiStageDynamodb}/Dynamodb 本テンプレートは、Amazon API Gateway のログを Amazon CloudWatch Logs に push するために必要な IAM ロールがアカウントに登録済みでないとエラーになります。それについては以下の記事をご確認ください。 Amazon API Gateway のログを Amazon CloudWatch Logs に書き込むための IAM ロールはアカウント単位の設定です Amazon API Gateway のログを Amazon CloudWatch Logs に書き込むための IAM ロール設定を紹介します。 blog.usize-tech.com 2024.07.01 まとめ いかがでしたでしょうか？ Amazon DynamoDB の API をそのまま使うだけの要件であれば、十分実用的であると思いました。VTL では対応しきれない文字列加工やビジネスロジックが必要になる場合は、やはり AWS Lambda 関数を間に挟む必要があります。 AWS AppSync のマッピングテンプレートでは便利な独自関数が用意されているのですが、Amazon API Gateway では標準 VTL が用意しているものしか使えないようなので (公式ドキュメントを見た限りでは) 、AWS AppSync の方がやや融通は利きやすいという印象でした。 本記事が皆様のお役に立てれば幸いです。

こんにちは、SCSK 木澤です。 SCSKでは、生成AIがより高精度の回答を出力できるRAG環境を、お客様AWSアカウントに構築できるテンプレートを提供する S-Cred+ InfoWeaveオプションを5月より提供開始 しました。 生成AI RAGソリューション InfoWeave｜SCSK株式会社 生成AI RAGソリューション（InfoWeave（インフォウィーヴ））は、S-Cred⁺ ※ の生成AIオプションサービスです。 www.scsk.jp 本記事では AWS Summit Japan 2024の当社ブース内で講演した内容をベースに、本サービスの特徴等などについて解説します。 なお本サービスについては7/23にウェビナーを開催しますので奮ってご参加下さい。 [AI活用紹介セミナー] AWSとRAG構築テンプレで社内チャットボットを始めよう 本セミナーでは、AWSとRAG構築テンプレート「InfoWeave」を活用して社内チャットボットを簡単に始められる方法をご紹介いたします。 さらに、今年6月に開催されるAWS Summit Japan 2024のアップデート情報とあわせてA... www.scsk.jp AWS Summit Japan 2024ミニシアター資料 ミニシアターにて講演した内容はこちらです。 私は 6/20に1回と、(急遽)6/21の午前中に2回、合計3回発表いたしました。聴講頂いた皆様、ありがとうございました。   InfoWeaveの概要 InfoWeaveは当社のAWS複合基盤サービス、S-Cred+のオプションとして提供されています。 S-Cred+についてはこちらをご覧下さい S-Cred+プラットフォーム S-Cred+プラットフォームとはアプリケーション開発やサービス提供を最適な形で実現する複合基盤サービスです www.scsk.jp S-Cred+では、単なる運用基盤(MSP)に留まらず、環境構築テンプレートや、SCSK自社開発のローコード開発ツール等を組み合わせることによって、AWS上でのシステム／サービス開発をより迅速に行えるよう構成されています。 今回提供を開始したInfoWeaveは、この「システム環境構築テンプレート」の一種として提供を始めたものとなります。 生成AIがより高精度の回答を出力できるRAG環境を構築できるテンプレートを提供しますので、お客様は速やかに(※)独自ナレッジを含んだチャットボットを利用できるようになります。 利用料金は以下の通りです。 初期料金：600,000円（AWSアカウント単位） 環境構築代行：60,000/回（当社側でテンプレート展開を代行する場合のみ） ※申込（契約）後、利用開始まで3営業日。テンプレートのデプロイは概ね1時間程度 RAGについて さて、ご存じの方も多いと思いますが、RAGについて簡単におさらいしたいと思います。 生成AIのチャットボットを利用したことがある方も多いと思いますが、思ったよりも回答精度が良くないと感じることがあるでしょう。 大規模言語モデル(LLM)は、過去のある時点の情報を基に学習しているため、最新の情報は回答できません。 また、より専門的な情報や組織内の情報を基にした回答をして欲しい場合もあるでしょう。 そうした場合に回答精度を高める手段の一つして利用できるのが、RAG(Retrieval-Augmented Generation)となります。 LLMへのインプットとして関連情報を付加することで、より高精度な回答を得ることができるようになります。 InfoWeaveの特徴 さて環境構築テンプレートを利用し速やかにRAG環境を立ちあげることができるInfoWeaveですが、特徴として以下が挙げられます。 既存ドキュメントの活用 環境構築後、学習用ドキュメント格納用のS3バケットが1つ用意されます。 お客様はここにドキュメントを放り込むだけ独自ナレッジを利用したチャットボットを立ちあげることができます。 （テキストやMS-Office系、PDFなど一般的なドキュメント形式に対応。画像等マルチモーダルは現時点で非対応） 速やかにRAG環境を立ちあげることができる 利用開始（契約）後、3営業日にて環境構築テンプレートが提供されます。 テンプレートをデプロイすることで概ね1時間程度でチャットボットのUIも含めて提供されますので、  ① テンプレートをデプロイ  ② ユーザーを追加  ③ 既存ドキュメントを放り込む この一連の流れだけですぐにRAG環境を利用することができます。 またチャットボットだけでなくAPI機能も提供されるので、既存システムとの連携も容易に行うことができます。 無制限に環境作成が可能 環境構築テンプレートはAWSアカウント単位で提供されます。 よって当該AWSアカウント内では追加料金なくRAG環境を立て放題となります（AWSリソース料金は発生します） これにより、業務ごと・部署毎に独自の専門的なRAG環境を立ちあげることができます。 要件に応じて選択可能 大規模言語モデル(LLM)は、Amazon Bedrock上のAnthropic Claude(各種)および、OpenAI GPT-4から選択可能です。 RAG用のベクトルデータベースについては、Amazon Kendraあるいは外部サービスのPineconeを選択可能です。 セキュリティ重視でAWS内に閉じたい場合やコスト重視の場合など、要件に応じて構成を選択できる特徴があります。 利用者の権限に応じて回答が変化 これがRAGを選択する最大の特徴かもしれません。 RAGでは関連情報を付加してLLMに問い合わせるといった仕組みであることから、利用者の権限によって回答内容を変えることができます。これによって以下のような仕組みが可能になります。      社内 からの問い合わせ：社外秘の資料を用いて詳細な回答を行う 社外 からの問い合わせ：社内ナレッジを利用しない回答を行う Knowledge bases for Amazon Bedrockとの違い AWSでは同様に簡単にRAG環境を構築できる Knowledge bases for Amazon Bedrockが提供されていますが、違いは以下となります。 ① 標準でWeb ChatbotのWeb UIが提供されすぐに利用できる ② 選択できるLLMや検索用DBの幅が広い ③ 権限による回答の制御ができる InfoWeaveのユースケース 先述の特徴を持つInfoWeaveですが、以下のようなユースケースに活用可能です。 ヘルプデスクの業務効率化 専門分野・業務向けのチャットボット 社内ロール（権限）に応じた回答   アーキテクチャ 少しだけで恐縮ですが、アーキテクチャの話に触れたいと思います。 InfoWeaveの構築テンプレートは当社側のサービス提供環境よりAWS Service Catalogを通じて提供されます。 デプロイされるサービスは主なものとして以下があります。 Amazon S3（ドキュメント格納用） Amazon ECS , AWS Fargate（APIサーバー、Chatbot UI コンテナ、管理機能 各コンテナ） Amazon Bedrock（※LLM） Amazon Kendra（※RAG用データベース） DynamoDB（データストア） Application Load Balancer ※利用を選択した場合 コンテナイメージも弊社側管理のECRリポジトリから提供され、適宜更新される予定です。   注意点 本サービスはSCSKの複合基盤サービス、S-Cred+のオプションとして提供されており、S-Cred+の契約が必須となります。 AWS Service Catalogによるテンプレートやコンテナイメージの展開にあたり、AWSアカウントを弊社の管理基盤の管理下にする必要があり、このような仕様としております。 このような制約は有るものの、InfoWeaveは独特の特徴があるサービスとなりますので   最後に：AWS Summit Japan 2024を終えて AWS Summit Japan 2024が終わりましたね。 私は当社出展のリードとしてここ数ヶ月注力してきました。 細かい反省点は多いのですが、今はとにかく大きなトラブル無く終了できてホッとしています。 当社の出展内容は、川原さんのレポートをご覧下さい。 AWS Summit Japan 2024に出展しました！ 6月20日～21日の2日間にわたり、幕張メッセで開催されたAWS Summit Japan 2024に出展しました。SCSKはプラチナスポンサーとして、スポンサーセッションとブースを出展し、大変多くの方々にご来場いただきました！ blog.usize-tech.com 2024.06.27 私は2日間、概ねブース周辺におりました。たくさんの方に来訪いただき本当に感謝しております。 また夜はHUB周辺に出没し、いろいろな方との交流を深めることができました。 こちらでお会いした方々にも感謝したいと思います。 なお、お陰様で今年の表彰も継続して頂戴することができました。 AWS Ambassadors Japan AWS Top Engineers Japan AWS All Certfications Engineers 今回のイベントを成功させるにあたっては、社内外の皆様の協力無くしてなし得ませんでした。 この点においても感謝ですし、一個人としてはこの経験を糧に、今後も邁進して行ければと思います。 全ての皆様に御礼まで。ありがとうございました。

こんにちは。SCSK株式会社の上田です。 2024年6月4日に最新バージョンであるZabbix 7.0 LTSがリリースされ、様々な新機能が追加されました。 今回は、追加された新機能の中から、便利な機能をピックアップしてご紹介します。 Zabbixとは まずはZabbixの説明を簡単にさせていただきます。 Zabbixは、エンタープライズ対応のオープンソース統合監視ツールです。 サービスやそれを支える ITシステム(サーバ、ネットワーク機器等)の状態を把握し、障害の予兆やサービスへ影響を及ぼす事象が発生した際に、システム管理者やオペレータに通知を行うオープンソースの統合監視ソリューションです。 数万デバイス規模のエンタープライズ環境でも多数の稼動実績を誇っています。 Zabbixの詳細情報については、下記リンクよりご確認ください。 Zabbix :: The Enterprise-Class Open Source Network Monitoring Solution ZabbixはITインフラストラクチャ・コンポーネントの可用性やパフォーマンスを監視するためのエンタープライス向けソフトウェアです。Zabbixはオープンソース・ソフトウェアとして開発されており、無料でダウンロードいただくことが可能です。 www.zabbix.com 新機能の紹介 ここからは、新機能をカテゴリごとに紹介していきます。 Zabbixプロキシの新機能 大規模な環境で使われているZabbixプロキシについて、2つの新機能がリリースされました。 プロキシの負荷分散と高可用性 Zabbix 6.0ではサーバのHAが可能でしたが、7.0では プロキシもHAと負荷分散に対応 しました。 プロキシグループ という新たな概念が登場し、監視対象ホストをグループ内で自動的に分散して監視できるようになりました。 一つのプロキシがダウンした場合でも、残りのプロキシに監視を振り分けることが可能です。 プロキシのメモリバッファ 従来は必須だったヒストリデータのDB書き込みが、 プロキシメモリ内から直接Zabbixサーバに送信できる ようになりました。 保持方式は以下の3種類から選択可能です。 方式 機能 hybrid 正常時はメモリから送信、バッファフル時やプロキシ停止時はDBに書き込み memory DBへの書き込みは一切行わず、停止時のデータ保証はなし disk メモリを使用せず、従来通りDBで管理 WEB機能の追加 ZabbixのWEBインターフェース関連で、いくつかの新機能がリリースされています。 新ウィジェットの追加 新しいウィジェット が利用可能になりました。その中からいくつかを実際の画面付きでご紹介します。 ウィジェット 機能 Gauge（ゲージ） 単一アイテムの値をスピードメータ形式で表示 Pie Chart（円グラフ） 単一/複数アイテムの値を円グラフで表示 ハニカム（ハチの巣） アイテムの値を色分け可能な六角形セルで表示 新機能①：ゲージ 新機能②：円グラフ   新機能③：ハニカム 定期レポート機能の拡張 6.0で試験的に導入されていた定期レポート機能が、7.0で正式リリースとなりました。 1ページだけでなく、 複数ページのPDF出力が可能 になっています。 ブラウザ監視の追加 新しいアイテムタイプ「 ブラウザ 」が追加されました。こちらは別記事で検証しておりますので、是非ご覧ください。 Zabbix 7.0 新機能検証 (ブラウザモニタリング編) Zabbix 7.0 の新機能について検証しています。今回はブラウザモニタリングでZabbixの「キュー概要」画面を監視しています。 blog.usize-tech.com 2024.06.28 多要素認証（MFA）機能の追加 Zabbixへのログインに MFA認証 が利用可能になりました。ワンタイムパスワードとDuo認証に対応しています。 こちらも別記事で検証しておりますので、是非ご覧ください。 Zabbix 7.0 LTS 新機能：多要素認証機能 (Duo認証) を利用してみた 2024年6月に最新バージョンであるZabbix 7.0 LTSがリリースされました。Zabbix 7.0の新機能である、多要素認証機能（Duo認証）の利用方法をご紹介いたします。 blog.usize-tech.com 2024.06.17 パフォーマンス改善 Zabbixのパフォーマンスを向上させる改善も行われています。 ポーリングの高速化 Pollerプロセスが並列実行できるようになり、 ポーリング処理が高速化 されました。 こちらも別記事で検証しておりますので、是非ご覧ください。 Zabbix 7.0 新機能検証 (ポーリングの高速化編) Zabbix 7.0 の新機能について検証しています。今回はデータ収集処理の改善について検証しています。 blog.usize-tech.com 2024.06.18 ネットワークディスカバリの動作改善 ネットワークディスカバリの処理も並列実行できるようになり、 ネットワークディスカバリが高速化 されました。 従来と比べておよそ10倍～100倍のパフォーマンスと謳われています。 その他の追加機能 Zabbix API 経由で Zabbix サーバにデータ送信可能 history.pushメソッドを使うことで、 API経由でZabbixサーバにデータ送信可能 です。 これにより、 Zabbix agentが入っていないホスト （例えばIoTデバイスなど） でも監視を行うことが可能 になりました。 アイテム名のユーザーマクロサポート機能復活 アイテム名、アイテム プロトタイプ名で、ユーザーマクロが使える ようになりました。 こちらは、Zabbix 6.0で廃止された機能でしたが、Zabbix 7.0になって復活しました。   その他にも、いくつかの新機能が搭載しています。 詳しくは以下の公式サイトをご参照ください。 What's new in Zabbix 7.0 LTS www.zabbix.com まとめ Zabbix 7.0の新機能を紹介しました。様々な機能が追加されていますので、是非Zabbix 7.0を試してみてください。 「 Zabbix 7.0を新規にインストールしてみたい 」「 既存のZabbixからバージョンアップしたい 」という方は、こちらの記事も参考にしてみてください。 Zabbix 7.0 LTSをインストールしてみた 最新バージョンであるZabbix 7.0 LTSがリリースされましたので、AWS上にインストールしてみたいと思います。 また、インストールするために必要な手順を本記事にて記載いたします。 blog.usize-tech.com 2024.06.12 Zabbix 5.0 LTS から 7.0 LTS へ簡単にバージョンアップしてみた Zabbix 5.0 LTS から 7.0 LTS へバージョンアップしてみました blog.usize-tech.com 2024.07.04 今回は概要だけでしたが、新機能を検証した記事を順次投稿していく予定です！ 最後まで読んでいただき、ありがとうございました。   最後に・・・ 弊社では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アカウントを開設しました！★ x.com X.com