皆さん、こんにちは！SCSK株式会社の川原です。 今年も、Google Cloudが主催するグローバルカンファレンスイベント「 Google Cloud Next Tokyo ’24 」が開催されます！このイベントは、クラウドテクノロジーの最新情報を学び、業界リーダーや専門家とのネットワーキングを行うための絶好の機会です。 ### Google Cloud Next Tokyo ’24 概要 開催日:  2024年8月1日（木）〜2日（金） 会場 : パシフィコ横浜ノース この度当社は、Platinumスポンサーとして出展いたします！ ブレイクアウトセッション &Ask the Speaker に登壇し、 Expo 会場へのブースを出展予定 です。 IT 業界のみならず様々な業界のリーダー、意思決定者、エンジニア、そして開発者の皆様にご満足頂けるセッションコンテンツが準備されていますので、この機会をぜひ​ご活用ください。皆様のご参加を心よりお待ちしております 。 ご登録がお済でない方は、まずはこちらからご登録ください↓↓ 【招待コード  : FY24nx_pt030】 申し込み時にご入力ください ！！   イベントの見どころ Google Cloud Next Tokyo ’24では、生成AIやセキュリティをはじめ、ビジネスに欠かせないテーマを元に、基調講演、ライブセッションやハンズオンなどのプログラムが用意されています。 ☁︎  基調講演 話題の生成  AI  を筆頭に多様なプロダクト アップデートや最新のソリューションを紹介します。 また、 Google Cloud  を導入しビジネスに革新をもたらす企業のリーダーから、そのビジョンと取り組みについてお聞きします。 ☁︎  ブレイクアウト セッション & Ask the Speaker 9 つのテーマで、米  Next  で発表された最新情報やお客様によるクラウド活用事例をお届けします。 具体的な活用事例やスピーカーへの質問コーナーを活用することで、自社に役立つヒントを見つけましょう。 ☁︎  ハンズオン セッション Google Cloud  の魅力を、実際のハンズオンを通して探求しましょう。 AI 、データ分析、インフラ構築、アプリ開発、セキュリティまで、 全てを学べるチャンスです！皆さまの参加をお待ちしております。 ☁︎ Expo Google Cloud  の最新製品やソリューション、パートナー、お客様の事例やデモを、エキスパートと交流しながら体験できるエリアです。 ☁︎ Innovators Hive デベロッパーやエンジニアのためのエリアです。 Google Cloud  のデモを体験し、学習プログラムや認定資格の最新情報を入手できます。 ぜひ会場で  Google Cloud  を共に学び、デベロッパー コミュニティと繋がりましょう。   ☁︎  体験  TAP for Gen AI 生成  AI  を活用した革新的なアイデアの創出を狙った  90  分間のアイディエーションを実施します。ソリューションや手段からではなく、 課題に焦点を当てて、生成  AI  で解決すべき問題を見つけましょう。   SCSKのセッションとブースのご紹介 SCSK セッションのご紹介 開始日時：8/1（木）14:00～14:30 タイトル： 明日からできる！業務で使える！多彩なAIを組み合わせたアーキテクチャとは？ 【概要】 生成AIは、様々な業界で革新をもたらしています。そして、AIにとってデータは燃料であり、その活用がAIの性能を大きく左右します。SCSKはGoogle Cloudを通じてデータ・生成AI活用に取り組み、経験とノウハウを蓄積してきました。本セッションでは、データから従来AI・生成AIを組み合わせたアーキテクチャをご紹介し、失敗談や成功談についてお話させていただきます。   取り上げる主な Google Cloud 製品 / サービス  BigQuery Dialogflow Vertex AI Search ※セッション レベル：初級 【SCSK登壇者のご紹介】 SCSK株式会社　ソリューション事業グループ クラウドサービス事業本部 データ＆AIソリューション部 第二課 AIリードエンジニア                青 木 琢人 SCSK のクラウド専門部隊に所属する、AI / ML サービスのリードエンジニア。Google Cloud の画像認識系AI、コンタクトセンターAI、生成AIを活用し、 製造業・金融業・食品業界など幅広いお客様のシステム設計・構築を担当。 生成AIを業務活用したい方、ぜひセッションへお越しください！ SCSKブース SCSKのブースでは、 ソーシャルインパクト パートナー オブ ザ イヤーを受賞したSCSKが提供する「 総合SIer × AI ・ 生成AI の可能性 」 をテーマに、SCSKが提供するAI技術とそのビジネス活用についてご紹介いたします。SCSKは、 AIだけではなく良いシステムイングレーションやデータ整備など、業務課題の解決に必要な全体検討と組み合わせで、最適な業務実装まで支援することができる点が強みです 。当日の展示では、技術知見に留まらない、実績に基づいた具体的なシステムイメージをお伝えします。 ぜひご来場いただき、最新のAI技術とSCSKだからできるビジネスへの活用方法についてご確認ください！ では皆様、 GoogleCloudNextTokyo’24を楽しみにお待ちください。 当日はSCSKセッションならびに Ask the Speaker、 展示ブースへの来場をお待ちしております！ 【招待コード  : FY24nx_pt030】 申し込み時にご入力ください ！

坂木です。 2024年6月12日-6月14日にかけて、幕張メッセで Interop24 Tokyo が開催されました。 SCSKはZabbix Japanと共同で出展いたしましたので、出展内容や出展感想等をご紹介いたします。   イベント概要 Interop Tokyoは、日本最大級のインターネットテクノロジーイベントであり、最新の技術や最新製品を紹介しています。 イベント内容としては、各企業ブースにてパネルディスカッションやワークショップ、ショートセミナーなどが実施されています。 Zabbixブースでは、Zabbix関連ソリューションのパネルディスカッションやショートセミナーを実施しました。   SCSKのZabbixブース出展内容 SCSKの展示では 監視ツールの移行 と Zabbix自動チューニング を紹介しました。 監視ツールの移行 Zabbixは、オープンソースソフトウェア（OSS）のためライセンス料がかからず、有償監視ツールから移行するとコストメリットが大きいことをご紹介しました。 また、監視ツール移行の手間という観点から見ても、Zabbixへの移行は自動化できる部分が多く、オペレーターの負担が少ないことも併せてご説明しました。 Zabbix自動チューニング 生成系AIを活用して、エラー内容の分析・原因調査・解決策提示を自動化する取り組みを紹介しました。 また、AIからの回答を元に、設定ファイルのエラー原因となっている箇所を自動で修正する手法も提案し、エラー発生から解決まで一切人を介在させず実現できることを示しました。   ちなみに、私は上記2項目を題材としてショートセミナーにて講演いたしました。 AI分野に興味を持つ方が多いのか、Zabbix自動チューニングの話をしているときは特に食いつきがよかった気がします。   感想 まず第一に、人が多いです。 Interopは規模が大きいITイベントということもあり、出店企業や参加者が非常に多かったです。   Interopでは各企業が最新のサービス・製品紹介を行っています。私はいくつかの企業ブースで話を伺いましたが、どれも聞いてて飽きることのない魅力的な内容で、多くの知見を得ることができました。 また、各企業ブースに話を聞きに行くとノベリティがもらえます。知見とノベリティが得られて一石二鳥です。 ちなみに、私は今治タオルとハイチュウをもらいました。   最後に 私は入社2年目で、IT業界での経験は浅く高い専門性を有してはいませんが、インタロップは楽しめました。そのため、ITに精通しているとまで言わなくても、多少ITを知っている方であれば楽しめるイベントだと思います。

こんにちは、広野です。 Amazon API Gateway REST API のロギングにはいくつか種類と方法がありますが、Amazon CloudWatch Logs は他の AWS サービスのログを見るときにも日々アクセスするため、なんだかんだ言うものの慣れているというのと、設定が簡単なので使いやすいです。 ですが、Amazon API Gateway に Amazon CloudWatch Logs に書き込みを許可する IAM ロールはその AWS アカウント共通の設定 なので、そのアカウントで最初に設定すると以後気にしなくなりますし、そもそも最初から設定されていたアカウントで作業する場合は何もすることがありません。そのため、私は新しい AWS アカウントで作業するときに必ずこの設定を忘れます。思い出すタイミングは、Amazon API Gateway のログ設定を有効にしようとしてエラーになるときです。 以下、備忘のため設定方法を書き落としておきます。 設定方法 まずは公式ドキュメントから。 API Gateway での CloudWatch による REST API のログの設定 - Amazon API Gateway Amazon API Gateway で CloudWatch によるログを設定する方法について説明します。 docs.aws.amazon.com   IAM ロールを作った後は、AWS マネジメントコンソールの以下の画面で IAM ロールを登録するだけです。   一応、AWS CloudFormation テンプレートにも落とし込んでおいたので、これを一発流すだけでも一通り設定できます。 AWSTemplateFormatVersion: 2010-09-09 Description: The CloudFormation template that creates an IAM Role and an account setting to push CloudWatch Logs from API Gateway. This setting is shared in your AWS account. Resources: # ------------------------------------------------------------# # API Gateway CloudWatchLogs Invocation Role (IAM) # ------------------------------------------------------------# ApigCloudWatchLogsInvocationRole: Type: AWS::IAM::Role Properties: RoleName: !Sub ApigCloudWatchLogsInvocationRole-${AWS::AccountId} Description: This role allows all API Gateways to invoke CloudWatch Logs. AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: Service: - apigateway.amazonaws.com Action: - sts:AssumeRole Path: / ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AmazonAPIGatewayPushToCloudWatchLogs ApigAccountSettingCloudWatchLogs: Type: AWS::ApiGateway::Account Properties: CloudWatchRoleArn: !GetAtt ApigCloudWatchLogsInvocationRole.Arn DependsOn: - ApigCloudWatchLogsInvocationRole   まとめ いかがでしたでしょうか？ このように AWS にはアカウント単位の共通設定がたまにあるので、管理方法も含めて気を付けていきましょう。 本記事が皆様のお役に立てれば幸いです。

こんにちは、SCSK株式会社の小寺崇仁です。 今回は「データベースモニタ」について設定方法を紹介します。 データベースモニタとは Zabbixのアイテムタイプに「データベースモニタ」があります。 データベースモニタでは、ZabbixサーバにインストールしたODBCドライバを使用して、監視対象のデータベースに接続し、任意のSQLを発行することができます。 このブログでは、ODBCドライバのインストール方法、アイテムの作成方法をご紹介します。 検証環境 AWS EC2 OS Red Hat Enterprise Linux release 9.4 (Plow) Zabbix 7.0.0 MySQL/MariaDB 10.5.22-MariaDB PostgreSQL PostgreSQL 13.14 on x86_64-redhat-linux-gnu SQLサーバ（MSSQL） Microsoft SQL Server 2019 (RTM-CU26) (KB5035123) – 15.0.4365.2 (X64) Oracle Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 – Production MySQL/MariaDB ODBCドライバのインストール（MySQL/MariaDB） # dnf install mariadb-connector-odbc インストールされたドライバのパスを確認（MySQL/MariaDB） cat /etc/odbcinst.ini ～～～～～～～～～～ [MariaDB] Description=ODBC for MariaDB Driver=/usr/lib/libmaodbc.so Driver64=/usr/lib64/libmaodbc.so FileUsage=1 ～～～～～～～～～～ アイテム作成（MySQL/MariaDB） アイテム名 任意   タイプ データベースモニタ   キー ※1行です。 db.odbc.select[ mysql_example, , Driver=/usr/lib64/libmaodbc.so; Database=zabbix; Server=127.0.0.1; Port=3306] Select用のキー 任意文字(第1引数) 不使用(第2引数) 上記で確認したパス 接続先のDB名 接続先のサーバ 接続先のポート データ型 任意   ユーザ DB接続ユーザー   パスワード DB接続パスワード   SQLクエリ 実行SQL 例：select version();   PostgreSQL ODBCドライバのインストール（PostgreSQL） # dnf install postgresql-odbc インストールされたドライバのパスを確認（PostgreSQL） cat /etc/odbcinst.ini ～～～～～～～～～～ [PostgreSQL] Description=ODBC for PostgreSQL Driver=/usr/lib/psqlodbcw.so Setup=/usr/lib/libodbcpsqlS.so Driver64=/usr/lib64/psqlodbcw.so Setup64=/usr/lib64/libodbcpsqlS.so FileUsage=1 ～～～～～～～～～～ アイテム作成（PostgreSQL） アイテム名 任意   タイプ データベースモニタ   キー ※1行です。 db.odbc.select[ pgsql_example, , Driver=/usr/lib64/psqlodbcw.so; Database=zabbix; Server=127.0.0.1; Port=5432] Select用のキー 任意文字(第1引数) 不使用(第2引数) 上記で確認したパス 接続先のDB名 接続先のサーバ 接続先のポート データ型 任意   ユーザ DB接続ユーザー   パスワード DB接続パスワード   SQLクエリ 実行SQL 例：select version();   SQLServer（MSSQL） ODBCドライバのインストール（MSSQL） # curl https://packages.microsoft.com/config/rhel/9/prod.repo | sudo tee /etc/yum.repos.d/mssql-release.repo # dnf install -y msodbcsql18 参考： https://learn.microsoft.com/ja-jp/sql/connect/odbc/linux-mac/installing-the-microsoft-odbc-driver-for-sql-server?view=sql-server-ver16&tabs=redhat18-install%2Calpine17-install%2Cdebian8-install%2Credhat7-13-install%2Crhel7-offline インストールされたドライバのパスを確認（MSSQL） cat /etc/odbcinst.ini ～～～～～～～～～～ [ODBC Driver 18 for SQL Server] Description=Microsoft ODBC Driver 18 for SQL Server Driver=/opt/microsoft/msodbcsql18/lib64/libmsodbcsql-18.3.so.3.1 UsageCount=1 ～～～～～～～～～～ アイテム作成（MSSQL） アイテム名 任意   タイプ データベースモニタ   キー ※1行です。 db.odbc.select[ mssql_example, , Driver=/opt/microsoft/msodbcsql18/lib64/libmsodbcsql-18.3.so.3.1; Database=master; Server=10.0.0.1; Port=1433; TrustServerCertificate=yes;] Select用のキー 任意文字(第1引数) 不使用(第2引数) 上記で確認したパス 接続先のDB名 接続先のサーバ 接続先のポート 接続エラー対策 データ型 任意   ユーザ DB接続ユーザー   パスワード DB接続パスワード   SQLクエリ 実行SQL 例：SELECT @@VERSION AS ‘SQL Server Version’;   Oracle ODBCドライバのインストール（Oracle） # mkdir /opt/oracle # cd /opt/oracle # wget https://download.oracle.com/otn_software/linux/instantclient/2111000/instantclient-basic-linux.x64-21.11.0.0.0dbru.zip # wget https://download.oracle.com/otn_software/linux/instantclient/2111000/instantclient-odbc-linux.x64-21.11.0.0.0dbru.zip # unzip instantclient-basic-linux.x64-21.11.0.0.0dbru.zip # unzip instantclient-odbc-linux.x64-21.11.0.0.0dbru.zip # echo /opt/oracle/instantclient_21_11 > /etc/ld.so.conf.d/oracle-instantclient.conf # ldconfig 参考： https://www.oracle.com/jp/database/technologies/instant-client/linux-x86-64-downloads.html アイテム作成（Oracle） アイテム名 任意   タイプ データベースモニタ   キー ※1行です。 db.odbc.select[ oracle_example, , Driver=/opt/oracle/instantclient_21_11/libsqora.so.21.1; Server_Name=10.0.0.2/ORCL; Port=1521] Select用のキー 任意文字(第1引数) 不使用(第2引数) 上記で確認しパス 接続先のサーバ/SID 接続先のポート データ型 任意   ユーザ DB接続ユーザー   パスワード DB接続パスワード   SQLクエリ 実行SQL 例：select * from v$version;   動作状況 このような形でデータ取得ができます。 最後に 弊社では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

こんにちは、SCSK株式会社の小寺崇仁です。 今回は「Java(JMX)監視」について設定方法を紹介します。 Java(JMX)監視とは Javaのプロセス内部は複雑で、独自のメモリ管理や、様々な処理が行われています。ZabbixではJavaのプロセスを監視することができ、テンプレートも準備されています。 しかし、設定が難しくあまり使われていないように思います。今回は、Zabbixサーバ側の設定とプロセス側の設定についてご紹介します。 Zabbixサーバーの設定 Javaを監視するには、「zabbix-java-gateway」といパッケージをインストールする必要があります。 「zabbix-java-gateway」サービスを起動して、「zabbix-server」から接続する設定をします。 インストール # dnf install zabbix-java-gateway # systemctl start zabbix-java-gateway # systemctl enable zabbix-java-gateway 設定 # vi /etc/zabbix/zabbix_server.conf JavaGateway=127.0.0.1 StartJavaPollers=1 # systemctl restart zabbix-server Javaプロセス側の設定 Javaのプロセス側ではJMXでリモート接続できるようにする必要があります。 設定を有効にするには起動時に以下のオプションを設定します。 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=12345 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false 次に設定方法の例をご紹介します。 単純なJavaプロセス 起動時の引数に設定します。先日の Seleniumサーバ の場合、次のように設定します。 java -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=12345 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -jar selenium-server-4.21.0.jar standalone --selenium-manager true Tomcatの場合  次の手順で確認しました。Tomcatではsetenv.shを作成すればオプションを読み込みます。 # mkdir /opt/tomcat # cd /opt/tomcat/ # wget https://dlcdn.apache.org/tomcat/tomcat-10/v10.1.25/bin/apache-tomcat-10.1.25.tar.gz # tar zxvf apache-tomcat-10.1.25.tar.gz # vi /opt/tomcat/apache-tomcat-10.1.25/bin/setenv.sh #!/bin/sh CATALINA_OPTS="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=12345 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false" export CATALINA_OPTS # /opt/tomcat/apache-tomcat-10.1.25/bin/startup.sh Zabbixのホスト作成 ホスト 任意   テンプレート Generic Java JMX Apache Tomcat by JMX 単純なプロセス用 Tomcat用 ホストグループ 任意   インターフェース JMX   　IPアドレス プロセスが起動しているサーバのIP   　ポート 引数で指定したポート   値の取得 このような形で値の取得ができます。 最後に 弊社では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

こんにちは、SCSK株式会社の小寺崇仁です。 先日Zabbixの7.0がリリースされました。 今回は「ブラウザモニタリング」について検証していきます。 ブラウザモニタリングとは ブラウザモニタリングとは、アイテムのタイプ「ブラウザ」というZabbix7.0の新機能になります。ブラウザを使用したWebサイトの操作をZabbixで再現して監視を行う機能になります。 Webシナリオ監視と類似した機能になりますが、違いは以下となります。 監視タイプ 概要 設定難易度 ブラウザモニタリング Seleniumを使用したスクレイピング 優しい Webシナリオ HTTPリクエスト、レスポンスを自作したスクレイピング 激ムズ 環境準備 ブラウザモニタリングを使用するには、Zabbix7.0とは別に、「WebDriverサーバ」を構築する必要があります。 「WebDriverサーバ」を構築する方法としては以下の2パターンあります。 SeleniumのDockerイメージを使用する SeleniumのStandaloneサーバを起動する ZabbixサーバにDockerを入れたくなかったので、私は２で検証をしました。 Dockerを使用する 検証はしておりませんが、次のURLに構築手順が記載してあります。 https://assets.zabbix.com/files/events/2024/conference_benelux_2024/KasparsM_browser_monitoring.pdf Standaloneを使用する 次の流れで、Selenium Standalone サーバを構築します。 Javaをインストールします。 Seleniumの公式HPから「Selenium Server (Grid)」をダウンロードします。 Selenium Standalone サーバを起動します。 Zabbixサーバのconfを編集します。 私が構築した際のコマンドは以下となります。 1.Java インストール # dnf install java-21-openjdk 2.Seleniumダウンロード # wget https://github.com/SeleniumHQ/selenium/releases/download/selenium-4.21.0/selenium-server-4.21.0.jar 3.Selenium起動 ※「--selenium-manager true」をオプションを付けることで各ブラウザのドライバーを自動ダウンロードできます。 # java -jar selenium-server-4.21.0.jar standalone --selenium-manager true 4.Zabbixサーバのconf編集 # vi /etc/zabbix/zabbix_server.conf WebDriverURL=http://localhost:4444 StartBrowserPollers=1 ※以下のバージョンで検証した際にエラーとなりました。そのため、Firefoxのドライバーを使用して回避しました。 Selenium-server：4.21.0、ChromeDriver：126.0.6478.126 アイテムの作成 サンプルでZabbixの管理画面にログインをして、キューの画面を監視したいと思います。 標準テンプレートで全体のキューの数しかわからないので、個別で監視を入れたいと思います。 項目 設定値 備考 アイテム名 キュー監視   タイプ ブラウザ   キー 任意   データ型 テキスト   スクリプト 次に記載   var browser = new Browser(Browser.firefoxOptions()); browser.navigate("http://localhost/zabbix/"); browser.findElement('css selector','#name').sendKeys("Admin"); browser.findElement('css selector','#password').sendKeys("zabbix"); browser.findElement('css selector','#enter').click(); browser.navigate("http://localhost/zabbix/zabbix.php?action=queue.overview"); return　browser.findElement('xpath','/html/body/div/main').getText(); ※Chromドライバーを使用するとエラーになったため、Firefoxを使用しています。 ※最後に「getText」で文字列を取得していますが、「getScreenshot」で画像（バイナリデータ）の保存もできます。画像データの表示については別途検証する予定です。 ※スクリプトを作成する際に以下のマニュアルが参考になります。 https://www.zabbix.com/documentation/current/en/manual/config/items/itemtypes/browser https://www.zabbix.com/documentation/current/en/manual/config/items/preprocessing/javascript/browser_item_javascript_objects 監視データ（取得値） このような形でキューの画面の内容をテキスト保存できます。 総括 ブラウザモニタリングでSeleniumが使用できるようになり、監視設定がとても簡単になったと思います。 （Webシナリオ監視では、リクエストを自作する必要があったため、hiddenにトークンが仕込まれていたり、jQueryでお洒落なつくりをしていた場合、発狂していました。） 今後はブラウザモニタリングが主流になっていくと思いますので、ぜひご活用ください。 最後に 弊社では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

こんにちは！SCSK の中山です。   先日、Cato×SCSKで開催された「Catoクラウド 1Dayハンズオンセミナー@東京」に参加してきました！ 私は4月に異動でCatoを担当することになり、今回は勉強のために参加させていただきましたが、”Catoとは何か”を理解するにはとても良いハンズオンでした。 少しセミナーから時間が経ってしまいましたが、今回はその内容をあくまで感想ベースで記事にしてみたいと思います。 この記事を見てCatoやセミナーの内容が気になった方は、大阪、名古屋で開催されるセミナーにページ下部のリンクよりお申し込みが可能です。   ハンズオン概要 Cato×SCSKで開催しているハンズオンセミナーは、私が参加した東京を含めた5都市で行われています。 このセミナーでは、Catoの導入にあたって使用するソケットを実際に触りながら、各機能をハンズオン形式で試すことができます。 参加人数も少ないため、ハンズオンで困った点や気になった点があれば、直接対応していただけます。 また、講師はCato社のエンジニアの方なので、その場でQ&Aに応じていただけるほか、Catoの導入を検討しているユーザー様であれば、弊社営業を含めた相談もできる体制になっています。   ●会場の様子 少人数のため、ハンズオンで詰まった時のフォローが手厚かったです。   当日のアジェンダ セクション   内容 時間 1 オープニング ・ご挨拶 ・ Cato×SCSK の取り組み紹介 ・ Cato Networks 紹介 /Cato クラウド概要 10:00–10:45 ２ ハンズオン（ AM ） ・ Cato 管理ポータル（ Cato Management Application ）概要 ・ Cato Socket ・ SD-WAN 10:45–12: １ 5 ３ 休憩 各自お昼休憩（ 60 分） 12: １ 5–13:15 ４ ハンズオン（ PM ） ・ ZTNA ・ Internet Firewall/WAN Firewall ・ TLS インスペクション / アンチマルウェア /IPS ・ RBI/CASB/DLP 、等 13:15–15:45 5 クロージング ・ Q ＆ A ・ご検討にあたって ・ Tips 、等 15:45–16:30   以降は当日の各アジェンダの概要を記載していきます。 オープニング Cato Networks社のチャネルセールスエンジニアの大森様より、Cato社、Catoクラウドの概要の説明をいただきました。 個人的に聞いていて以下の点が面白いなーと思いました。 Catoクラウドは”SASE”という言葉が生まれる前からサービス稼働している。 Catoクラウドをご存じの方はCatoクラウド=1SASE製品という認識されている方が多いのかなと思ってます。 実は”SASE”という言葉が生まれる前から、Catoクラウドは”SASE”の概念を持って設計されたサービスになっており、”SASE”という概念・言葉が生まれることにも携わっているというのが驚きでした！ Catoはシングルエンジンで稼働している。 Catoクラウドには様々なサービスがありますが、基本的なサービスはすべてPoP上で処理をしており、同じ構成を使って処理をしているとのことです。 これによりユーザとしてはログが同じ形式で出てくるため、まとめて確認・検索ができるようになります。 当たり前のようにコンソールから確認してましたが、セキュリティとネットワークのログをまとめて見れるって従来のセキュリティ・ネットワーク製品では意外とできなかったなと思いました。 ハンズオン環境 今回ハンズオンで使用する環境は以下の通りです。 会場にはユーザ2名ごとにソケットが用意されており、2名ごとにこちらの環境を参加者ごとに作成しました。   ハンズオン(AM) 午前中はソケットをインターネットに接続し、Cato管理ポータル（以下、CMA）から作成したサイト（各拠点）とソケットを紐づけ、ソケットからCatoを経由して通信することを確認しました。 その後、固定IPを指定することで、固定IPからNetflixのサイトにアクセスし、日本向けではなくドイツ向けのページにアクセスできることを確認しました。 ◆サイトの作成 会場からSite接続するために、ハンズオンの会場を1つの拠点と見立ててサイトを作成。   ◆PoP指定(frankfurt) Netflixへの接続時に、フランクフルト(ドイツ)のPoPが出口となるように、Network Ruleを追加。   ◆接続確認 フランクフルトからのアクセスとみなされ、ドイツのNetflixサイトが表示されることを確認。   ハンズオン(PM) 午後は、午前に行ったソケット経由のアクセスに続いて、各PCからのクライアント接続から始まり、アジェンダに記載された各種機能（CASB、RBIなど）の説明とハンズオンを実施しました。 以下にハンズオンで実際に試した内容を紹介します。   ◆ZTNA(Zero-Trust Network Access) 今回は、コンソールからモバイルアクセス用のユーザーを新規で作成し、アクセスを行いました。 午前の内容ではサイト接続からのルールを追加していたため、モバイル接続からのアクセスではルールが適用されず、日本のNetflixのページが表示されました。   ◆CASB(Cloud Access Security Broker) CASBとはCloud Access Security Brokerの略でSaaSサービスへの処理を制限することができる機能になります。 実際に使用する場面としては、ファイルの受け渡しでクラウドストレージからファイルのダウンロードはしたいけれど、ファイルのアップロードはさせたくないという場合に使える機能です。 ハンズオンでは、YouTubeの動画再生のみを制限し、YouTubeにアクセスはできるけれど動画を見ることはできないという形でCASBを実際に試しました。 ・Application Controlより、YouTubeの「watch stream」をブロックするルールを追加。 ・YouTubeの動画が見れないことを確認。 ◆RBI(Remote Browser Isolation) RBIとは、手元のクライアントのブラウザから直接Webページにアクセスするのではなく、クラウドの仮想環境上のブラウザからWebページにアクセスし、その映像をクライアントのブラウザに表示する機能です。 これにより、クライアントから直接Webページにアクセスすることがないので、Webページに含まれる脅威からクライアントを守ることができます。 Catoでは、危険なページへのアクセスはそもそもブロックすべきとのことで、グレーなサイトへのアクセス時に使用することが推奨されています。 今回のハンズオンでは、グレーゾーンのサイトへのアクセスではなく、RBIのテスト用のページにアクセスしました。   ・RBIが有効化されていることの確認。 ・Internet FirewallにCategoryが「Uncategorized」「Undefined」のページに対して、Actionが「RBI」でアクセスするようなルールを追加する。 ・「rbicheck.com」というRBIのテストサイトにアクセスし、ファイルのダウンロードが防がれていることを確認する。 最後に 私が参加したハンズオンセミナーの内容の一部を記事にしてみました。 今回のハンズオンや説明を受けた内容は、Cato導入時に必要な作業や知識であり、私のようにCatoを扱い始めた人や、今Catoの導入を検討しているけれど何ができるか、何をすればいいのか分からないという人にピッタリの内容だと思います。 東京開催は終わってしまいましたが、まだ4か所で開催予定ですので、 Catoクラウドを触ってみたい！ Catoって何ができるのか、イマイチ分からん、、 という方々は、場所や時間の都合もあるかと思いますが、ぜひ参加してみてください！   ●大阪(日程：7/18(木)) 世界初のSASEプラットフォーム Catoクラウド ハンズオンセミナー《午後開催》～全国5都市開催（東京/大阪/名古屋/博多/札幌）～ クラウドサービスの利用が拡大しワークスタイルが大きく変化する中、ランサムウェアを始めとするサイバー攻撃はより複雑・巧妙化し、被害は拡大の一途をたどっています。そこで、従来のネットワーク/セキュリティのレガシーアーキテクチャが抱える様々な課題... www.scsk.jp   ●名古屋(日程：7/25(木)) 世界初のSASEプラットフォーム Catoクラウド ハンズオンセミナー《午後開催》～全国5都市開催（東京/大阪/名古屋/博多/札幌）～ クラウドサービスの利用が拡大しワークスタイルが大きく変化する中、ランサムウェアを始めとするサイバー攻撃はより複雑・巧妙化し、被害は拡大の一途をたどっています。そこで、従来のネットワーク/セキュリティのレガシーアーキテクチャが抱える様々な課題... www.scsk.jp

みなさんこんにちは、鎌田です。 Prisma Cloud を使ったサービス開発、運営を行っている中での気づきや、使いこなし方などを皆さんと共有することで、クラウドセキュリティの重要性の認知度や対策レベルをみんなで徐々に上げられればいい、そういうモチベーションのブログ記事です。 ただの情報発信ではなく、Prisma Cloud の使いこなし方や、失敗から学んだ教訓など、少し具体的な実務よりの内容も共有していければと思います。 少し前に、Prisma Cloud の主の機能の１つ、CWPPについて確認、検証を行いましたので、これからそのナレッジを発信していきたいと思います。 今回は初回ということで、CWPPのアーキテクチャについて解説したいと思います。 CWPPのアーキテクチャ Prisma Cloud のCWPP機能は、大きく以下のアーキテクチャで成り立っています。 Prisma Cloud Console : セキュリティとコンプライアンスの管理を一元化するためのユーザーインターフェース Intelligence Stream（IS） : 最新の脅威インテリジェンスを提供するための機能 Defender : 各クラウドワークロード（仮想マシン、コンテナ、Kubernetesなど）に対するエージェント Radar : セキュリティ脅威やリスクをリアルタイムで可視化する機能 WildFire : 悪意のあるファイルや未知の脅威を分析し、インテリジェンスを提供するサービス これらの構成要素の関連を図にすると以下のようになります。 Prisma Cloud コンソールは、ISから脅威情報、Defenderからスキャン結果や不正な処理情報を受け取り、突き合わせを行い、危険な状態を可視化、アラート通知するというのが大まかな仕組みです。 そしてこれらのアーキテクチャをもとに、脆弱性・コンプライアンスの管理や、ランタイムプロテクション、ネットワークセグメンテーションといった機能を提供しています。 機能の説明は次回行いますので、今回はアーキテクチャについてもう少し具体的に解説していきます。 Intelligence Stream Prisma Cloud Intelligence Stream (IS) は、既知の脆弱性データベース、公式ベンダーフィード、各プロバイダーから集めた脆弱性データや脅威インテリジェンスをほぼリアルタイムに提供します。Prisma Cloud コンソールは自動的にISに接続し、特別な設定なしでアップデートをダウンロードします。IS は1日に数回更新され、コンソールは常にアップデートをチェックしてくれるので安心です。 Defender Defenderは、クラウド環境におけるワークロードやリソースをリアルタイムで保護するエージェントです。コンテナ、ホスト、サーバーレス環境など、さまざまなクラウドリソースを防御するために設計されています。仕様や動作原理については別の記事で詳しく解説予定ですので、ここでは、クラウド環境のワークロードを防御するためのエージェントという感じで理解しておいてもらえれば大丈夫です。 Radar 一言でいうと、クラウド環境におけるリソースの配置、接続状況、セキュリティリスクを視覚的に表示するダッシュボードのような機能を、よりグラフィカルな形で提供してくれるものです。以下のような情報をまとめてくれます。 クラウドリソースの全体マップ 各リソースのセキュリティステータス ネットワークトラフィックの視覚化 リソース間の依存関係と接続状況 WildFire Palo Alto Networksが提供するマルウェア分析および脅威インテリジェンスサービスで、以下のような解析を行います。 静的解析 ：ファイルのコードを解析し、悪意のあるパターンを検出します。 動的解析 ：サンドボックス環境でファイルを実行し、その動作を観察します。これにより、未知のマルウェアも検出できます。 機械学習 ：機械学習アルゴリズムを使用して、未知のマルウェアを検出し、既知のマルウェアと比較して分類します。 まとめ CWPPの構成要素について解説しました。初回ということでまずは簡単な解説までとなりますが、この後は各構成要素を深掘りしたり、導入や設定等、実際に手を動かしてみたところを、より具体的に解説していこうと考えています。 最後に、当社ではPrismaCloudを用いたマネージドサービスを提供しているので紹介させてもらいます。 ＝＝＝ 【CSPMマネージドサービス SmartOneCloudSecurity】 SmartOneCloudSecurityは、Prisma Cloud を用いたCSPMマネージドサービスです。Prisma Cloud の導入から設定変更まで、弊社技術担当者がお客様のCSPM対策をサポートします。CSPMの導入を検討中の方はもちろん、Prisma Cloud を利用中だけど機能や運用面でもっと上手に活用したい、というような課題をお持ちな方は、お気軽に下記URLからお問い合わせください。Prisma Cloud のPoCの相談も受けています。 New!! CWPPの導入サポートも始めました！ Smart One Cloud Security® パブリッククラウドのセキュリティ設定を診断/監視するマネージドCSPMサービスです。Palo Alto Networks社Prisma Cloud（CSPM機能）を使い易く、簡単に導入いただけます。 www.scsk.jp

こんにちは。SCSKのふくちーぬです。 2024/6/26時点で、Amazon InspectorのLambdaコードスキャンがPython3.12のランタイムでも動作確認できたので紹介します。   Amazon Inspector とは Amazon Inspector は、ソフトウェアの脆弱性やネットワークの接続性について AWS ワークロード(Amazon EC2,Amazon ECR,AWS Lambda)を継続的にスキャンする脆弱性管理サービスです。 Lambda スキャンについて 種類 説明 Lambda 標準スキャン Lambda 関数とそのレイヤー内のアプリケーションの依存関係をスキャンして、パッケージ脆弱性がないか調べます。  Lambda コードスキャン 関数やレイヤー内のカスタムアプリケーションコードをスキャンして、コードの脆弱性がないか調べます。   Amazon Inspector による AWS Lambda 関数のスキャン - Amazon Inspector Amazon Inspector による AWS Lambda 関数のサポートにより、Lambda 関数とレイヤーのセキュリティ脆弱性を継続的に自動評価できます。Amazon Inspector では、2 種類の Lambda スキャンを提... docs.aws.amazon.com 検証 今回は、Lambdaコードスキャンに着目して脆弱性の検出及び修正を実施します。 Amazon Inspector の有効化 以下手順に従って、有効化しておいてください。 15日間の無料トライアル期間があります。料金は、スキャンした回数に応じて課金されますのでご留意ください。 Amazon Inspector の開始方法 - Amazon Inspector Amazon EC2、Amazon ECR、および Lambda リソースタイプ全体の脆弱性を検出するためのベストプラクティス設定で Amazon Inspector をセットアップします。 docs.aws.amazon.com AWS CloudFormation テンプレート 以下のテンプレートをデプロイしてください。 ここでは、脆弱性を持つコードとして機密情報をハードコーディングしています。 AWSTemplateFormatVersion: 2010-09-09 Description: For Lambda Code Scan Parameters: ResourceName: Type: String Resources: # ------------------------------------------------------------# # Lambda # ------------------------------------------------------------# Function: Type: AWS::Lambda::Function Properties: FunctionName: !Sub ${ResourceName}-lambda-function Role: !GetAtt LambdaRole.Arn Runtime: python3.12 Handler: index.lambda_handler # Environment: # Variables: # AWS_SECRET_ACCESS_KEY: '{{resolve:secretsmanager:aws_secret_access_key:SecretString:sample_key::}}' Code: ZipFile: !Sub | import boto3 import os import json def create_session_noncompliant(): import boto3 # Noncompliant: uses hardcoded secret access key. sample_key = "AjWnyxxxxx45xxxxZxxxX7ZQxxxxYxxx1xYxxxxx" boto3.session.Session(aws_secret_access_key=sample_key) #def create_session_compliant(): # import boto3 # # Compliant: uses environment variable for secret access key. # sample_key = os.environ.get("AWS_SECRET_ACCESS_KEY") # boto3.session.Session(aws_secret_access_key=sample_key) def lambda_handler(event, context): create_session_noncompliant() # create_session_compliant() return { 'statusCode': 200, 'body': json.dumps('Hello form Lambda') } # ------------------------------------------------------------# # Log Group # ------------------------------------------------------------# FunctionLogGroup: Type: AWS::Logs::LogGroup Properties: LogGroupName: !Sub "/aws/lambda/${Function}" # ------------------------------------------------------------# # IAM Role # ------------------------------------------------------------# LambdaRole: Type: AWS::IAM::Role Properties: RoleName: !Sub ${ResourceName}-lambda-role AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Action: sts:AssumeRole Principal: Service: - lambda.amazonaws.com ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole   脆弱性の検出 パスワードやアクセス キーなどのアクセス資格情報を、ソース コードにハードコードしたため、脆弱性が検出されました。 ディテクターの名前を押下すると、以下のリンクに飛びます。 Hardcoded credentials | Amazon CodeGuru, Detector Library Credentials, such as passwords and access keys, should not be hardcoded in source code. docs.aws.amazon.com 脆弱性が発生した箇所もピンポイントで示してくれます。 内部で生成AIが利用され自動推論と機械学習を使用してコードを評価してくれるおかげで、修復方法も一目瞭然です。 ランタイムPython3.12でも検出されることを確認できました。 提案された修正コードを利用して、Lambdaを更新していきます。 AWS Secrets Manager の作成 機密情報をテンプレート内に記載するのではなく、AWS Secrets Manager から読み取るために事前にSecretを作成しておきます。 AWS Secrets Manager シークレットを作成する - AWS Secrets Manager AWS Secrets Managerでシークレットを作成する方法について説明します。 docs.aws.amazon.com 脆弱性を持つコードの修正 以下のテンプレートを使用して、スタックを更新します。 AWSTemplateFormatVersion: 2010-09-09 Description: For Lambda Code Scan Parameters: ResourceName: Type: String Resources: # ------------------------------------------------------------# # Lambda # ------------------------------------------------------------# Function: Type: AWS::Lambda::Function Properties: FunctionName: !Sub ${ResourceName}-lambda-function Role: !GetAtt LambdaRole.Arn Runtime: python3.12 Handler: index.lambda_handler Environment: Variables: SAMPLE_SECRET_ACCESS_KEY: '{{resolve:secretsmanager:aws_secret_access_key:SecretString:sample_key::}}' Code: ZipFile: !Sub | import boto3 import os import json # def create_session_noncompliant(): # import boto3 # # Noncompliant: uses hardcoded secret access key. # sample_key = "AjWnyxxxxx45xxxxZxxxX7ZQxxxxYxxx1xYxxxxx" # boto3.session.Session(aws_secret_access_key=sample_key) #def create_session_compliant(): import boto3 # Compliant: uses environment variable for secret access key. sample_key = os.environ.get("SAMPLE_SECRET_ACCESS_KEY") boto3.session.Session(aws_secret_access_key=sample_key) def lambda_handler(event, context): # create_session_noncompliant() create_session_compliant() return { 'statusCode': 200, 'body': json.dumps('Hello form Lambda') } # ------------------------------------------------------------# # Log Group # ------------------------------------------------------------# FunctionLogGroup: Type: AWS::Logs::LogGroup Properties: LogGroupName: !Sub "/aws/lambda/${Function}" # ------------------------------------------------------------# # IAM Role # ------------------------------------------------------------# LambdaRole: Type: AWS::IAM::Role Properties: RoleName: !Sub ${ResourceName}-lambda-role AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Action: sts:AssumeRole Principal: Service: - lambda.amazonaws.com ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole Amazon Inspector の確認 Amazon Inspector の検出結果画面にて、該当のLambdaが表示されていません。 無事コード脆弱性に対処することができました。 まとめ ・実環境でPython3.12についてもLambdaコードスキャンの対象として動作を確認しました。 日本語ドキュメントでは、Python3.12はサポートされていないと記述されておりますが、英語ドキュメントではサポートしている旨が記述されています。 Amazon Inspector でサポートされているオペレーティングシステムとプログラミング言語 - Amazon Inspector Amazon Inspector が脆弱性を検出するためにスキャンできるオペレーティングシステムとプログラミング言語について説明します。 docs.aws.amazon.com Operating systems and programming languages that Amazon Inspector supports - Amazon Inspector Learn about the operating systems and programming languages that Amazon Inspector supports to detect vulnerabilities. docs.aws.amazon.com ※2024/2/21時点では、日本語ドキュメント及び英語ドキュメント双方ともPython3.11までしかサポートしておりませんでした。実環境においてもPython3.12を検証したところ、スタータス欄に”サポートされていないランタイム”と表示され、コードスキャンの対象外であることを確認済みでした。 他のランタイムについては、本検証では未確認となりますので、Amazon Inspector 及び AWS Lambda 導入時にはご自身で検証の上ご利用ください。 最後に いかがだったでしょうか。 公式ドキュメントを英語で読むこと、きちんと動作検証をすることが重要であることを実感する良い機会になりました。 本記事が皆様のお役にたてば幸いです。 ではサウナラ～🔥

こんにちは、SCSK株式会社の川原です。 6月20日～21日の2日間にわたり、幕張メッセで開催された” AWS Summit Japan 2024 “に出展しました。 SCSKはプラチナスポンサーとして、スポンサーセッションとブースを出展しました！ 出展概要に関する内容は、以下をご確認ください。 AWS Summit Japan 2024に出展します！ SCSKは 2024/6/20(木)～6/21(金)開催の日本最大の AWS を学ぶイベント「AWS Summit Japan」に出展します。 SCSKセッションでは、”データセンターのラックぜんぶ抜く！SCSK だからできる脱オンプレの秘策とは？”というテーマで、沖電気工業様のマイグレーション事例をご紹介いたします。 blog.usize-tech.com 2024.05.09 当社セッション クラウド Lift & Shift の秘訣 について、沖電気工業様と当社の取り組みをご紹介させていただきました。2日目の最終セッションにもかかわらず、多くの方々にご来場いただきました。 今回は、沖電気工業株式会社のCIOである高島様にご登壇いただき、共にお話しできたことで、クラウド移行を成功させるために両社がどのように協力し、その困難を乗り越えたのかをより深くご理解いただけたのではないかと思います。 足を運んでいただいた皆様ありがとうございました！ 出展ブース 展示ブースでは、「 AWS愛が、凄い。SCSK 」をテーマに、 SCSK独自ソリューションの4商材を展示、ミニシアターでは7つのAWS関連ソリューションから発表させていただきました 。出展ブースの詳細に関しては、以下の記事をご確認ください。 【近日開催！】AWS Summit Japan 2024「AWS愛が、凄い。SCSK」ブースのご紹介！ SCSKは、いよいよ開催が迫る「AWS Summit Japan」に出展します。 ブースでは「AWS愛が、凄い。SCSK」をテーマに独自ソリューションの4商材を展示、ミニシアターで7つのAWS関連ソリューションから発表いたします。 blog.usize-tech.com 2024.06.11   展示商材 展示商材のご紹介では、 実際のデモンストレーションを通じて、各ソリューションの具体的な機能や利便性を直接体験していただくことができました 。各ソリューションがどのようにお客様のビジネス課題を解決するのか、より深く理解していただけたことと思います。   ミニシアター ミニシアターでは、7つのAWS関連ソリューションについて1日に各2回ずつ講演を行いました。 最新の技術トレンドを交えながら、SCSKの豊富なソリューションの特長やAWS活用について専門スタッフがご紹介しました 。 当日表彰された AWS Ambassador や AWS Top Engineer も多く登壇し、多くのお客様が足を止めて聞いてくださいました。   予想を上回る多くのお客様にお立ち寄りいただき、盛況のうちに展示会を終了いたしました。ブース対応を担当したメンバーからは、嬉しい悲鳴を上げるほどの反響でした。ご来場いただいた皆様に心より御礼申し上げます！   フォローアップセミナーを開催します！ AWS Summit Japan 2024でのセッションや展示ブースを通じて、お悩みを解決したい方やご興味を持たれた方々に向けて、 クラウド移行 と 生成AI に関する フォローアップセミナーを開催いたします 。 本セミナーでは、Summitでの内容をさらに深掘りし、皆様のビジネスにどのように役立てるかについて詳しくお話しします。ぜひご参加ください！ クラウドネイティブ化にも対応！ ITX for MCP SCSK版でAWS移行を最適ルートで実現しよう SCSKのAI活用紹介セミナー ～AWSとInfoWeaveで社内チャットボットを始めよう～ このようなお悩みをおもちではありませんか？ 移行対象はDBや基幹系など様々だが、確実に移行するナレッジが不足 AWS移行後、運用やDX推進できるか不安 クラウドネイティブってなにから始めたらいいのかわからない・・・ AWSへの大規模移行やクラウドネイティブ化を最適ルートで実現するソリューションパッケージ「AWS ITトランスフォーメーションパッケージ(ITX) for MCP SCSK版」が、そのお悩み解決します。 本セミナーでは、AWS Summit Japan 2024でもご紹介したITXの事例や活用方法について、詳しくお伝えします。 お申し込みは こちら AIチャットを導入し業務効率を向上させたいと考えている中、スキルや体制の不足により、実現が難しい状況にお悩みではありませんでしょうか？ 本セミナーでは、AWSとRAG構築テンプレート「InfoWeave」を活用して社内チャットボットを簡単に始められる方法をご紹介いたします。 さらに、今年6月に開催されるAWS Summit Japan 2024のアップデート情報とあわせてAWSのAI系サービスについてもご紹介させていただきます。 社内情報を活用した生成AIを導入したい方には必見の内容となっていますので、是非ご参加ください。 お申し込みは こちら   最後に 弊社のセッションおよびブースへご来場いただいた方々、誠にありがとうございました！ 多くの皆様に会えたことをとてもうれしく思います。これからもお客様のビジネスを支援に尽力いたします。 今後ともSCSKのAWSサービスをよろしくお願いいたします。

CatoクラウドのBackhaulingという機能はご存知ですか？ 通常、Catoクラウド経由でインターネット接続をする際、トラフィックはCatoクラウドのPoPから出力されますが、Backhaulingを利用することで Catoクラウドに接続する特定サイト(拠点)から直接出力 させることができます。 今回は、Backhaulingについて解説していきます！ 「Internet Breakout」と 「Local gateway IP」 冒頭でお伝えした通り、BackhaulingをさせるとCatoクラウドのPoPではなく、Catoクラウドに接続する特定サイト(拠点)から直接インターネットに接続させることができます。 また、Backhaulingには以下の 2種類があります。 特定サイト(拠点)のSocketからトラフィックを出力させるか、 Firewallなどの特定の 機器から出力させるかにより異なります。 Backhaulingの種類とその違い Local gateway IP ： Firewallなどの既存機器 からトラフィックを出力させる場合に使用 Internet Breakout： Socket からトラフィックを出力させる 場合に使用 「Internet Breakout」は別記事でご紹介することにして、 本記事で は1つめの「Local gateway IP」についてご紹介 します！ 「 Local gateway IP」の ユースケース ※本記事では「Local gateway IP」のユースケースの一例をご紹介します。 まずは結論から。Backhaulingの「Local gateway IP」は Catoへの移行途中に活躍 します 。 現行ネットワークからCatoへ移行する際、Firewallなどのセキュリティアプライアンス機器からCatoクラウドのInternet Firewallへポリシーの移行が必要となりますが、Backhaulingを使えばこの移行作業を段階的に行うことができます。 例えば、下図のような構成の場合です。 本社内に設置された現行のFirewallを残しつつ、Firewallの上位にSocketを設置します。 この場合、支店のユーザやモバイルユーザからexample.comへのトラフィックのみを 本社 内のFirewallにて処理させることができます。 このように、Backhaulingの 「Local gateway IP」は主に 「一部トラフィックのみ、現行機器のセキュリティポリシーを適用させたい」といった場合に利用されます。 ここで注意いただきたいのは、 BackhaulさせたトラフィックもCatoクラウドを経由する という点です。 そのため、Catoクラウドのセキュリティポリシーも適用されます。 つまり、この例ですと 支店のユーザやモバイルユーザからexample.com へのトラフィックは、Catoクラウドのセキュリティチェックを突破したのちに本社のFirewallへルーティングされFirewallのセキュリティチェックが行われるという流れになります。 「Local gateway IP」の設定例 上記ユースケースを踏まえ、設定手順をまとめてみました。 構成例 今回は、下図の構成を想定します。 支店のユーザから、 example.com へのトラフィックのみをBackhaulさせ、本社のFirewallによるセキュリティチェックを適用させるというシナリオです。 設定手順 Backhaulingは下記の順番で設定をします。 Step１： Gatewayサイトの定義 →インターネット接続の出口となる拠点をGatewayサイトとして定義します。 → 今回は、Firewallが設置されている”本社”というサイトをGatewayサイトとして定義します。 Step２：Network Ruleの作成 →対象トラフィックをGatewayサイトに向けるためのルーティングの設定を行います。 → 今回は、支店のユーザから example.com へのトラフィックのみを”本社”にルーティングさせます。 Gatewayサイトの定義 設定箇所：Network＞Site＞Site Configuration＞Backhauling 「Use this site as a backhauling gateway」のチェックボックスにチェックを入れます。 「Select the destination for the traffic」の設定項目が出力されます。 ここで 「Internet breakout」か「Local gateway IP」のどちらかを選択しますが、今回は「Local gateway IP」を選択します。                 上の手順で「Local gateway IP」を選択すると、IPアドレスの設定項目が出力されます。 ここではGatewayサイト内のどの機器で処理させるかを指定します。 今回はFirewallでトラフィックを処理させたいので「172.15.21.254」を入力します。                ここまででStep1のGatewayサイトの定義は完了です。 次にStep2のNetwork Ruleの作成に進みます。 Network Ruleの作成 中国のユーザからの接続の場合や、中国の拠点をGatewayサイトとする場合は、中国のインターネット規制に違反していないことを事前に確認し、設定を行う必要があります。 設定箇所：Network＞Network Rules 「New」からルールを作成していきます。 本記事ではNetwork Rulesの詳細な説明は省略いたしますが、今回は以下の通り設定をしています。   ・Name：Backhauling test ・Rule Type：Internet ・Source：Site(支店) ・App/Category：Domain(example.com) ・Configuration    – Bandwidth priority：P255    – Priority Transport：CATO(Automatic)    – Secondary Transport：None ConfigurationのRouting Methodでは「Backhaul via」を選択します。 「Backhauling Gateway Site」の設定項目が出力されるので、+ボタンからStep1で設定したGatewayサイトを選択します。 最後に「Save」ボタンで設定保存をします。 これで設定は完了です。 補足～「Local gateway IP」×「Backhaul hairpinning」～ 上の例では、Gatewayサイトの外からのアクセスとなっておりましたが、Gatewayサイト内からでもBackhaulさせることができます。 この場合は Backhaul hairpinning と呼ばれ、一部トラフィックはPoPを介してヘアピンされ、さらにGatewayサイトに転送されます。 例えば、下図のような構成の場合です。 本社のユーザからexample.comへのトラフィックのみ赤線の経路で本社内のFirewallに転送させ、Firewallにてトラフィックの処理をさせることができます。 このように、Backhaul hairpinningも上の例と同様で、一度 Catoクラウドを経由させることで移行作業を段階的に行うことが可能です。   Backhaul hairpinningの設定方法は通常のBackhaulingの設定とほとんど変わりません。 違うところは、Network RulesのRouting Methodです。 Backhaul hairpinningの場合は下図のように「Backhaul via」ではなく「Backhaul hairpinning」を選択します。 さいごに 本記事ではBackhaulingの「Local gateway IP」についてご紹介させていただきました！ 「Internet Breakout」については、別の記事にてご紹介します。

こんにちは。SCSKのふくちーぬです。 2024/6/20(木)～2024/6/21(金)に開催されたAWS Summit Japan 2024 に参加してきました。 AWS Summit Japan | 2024 年 6 月 20 日（木）, 21 日（金） オンデマンド配信中 AWS Summit は、AWSに関して学習し、ベストプラクティスの共有や情報交換ができる日本最大級の AWS イベントです。基調講演・150 を超えるセッション、さらに 250 以上の展示やハンズオンなどのEXPOコンテンツを体験し、皆様... aws.amazon.com 認定者ラウンジ 資格取得者のみ利用できるラウンジスペースと特典の配布会場です。 全冠の旨を伝えると、「おめでとうございます！」と言って貰えました。なんだか恥ずかしかったです（笑） SAP,DVA,SOAのステッカーとボトルは既に配布終了していました。。皆さんのAWS認定の注目の高さが分かります。 EXPO - AWS Summit Japan | AWS AWS Summit は、AWSに関して学習し、ベストプラクティスの共有や情報交換ができる日本最大級の AWS イベントです。 aws.amazon.com SCSKブース 弊社のブースにも立ち寄ってみました。 生成AIを活用したRAGソリューション（InfoWeave）、IoTを活用した製造業向けデジタル化ソリューション（Duetics）等、見どころたっぷりの展示やミニセッションでした。 生成AI RAGソリューション InfoWeave｜SCSK株式会社 生成AI RAGソリューション（InfoWeave（インフォウィーヴ））は、S-Cred⁺ ※ の生成AIオプションサービスです。 www.scsk.jp Duetics（デュエティクス） Duetics（デュエティクス）は、製造現場のデジタル化を支援するトータルソリューションです。製造業のお客様が求める高速かつ高い柔軟性を持つクラウドのデータ分析アプリケーションをはじめ、現場からクラウドへの直結ネットワーク、そして現場でのデ... www.scsk.jp 今年のAWS Summitは、AWS社含めたどのパートナー企業も生成AIやIoT,データ活用にかなり力をいれていました。 大規模クラウドインフラ設計・構築案件の歩き方 AWS社によるセッションです。 インフラ構築プロジェクトに参画している私としては、今回一番楽しみにしていたセッションとなります。 大規模クラウドインフラ設計・構築案件の歩き方 クラウド技術のコモディティ化により、エンタープライズ分野では近年、AWS 上での大規模なアプリケーション開発が一般的になりつつあります。これを支えるクラウドインフラ設計についても、求められる非機能要件の高度化と関連する AWS サービスの多... japansummit.awslivestream.com 聴講者として以下を想定しているそうですが、AWSに限らず全エンジニアにおすすめしたいコンテンツとなっています。 　概要：大規模クラウドインフラの設計・構築案件で得た知見や学びが体系的にまとまっている 　想定聴講者：インフラ設計発注者・受注者・内製担当者 設計 設計の骨組みづくり 以下は簡単なサンプルですが、インフラ設計書の目次となります。配属当時に知っていたら、どんなに助かったことかと思いました。 設計書一覧は可能な限り詳細に記載することで、バイネームで担当者を割り当て責任所在を明確にすること 設計事由を残すことで、設計の見直しができる状態にしておくこと 詳細設計書は、人へ分かりやすく伝えるために構築時点では詳細設計書+IaC。それ以降は、IaCを正とすること アプリ/インフラチームの責任分界 どこまでインフラチームまでの担当で、どこからアプリチームの担当であるか線引きすることはなかなか難しいですよね。 選定した開発方針とガバナンスを元に、要件に応じてインフラ/アプリチーム相互に議論して線引きを決めること コーディングルール プログラム言語で記述するのと同じくIaCでも、コーディングルールを決めておかないと品質低下につながります。 IaCにもコーディングルールは必要である（利用ツール、命名規則、スケルトンコードの利用等） 静的解析 IaCコードは、デプロイ前に必ず事前にチェックしておかないとデプロイ時に意図しないエラーやリソースが作成されるので留意しましょう。 書式のチェック(cfn-lint)、セキュリティの強制(cfn_nag)を実施するべき 構築 コスト管理はいますぐはじめる 開発開始時点で始めることが鉄則である（コスト異常検知や利用状況に気づけるように、最低限Budgets,Cost Explorerを導入しておくべき） クリティカルパスの特定 大規模/本番構築はIaCのみでは完結しないため、どのタスクがどの方法で構築することが合理的なのか、リードタイムはどれくらいなのか設計段階時に調査しておくべき 展開手順の整備 IaCコードのみに着目されがちですが、デプロイは繰返し実施されるため、更新手順や削除手順等のドキュメントを整備しておくことも忘れてはいけません。 IaC/手動/申請系を区別し、時系列や依存関係を踏まえて第三者でも分かりやすい表現でドキュメントを作成すること クラウドリソースのテスト 最後にテストについてです。 最低限、実環境・疎通性・性能の3要素に焦点を当ててテストを実施するべき Serverlesspresso – コーヒーをサーバレスとともに – カフェの注文システムをサーバレス構成で実装し、実際にコーヒーまで頂くことができるブースです。 Serverlesspresso バリスタの舞台裏 ~Happy Coffee, Happy Coding ! ~ - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS スマートフォンから注文できるコーヒー カウンター用のマルチテナント・イベント駆動型サーバーレス アプリケーション "Serverlesspresso" を提供する背景とその仕組みをご紹介します。 aws.amazon.com 5分間で10杯までしか注文を受け付けないことで、バリスタがきちんとお客さんを捌くことができます。 さすがにお客さんが増えてくると、QRコードの読み取りの待ち時間が増えているようでした。1人当たりのバリスタの処理時間をシステムの処理時間制約としている点が興味深かったです。   何とか注文できました。 無事エスプレッソを飲み、一息つくことができました。 『たまごっち』シリーズの進化と、AWS IoTで築いた 『Tamagotchi Uni』で つながる世界 続いてバンダイ様のセッションです。みなさんご存じ『たまごっち』の裏側の紹介です。 運用管理の負荷軽減と開発スピードを上げるために、サーバレスサービスをフル活用し設計しています。 IoTを利用する上で、重要な課題であるファームウェアのアップデート課題の向き合い方が非常に勉強になりました。 以下の2つを実践することで、解決していました。 アップデート対象機器に優先順位を付ける AWS IoT Device Managementの機能であるDynamic Groupの利用 この結果、世界中の皆さんの手元にあるどの『たまごっち』も仲間外れにされることなく、最新機能が配信されたと同時に遊ぶことが可能になっているんですね。 最後に いかがだったでしょうか。AWS Summit の現地レポートをお届けしました。 現地開催は、AWSの熱気や技術の面白さを生で感じ取ることができる良い機会だと改めて認識しました。 個人的には、7月発売予定の『たまごっち』が待ち遠しいです。 本記事が皆様のお役にたてば幸いです。 ではサウナラ～🔥

こんにちは、ひるたんぬです。 先日AWS Summit Japanに初参加してきました。 最初から最後まで、その規模の大きさに圧倒され、あっという間に一日が経っていました。 参加レポについてはTechHarmonyにおいても他の方が書かれると思うので、今回はサミットに参加して、私がふと思った点について書こうと思います。 技術的な内容はありませんので、寝る前の読み物として…などで読んでいただけますと幸いです。 思ったこと AWS Summitの基調講演や各セッションを見ていると、多くのセッションでアーキテクチャの説明が行われていました。その際に、 〇〇はAPI Gatewayを通してアプリケーションからのアクセスを可能にしています。 ここの部分についてはサーバレスにて設計しています。 などの説明と同時にアーキテクチャ図が投影されていました。 これを見ながら説明を聞くと、「こういう構成をしているのか～」や、「ここってこうじゃないの、なんでだろう…」と、各セッションの取り組みをより深く理解することができるなぁ～と感じました。 （なんとなくでも、やっていることや構成が理解できるようになってきたのが嬉しい今日このごろです。） と同時に、それぞれのセッションで投影されるアーキテクチャ図のスタイルに少なからず違いがあり、「標準的な書き方やガイドラインって何かあるのかな？」と漠然と思ったので、調べてみました。   結論 ありました。それも結構細かったです。びっくりしました。   具体的には？ AWS アーキテクチャアイコンの配布サイト にてガイドラインを確認することができました。 以下にその内容についてまとめていきます。 ガイドラインはすべて英語で記載されています。 私がまとめた内容と実際のガイドラインに齟齬がある場合がありますので、厳密に確認が必要な場合などは、公式ガイドラインをご確認ください。 「Release 18-2024.02.06」の資料を基に作成しております。 アーキテクチャ図の作成手順 カラーテーマを選ぶ アーキテクチャアイコンには、背景色のタイプに合わせて「ライトテーマ」と「ダークテーマ」の2つが用意されています。作成物に合わせてより適切な方を選択します。 「ライトテーマ」はWebサイト、「ダークテーマ」はプレゼン資料で用いられる傾向があるようです。 リージョンやVPC（”Groups”と表現されています。）を配置する 大枠の構造として、グループを配置します。 アーキテクチャアイコンやリソースアイコンを配置する アイコンセットから必要なアイコンを選択し、適切な位置に配置します。 矢印でそれぞれのアイコンを結ぶ 矢印でアイコンを結び、ワークフローを表現します。 【オプション】ステップを追加する アーキテクチャ図内に番号を付与することで、手順をわかりやすく表現できるようにします。 縦長なレイアウト（Wordやブログ記事など）の場合 この場合はPowerPointのスライドを縦長に設定し、アーキテクチャ図を作成します。 PowerPointで「新しいプレゼンテーション」を作成する スライドのサイズを変更する 「デザイン」→「スライドのサイズ」より「ユーザー設定のスライドのサイズ」を押下します。 幅に「6.5″」、高さに「8.75″」と入力し、「OK」を押下します。 背景色は白色に設定しておきます。 ガイドラインに従いアーキテクチャ図を作成する 上記「アーキテクチャ図の作成手順」を参考にしてください。 図として貼り付ける 作成したアーキテクチャ図をすべて選択しコピーし、Wordにて「図として貼り付け」をします。 ブログ記事への貼り付け時や画像ファイルで保存したい場合などは、すべて選択したあとに右クリック→「図として保存」を選択することで可能です。 “Training and Certification” の場合 過去のガイドラインでは、スライド投影時のガイドラインとして記載されていたようですが、タイトルが変更されています。直訳すると「トレーニングと認定」ですが、これが何を指しているかはガイドラインから理解することはできませんでした… 過去のガイドライン記事の参考： 株式会社BeeX 「AWSのアーキテクチャ作図ガイドラインを確認してみた」 テキストサイズと色について テキストサイズは「16pt」で「黒色」にしてください。 アイコンサイズと色について アイコンサイズや色は変更しないでください。 線の太さと色について 線の太さは「2pt」で、色は変更しないでください。 アイコンや線の色を変更しない理由として、アクセシビリティの検証を行っているためとありました。 各種デザインの使用上の注意 以降では、種類別にアーキテクチャ図に挿入する上での注意事項が記載されています。 グループ（VPC, サブネットなど） サイズの変更方法 枠の右下を選択して実施してください。 ネスト(入れ子に)する場合 それぞれのグループの線の間に最低でも0.05″の間を空けてください。 引用：AWS 「 AWS アーキテクチャアイコン PowerPoint用ツールキット 」 プリセットに適したものがない場合は”genetic group”を使用すること 必要に応じて自分でカスタムグループを作成すること カスタムグループの雛形が用意されているため、アセットにあるアイコンと入れ替えて使用します。 入れ替えるアイコンはサイズ(ファイル名などに”32″とあります)や拡張子(.svg)の指定があります。 未承認のAWSアイコンを使用してグループを作成すること グループに設定するアイコンのサイズを変更すること アイコン サイズの変更 プレゼンテーションで使用する場合のみ拡大・縮小が許可されています。 縦横比を維持するため、Shiftキーを押下したままサイズの変更をしてください。 プレゼンテーション以外の用途では、サイズの変更はしないでください。 アイコンのトリミングをすること アイコンを反転・回転すること アイコンの形を変えること 矢印 プリセットを使用 矢印はプリセットよりコピーして使用してください。 サイズ（長さ）を変更する場合はShiftキーを押下したまま行ってください。 → 同一直線上でサイズ変更ができます。 可能な限り直線と折れ線（直角）で各アイコンをつなぐこと できない場合は、対角線（斜め）でつないでも良い プリセットの矢印の形状が利用できない・存在しない場合はデフォルトの形状で使用すること プリセットやデフォルト以外の形状の矢印を使用すること アイコンラベル フォントについて 書体は「Arial」で、フォントサイズは「12pt」にしてください。 ラベルの改行について サービス名は2行以内に収める必要があります。 また、”AWS”や”Amazon”と付く場合には、そのあとに続くサービス名を同じ行に含めなければなりません。そして、単語の途中で改行することは禁止されています。（下図参照） 引用：AWS 「 AWS アーキテクチャアイコン PowerPoint用ツールキット 」 ドキュメント内で正式名称に言及せずに、略称のみ記載すること 略称が重複すること 例）ELB：Elastic Beanstalk, Elastic Load Balancing 番号吹き出し スタイルについて 黒丸に白色の字で番号を記載します。（アーキテクチャ図内で目立つようにするため） アーキテクチャ図の複雑さに応じて2種類のフォーマットが用意されています。 できる限り直線的に番号を順に振ること 左から右、上から下、時計回りなどに振ってください。 吹き出しの位置はなるべく統一すること 同一アーキテクチャ図で、サイズの異なる吹き出しを使用すること 文字や記号など、数字以外をラベルとして使用すること 吹き出しのサイズを手動で変更すること 新しい形の吹き出しを作成すること   おわりに 今回は技術的な内容とは少し離れましたが、AWSに触れる方の多くは一度は見ているであろうアーキテクチャ図について、そのお作法があるということを改めて知ることができました。今まで業務やこのブログにおいて何回かアーキテクチャ図を書いていましたが、ガイドラインに準拠していないところだらけで、少し恥ずかしく思っております。 ガイドラインに沿って作成することで、自然と見る相手にも分かりやすいアーキテクチャ図になると思うので、作図の練習を通してこのガイドラインを身につけていきたいなと思いました。   余談ですが… この度 AWS Japan APN ブログ や 弊社プレスリリース でも発表がありましたが、私(蛭田)は「2024 Japan AWS Jr. Champions」に選ばれました！ 入社から一年と少し、そしてAWSに触れ始めてからおよそ半年でここに選出いただけたことはとても光栄であり、今までの取り組みを認めていただけたのだと達成感を感じております。ですが、これに満足しておしまい…では決してありませんので、限られた任期(1年)の中を後悔することのないように日々邁進してまいります。

どうもこんにちは、SCSKの齋藤です。 みなさんは先日のAWS Summit Japanに参加しましたか？ 相変わらずの熱狂ぶりがすごかったですね〜 多くのセッションを通じて学びを得れたのと、社内外多くの知り合いに再会できて、大変刺激的な時間を過ごすことができました。 また、弊社の2024 Japan AWS Jr. Championsも輩出され、一緒に写真を撮ったりして、後輩のジュニチャンができたことを強く実感しました！後輩よ、頑張ってくれ〜 さて話は本題に入りますが、先日のAWS Summit Japanのセッションの中で気になることを学びましたので、早速検証して記事にしてみました。 概要 題名にもある通り、AWS StepFunctionsから直接APIを叩くことができるというものです。 以前からAWS StepFunctionsにはAPI Gatewayの連携はありまして、API Gatewayで作成されたAPIなら直接アクセスすることはできました。しかし、サードパーティAPIについては、Lambda関数を作成してアクセスする必要がありました。 ですが、なんとサードパーティAPIへのアクセスもStepFunctionsから直接叩けるようになってたとのことです。驚きですね！ このアップデート自体は、昨年のre:invent2023で発表されたものなのでまだ半年ちょっとしか経過していません。 ちょうど、私が4月から担当しているプロジェクトでも、サーバーレス開発をしているので、役立つかも知れないと思い検証してみました！   検証内容 今回は下記のようなステートマシンとしております。 ステートマシンのワークフローの中で、APIGatewayに直接叩きに行く処理を先に2回実施し、そのレスポンスをもとに、サードパーティAPIを叩きに行くという流れとなります。 実際のプロジェクトなどで開発する場合では、リソース間の情報を連携してAPIを叩きにいくことは多いかと思いますので、こういった観点で検証してみました。   準備 今回の検証には主に下記3種類のリソースを作成します。 ① StepFunctionsステートマシン ② APIGatewayエンドポイント ③ サードパーティAPI（ApiGateway、Lambda） ①、②については、AWS側でテンプレートがあったので、それをそのまま使って構築しました。 ③については、サードパーティAPIをAPIGatewayで作成しました。（なんかややこしいですね。） APIGatewayのデプロイと、APIキーの作成、使用量の作成を行えば、実質サードパーティAPIができたも同然なので、そのAPIを叩きにいくようにしました。さらに、APIの裏側でLambdaを実装し、データの加工を少しだけ行うようにしました。 では、作成方法を解説します。   ①StepFunctionsステートマシン、②APIgatewayエンドポイント StepFunctionsのコンソール画面に行き、「ステートマシンの作成」を押下すると、テンプレート選択画面が出ます。 ここで、自分が実装したいことの類似テンプレートを選択すると、ある程度出来上がったステートマシンを見ることができます。 今回は、「API Gateway への呼び出しを行う」にチェックをつけ、次へ行きます。 テンプレートの活用方法が選択できるので、「デモの実行」を選択します。一旦ステートマシンを作成して、後ほどサードパーティAPIの処理を追加します。 今回のテンプレートは、 ① 最初のAPIGatewayでペットストアにペット商品の情報を登録（Post）し、 ② 2つ目のAPIGatewayで、ペットストアの情報を取得（Get）する 上記２つの流れのステートマシンとなっております。 次に画面が遷移するので、「デプロイと実行」をクリックし、ステートマシンの実行を行います。   CloudFormationの実行が走るので、少々待ちます。 デプロイが完了すると、実行画面が表示されます。 入力情報を作成し、「実行開始」をクリックします。デフォルトでサンプル値が用意されており、カメの商品情報を追加するデータとなっています。 実行が成功すると、画面上部に成功メッセージが表示され、ステートマシンの通過した処理を緑で表示します。 ちなみに、各アクションをクリックすると、イベント情報の詳細を確認できます。 下記２つののキャプチャは、1番最初に実行されるアクション「Add Pet to Store」の入力と出力です。 そしてさらに下記２つのキャプチャは、「Retrieve Pet Store Data」の入出力データです。入力データが、前の「Add Pet to Store」の出力データと同じになっていることを確認できますね。 出力データも長くて見切れていますが、「ResponseBody」で始まるフェーズと、「ExistingPets」で始まるフェーズがあるのを確認できます。 「ResponseBody」は新規に追加した情報で、「ExistingPets」は従来から存在しているデータのことを指していると思われます。 この後設定するサードパーティAPIは、「Retrieve Pet Store Data」の後に追加する予定のため、この出力データの一部である「ResponseBody」をサードパーティAPIのインプットにする予定です。 一旦、ここまででストップし、サードパーティAPIの作成に移ります。 ③ サードパーティAPI 先述した通りAPIGatewayとLambdaを使ってサードパーティAPIもどきを作成します。 Lambda 先にLambda関数を作成します。 サードパーティAPIの裏側で稼動するLambdaとして、今回は受け取ったリクエストをjson形式に変換し、ステータスコードとともに変換するという処理を実施します。 Lambdaのコンソール画面に移動し、「関数の作成」をクリックします。 任意の名前とランタイムで関数を作成します。今回はPythonを使います。 関数が作成されるのを確認します。 デフォルトで作成されたソースコードを少しだけ編集します。 ソースコードのjson.dumpの中身を入力値eventに置き換えます。入力値をjson形式に変換する処理を実施するためです。 下記のように変更いたら、「Deploy」ボタンを押下します。 デプロイの成功後、テストを実施するため、上記画面の「Test」を押下し、テンプレートを作成し、保存します。 その後、再び「Test」ボタンを押下して、テストを実施します。 json形式に変換してステータスコードとともに表示するので、下記のような結果になれば作成成功です！   APIGateway APIGatewayコンソールに移動し、「APIを作成」をクリックします。 APIの種類を選択する画面で、「REST API」を選択します。   「新しいAPI」を選び、APIエンドポイントタイプを「リージョン」にして、任意のAPI名で作成します。 そうすると、空のAPIが作成されました。 リソースの作成 空のAPIができたので、次はリソースを追加します。 先ほどの空のAPI作成画面の左上に「リソースを作成」というボタンがありますので、そこをクリックします。 リソースパス/の配下に、任意のリソース名を作成します。 作成されると、リソース欄に表示されるのを確認できます。 メソッドの作成 その後、同じ画面の「メソッドを作成」をクリックし、APIが叩かれた後の処理を定義します。 メソッドタイプをPOSTにし、統合タイプを「Lambda関数」に設定します。 Lambda関数は選択式なので、先ほど作成したものを選びます。 後の設定はデフォルトで良いため、画面下の「メソッドの作成」を押下します。 作成が完了すると、メソッド情報が表示されるようになります。 テスト API動作のテストを行います。 先ほどの画面の「テスト」というボタンを押下すると、テスト作成ができます。 リクエスト本文に{“test”:1}と入力し、テストの作成を行います。 テスト作成後にすぐにテストされるので、結果を確認します。 いいですね！ステータスコード200とjson化された入力値が返されており、先ほど作成したLambda関数と統合されているのがわかります。 APIキーの作成 APIリクエストにはAPIキーによる認証をした方が望ましいので、APIキーを作成します。 まず、作成したAPIの画面の左のバーから、「APIキー」を選択します。 その後の画面から、「APIキーを作成」を押下します。 任意の名前でAPIキーを作成します。 保存後に、APIキーが作成されていることを確認します。 なお、APIキーの四角の部分をクリックすると、APIキーがクリップボードにコピーされます。後ほど必要なので、手元に控えておいてください。 リクエストとAPIキーの結び付け リクエストにAPIキーを結び付けて、接続の際に認証するようにします。 まず、APIのトップ画面に遷移し、画面左の緑のPOSTをクリックします。そうすると、下記のような画面になるかと思います。   1番最初のリクエストのところでAPIキーが欲しいため、「メソッドリクエストの設定」の編集ボタンをクリックします。 「APIキーは必須です」をクリックし、保存を押下します。 デプロイ APIそのものは整ったので、公開する準備を行います。 再び、作成したAPIのトップ画面へ遷移します。 その画面の「APIをデプロイ」を選択します。 ステージを作成するため、下記情報を入力します。 今回は開発環境ということでdevというステージ名にしております。 入力後、デプロイを押下します。 使用量プランの設定 API公開前最後の設定を行います。 再び、作成したAPIの画面の左のバーから、「使用量プラン」を選択します。 その後の画面で「使用量プランを作成」をクリックします。 スロットリングやクォータの設定をできますが、今回はどちらもチェックを外して、「使用量プランを作成」をクリックします。 作成後、使用プランのページに遷移するので、ステージとAPIキーを追加していきます。 まずは、「関連づけられたステージ」→「ステージを追加」をクリックします。 APIの部分は作成したリソース名を選択し、ステージの部分は作成したステージを選択し、追加を押下します。 再び使用プランのページに戻り、今度は「関連づけられたAPIキー」にスイッチし、「APIキーを追加」を押下します。 既存のキーから、事前に作成したAPIキーを選択し、追加します。 これにてAPIを公開することができました。   StepFunctionsの編集 作成したサードパーティAPIをStepFunctionsに組み込みます。 事前に作成したStepFunctionsのページを開き、画面右上の編集ボタンを押下します。 編集画面の左側から「Call third-party API」を選択し、２つ目のAPIGatewayの後にドラッグ＆ドロップします。 挿入後、API接続の設定画面が表示されるので、設定を諸々入力します。 APIエンドポイント 作成したサードパーティAPIのURLを入力します。 メソッド 今回はPOSTするようにサードパーティAPIを作成したので、POSTを選択します。 Authentication APIキーの保存先の参照を設定します。これはEventBridgeConnectionというリソースを経由してSecretsManagerに保存されるため、そのリソースを作成します。「新しい接続を作成」をクリックしてください。 接続名は任意の名前を設定し、送信先タイプを「その他」で選択し、認証の部分で「APIキー」を選択します。 ヘッダー名には、 x-api-key と入力してください。 ヘッダー値には、APIキー作成時に控えておいた、APIキーを入力します。 作成後、再びStepFunctionsの画面に戻ります。 Authenticationの選択肢に、先ほど作成したものが追加されるので、選択します。 その後、リクエスト本文を入力します。 今回は、前のAPIGatewayの処理のレスポンスを受け取り、それをサードパーティAPIのリクエストにするため、「実行時に状態入力からリクエスト本文を取得」を選択し、「 $.ResponseBody 」と入力し、保存を押下します。 これは、先述した「①StepFunctionsステートマシン、②APIgatewayエンドポイント」の最後の方で、「Retrieve Pet Store Data」の出力の一部である「ResponseBody」をサードパーティAPIの入力にすると記載しましたのを反映してます。 先頭に$.をつけると、入力値のjson辞書から該当のKey値（今回でいうとResponseBody）の値を取得する設定を行うことができます。 もちろん、「ExistingPets」を入力としたい場合は、「$.ExistingPets」とすることで正しく渡されるのを確認できます。 保存が完了したら、画面右上から「終了」を押下します。 必要権限の設定 最後に、StepFunctionsに必要な権限を設定します。 ステートマシンの画面からIAMロールARNをクリックし、IAMの画面に遷移します。 最初に作ったStepFunctionsはAPIGatewayを直接叩くのみの権限しかないため、サードパーティAPIを叩くのに必要な権限をインラインポリシーで追加します。 下記のようなポリシーを作成してポリシーをアタッチします。 権限付与に参考にしたブログは下記のとおりです。 Third-party API integration in AWS Step-Functions The objective of this blog is to give a basic understanding of how Step Functions incorporate third-party API integratio... community.aws   ステートマシンの実行 長かったですが、これでサードパーティAPIを叩く準備はできました。 今一度ステートマシンのページに移動し、画面右上の「実行を開始」をクリックします。 入力データを求められるので、最初のStepFunctions作成した時の入力データを参考に新しいペット情報を入力し、「実行を開始」ボタンを押します。 実行された後、ステートマシンのステータスを確認できるので、全て緑になっていれば成功です。 試しに、「Call third-party API」をクリックすると、画面右にデータが表示されます。 出力タブをクリックし、下にスクロールすると、ResponseBodyに1番最初に入力したデータが表示されております。 サードパーティAPIの裏のLambdaで処理された値なので、ResponseBodyの中にステータスコードとjson化された入力データが入っているのを確認できます。 これにより、前の処理で実行された APIGatewayの値をインプットに、サードパーティAPIにアクセスすることができると確認できました。   まとめ 今回はStepFunctionsからサードパーティAPIへの接続を試行してみました。 今回は検証初期段階ですが、私が現時点で気になることとして下記3点が挙げられます。 出力の整形はどこまで可能か？ 前後にLambdaを挟んでも情報を正しくやり取りすることは可能か？ APIエラー時の扱いもどこまで柔軟に設定が可能か？ 上記はこれから検証することとして今回のブログは一旦終わりにしたいと思います。 個人的な所感としては、APIのレスポンス情報を元に複雑なメッセージ整形処理を必要とする場合、Lambdaの方が適しているのかなと考えております。 APIを叩いて、その情報をほとんどそのまま次の処理に渡すなどの場合は、Lambdaではなく、この機能を活用した方が開発生産性が上がるかもしれません。

はじめに クラウドセキュリティは、多くの企業にとって必須の検討事項です。クラウドセキュリティを強化するため、CSPM（Cloud Security Posture Management）ツールの導入を検討すると、ツール選定が必要になります。ツール選定では多くの場合、自分のクラウド環境で提供されているCSPMツールを始めとして、サードパーティーのCSPMツールなどと比較・評価を行いますが、比較・評価にはそれなりの時間が必要となります。 そこで本記事では、AWS社のCSPMサービスであるSecurity HubとCPSMの代表的なサービスであるPalo Alto Networks社のPrisma Cloudを比較・評価して両ツールの違いを解説し、Prisma Cloudを利用することのメリットをお伝えいたします。   Prisma Cloudとは Prisma CloudというCSPMツールを初めて聞いた方向けに、まずはPrisma Cloudを説明いたします。 Prisma Cloud®は、クラウド ネイティブ アプリケーション保護プラットフォーム(CNAPP)であり、アプリケーション、データ、インフラストラクチャに対して業界で最も広範なセキュリティとコンプライアンスを提供し、コードからクラウド™まで、テクノロジー スタック全体のセキュリティ保護を支援します。 Prisma CloudのSaaSベースのソリューションは、ハイブリッドおよびマルチクラウド環境において、データ流出、インターネットに公開されているAPI、脆弱なCI/CDパイプラインが発生しやすい攻撃経路を検出するのに役立ちます。Prisma CloudのAIを活用したソリューションを活用して、問題をプロアクティブに予測し、ますます巧妙化する脅威や攻撃者に先手を打つことができます。 原文：Prisma Cloud® is a Cloud Native Application Protection Platform (CNAPP), providing you with the industry’s broadest security and compliance coverage for applications, data, and infrastructure, helping you secure your entire technology stack, from Code to Cloud™. Prisma Cloud’s SaaS based solution helps you detect attack paths prone to data exfiltration, internet exposed APIs, and vulnerable CI/CD pipelines across hybrid and multi-cloud environments. Leverage Prisma Cloud’s AI powered solution to proactively anticipate issues and stay ahead of increasingly sophisticated threats and attackers. 引用： Prisma Cloudへようこそ Prisma Cloudはアプリ、データ、インフラに対して、幅広くセキュリティを提供しているCSPMツールとなります。また、ハイブリッドやマルチクラウド環境において発生しやすい攻撃経路を検出できることや、AIを活用して問題を予測することができます。 Prisma Cloudでは以下3つの機能が提供されています。 クラウドセキュリティ ：認証や権限の問題、設定ミス、未解決の脆弱性に起因する攻撃からクラウド資産を保護するのに役立ちます。 アプリケーションセキュリティ ：アプリケーション依存関係の視覚化を提供し、IaC、ソースコード上のシークレットを検出するのに役立ちます。 ランタイムセキュリティ ：アプリケーションのライフサイクル全体にわたってマイクロサービス、ホスト、コンテナ、サーバーレス機能を保護するのに役立ちます。 クラウドへの移行の初期段階にある場合は、クラウドの体制をより詳細に可視化するために、クラウドセキュリティから始めることをPrisma Cloudは推奨しています。 本記事ではこのクラウドセキュリティで利用できる以下6つの機能をAWS Security Hubで利用できるかで比較・評価します。 監視可能なパブリッククラウド ポリシー コンプライアンス アラート リソース可視化 ダッシュボード 評価項目はPrisma Cloudの ドキュメント目次 をサマライズして作成しています。 また、本内容は2024年2月7日時点の情報となります。最新の情報を必ず各社メーカーのドキュメントでご確認ください。   監視可能なパブリッククラウド Prisma CloudとSecurity Hubで監視可能なパブリッククラウドです。 Prisma Cloudは複数のパブリッククラウドに対応していますが、Security HubはAWSのマネージドサービスのため、AWSしか監視できません。 項目 Prisma Cloud Security Hub 評価 評価 AWS 〇 〇 Azure 〇 × GCP 〇 × Oracle Cloud Infrastructure 〇 × Alibaba Cloud 〇 × 参考： クラウド・アカウント・オンボーディング (prismacloud.io)   ポリシー Prisma Cloudではポリシーとは検知項目を表しており、Security HubにおけるFindingsと同じです。 組み込みポリシーの種類では、Prisma CloudはAWS用のポリシーだけで約1766種類が用意されています。 また、Prisma Cloudはマルチクラウド対応のため全パブリッククラウドのポリシーを合計すると約2940種類が用意されております。 検知領域では、Prisma Cloudのクラウドセキュリティは異常な振る舞い(ユーザ、ネットワーク、DNS)、特権アクティビティ、ネットワークの保護、ワークロードのインシデント、設定ミス・非推奨設定、脆弱性、攻撃経路の有無を検知できます。 また、Security Hubは組み込みのコンプライアンスによる検知や、他サービスとの統合(※1)により、侵入検出の結果(Amazon GuardDuty)、脆弱性(Amazon Inspector)、S3バケットポリシーの検出結果(Amazon Macie)、一般にアクセス可能なクロスアカウントリソース(IAM Access Analyzer)などを検知できます。 項目 Prisma Cloud Security Hub 評価 補足 評価 補足 組み込みポリシーの種類 〇 約1766種類 (※AWSポリシーのみ) 〇 約304種類 ポリシーのカスタマイズ 〇 SQLに似た独自言語でカスタマイズ △ Configでカスタムルール作成後に 統合で可能 (※2) ポリシー重要度 〇 5段階 〇 5段階 参考： Prisma Cloudポリシーの管理 ※1： AWS Security Hub での製品の統合 – AWS Security Hub (amazon.com) ※2： AWS Security Hub が AWS Config のマネージドルールとカスタムルールの評価結果を受け取るようになりました (amazon.com)   コンプライアンス Prisma Cloudではコンプライアンス標準や業界標準に対してクラウド環境の健全性とコンプライアンス体制を表示、評価、レポート、監視、レビューできます。 本記事では、異なるバージョンのコンプライアンス標準は別の標準としてカウントしています。 項目 Prisma Cloud Security Hub 評価 補足 評価 補足 組み込みのコンプライアンス 〇 約67種類(AWSの場合※1) 〇 8種類(※2) コンプライアンスのカスタマイズ 〇 ポリシーを付け替えてカスタム可能 △ コンプライアンス内の ルール有効/無効のみ(※3) コンプライアンス準拠状況のレポート作成 〇 – × – 参考： Prisma Cloud Compliance ※1： Compliance Standards (prismacloud.io) ※2： Security Hub 標準のリファレンス – AWS Security Hub (amazon.com) ※3： すべての標準におけるコントロールの有効化と無効化 – AWS Security Hub (amazon.com)   アラート Prisma Cloudではすべてのクラウド環境を継続的に監視し、ポリシー違反によってアラートを生成します。 Security Hubと同様にPrisma Cloudでもアラートを手動で無視できます。無視されたアラートは、同じポリシー違反が再び発生した場合でも無視された状態のままになります。( View and Respond to Prisma Cloud Alerts ) また、アラートのポリシーに関連付けられたCLIコマンドを実行し、違反を検出したクラウド環境でポリシー違反を自動的に修正できます。 項目 Prisma Cloud Security Hub 評価 補足 評価 補足 アラートのメール通知 〇   △ EventBridgeとSNSとの統合で可能 サードパーティへの通知 〇 Teams、Slackなど複数製品に対応 (※1) △ EventBridgeとLambdaとの統合で可能 アラートの無視 〇   〇   アラートの一時的な無視 〇   ×   リソースの自動修正 〇   △ EventBridgeとLambdaとの統合で可能 リソースを修正するための推奨手順 〇 ポリシーから手順を確認できる(※2) △ ドキュメントから個別に手順を確認する必要がある(※3) アラート状況のレポート作成 〇   ×   参考： Prisma Cloud Alerts ※1： Prisma Cloudでの外部統合の構成 リソースを修正するための推奨手順の確認方法 Prisma Cloudの場合は、ポリシー毎に具体的な修正手順が記載されているため、アラートへ対応しやすいかと思います。 ※2： Risk Prioritization and Remediation (prismacloud.io) Security Hubの場合は、下記リンクのようにドキュメントが修正手順となります。修正手順の中でさらに別ドキュメントの参照を促され、ドキュメントを確認する手間が発生します。 ※3： Amazon Simple Storage Service コントロール – AWS Security Hub   リソース可視化 Prisma CloudではAWSリソースだけでなく、マルチクラウドで所有しているリソースとアラート状況を一元的に確認できます。 また、それぞれのリソースで検知されているアラート数も容易に確認できます。 AWSではPrisma Cloudのようにリソースとアラート状況を一覧化する機能はなく、各サービス毎にリソースを確認する必要があります。 ※AWS Resource Explorerというサービスでリソースを横断的に検索、一覧化できますが、検索結果の上限が1000件などの制限があります。 参考： Prisma Cloud Asset Inventory(プリズマ クラウド アセット インベントリ)   ダッシュボード Prisma Cloudではダッシュボードを利用して、クラウド環境の健全性とセキュリティ体制を可視化できます。 Prisma Cloudのダッシュボード 参考： Get Started with Dashboards Security Hubのダッシュボード   CSPMの導入にかかる手間 Prisma Cloudではパブリッククラウドと接続することで全リージョンのリソース情報が取得されるため、リソースの可視化、監視を容易に開始できます(※1)。一方、Security HubではSecurity Hub自体がリージョンサービスのため、全リージョンを監視する場合、各リージョンでのSecurity Hub有効化と設定の管理が必要となります。また、他AWSサービス/サードパーティーと統合して利用する場合、各リージョン/サードパーティ毎に統合するサービスの有効化、設定の管理が必要となります。 ※AWS Organizationsにより、一部サービスで上記を自動化することも可能です。 ※1： 【CSPM】Prisma Cloud で AWS 環境をチェックしてみた 項目 Prisma Cloud Security Hub 評価 評価 CSPM導入にかかる手間 〇 △   まとめ 本記事では、AWSのSecurity HubとPrisma Cloudのクラウドセキュリティ機能を比較・評価して両ツールの違いを解説し、Prisma Cloudを利用することのメリットをお伝えしました。本記事でPrisma Cloudを利用することのメリットが伝わりましたら幸いです。 また当社ではPrisma Cloud利用して、複数クラウド環境の設定状況を自動でチェックし、設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。 マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 ご興味のある方は是非、お気軽にお問い合わせください。

こんにちは、SCSK株式会社の小寺崇仁です。 このブログではZabbixのデータベース内部構成について紹介をしたいと思ってます。 第2弾としてアイテム、トリガーの設定を取得するSQLを作成してみます。 はじめに 私はZabbixの構築を主に担当しています。最近はZabbixと外部システムを連携しているお客様が増加傾向にあると感じています。外部システムと連携をしたいお客様にはサポート範囲内である、ZabbixAPIを使用した方法を案内しています。 しかし、Zabbixはオープンソースであり、RDBMSを使用しているため、DBを直接参照することが可能です。DBの知識がある方であれば、容易にデータ抽出ができますので、表の構造とサンプルSQLを記事にしたいと思います。 注意事項 Zabbixのデータベース内部に関するは情報が少ないです。そのため私が個人的にDBを解析して情報発信を行う非公式情報になります。 当社ではZabbixの有償サポートを実施しております。Zabbixのデータベース内部に関する問い合わせはサポート範囲に含まれておらず、本ブログの内容をサポート宛に問い合わせをいただいても回答ができません。 個人的に作成したSQLです。自己責任でご利用ください。間違っていた場合イベント等でこっそり教えてください。 テーブル定義(MySQL) items アイテム情報が格納されるのテーブルです。 Field 日本語名称 Type Null Key Default Extra itemid アイテムID bigint unsigned NO PRI NULL   type タイプ int NO   0 0 – Zabbix エージェント 2 – Zabbix トラッパー 3 – シンプル チェック 5 – Zabbix インターナル 7 – Zabbix エージェント (アクティブ) 9 – Web アイテム 10 – 外部チェック 11 – データベース監視 12 – IPMI エージェント 13 – SSH エージェント 14 – Telnet エージェント 15 – 計算済み 16 – JMX エージェント 17 – SNMP トラップ 18 – 依存アイテム 19 – HTTP エージェント 20 – SNMP エージェント 21 – スクリプト snmp_oid SNMP OID varchar(512) NO       hostid ホストID bigint unsigned NO MUL NULL   name 名前 varchar(255) NO       key_ アイテムキー varchar(2048) NO MUL     delay 監視間隔 varchar(1024) NO   0   history ヒストリ保存期間 varchar(255) NO   90d   trends トレンド保存期間 varchar(255) NO   365d   status ステータス int NO MUL 0 0 – 有効なアイテム 1 – 無効なアイテム value_type 値のタイプ int NO   0 0 – 数値(浮動小数) 1 – 文字列 2 – ログ 3 -数値(整数) 4 – テキスト trapper_hosts トラッパーホスト varchar(255) NO       units 単位 varchar(255) NO       formula 計算式 varchar(255) NO       logtimefmt ログ時間形式 varchar(64) NO       templateid テンプレートID bigint unsigned YES MUL NULL   valuemapid 値のマップID bigint unsigned YES MUL NULL   params パラメータ text NO   NULL   ipmi_sensor IPMIセンサー varchar(128) NO       authtype 認証タイプ int NO   0   username ユーザー名 varchar(64) NO       password パスワード varchar(64) NO       publickey 公開鍵 varchar(64) NO       privatekey 秘密鍵 varchar(64) NO       flags フラグ int NO   0   interfaceid インターフェースID bigint unsigned YES MUL NULL   description 説明 text NO   NULL   inventory_link 在庫リンク int NO   0   lifetime 有効期間 varchar(255) NO   30d   evaltype 評価タイプ int NO   0   jmx_endpoint JMXエンドポイント varchar(255) NO       master_itemid マスターアイテムID bigint unsigned YES MUL NULL   timeout タイムアウト varchar(255) NO   3s   url URL varchar(2048) NO       query_fields クエリフィールド varchar(2048) NO       posts 投稿 text NO   NULL   status_codes ステータスコード varchar(255) NO   200   follow_redirects リダイレクト追跡 int NO   1   post_type 投稿タイプ int NO   0   http_proxy HTTPプロキシ varchar(255) NO       headers ヘッダ text NO   NULL   retrieve_mode 取得モード int NO   0   request_method リクエストメソッド int NO   0   output_format 出力形式 int NO   0   ssl_cert_file SSL証明書ファイル varchar(255) NO       ssl_key_file SSL鍵ファイル varchar(255) NO       ssl_key_password SSL鍵パスワード varchar(64) NO       verify_peer ピア検証 int NO   0   verify_host ホスト検証 int NO   0   allow_traps トラップ許可 int NO   0   discover ディスカバー int NO   0   uuid UUID varchar(32) NO       ※参考：APIマニュアル https://www.zabbix.com/documentation/6.0/jp/manual/api/reference/item/object triggers トリガー情報が格納されるのテーブルです。 Field 日本語名称 Type Null Key Default Extra triggerid トリガーID bigint unsigned NO PRI NULL   expression 式 varchar(2048) NO       description 説明 text NO   NULL   url URL varchar(255) NO       status ステータス int NO MUL 0 0 – 有効 1 – 無効 value 値 int NO MUL 0   priority 優先度 int NO   0 0 – 未分類 1 – 情報 2 – 警告 3 – 軽度の障害 4 – 重度の障害 5 – 致命的な障害 lastchange 最終変更 int NO   0   comments コメント text NO   NULL   error エラー varchar(2048) NO       templateid テンプレートID bigint unsigned YES MUL NULL   type タイプ int NO   0   state 状態 int NO   0   flags フラグ int NO   0   recovery_mode リカバリーモード int NO   0   recovery_expression リカバリー式 varchar(2048) NO       correlation_mode 相関モード int NO   0   correlation_tag 相関タグ varchar(255) NO       manual_close 手動クローズ int NO   0   opdata 操作データ varchar(255) NO       discover ディスカバー int NO   0   event_name イベント名 varchar(2048) NO       uuid UUID varchar(32) NO       ※参考：APIマニュアル https://www.zabbix.com/documentation/6.0/jp/manual/api/reference/trigger/object functions アイテムとトリガーの関連付け情報が格納されるのテーブルです。 Field 日本語名称 Type Null Key Default Extra functionid 関数ID bigint unsigned NO PRI NULL   itemid アイテムID bigint unsigned NO MUL NULL   triggerid トリガーID bigint unsigned NO MUL NULL   name 名前 varchar(12) NO       parameter パラメータ varchar(255) NO   0   サンプルSQL アイテム取得 SELECT h.hostid AS ホストID ,i.itemid AS アイテムID ,h.name AS ホスト名 ,i.name AS アイテム明 ,i.key_ AS アイテムキー ,i.delay AS 監視間隔 ,i.history AS ヒストリ保存期間 ,i.trends AS トレンド保存期間 FROM hosts h LEFT JOIN items i ON h.hostid = i.hostid WHERE h.hostid = 10084 AND i.flags IN (0,4) トリガー取得 SELECT DISTINCT h.hostid AS ホストID ,h.name AS ホスト名 ,t.triggerid AS トリガーID ,t.description AS トリガー名 ,t.expression AS 条件式 ,CASE t.priority WHEN 0 THEN '未分類' WHEN 1 THEN '情報' WHEN 2 THEN '警告' WHEN 3 THEN '軽度' WHEN 4 THEN '重度' WHEN 5 THEN '致命的' END AS 重要度 FROM hosts h LEFT JOIN items i ON h.hostid = i.hostid LEFT JOIN functions f ON i.itemid = f.itemid LEFT JOIN triggers t ON f.triggerid = t.triggerid WHERE h.hostid = 10084 AND i.flags IN (0,4) ホスト＋アイテム＋トリガー取得 SELECT h.hostid AS ホストID ,i.itemid AS アイテムID ,t.triggerid AS トリガーID ,h.name AS ホスト名 ,i.name AS アイテム明 ,i.key_ AS アイテムキー ,i.delay AS 監視間隔 ,i.history AS ヒストリ保存期間 ,i.trends AS トレンド保存期間 ,t.description AS トリガー名 ,t.expression AS 条件式 ,CASE h.status WHEN 0 THEN '有効' WHEN 1 THEN '無効' END AS ホストステータス ,CASE i.status WHEN 0 THEN '有効' WHEN 1 THEN '無効' END AS アイテムステータス ,CASE t.status WHEN 0 THEN '有効' WHEN 1 THEN '無効' END AS トリガーステータス FROM hosts h LEFT JOIN items i ON h.hostid = i.hostid LEFT JOIN functions f ON i.itemid = f.itemid LEFT JOIN triggers t ON f.triggerid = t.triggerid WHERE h.hostid = 10084 AND h.status in (0,1) AND i.flags IN (0,4)

こんにちは、広野です。 AWS AppSync を使用したアプリケーションを開発する機会があり、リゾルバ、主に VTL の書き方に関してまとまった知識が得られたので紹介します。前回からの続きもので、今回は 1つの VTL で 2つのクエリをアトミックに (同期的に冪等性を担保して) 実行する方法を紹介します。 本記事では、VTL の書き方にフォーカスしています。ご了承ください。 AWS AppSync、リゾルバ、VTL の説明については以下の記事をご覧下さい。 AWS AppSync リゾルバ (VTL) の書き方サンプル No.1 - Amazon DynamoDB GetItem Amazon DynamoDB に VTL で GetItem をかけるときの基本的な書き方を紹介します。 blog.usize-tech.com 2024.01.09 AWS AppSync リゾルバ (VTL) の書き方サンプル No.2 – Amazon DynamoDB BatchGetItem Amazon DynamoDB に VTL で BatchGetItem をかけるときの基本的な書き方を紹介します。 blog.usize-tech.com 2024.01.19 AWS AppSync リゾルバ (VTL) の書き方サンプル No.3 – Amazon DynamoDB Query Amazon DynamoDB に VTL で Query をかけるときの基本的な書き方を紹介します。 blog.usize-tech.com 2024.02.26 AWS AppSync リゾルバ (VTL) の書き方サンプル No.4 - Amazon DynamoDB PutItem Amazon DynamoDB に VTL で PutItem をかけるときの基本的な書き方を紹介します。 blog.usize-tech.com 2024.02.26 AWS AppSync リゾルバ (VTL) の書き方サンプル No.5 – Amazon DynamoDB UpdateItem Amazon DynamoDB に VTL で UpdateItem をかけるときの基本的な書き方を紹介します。 blog.usize-tech.com 2024.02.27 AWS AppSync リゾルバ (VTL) の書き方サンプル No.6 - Amazon DynamoDB 応用編 引数内のフラグにより処理を分ける Amazon DynamoDB に VTL でデータ読み書きをさせるときに、引数内のフラグにより実行させる処理を分岐する方法を紹介します。 blog.usize-tech.com 2024.06.17 AWS AppSync リゾルバ (VTL) の書き方サンプル No.7 - Amazon DynamoDB 応用編 2つのクエリを直列に実行 Amazon DynamoDB に VTL で 複数のクエリを直列に実行するときの書き方を紹介します。前のクエリの結果を後のクエリで使用することができるスグレモノです。 blog.usize-tech.com 2024.06.19 AWS AppSync を使って React アプリからキックした非同期ジョブの結果をプッシュ通知で受け取る 非同期ジョブを実行した後、結果をどう受け取るか？というのは開発者として作り込み甲斐のあるテーマです。今回は React アプリが非同期ジョブを実行した後に、AWS AppSync 経由でジョブ完了のプッシュ通知を受け取る仕組みを紹介します。 blog.usize-tech.com 2022.12.01 やりたいこと 以下のような処理をしたいです。冒頭、アトミックにという表現をしましたが、言葉を変えて説明します。 アプリからの1回のリクエストを受けて、リゾルバの中で 2つの書き込みオペレーションを実行したい。 ただし、2つのオペレーションが両方とも成功した場合にのみ、オペレーションをコミットしたい。もし片方が失敗した場合は、成功した方もオペレーションを無効にしたい。 これは、以下のように Amazon DynamoDB が提供している TransactWriteItems API を利用することで実現できます。 公式には、以下のドキュメントをご覧下さい。 Amazon DynamoDB Transactions: 仕組み - Amazon DynamoDB Amazon DynamoDB Transactions を使用すれば、複数のアクションをまとめてグループ化し、1 つのオールオアナッシングの TransactWriteItems または TransactGetItems オペレーションと... docs.aws.amazon.com 本記事のサンプルでは、アプリから AWS AppSync に「2つの書き込みオペレーション」リクエストを受けたとします。テーブル名はリゾルバの別の設定 (Data Source) で設定しますが、実際に使用されるのはリクエストマッピングテンプレート内で設定されたテーブルになります。 1つ目のオペレーション: パーティションキー pkey、ソートキー skey1、属性 attr1 をテーブル A に書き込み 2つ目のオペレーション: パーティションキー pkey、ソートキー skey2、属性 attr2 をテーブル B に書き込み Amazon DynamoDB に TransactWriteItems する VTL リクエストマッピングテンプレート { "version": "2018-05-29", "operation": "TransactWriteItems", "transactItems": [ ## 1つ目のオペレーションを定義 { "table": "TableA", "operation": "PutItem", "key": { "pkey": $util.dynamodb.toDynamoDBJson($context.arguments.pkey), "skey1": $util.dynamodb.toDynamoDBJson($context.arguments.skey1) }, "attributeValues": { "attr1": $util.dynamodb.toDynamoDBJson($context.arguments.attr1) } }, ## 2つ目のオペレーションを定義 { "table": "TableB", "operation": "PutItem", "key": { "pkey": $util.dynamodb.toDynamoDBJson($context.arguments.pkey), "skey2": $util.dynamodb.toDynamoDBJson($context.arguments.skey2) }, "attributeValues": { "attr2": $util.dynamodb.toDynamoDBJson($context.arguments.attr2) } } ] } transactItems の中に、配列で同期的に実行したいオペレーション、ここでは 2つの PutItem を定義しています。 関数 1 のレスポンスマッピングテンプレート この例では、エラーになったときは “error” を返すようにしています。 #if($ctx.error) $util.toJson({ "pkey": "error" }) #elseif($ctx.result) $util.toJson({ "pkey": $context.arguments.pkey }) #else $util.toJson({ "pkey": "error" }) #end まとめ いかがでしたでしょうか。 複数のオペレーション結果を総合的に判断させるクエリが作成が必要なケースはあると思います。もっとエラー時のレスポンスはきちんと作らないといけないとは思いますが。 本記事が皆様のお役に立てれば幸いです。

こんにちは、SCSK　池田です。 新しい試みとして、LifeKeeperの紹介動画を作成しました。 第一弾として、昨年11月に記事を掲載させていただいた「第１回　HAクラスタウェア「LifeKeeper」で可用性を高めよう！」の内容を動画化しました。 SCSKのYouTube公式チャンネル（以下リンク）からご視聴ください 5分で解説！HAクラスターソフトウェア「LifeKeeperとは？」 サムネイル   動作環境について 本動画コンテンツは、以下のツールを組合せて作成しています。 　 ◆パソコン Apple社 M3 MacBook Pro 16インチ ◆動画編集 Adobe社 Premiere Pro ※Adobe CreativeCloudサブスク ◆AIナレーション AHS社 VOICE PEAK AI音声合成技術を搭載した入力文字読み上げソフト 6人のナレーターと感情パラメータによる喜怒哀楽の表現も可能 ◆アニメーションソフト VYOND アニメーション映像製作プラットフォーム おわりに 今後、これまで記事にしてきた内容を動画でも公開していく予定ですので、ご期待ください！

こんにちは、広野です。 AWS AppSync を使用したアプリケーションを開発する機会があり、リゾルバ、主に VTL の書き方に関してまとまった知識が得られたので紹介します。前回からの続きもので、今回は 1つの VTL で 2つのクエリを直列に実行する方法 (パイプラインリゾルバ) を紹介します。 本記事では、VTL の書き方にフォーカスしています。ご了承ください。 AWS AppSync、リゾルバ、VTL の説明については以下の記事をご覧下さい。 AWS AppSync リゾルバ (VTL) の書き方サンプル No.1 - Amazon DynamoDB GetItem Amazon DynamoDB に VTL で GetItem をかけるときの基本的な書き方を紹介します。 blog.usize-tech.com 2024.01.09 AWS AppSync リゾルバ (VTL) の書き方サンプル No.2 – Amazon DynamoDB BatchGetItem Amazon DynamoDB に VTL で BatchGetItem をかけるときの基本的な書き方を紹介します。 blog.usize-tech.com 2024.01.19 AWS AppSync リゾルバ (VTL) の書き方サンプル No.3 – Amazon DynamoDB Query Amazon DynamoDB に VTL で Query をかけるときの基本的な書き方を紹介します。 blog.usize-tech.com 2024.02.26 AWS AppSync リゾルバ (VTL) の書き方サンプル No.4 - Amazon DynamoDB PutItem Amazon DynamoDB に VTL で PutItem をかけるときの基本的な書き方を紹介します。 blog.usize-tech.com 2024.02.26 AWS AppSync リゾルバ (VTL) の書き方サンプル No.5 – Amazon DynamoDB UpdateItem Amazon DynamoDB に VTL で UpdateItem をかけるときの基本的な書き方を紹介します。 blog.usize-tech.com 2024.02.27 AWS AppSync リゾルバ (VTL) の書き方サンプル No.6 - Amazon DynamoDB 応用編 引数内のフラグにより処理を分ける Amazon DynamoDB に VTL でデータ読み書きをさせるときに、引数内のフラグにより実行させる処理を分岐する方法を紹介します。 blog.usize-tech.com 2024.06.17 AWS AppSync を使って React アプリからキックした非同期ジョブの結果をプッシュ通知で受け取る 非同期ジョブを実行した後、結果をどう受け取るか？というのは開発者として作り込み甲斐のあるテーマです。今回は React アプリが非同期ジョブを実行した後に、AWS AppSync 経由でジョブ完了のプッシュ通知を受け取る仕組みを紹介します。 blog.usize-tech.com 2022.12.01 やりたいこと 以下のような処理をしたいです。 アプリからの1回のリクエストを受けて、リゾルバの中で直列した 2 つの処理を実行した結果をアプリにレスポンスする。 アプリへのレスポンスは、1つ目の処理 (関数1) の結果を 2つ目の処理 (関数2) が受け取り、処理に使用する。 これは、以下のようなパイプラインリゾルバを構築することで実現できます。 公式には、以下のドキュメントをご覧下さい。 リゾルバーのマッピングテンプレートの概要 - AWS AppSync AWS AppSync 対応のリゾルバーのマッピングテンプレートの概要 docs.aws.amazon.com 本記事のサンプルでは、アプリから AWS AppSync に「グラフに使用する 3 つのデータを取得する」リクエストを受けたとします。Amazon DynamoDB には適切なデータがある想定です。テーブル名はリゾルバの別の設定 (Data Source) で行います。 1つ目の関数: パーティションキー pkey、ソートキー skey1 が “TRUE” である件数をテーブル A から取得 2つ目の関数: パーティションキー pkey、ソートキー skey1 が “FALSE” である件数をテーブル A から取得 3つ目の関数: パーティションキー pkey、ソートキー skey2 が “Red” から始まる件数をテーブル B から取得 pkey は pkey という変数名で引数としてアプリから値を渡される これらの件数を、以下のフォーマットの JSON データとしてまとめてレスポンスする。 { "true": xx, "false": xx, "red": xx } Amazon DynamoDB に命令する VTL まず、大元締めのパイプラインリゾルバのマッピングテンプレートをつくりますが、実体はほぼ空です。実処理は各関数のリゾルバに記述します。 パイプラインリゾルバのリクエストマッピングテンプレート 何もしません。(笑) {} パイプラインリゾルバのレスポンスマッピングテンプレート 最後に実行された関数から受け取ったレスポンスをそのままパイプラインリゾルバのレスポンスとしてアプリに返す仕様にします。 $util.toJson($context.result) 関数 1 のリクエストマッピングテンプレート { "version": "2018-05-29", "operation": "Query", "query": { "expression": "#pkey = :pkey AND #skey1 = :skey1", "expressionNames": { "#pkey": "pkey", "#skey1": "skey1" }, "expressionValues": { ":pkey": $util.dynamodb.toDynamoDBJson($context.arguments.pkey), ":skey1": $util.dynamodb.toDynamoDBJson("TRUE") } }, "nextToken": $util.toJson($util.defaultIfNullOrEmpty($context.arguments.after, null)), "scanIndexForward": false, "consistentRead": false, "projection": { "expression": "pkey" } } シンプルな、条件に合致する行の件数をカウントしたいだけのクエリなので、projection に pkey のみを指定しています。これによりレスポンスのデータ量を節約します。 関数 1 のレスポンスマッピングテンプレート 結果のうち、件数だけを取得したいので、以下のように scannedCount を使用します。 $util.toJson({ "true": $ctx.result.scannedCount }) このレスポンスは、関数 2 に渡されます。 関数 2 のリクエストマッピングテンプレート { "version": "2018-05-29", "operation": "Query", "query": { "expression": "#pkey = :pkey AND #skey1 = :skey1", "expressionNames": { "#pkey": "pkey", "#skey1": "skey1" }, "expressionValues": { ":pkey": $util.dynamodb.toDynamoDBJson($context.arguments.pkey), ":skey1": $util.dynamodb.toDynamoDBJson("FALSE") } }, "nextToken": $util.toJson($util.defaultIfNullOrEmpty($context.arguments.after, null)), "scanIndexForward": false, "consistentRead": false, "projection": { "expression": "pkey" } } 本サンプルでは、関数 2 は関数 1 のソートキーの条件を変えただけのもので、ほとんど同じです。skey1 が FALSE である件数を取得する目的です。 関数 2 のレスポンスマッピングテンプレート ここは関数 1 とは少し変わります。関数 1 のレスポンスを受け取ったものをここでマージします。 $util.qr($ctx.prev.result.put("false", $ctx.result.scannedCount)) $util.toJson($ctx.prev.result) $ctx.prev.result が関数 1 のレスポンスです。そこに “false”: に続けて関数 2 の結果 $ctx.result の中の件数に当たる scannedCount を取り出してマージしています。結果として、以下のデータが関数 2 のレスポンスとして関数 3 に渡されます。 { "true": xx, "false": xx } 関数 3 のリクエストマッピングテンプレート こちらは、関数 1,2 とは別のテーブルから別のデータの件数を取得します。 { "version": "2018-05-29", "operation": "Query", "query": { "expression": "#pkey = :pkey AND begins_with(#skey2, :skey2)", "expressionNames": { "#pkey": "pkey", "#skey2": "skey2" }, "expressionValues": { ":pkey": $util.dynamodb.toDynamoDBJson($context.arguments.pkey), ":skey2": $util.dynamodb.toDynamoDBJson("Red") } }, "nextToken": $util.toJson($util.defaultIfNullOrEmpty($context.arguments.after, null)), "scanIndexForward": false, "consistentRead": false, "projection": { "expression": "pkey" } } 関数 3 のレスポンスマッピングテンプレート 関数 2 から受け取ったレスポンスをここでマージします。やっていることは関数 2 と同じです。 $util.qr($ctx.prev.result.put("red", $ctx.result.scannedCount)) $util.toJson($ctx.prev.result) 結果として、以下のデータが関数 3 のレスポンスとしてパイプラインリゾルバに返されます。パイプラインリゾルバは今回の例ではそのままアプリにデータを返すので、実質関数 3 のレスポンスが最終的なレスポンスになります。 { "true": xx, "false": xx, "red": xx } (参考) AWS CloudFormation テンプレート 私はこの面倒なリゾルバの定義を AWS マネジメントコンソールで設定する気が起きず (UI がわかりにくいので)、AWS CloudFormation でデプロイしています。完全な AWS AppSync のテンプレートではありませんが、パイプラインリゾルバのところの Resources のみ抜粋して紹介します。 # パイプラインリゾルバの定義 AppSyncResolverPipeline: Type: AWS::AppSync::Resolver Properties: ApiId: !GetAtt AppSyncApi.ApiId # AppSync の API ID TypeName: Query FieldName: queryUserExamScore # AppSync のスキーマで定義したクエリの名前 Kind: PIPELINE # ここでパイプラインリゾルバであることを宣言 PipelineConfig: Functions: # 作成したい関数を処理順に並べる、関数 ID を参照 - !GetAtt FunctionUserExamScore1true.FunctionId - !GetAtt FunctionUserExamScore2false.FunctionId - !GetAtt FunctionUserExamScore3red.FunctionId RequestMappingTemplate: | {} ResponseMappingTemplate: | $util.toJson($context.result) DependsOn: - FunctionUserExamScore1true - FunctionUserExamScore2false - FunctionUserExamScore3red # 関数 1 の定義 FunctionUserExamScore1true: Type: AWS::AppSync::FunctionConfiguration Properties: ApiId: !GetAtt AppSyncApi.ApiId # DynamoDB テーブル A のデータソース名をここで参照 DataSourceName: !GetAtt AppSyncDataSourceTableA.Name Description: AppSync Function for User Exam Score Graph 1 for true FunctionVersion: 2018-05-29 Name: AppSyncFunctionUserExamScore1true RequestMappingTemplate: | { "version": "2018-05-29", "operation": "Query", "query": { "expression": "#pkey = :pkey AND #skey1 = :skey1", "expressionNames": { "#pkey": "pkey", "#skey1": "skey1" }, "expressionValues": { ":pkey": $util.dynamodb.toDynamoDBJson($context.arguments.pkey), ":skey1": $util.dynamodb.toDynamoDBJson("TRUE") } }, "nextToken": $util.toJson($util.defaultIfNullOrEmpty($context.arguments.after, null)), "scanIndexForward": false, "consistentRead": false, "projection": { "expression": "pkey" } } ResponseMappingTemplate: | $util.toJson({ "true": $ctx.result.scannedCount }) DependsOn: - AppSyncDataSourceTableA # 関数 2 の定義 FunctionUserExamScore2false: Type: AWS::AppSync::FunctionConfiguration Properties: ApiId: !GetAtt AppSyncApi.ApiId # DynamoDB テーブル A のデータソース名をここで参照 DataSourceName: !GetAtt AppSyncDataSourceTableA.Name Description: AppSync Function for User Exam Score Graph 2 for false FunctionVersion: 2018-05-29 Name: AppSyncFunctionUserExamScore2false RequestMappingTemplate: | { "version": "2018-05-29", "operation": "Query", "query": { "expression": "#pkey = :pkey AND #skey1 = :skey1", "expressionNames": { "#pkey": "pkey", "#skey1": "skey1" }, "expressionValues": { ":pkey": $util.dynamodb.toDynamoDBJson($context.arguments.pkey), ":skey1": $util.dynamodb.toDynamoDBJson("FALSE") } }, "nextToken": $util.toJson($util.defaultIfNullOrEmpty($context.arguments.after, null)), "scanIndexForward": false, "consistentRead": false, "projection": { "expression": "pkey" } } ResponseMappingTemplate: | $util.qr($ctx.prev.result.put("false", $ctx.result.scannedCount)) $util.toJson($ctx.prev.result) DependsOn: - AppSyncDataSourceTableA # 関数 3 の定義 FunctionUserExamScore3red: Type: AWS::AppSync::FunctionConfiguration Properties: ApiId: !GetAtt AppSyncApi.ApiId # DynamoDB テーブル B のデータソース名をここで参照 DataSourceName: !GetAtt AppSyncDataSourceTableB.Name Description: AppSync Function for User Exam Score Graph 3 for red FunctionVersion: 2018-05-29 Name: AppSyncFunctionUserExamScore3red RequestMappingTemplate: | { "version": "2018-05-29", "operation": "Query", "query": { "expression": "#pkey = :pkey AND begins_with(#skey2, :skey2)", "expressionNames": { "#pkey": "pkey", "#skey2": "skey2" }, "expressionValues": { ":pkey": $util.dynamodb.toDynamoDBJson($context.arguments.pkey), ":skey2": $util.dynamodb.toDynamoDBJson("Red") } }, "nextToken": $util.toJson($util.defaultIfNullOrEmpty($context.arguments.after, null)), "scanIndexForward": false, "consistentRead": false, "projection": { "expression": "pkey" } } ResponseMappingTemplate: | $util.qr($ctx.prev.result.put("red", $ctx.result.scannedCount)) $util.toJson($ctx.prev.result) DependsOn: - AppSyncDataSourceTableB まとめ いかがでしたでしょうか。 今回のサンプルでは、それぞれの関数の結果を順番にマージしていくだけの簡単な直列処理でしたが、前の関数の結果を次の関数のクエリのパラメータに使用することもできます。その場合はリクエストマッピングテンプレートの中で前の関数のレスポンス $ctx.prev.result を使用します。 それにより通常 DynamoDB への単体のクエリでは実現できない、テーブルの結合に近いことが実はできます。まあ同じことやるにしても Lambda 関数書けば普通にできるんですが、VTL の方が処理が速いのと Lambda 関数が乱立しなくていいなぁと思って極力私は VTL を使っています。 本記事が皆様のお役に立てれば幸いです。

こんにちは、SCSK株式会社の小寺崇仁です。 先日Zabbixの7.0がリリースされました。 Zabbix7.0では、様々な機能追加、改善が行われております。 詳細は以下をご確認ください。 What's new in Zabbix 7.0 LTS www.zabbix.com   はじめに 今回は7.0で行われた性能改善について検証をしていきたいと思います。 公式HPでは以下の記載があります。 Improved data collection speed and scalability ・Faster metric polling for agent, SNMP and HTTP checks ・Next metric can now be polled before waiting for a response from previously requested metric 今までは、エージェント監視、SNMPエージェント監視、HTTPエージェント監視は「poller」プロセスで監視が行われておりましたが、「agent poller」「snmp poller」「http poller」に分割されたようです。 また、値を取得する際に、リクエスト送信からレスポンス受信までの間はプロセスが待機をしており、ビジー率上昇をしておりましたが、非同期で処理を行うように改善されたようです。 検証環境について 6.0と7.0のZabbixサーバからSNMPDのインストールされたサーバーに対してSNMPポーリング監視を行い、稼働状況を確認します。 サーバ情報 項目 Zabbix6.0 Zabbix7.0 SNMPサーバ OS RHEL 9.4 RHEL 9.4 RHEL 9.4 Zabbixバージョン 6.0.30 7.0.0 ー SNNPDバージョン ー ー 5.9.1 インスタンスタイプ t2.medium（2vcpu,４GB） t2.medium（2vcpu,４GB） t2.medium（2vcpu,４GB） ディスク 30GB (gp3 3000iops) 30GB (gp3 3000iops) 30GB (gp3 3000iops) Zabbixのパラメータ情報 項目 Zabbix6.0 Zabbix7.0 備考 StartPollers 5 5 デフォルト=5 StartSNMPPollers ー 10 7.0新機能 MaxConcurrentChecksPerPoller ー 1000 7.0新機能 CacheSize 512M 512M 検証時に不足 TrendCacheSize 256M 256M 検証時に不足 ※上記以外がデフォルトパラメータを使用 ※Mariadbはデフォルトパラメータを使用 監視設定 インターフェースのステータスを取得するテンプレートを作成しました。 インターフェースは50個ある想定で50アイテム作成しています。 ホストを1000台登録し、１のテンプレートを適用しました。 SNMPインターフェースのBulkリクエストは検証のため無効にしました。 アイテムの取得間隔は1分です。 7.0の新機能を使うには、アイテムのOIDは「get[OUID]」「walk[OID,OID]」と記入する必要があります。 Zabbixの状態としては以下の通りです。 項目 Zabbix6.0 Zabbix7.0 備考 監視対象ホスト 1002 1002   アイテム数 50175 50180     1秒あたりの監視項目数(NVPS) 835.86 835.91   検証結果１（通常監視） Zabbix6.0 Pollerプロセスの使用率は平均11％ キューなし Zabbix7.0 SNMPPollerプロセスの使用率は1%前後 キューなし   結果＆考察 Zabbix7.0でSNMPPollerプロセスの使用率がほぼ上がらず、とても効率よく処理ができていると思われます。 検証１はZabbixサーバとSNMPサーバが同じVPCにあり、SNMPの値の取得が一瞬で終わっています。検証2では実際の環境に近い形で検証しします。 検証２（レスポンスの悪いOIDを追加する） 実際の監視では、レスポンスの悪いNW機器があり、待機時間によりPollerプロセスの使用率を上昇させていることがあると思います。 検証2では、レスポンスの悪いカスタムOIDを追加し検証します。 /etc/snmp/snmpd.confに以下を追記します。 view systemview included .1 extend sleep /tmp/test.sh /tmp/test.shの内容は以下となります。2秒待機してから値を返却します。 #!/bin/sh sleep 2 echo 11 新しく作成した監視のアイテムを作成します。 各ホストにアイテムを1つ（1000アイテム）追加しています。 Zabbix6.0 応答が遅いOIDが追加されたことでPollerプロセスの使用率が50%弱まで上昇しました。 Zabbix7.0 SNMPサーバ側が負荷に耐えられなくなったため、MaxConcurrentChecksPerPollerを1000→100に変更しました。 SNMPPollerプロセスの使用率は1%前後のままから上昇しませんでした。（値を取得するまで待機していない事が分かります） 値が正しく取得できているか不安になりますが、問題なく取得できています。 総括 データ収集処理は非同期処理に変更され、値の取得を待機しなくなったため、パフォーマンスが劇的に改善しました。 1プロセスのリクエスト数（MaxConcurrentChecksPerPoller）が設定できるようになり、効率化されている。 アイテム作成時にOIDの書き方に注意が必要です。（get[],walk[]をつける必要がある） 最後に 弊社では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