こんにちは、SCSKの前田です。 私が携わった LifeKeeper の案件で導入を行った ARK について紹介をかねてお話したいと思います。 今回は、Oracle 編と言うことで、Oracle 社が開発・販売されているリレーショナルデータベース管理システムを簡単に冗長化するための ARK の導入事例について、Linux 版をベースにご紹介していきます。 おさらい LifeKeeper の ARK について、おさらいしたいと思います。 ARK とは、Application Recovery Kits の略で、LifeKeeper が特定のアプリケーション（オープンソースソフトウェアや商用アプリケーション）を容易にリソースとして組み込むことが可能になる製品です。 ARK による、アプリケーションのリソースへの組み込みはウィザード形式（GUI上で設定）で作業が可能となり、ARK には、アプリケーションを操作（起動・停止・監視・再起動）するための4つのスクリプトがあらかじめ準備されているため、スクリプトを設計・作成するための開発工数の削減や人的なミスを防止することが出来ます。 概要説明 Oracle ARK では、Oracle Listener と Oracle Database を、LifeKeeper の保護対象リソースとして登録し、保護する機能を提供します。 Oracle ARK は、汎用アプリケーション(Generic Application)リソースの導入とは違い、起動・停止・監視・再起動を行うためのスクリプトを明示的に指定することはなく、リソースの作成に必要な項目に対するパラメータをウィザード形式で入力または、選択することでリソースを作成することが出来ます。 Oracle ARK として Oracle Listener と Oracle Database の処理内容は以下の通りとなります。 Oracle Listener の処理 処理名 処理内容 起動処理 lsnrctl start コマンドによるリスナーの起動を実施 停止処理 lsnrctl stop コマンドによるリスナーの停止を実施 監視処理 lsnrctl status コマンドによるリスナーの状態を確認 再起動処理 lsnrctl start コマンドによるリスナーの起動を実施 Oracle Database の処理 処理名 処理内容 起動処理 startup コマンドによる Oracle の起動を実施 停止処理 shutdown コマンドによる Oracle の停止を実施 監視処理 ① ps コマンドによる Oracle の動作確認を実施 ② DB へ接続しコネクションの状態確認を実施 ③ 一時ファイルへ ORA エラーが出力されていないか確認を実施 再起動処理 ① shutdown abort による Oracle の強制終了を実施 ② startup コマンドによる Oracle の起動を実施し、失敗した場合、startup force コマンドで Oracle の起動を実施 Oracle ARK の構築例 それでは、実際に Oracle ARK の構築についてお話していきたいと思います。 Oracle ARK のパラメータ項目 Oracle ARK でリソースを作成する際は、事前に構成を決めておくことで、スムーズな作業が可能になります。 そこで Oracle Listener と Oracle Database のリソース固有のパラメータを一覧表にまとめてみましたので参考にしてみてください。 ＜Oracle Listener＞ 項目 設定値 内容 Listener Configuration File Path 「listener.ora」フルパス Oracle Listener の設定ファイルのフルパスを入力 Listener Name 【Listener名】 Oracle Listener 名を入力 Listener Executable 【プログラム実行パス】 Oracle Listener のプログラムの実行パスを入力 Listener Protection Level Full 又は Intermediate 又は Minimal Oracle Listener の保護レベルを選択 (Full, Intermediate, Minimal の3つから選択可能) ・Full：リスナーの起動、停止、監視、回復処理を実施（デフォルト） ・Intermediate：リスナーの起動、監視、回復処理を実施 ・Minimal：リスナーの起動、監視処理を実施 Listener Recovery Level Standard 又は Optional Listener のリカバリレベルを選択 (Standard,Optional の2つから選択可能) ・Standard：リスナーリソースの障害検出による、ローカルリカバリ と フェイルオーバーを有効にする ・Optional：リスナーリソースの障害検出による、ローカルリカバリを有効にし、フェイルオーバーを無効にする IP Adderss Name 【IPリソース名】 リソース階層の依存関係として保護される IP アドレスのリソース名を選択   ＜Oracle Database＞ 項目 設定値 内容 ORACLE_SID for Database 【Oracle-SID名】 ORACLE_SID を選択 Username 【Oracleユーザー名】 sysdba 権限のある、Oracle-SID にログインするユーザー名を入力 Password 【Oracleユーザーパスワード】 Oracle-SID にログインするユーザーのパスワードを入力 Select the Oracle Listener 【OracleListenerリソース名】 Oracleリスナーリソース名を選択 Oracle Database 関連リソースの作成 Linux 版の Oracle ARK では「Oracle Listener」と「Oracle Database」のリソースを作成することが可能です。 この2つのリソースを LifeKeeper の GUI によって作成する流れを例として紹介します。 注意 Oracle で使用する共有ディスクリソースと、 IP リソース、及び、別のリソース等、それぞれの依存関係がある状態で Oracle リソースを作成した場合、Oracle リソース作成時の自動による依存関係の作成が失敗する可能性があるため、必要に応じて依存関係を削除する必要があります。 以降の例では、共有ディスクリソースと IP リソースの依存関係がない状態で Oracle リソースの作成を実施しています。 ＜Oracle Listenerリソース作成＞ 処理内容 Oracle Listener リソース作成前のツリー構造 保護アプリケーションの選択（Oracle Database Listener） 稼働系ノードのSwitchbackタイプの選択 ※デフォルト：intelligent 稼働系ノードの選択 稼働系ノードのOracle Listener 設定ファイルのフルパスの入力 Oracle Listener 名の選択 稼働系ノードのOracle Listener プログラムの実行パスの入力 Listener リソースの保護レベルの選択 Listener リソースのリカバリレベルの選択 依存関係として保護される IP リソース名の選択 稼働系ノードの管理GUIに表示されるリソースタグ名の入力 稼働系ノードのリソース作成結果 待機系ノードの選択 待機系ノードのSwitchbackタイプの選択 ※デフォルト：intelligent 稼働系ノードの優先順位の設定 ※デフォルト：1 待機系ノードの優先順位の設定 ※デフォルト：10 待機系ノードのリソース作成準備の確認結果 待機系ノードのOracle Listener 設定ファイルのフルパスの入力 待機系ノードのOracle Listener プログラムの実行パスの入力 待機系ノードの管理GUIに表示されるリソースタグ名の入力 待機系ノードのリソース作成結果 リソース作成後のツリー構造（Oracle Listener リソースと IP リソースの依存関係が自動で作成される）   ＜Oracle Databaseリソース作成＞ 処理内容 Oracle Database リソース作成前のツリー構造 保護アプリケーションの選択（Oracle Database） 稼働系ノードのSwitchbackタイプの選択 ※デフォルト：intelligent 稼働系ノードの選択 ORACLE_SID の選択 Oracle-SID のログインユーザー名の入力 Oracle-SID のログインユーザー名のパスワードの入力 Oracleリスナーリソース名の選択 稼働系ノードの管理GUIに表示されるリソースタグ名の入力 稼働系ノードのリソース作成結果 待機系ノードの選択 待機系ノードのSwitchbackタイプの選択 ※デフォルト：intelligent 稼働系ノードの優先順位の設定 ※デフォルト：1 待機系ノードの優先順位の設定 ※デフォルト：10 待機系ノードのリソース作成準備の確認結果 待機系ノードの管理GUIに表示されるリソースタグ名の入力 待機系ノードのリソース作成結果 リソース作成後のツリー構造（Oracle Database リソースと共有ディスクリソース・Oracle Listener リソースの依存関係が自動で作成される） これで、LifeKeeper による Oracle Database 製品 のリソースが完成です。 あとは、必要に応じてリソース階層の依存関係を変更します。 まとめ 今回は LifeKeeper ARK の導入事例と言うことで、Linux 版の Oracle Database 製品のリソース作成について紹介してみました。 Oracle ARK は、汎用アプリケーション(Generic Application)リソースとは違い、起動・停止・監視・再起動を行うためのスクリプトを準備する必要がなく、リソースを作成することで意識することなく自動でスクリプトが導入されます。 LifeKeeper の機能として、リソース作成後、必要に応じて再起動処理やフェイルオーバー処理を無効化にすることも出来ます。システムの要件に合わせカスタマイズが可能になっています。 Oracle ARK を導入するための手順を纏めます。 ・Oracle Listener と Oracle Database のリソース固有のパラメータの設定値を検討する ・LifeKeeper GUI を用いて、Oracle Listener と Oracle Database のリソースを作成する LifeKeeper では Oracle Database 以外にも多数の ARK が用意されていますので、また次の機会に別の ARK について紹介していきたいと思います。 JP1/AJS3 ARK の導入事例に関しては以下のリンクからどうぞ！ LifeKeeper ARK の導入事例を紹介＜JP1/AJS3編＞ – TechHarmony 詳しい内容をお知りになりたいかたは、以下のバナーからSCSK LifeKeeper公式サイトまで

みなさん、こんにちは。 SCSK株式会社の津田です。 今回は前回に引き続きLifeKeeper運用での基本的操作をご紹介します。 LifeKeeperではGUIとコマンドでの操作が可能です。 本記事では コマンドでの操作 をご紹介させて頂きます。 前回のGUI編の記事と読み比べて頂くことで、コマンドでの操作内容や操作感の違いがよりイメージしやすいかと思います。 LifeKeeper基本運用操作（GUI編） 今回はLifeKeeper運用での基本的操作をご紹介します。LifeKeeperではGUIとコマンドでの操作が可能です。本記事ではGUIでの操作をご紹介させて頂きます。 blog.usize-tech.com 2025.07.15 はじめに コマンドによる操作の特徴 ・LifeKeeper GUIによる基本運用操作では、自サーバだけでなく対向サーバの情報取得や操作が可能でしたが、 　 コマンドによる操作は、基本的にコマンドを実行するサーバ自身に限定されており、対向サーバに対する情報取得や 　 直接的な操作はできません。 ・操作はTeraTerm等のターミナルやコマンドプロンプトから実行可能です。 　 (LifeKeeperコマンド格納先(デフォルト)　 Linux：/opt/LifeKeeper/bin 　 Windows：C:\LK\Bin ） 　 ここではターミナルからのコマンド実行を例にご紹介していきます。 GUI編の記事同様、以下LifeKeeper構成を例にコマンドライン基本操作を紹介していきます。 ステータス確認  /opt/LifeKeeper/bin/lcdstatus -e   でリソースのステータス確認ができます。 ※ステータス確認を行いたいサーバでコマンド実行が必要です。 ▼稼働系ステータス確認 ▼待機系ステータス確認   以下を参考に「STATE」項目でステータス情報の確認ができます。 GUIではアイコンからステータスが確認できましたが、CLIではアルファベット(略語)で表示されます。   リソース停止起動 全リソース停止 LifeKeeperで制御している全リソースの停止方法をご紹介します。 ※LifeKeeperのサービス自体は停止されません。 ※リソース停止を行いたいサーバでのコマンド実行が必要です。 ※今回のLifeKeeperの構成のように依存関係(リソースツリー)を作成している場合、 　 リソース階層に基づき最上位のリソースから停止対象のリソースまでが順番に停止されます。 稼働系で /opt/LifeKeeper/bin/perform_action -t <最下位リソース> -a remove を実行すると稼働系で起動中の全リソースが停止します。 /opt/LifeKeeper/bin/lcdstatus -e で全リソース停止を確認できます。      リソース階層に基づき最上位のリソースから停止対象のリソースまでが順番に停止されます。 そのため本構成でいうと「httpd」リソース単体停止、「httpd」と「ip-10.10.5.100」リソースだけ停止、という操作も可能ですが、リソースツリーの途中（「ip-10.10.5.100」リソース）だけ停止させることはできません。 (依存関係がなければ「ip-10.10.5.100」リソースのみの停止も可能。） 全リソース起動 LifeKeeperで制御している全リソースの起動方法をご紹介します。 ※リソース起動を行いたいサーバでのコマンド実行が必要です。 ※今回のLifeKeeperの構成のように依存関係(リソースツリー)を作成している場合、 　 リソース階層に基づき最下位のリソースから起動対象のリソースまでを順番に起動できます。←停止とは逆向きの動作になります！ /opt/LifeKeeper/bin/perform_action -t <最上位リソース> -a restore -b  を実行すると全リソースが起動します。 /opt/LifeKeeper/bin/lcdstatus -e で全リソース起動を確認できます。   停止とは逆で、最下位のリソースから起動対象のリソースまで順番に起動されますので、 本構成でいうと「lbhc-12345」リソース単体起動、「lbhc-12345」と「ip-10.10.5.100」リソースだけ起動、という操作も可能ですが、リソースツリーの途中（「ip-10.10.5.100」リソース）だけ起動させることはできません。　　　　　　　　　　(依存関係がなければ「ip-10.10.5.100」リソース単体停止も可能。）   LifeKeeper停止起動 LifeKeeperのサービス停止起動は、LifeKeeper GUI ではできない操作になります。 LifeKeeper停止 LifeKeeperのサービスを停止する方法をご紹介します。 ※LifeKeeperで制御している全リソースも停止します。フェールオーバは発生しません。 ※LifeKeeperのサービスを停止したいサーバでのコマンド実行が必要です。 /opt/LifeKeeper/bin/lkstop を実行するとLifeKeeperサービスが停止します。 LifeKeeperサービス確認コマンド /opt/LifeKeeper/bin/lktest を実行すると何も返らない状態(⇒LifeKeeper停止)となります。 LifeKeeper起動 LifeKeeperのサービスを起動する方法をご紹介します。 ※LifeKeeper停止時のリソース起動状態を保持します。 ※LifeKeeperのサービスを起動したいサーバでのコマンド実行が必要です。 /opt/LifeKeeper/bin/lkstart を実行するとLifeKeeperサービスが起動します。 LifeKeeperサービス確認コマンド /opt/LifeKeeper/bin/lktest を実行するとL ifeKeeper常駐プロセスが表示されます。   スイッチオーバ・スイッチバック スイッチオーバ 稼働系から待機系に起動中のリソースを手動で切り換える方法をご紹介します。 ※スイッチオーバ先(待機系)でのコマンド実行が必要です。 ※今回のLifeKeeperの構成のように依存関係(リソースツリー)を作成している場合、 　 稼働系の最上位リソースから最下位リソースの順番に停止、待機系の最下位リソースから最上位リソースの順番に起動することでスイッチオーバします。 スイッチオーバ先で /opt/LifeKeeper/bin/perform_action -t <最上位リソース> -a restore を実行すると全リソースが起動します。 /opt/LifeKeeper/bin/lcdstatus -e で確認すると、スイッチオーバにより待機系のリソースがアクティブ(ISP)状態になっています。 稼働系のリソースはスタンバイ(OSU)状態になります。 スイッチバック 待機系から稼働系に起動中のリソースを手動で切り戻す場合もスイッチオーバと同様の手順となります。 ※スイッチバック先(稼働系)でのコマンド実行が必要です。 スイッチバック先で /opt/LifeKeeper/bin/perform_action -t <最上位リソース> -a restore を実行すると全リソースが起動します。    /opt/LifeKeeper/bin/lcdstatus -e で確認すると、スイッチバックにより稼働系のリソースがアクティブ(ISP)状態になっています。 待機系のリソースはスタンバイ(OSU)状態になります。   さいごに 今回はコマンドによる基本的な運用操作についてご紹介しましたが、操作イメージを持って頂けましたでしょうか？ LifeKeeper GUIは視覚的に分かりやすく直感的な操作が可能ですが、今回紹介したLifeKeeper停止起動のようにGUIではできない操作もあります。コマンドでは、こうした操作に加え、スクリプトやバッチ処理への組み込みが可能であり、運用の自動化や効率化にもつながります。GUIとコマンド、それぞれ状況に応じて使い分けて頂くことでより柔軟な運用が可能になるかと思います。 詳しい内容をお知りになりたいかたは、以下のバナーからSCSK Lifekeeper公式サイトまで

SCSKの坂木です。 本記事では、Zabbixにおける脆弱性の対応方法について紹介いたします。   セキュリティパッチとバージョンアップ システムの脆弱性は、常にセキュリティ上の脅威です。脆弱性情報（CVE）が公開された際は、速やかな対応が不可欠であり、セキュリティパッチの適用など適切な対策を講じる必要があります。 Zabbix は セキュリティパッチを個別に提供する代わりに、バージョンアップによってバグや脆弱性へ対応 しています。 特にマイナーバージョンアップ（7.0.X の X の部分のみを変更）であれば、 メジャーバージョンを維持したまま脆弱性を解消 できます。 メジャーバージョンアップは影響範囲が大きく、ベンダーへの依頼が必要となるケースもありますが、マイナーバージョンアップは深刻な脆弱性対策として比較的容易に実施できます。 そこで、本ブログでは、 マイナーバージョンアップの手順を紹介 いたします。(RHEL系コマンドで実施してます)   Zabbixの脆弱性確認 お使いのZabbixのバージョンに脆弱性があるか、また、どのバージョンへアップデートすべきかについては、こちらのブログで詳しく解説しています。 Zabbixの脆弱性情報収集と確認方法について Zabbixの脆弱性情報の確認方法について生成AIで効率的に実施してみました。 blog.usize-tech.com 2024.08.27   Zabbixのマイナーバージョンアップ 本ブログでは、Zabbixサーバをバージョン7.0.8から7.0.16(ブログ作成時の最新バージョン)へマイナーアップデートします。 現在のZabbixサーバのバージョンを確認します。GUIで確認すると下の方にバージョンが記載されています。   CLIでは以下のコマンド等で確認できます。 # Zabbix_server -V # dnf  list installed | grep zabbix   最新バージョンに更新していきます。 # dnf upgrade zabbix-*   最新バージョンになっていることを確認します。 # dnf list installed | grep zabbix   GUIからも確認してみましょう。CLI、GUIどちらからもマイナーバージョンアップできていることを確認できました。   まとめ 最後までお読みいただき、ありがとうございます。 本記事では、Zabbixにおける脆弱性の対応方法を紹介しました。 最も重要なポイントは、 Zabbixのセキュリティは、パッチではなくバージョンアップで確保する ということです。この基本を押さえ、安全なZabbix運用を心がけていきましょう。   Zabbixをより詳しく知りたい方へ この度、SCSKが「Zabbix」を学ぶセミナーを開催します。 Zabbixの基本から最新機能までを学習できます。ぜひこの機会にお見逃しなく！ 開催日時 2025年8月5日（火） 16:00～17:00 開催場所 オンラインセミナー（お申し込み後、受講用URLをご案内致します。） イベント詳細 Zabbix入門セミナー（夏） ～Zabbxiの基本とZabbixCloudについて～ オープンソースの監視ソフトウェア「Zabbix」を学ぶセミナーを開催します。このセミナーは、Zabbixを初めて学ぶ方や、監視システムの導入を検討している方に最適です。 基礎知識を習得し、実際の環境での監視設定を実践できるようになることを目... www.scsk.jp イベント申し込み Zabbixセミナー(8/5)登録 - 入力画面 form.scsk.jp   筆者の他のブログもよかったら見てやってください！ 【Zabbix】トリガーアクションでスクリプトを実行する方法 本ブログではZabbixのトリガーアクションで障害対応を自動化する方法を解説します。 今回はトリガーアクションの中でもスクリプトの実行方法について説明します。 blog.usize-tech.com 2025.06.10 Zabbixで複雑なログ監視を実装する方法-count関数編- Zabbixのcount関数を使った複雑な条件のログ監視を行う方法をご紹介します。ログ監視で、5分間で5回”ERROR”という文字列が含まれるといった条件はパッと作成できますか？さらには、5分間で連続で5回”ERROR”という文字列が含まれるといったように、「連続で」という条件がつくとさらに頭を悩ませるのではないでしょうか。そこで今回は、このような条件式を作成できるcount関数を用いたログ監視について紹介していきます。 blog.usize-tech.com 2025.05.07

こんにちは、SCSK株式会社 櫻本です。 2025/6/11-13に幕張メッセで開催されたInterop Tokyo 2025に参加しました。 Interop Tokyoは、ネットワーク・AI・クラウド・セキュリティなどの最新技術や業界動向を体感できる、日本最大級のIT展示会です。 ※イベントの概要については他の方々が書いていますのでここでは割愛します。 このイベントには毎年参加しており、毎回ざっくりとした流行のキャッチアップのみで済ましていましたが、 今年は出展されている製品で担当している顧客の課題解決ができるかという観点で製品をチェックしてきました。 この投稿では顧客が抱える課題のうち、以下の課題に対して効果的な製品をご紹介いたします。 1.サーバの監視業務を行うオペレータが監視ツールからのアラートメッセージを目視で確認したうえで対応するため、多大な保守工数と人為的なミスの懸念を抱えている。 2.保守員がサーバにログインするためのアカウントを利用する際の手続き・事前作業によって発生する運用コストを削減したい。 1.WebSAM Automatic Message Call（NEC社） 【顧客の課題】 サーバの監視業務を行うオペレータが監視ツールからのアラートメッセージを目視で確認したうえで対応するため、多大な保守工数と人為的なミスの懸念を抱えている。 担当顧客では各監視ツールのメッセージをJP1に集約させ、オペレータがJP1のコンソールを確認したうえで手作業でアラートを通知する運用を実施しています。（下図を参照） この運用は24h/365dで行われており、オペレータ複数人での体制を敷いていることから高額な費用を必要としながら、目視でメッセージを確認していることからメッセージの見落とし・連絡先の誤りといったオペミスのリスクがあります。 【1-1.顧客の現状】 WebSAM Automatic Message Call（AMC）は前述の課題を解決する製品となっています。（Zabbixブースで紹介されていました） 機能としてはZabbixやJP1などから送信されるメッセージをAMCで収集し、AMCが事前に定義されたパターンマッチングを基に所定の担当者・通知手段で通知するというものです。 前述の担当顧客の現状で表現するなら、オペレータが実施する業務を全て自動化するものとなります。 オペレータの業務を自動化することでコスト減＋オペミスのリスク減が実現できるため、前述の顧客課題を解消することができる製品と思いご紹介させていただきました。 【1-2.機能概要（ クラウド型通報サービス WebSAM Automatic Message Call: WebSAM | NEC ）】 2.Password Manager Pro（ManageEngine社） 【顧客の課題】 保守員がサーバにログインするためのアカウントを利用する際の手続き・事前作業によって発生する運用コストを削減したい。 担当顧客（前項と同じ顧客）では運用ベンダーがサーバにログインする際、大まかに以下の流れで手続きを行います。 下記手順の運用ではオペレータの負荷の高さや、サーバ利用時ログ取得に外部の録画ツールを必要といった課題があります。 ①.サーバの利用者がサーバの利用申請を起票 ②.システム管理者が承認 ③.オペレータがアカウントの申請を確認して手動でOSのアカウントロック解除を実施する ④.利用者がアンロックされたアカウントを使用して作業を実施する（利用者は録画ソフトを使用して作業証跡を記録する） ⑤.作業終了後にオペレータが手動でアカウントをロックする 【2-1.アカウント運用の現状】 上記の課題を解消するためのツールとして、Password Manager Proをご紹介いたします。 Password Manager Proはワークフロー機能とリモートアクセス機能を統合した特権ID管理ツールです。 申請・承認フローを通したアクセス制御の全てをWebアプリケーションで提供し、操作履歴の記録や画面の録画により監査対応も可能となります。 【2-2.PMP導入例】 前述の顧客のアカウント運用をツールで実現した場合、オペレータでの手動アンロック作業が不要となるため運用工数の削減が期待できます。 例えば、前述のアカウント運用手順で表現するなら、導入時は打消し線の箇所が不要となります。 ①.サーバの利用者がサーバの利用申請を起票 ②.システム管理者が承認 ③.オペレータがアカウントの申請を確認して手動でOSのアカウントロック解除を実施する ④.利用者がアンロックされたアカウントを使用して作業を実施する （利用者は録画ソフトを使用して作業証跡を記録する） ⑤.作業終了後にオペレータが手動でアカウントをロックする 特権ID管理ツールの類似製品はいくつかありますが、前述のアカウント運用の実施内容に対してはマッチした製品であるため、ご紹介させていただきました。 まとめ 今回のInteropではテーマが具体的であるが故に比較的狭い視野でブースを見ることになりましたがその分、各製品の説明やデモンストレーションでは製品の細かい仕様や実装例を知ることができました。 この記事を見ていただいた皆様も、具体的な課題を解決するという明確な目的をもって参加することで製品やサービスに対してより深堀することができると思いました。

皆さんこんにちは。UGです。 6月25日（水）、26日（木）に開催されたAWS Summit Japan 2025に出展しました。 【近日開催！】AWS Summit Japan 2025「AWSで、夢ある未来を共に創る。SCSK」ブースのご紹介！ SCSKはいよいよ開催が迫る「AWS Summit Japan」に出展します。ブースでは「AWSで、夢ある未来を共に創る。SCSK」をテーマに独自ソリューションの4商材を展示、ミニシアターでは6つのAWS関連ソリューションから発表いたします。 blog.usize-tech.com 2025.06.02 今回、自分が所属するAWS内製化支援チームである『 テクニカルエスコート 』が、なんでも相談コーナーとしてブース出展を行いましたので、当日の様子をご紹介します！ またテクニカルエスコートのメンバーである、貝塚社員がパートナーセッションに登壇されましたので、そちらについてもご紹介します！ テクニカルエスコートとは？？ 当日の様子をご紹介する前に、まずテクニカルエスコートってなんぞや？と思った方いらっしゃると思います。 「テクニカルエスコート」は、 お客様のチームに寄り添い、クラウド技術活用人材を育成する、AWS専門家による伴走型内製化支援サービス です。 お客様のプロジェクトにAWS技術者がアドバイザーとして参画し、技術的な指導や課題解決のアドバイスを提供することで、クラウド案件をスムーズに遂行できる体制を支援します。 ↓↓↓テクニカルエスコート公式ページ↓↓↓ AWS内製化支援サービス ー テクニカルエスコートサービス for AWS｜サービス｜企業のDX戦略を加速するハイブリッドクラウドソリューション SCSKの内製化支援サービス「テクニカルエスコートサービス」では、AWSの導入に関して課題に直面されているお客様に、上位認定資格を保有するAWSプロフェッショナルが参画し、AWS活用をサポートします。 www.scsk.jp ↑AWS Summit当日にお配りしていたブローシャー   なんでも相談コーナー では本題のブースの様子です。 ↑なんでも相談コーナー 前述の通りなんでも相談コーナーとして、本当にどんなことでもお聞きくださいというスタンスでブース出展を行っていました。 ぶっちゃけてしまうと本家AWSの方々が様々な相談窓口を設けているので、そんなに来ないのでは？というのが本音でした笑 ですが 嬉しいことに多くの方が足を運んでくださり、相談やテクニカルエスコートの説明を聞いてくださいました！ 中にはAWSについて学びたいという熱意ある学生も来てくださりと、幅広い層への関心を実感しました。 相談内容としては、トレンドであるAIに関するものや、クラウドリフトが多かった印象です。 ↑ブースで相談にのるテクニカルエスコートメンバー（写真は兒玉エンジニア） 貝塚社員登壇『AI で振り込め詐欺を防止しろ！ 四国銀行の 9 ヶ月間の挑戦』 26日(木)の13:00-14:00にてSCSKと四国銀行様との共同でのパートナーセッションがありました！ このセッションでは、テクニカルエスコートのメンバーである貝塚社員と、四国銀行様 のご担当者様 がご登壇され、四国銀行様の取り組みの成果と内製化支援についてのお話をされました。 ↑当日のセッション風景。多くの方にご来場いただき満員御礼となりました！ セッション後にはブースに足を運んでいただき、「感動しました！」とおっしゃってくださる方もいらっしゃいました。 非常にうれしいですね。 テクニカルエスコートメンバーがAWS パートナーネットワーク表彰制度にて選出 25日(水)の17:45～18:05にて表彰セッションが実施され、テクニカルエスコートからは7名が選出されました！！ 表彰者 表彰名 TechHarmonyブログURL 広野 祐司 2025 Japan AWS Ambassadors 2025 Japan AWS Top Engineers (Services)  2025 Japan All AWS Certifications Engineers https://blog.usize-tech.com/author/hirono/ 寺内 康之 2025 Japan AWS Top Engineers (Services)  https://blog.usize-tech.com/author/y-terauchi/ 貝塚 広行 2025 Japan AWS Top Engineers (Networking)  2025 Japan All AWS Certifications Engineers https://blog.usize-tech.com/author/h-kaizuka/ 間世田 秀  2025 Japan AWS Jr. Champions https://blog.usize-tech.com/author/maseda/ 稲葉 航平 2025 Japan All AWS Certifications Engineers https://blog.usize-tech.com/author/k-inaba/ 尾身 優治 2025 Japan All AWS Certifications Engineers https://blog.usize-tech.com/author/omi/ 兒玉 純 2025 Japan All AWS Certifications Engineers https://blog.usize-tech.com/author/j-kodama/ ↑記念写真（左から「兒玉 純」「尾身 優治」「貝塚 広行」「間世田 秀」「広野 祐司」） 自分も今回初めて選出されまして嬉しい限りですが、来年はTop Engineersに選出されるように頑張っていきたいと思います！ ＳＣＳＫ、AWS パートナーネットワーク表彰制度で過去最多の表彰者を輩出 ～高度な技術力と確かな実績で、「AWS に強いＳＣＳＫ」を証明～ 最後に 弊社のセッションやブースにお越しいただいたみなさま、誠にありがとうございました！ 自分は昨年初めてAWS Summitに参加し、当時はAWSを触れたばかりの初心者により雰囲気に圧倒されるだけでしたが、今年は圧倒されることなく楽しむことができたので、それなりに成長できているのかもしれません笑 また今年はブース出展でいろんな方とお話することができ、様々な刺激を得ることができました。 来年のAWS Summitも皆様楽しみましょ～！

みなさん、こんにちは。SCSK株式会社の津田です。 今回はLifeKeeper運用での基本的操作をご紹介します。 LifeKeeper導入後の運用操作のイメージを持っていただけたらと思います。 LifeKeeperではGUIとコマンドでの操作が可能です。 本記事では GUIでの操作 をご紹介させて頂きます。 はじめに GUI操作での特徴は何といっても直感的な操作、情報確認が可能な点です。 GUIはLifeKeeperをインストールした稼働系・待機系どちら側からも起動ができ、対向ノードの情報確認できたり操作が可能です。 ここでは以下LifeKeeper構成を例にGUI 基本操作を紹介していきます。 ※「LifeKeeper GUI」の画面を例に紹介しますが、Webブラウザを利用するLKWMCでのGUIも類似の画面構成となっておりますので同様に操作頂けます。 ステータス確認 GUIを起動するとまず最初に以下の画面が表示されます。 この画面だけでLifeKeeperのステータス確認が可能です。 ▼稼働系(lk01)からGUIを起動した場合の画面 ▼待機系(lk02)からGUIを起動した場合の画面 以下アイコン毎にステータス情報の確認ができます。 ▼サーバ状態の情報 ▼リソース状態の情報   リソース停止起動 全リソース停止 LifeKeeperで制御している全リソースの停止方法をご紹介します。 ※LifeKeeperのサービス自体は停止されません。 ※稼働系から起動したGUI、待機系から起動したGUIどちらからでも操作可能です。 ※今回のLifeKeeperの構成のように依存関係(リソースツリー)を作成している場合、 　 リソース階層に基づき最上位のリソースから停止対象のリソースまでが順番に停止されます。   最下位リソースのActive上で右クリックし、「Out of Service」をクリックします。 以下の様な画面遷移を経て稼働系でアクティブとなっていた全リソースが停止状態になります。 全リソース停止後のGUI。       リソース階層に基づき最上位のリソースから停止対象のリソースまでが順番に停止されます。 そのため本構成でいうと「httpd」リソース単体停止、「httpd」と「ip-10.10.5.100」リソースだけ停止、という操作も可能ですが、リソースツリーの途中（「ip-10.10.5.100」リソース）だけ停止させることはできません。 (依存関係がなければ「ip-10.10.5.100」リソースのみの停止も可能。） ▼「httpd」リソースだけ停止 ▼「httpd」リソースと「ip-10.10.5.100」リソースだけ停止   全リソース起動 LifeKeeperで制御している全リソースの起動方法をご紹介します。 ※稼働系から起動したGUI、待機系から起動したGUIどちらからでも操作可能です。 ※今回のLifeKeeperの構成のように依存関係(リソースツリー)を作成している場合、 リソース階層に基づき最下位のリソースから起動対象のリソースまでを順番に起動できます。←停止とは逆向きの動作になります！ リソース起動させたいサーバの最上位リソース（本構成でいう「httpd」リソース）を右クリックし、「In Service」をクリックします。 以下の様な画面遷移を経てリソースが全て起動します。 全リソース起動後のGUI。    停止とは逆で、最下位のリソースから起動対象のリソースまで順番に起動されますので、 本構成でいうと「lbhc-12345」リソース単体起動、「lbhc-12345」と「ip-10.10.5.100」リソースだけ起動という操作も可能です。 ただしリソースツリーの途中（「ip-10.10.5.100」リソース）だけ停止させることはできません。(依存関係がなければ「ip-10.10.5.100」リソース単体停止も可能。） スイッチオーバ・スイッチバック スイッチオーバ 稼働系から待機系に起動中のリソースを手動で切り換える方法をご紹介します。 ※稼働系から起動したGUI、待機系から起動したGUIどちらからでも操作可能です。 ※今回のLifeKeeperの構成のように依存関係(リソースツリー)を作成している場合、 　 稼働系の最上位リソースから最下位リソースの順番に停止、待機系の最下位リソースから最上位リソースの順番に起動することでスイッチオーバします。 待機系側の最上位リソース（「lbhc-12345」リソース）上で右クリックし、「In Service」をクリックします。 以下の様な画面遷移を経て待機系でリソースが全て起動します。   スイッチオーバ後のGUI。   スイッチバック 待機系から稼働系に起動中のリソースを手動で切り戻す場合もスイッチオーバと同様の手順となります。 ※稼働系から起動したGUI、待機系から起動したGUIどちらからでも操作可能です。 稼働系側の最上位リソース（「lbhc-12345」リソース）上で右クリックし、「In Service」をクリックします。 以下の様な画面遷移を経て稼働系でリソースが全て起動します。 スイッチバック後のGUI。 さいごに 今回はGUIでの基本的な運用操作をご紹介しましたが、いかがでしたでしょうか？ LifeKeeper導入後のGUI操作イメージを持っていただけたら幸いです。 やはりGUIは視覚的にもわかりやすいため、GUIでの操作が圧倒的に多くなるかと思います。 しかしGUIでおおよその運用操作は可能であるものの、一部コマンドラインでしかできない操作もあります。 次回のコマンド編で一部紹介しますので、ぜひ見て頂ければと思います！   詳しい内容をお知りになりたいかたは、以下のバナーからSCSK Lifekeeper公式サイトまで

こんにちは、石原です。 AWS上のデータベースのバージョンアップの際使用した 「Insight SQL Testing」 についてご紹介する内容の第二弾になります。 こちらはインサイトテクノロジー社が提供している製品になります。 Insight SQL Testing - 株式会社インサイトテクノロジー データベース移行及びバージョンアップ向けSQLテストソフトウェア。異種データベース間でSQLのテストができる唯一の製品。 www.insight-tec.com 本内容をご確認いただく前に前回の内容をまずご参照いただけると幸いです。 Insight SQL Testing を触ってみた（第一回） Insight SQL Testingを実際に触った内容を記事にしています。今後データベースのバージョンアップや移行を計画されており、それに伴う工数や懸念をお持ちの方々に是非知ってほしい製品になります。今回はMySQLを対象にして全体的な大まかな設定の流れや結果について概要レベルでまとめたものとなります。 blog.usize-tech.com 2025.04.03 前回は Insight SQL Testing に関して簡単に全体の設定の流れや結果についてお話をしました。 今回は「 Insight SQL Testing の製品導入」について取り扱います。 AWS Marketplace から SQL Testing Manager の Amazon マシンイメージを入手 Insight SQL Testingの導入用法は複数存在しますが、今回はAWSを利用している関係上、EC2上にInsight SQL Testing を構築する方法を紹介します。こちらに関しては、AMI(Amazonマシンイメージ：EC2の構築に必要な内容が入っているテンプレート)が提供されているため、比較的容易に導入が可能です。 注意点としては契約に応じた製品を選択する必要があります。 Insight SQL Testing 4マニュアル support.insight-tec.com 以下の内容は契約期間での請求「Insight SQL Testing Manager（BYOL）」を使用する場合を想定した内容となります。 早速、流れについての手順を説明していきます。 AWS Marketplace へ移動 AWSにログイン後、検索より「 AWS Marketplace 」と入力し、「サービス」→「AWS Marketplace」に移動します。 目的の製品を選択　※契約に依存するため注意が必要 「製品を検出」を選択し、検索にて「Insight SQL Testing」を入力しInsight SQL Testingを絞り込みます。契約に依存する関係上、「Insight SQL Testing BYOL」などといったキーワードで絞り込んだ方が安全です。 私の環境では既にサブスクライブされていたため、説明を一部省略します。 サブスクライブの状況は「サブスクリプションの管理」より確認することができます。 インスタンスの起動 「新規インスタンスの起動」より、ソフトウェアの設定に遷移していきます。   新規インスタンスの設定 新規インスタンスの設定を行っていきます。 バージョン等の設定 以下の画像のように設定してください。 なお、今回解説した「ソフトウェアのバージョン」は、「4.2.0.0」ですが、基本的には最新バージョンを選択するようにしてください。「リージョン」は日本であれば「東京」か「大阪」のいずれかの選択になるかと思いますが、具体的な値は、「グローバル」をクリックすることで確認できます。入力が完了したら「EC2を介して起動を続ける」を押して次に進みます。 Launch an instance の設定 以下の様に、このページは少し縦に長い入力画面になります。 項目数が多いので特に重要なところだけを取り上げます。 キーペア(ログイン) この項目ではインスタンスの接続に必要なキーペアを作成します。 画面にも記載されているように設定は「必須」となります。 ここでは「新しいキーペアの作成」の一例を記載します。 キーペアのタイプは「RSA」または「ED25519」より選択可能です。 作成が完了すると、ローカルにキーファイルがダウンロードされます。 ネットワーク設定 ネットワークの設定は、既存のセキュリティグループを利用することもできます。 ただし、その場合はセキュリティグループにSSH(22)およびHTTP(7777)を追記しておく必要があります。 ストレージを設定 詳しくはシステム要件の確認が必要となりますが、監視対象のデータベース1インスタンスあたり、1カ月で約50GB程度のストレージが必要と想定されています。もちろん、ソースDB側の利用状況に依存して必要となるサイズは異なります。基本的には、データ量域として50GB, バックアップ領域に10GB程度設定しておくとよさそうです。 以下はデフォルトの設定を載せています。 上から以下のように対応しています。 /dev/sda1　→　32GB以上の指定が必要。未満の場合には以下のようにインスタンスの起動に失敗します。 /dev/sdb　→　データ領域 /dev/sdc　→　バックアップ領域 /dev/sdd　→　PostgresSQLのWALログ領域   インスタンスの起動 上記までの設定を行い、起動に成功すると以下の画面が表示されます。 起動後は以下の設定を行います。   まとめ 今回はEC2の作成方法ということで書いてみたものの、少し中身の薄い内容になってしまいました。 次回は実際のInsight SQL Testingの操作（特にInsight SQL Testingに対してMySQLのジェネラルログ(一般ログ)の読み取りについて）です。 実際にここの動作に一番検証に時間を要しました。 検証結果をまとめてご報告できればと思います。

みなさま、こんにちは！ 最近笑いすぎてそろそろ腹筋が割れそうです。いとさんです。 先日目黒にてJapan AWS Top Engineers GameDay が開催されました。 社内のJapan AWS Top Engineersの方からご連絡いただき、こちらTop Engineerの方に同伴者が一人参加できるとのことで勇気を出して立候補しました。 私のスペック 名前 : いとさん ジョブ : サイト運営、セミナー運営、デザイン レベル : IT業界約1年 経験値 : AWSを触り始めて4ヶ月目 特技 : デザイン アイテム : PC んー…経験値もレベルも足りなさ過ぎているような気がしますが、とりあえずやってみようの精神で！ AWS Top Engineersの方々の渦に飛び込んみました。 メンバーの皆さん [左から(アイレット株式会社)髙橋さん、私、(キンドリルジャパン株式会社)奈良さん、(ソニービズネットワークス株式会社)濱田さん] 上記の御三方、実は AWS Ambassadors… 私、とんでもなく凄いメンバーの方々と一緒になってしまいました 因みにチーム名は The Generators。 どこかアーティストみを感じるとってもいい名前ですね👍 GameDay概要 GameDayの詳細はネタバレ防止のため公開できませんが、4名1チームとなり技術的課題の解決に挑み、GenAIを使ってアプリケーションのバグや生成AIの組み込みを行うというものでした。 書くことが出来ないのが大変心苦しいのですが シナリオ概要の説明が面白く細かいところまでこだわっていて運営の皆様の努力を感じました。 作業内容 作業は私とリーダーの方を1人と換算し3人で大設問を分担して行っておりました。 やはりひよっこの私にできることはとても少なかったですね。 プロンプトエンジニアリング、Amazon Bedrockの概要、ガードレール等について、コーチングしていただきながら設問に対して回答していきました。私の担当した設問はAmazonQやBedrockを使用してAIと会話し解決するというプロンプトエンジニアリングが重要になってくる設問でした。 stepfunctionもサービスとしては知っていましたが初めて触り、どのように動作しているかを実際に確認することが出来ました。 他の設問を担当していたメンバーの皆さんの解決スピードは全体の中で 1桁台！ (私は2桁…流石Ambassadorsの力強い…) お助けいただき、順調に進み残り1問となりました！ 全体順位10位台、残り時間は1分…F5キーを連打、果たして完走できたのでしょうか… 結果はいかに… 終了～！ 司会の方の合図とともに皆さん作業が終了いたしました。 解説の後ついに順位発表、果たして The Generators の結果は (;ﾟДﾟ)(ﾟДﾟ;(ﾟДﾟ;)(;ﾟДﾟ)…ｴｯ? なななんと、 優勝 でした…滑り込みで回答が間に合っていたようです。(F5の力凄い…) チームメンバーの皆さん含めまさか優勝とは思っておらず喜びより驚きが大きかったです。(2,3位の方も例年参加されている方々のため) 今後に向けて … 参加して今後に活かしていきたいことがいくつかありました。 プロンプトエンジニアリングに関する知識の必要性 Bedrockに質問するにあたり漠然としたプロンプトでは、期待外れの出力しか生成できないことが多く、何度も試行錯誤を繰り返すことになります。プロンプトエンジニアリングを習得することで、 一度のプロンプトで目的の結果に近づける ことが可能になり、時間とリソースの無駄を省くことができると感じた。 幅広い知識の習得 今回GenAIに関するGameDayだったからなのかクラウドの知識とAIとの対話、コーディングの理解が必要。 原因解決にあたりサービスの理解に加え開発に関する多様な知識があるとスピーディーに原因究明、解決に進めるのかなと思った。 メンバーとのコミュニケーションの重要性 今回のメンバーの方はお互いに解決できないことに対し積極的に会話を行なっており明るく作業を進めているように感じた。制限時間の間ずっと各個人で黙々行うチームもあったのかと思いますが今回一緒に進めさせていただいたメンバーの方は会話を、雰囲気を大切にされていて実力もあると思いますが、そこがさらに優勝に繋がった要因なのかと思いました。今後の業務でもポジティブに雰囲気を大切にしていこうとさらに思わされました。   感想&賞品 問題によっては初学者(ひよっこ)でも解ける問題がある。 GameDayのテーマの学習を進めておくと少し楽になるかも…？と思いました！ 初めてのGameDayは学びになることが多くとても楽しかったです。 新しい場所に飛び込むのは緊張すると思いますが玄人の皆さんはとても優しいです。 是非積極的に楽しんで飛び込んでいきましょう！！ 優勝商品とシールをいただきました🎁かわいい 冷たい飲み物沢山飲みます🎵

SCSK 永見です。 Reserved Instance、コスト削減の話になると、よく出てきます。 これらを詳しく知ろうとして調べても、詳細な説明に終始して、そもそも何なの？というのがよくわからず困った記憶があります。 この記事は「Reserved Instance チョットワカル」私が、この記事の読者に「Reserved Instance 完全に理解した」状態へ導く記事となっています。 前提事項 この記事は、初めてReserved Instance(以下、RI と省略します)に触れる人向けに、分かりやすさに重きを置いて執筆しています。正確・詳細な情報は公式ドキュメントなどを参照にしてください。 また、料金はすべて例示の値です。正式な情報は料金表をご確認ください。 Amazon EC2 リザーブドインスタンス料金表 | AWS aws.amazon.com 今回はEC2のRIを例にとり、説明しています。 Reserved Instanceとは？ カフェで使える割引券をイメージしてみましょう。 この割引券は、ドリンクの種類(コーヒー、カプチーノ、抹茶ラテ、etc…)、ドリンクのサイズ(S、M、L)、などを指定して購入します。 その割引券を使うことで、指定された条件と一致した種類・サイズのドリンクと引き換えることができます。 そして、普通に買うよりも割り引かれた金額でドリンクを購入することができます。 例えば、コーヒーSサイズ(以下、”コーヒー”と省略します)が1杯500円とし、この”コーヒー”用の割引券12枚つづりは4,800円で購入できる とします。 この割引券を使うことで、20%引きの400円で飲むことができます。 さて、割引券をRIに、”コーヒー”をインスタンスに置き換えてみましょう。 RIは、プラットフォーム(Linux、Windows、RedHat)、インスタンスタイプ(t3.large、r5.xlarge)などを指定して購入します。 購入されたRIは、指定された条件と一致したEC2インスタンスに対して、その料金として充当されます。 そして、オンデマンドで使うよりも割り引かれた金額でEC2インスタンスを利用することができます。 例えば、Linux、t3.largeのEC2インスタンスが、オンデマンドでは1時間あたり$0.1とし、このインスタンス相当のRI(1年間)は$560.64=$0.064/h×24時間×365日 で購入できる とします。 このRIの料金充当により、1時間あたり$0.064でEC2インスタンスを利用することができます。 じゃあたくさん買えばお得になるの？ 安く使えるならたくさん割引券を買っておけば、お得になるんじゃないの？と思うかもしれませんが、そうはいきません。 この割引券は毎月1枚しか使えず、かつ1か月間の使用期限があります。 なので、毎月コンスタントに”コーヒー”を飲む人にとってはお得ですが、1か月で12杯飲むために使用することはできません。 同じくRIも、割引は一時間ごとに適用され、一時間のうちに使用されたEC2に対して割引が適用されます。 なので、24時間365日稼働するEC2がある場合にはお得ですが、一時的な開発で大量のEC2を使う という場合にはコストメリットは享受しづらいです。 どうやって使うの？ コーヒーの割引券は購入の時に出すことで引き換えることができますが、RIは購入するだけで勝手に割引が適用されます。 また、コーヒーは”1杯”に対して割引が適用されますが、RIは対象のインスタンス”合計1台分”に対して割引が適用されます。 例えば、Linux、t3.largeのRIを1台分買っていて、かつLinux、t3.largeのEC2インスタンスが2台あった場合、30分間は2台ともRIによる割引料金で、のこり30分は2台ともオンデマンドの料金になります。 もっと安くするにはどうしたらいいの？ もっとお得に、つまりもっと安く”コーヒー”を飲むにはどうしたらいいでしょうか。 主に3つ方法があります。 方法その1：有効期限が長いものを買う この割引券は12枚(12枚×1年分)綴りと36枚(12枚×3年分)綴りがあります。36枚入りのほうが、より割引率が高く、安く”コーヒー”を買うことができます。 さて、割引券をReserved Instanceに、”コーヒー”をインスタンスに置き換えてみましょう。 Reserved Instanceは、期間が1年間と3年間があります。3年間のほうが、より割引率が高くなります。 方法その2：先払いする この割引券には3種類の買い方があります。 1つは最初に全額払ってしまう方法、2つ目は半額払って半額ののこりを分割払いする方法、3つ目は毎月分割払いする方法。 最初に払う金額が大きいほど、より割引率が高く、安く”コーヒー”を買うことができます。 さて、割引券をReserved Instanceに、”コーヒー”をインスタンスに置き換えてみましょう。 RIは、支払い方法が全額前払い、一部前払い、前払いなしの3種類あります。 最初に払う金額が大きい、つまり全額前払い→一部前払い→前払いなし の順番で、より割引率が高くなります。 方法その3：交換できない割引券を買う この割引券には、”コーヒー”以外の割引券に交換できる種類とできない種類があります。交換できる割引券において、値段が違う場合は、差額を払うことで交換することができます。 交換できない割引券のほうが、より割引率が高く、安く”コーヒー”を買うことができます。 さて、割引券をReserved Instanceに、”コーヒー”をインスタンスに置き換えてみましょう。 Reserved Instanceは、提供クラスにはスタンダートとコンバーティブルがあります。スタンダードは他のReserved Instanceと交換できませんが、コンバーティブルであれば交換できます。 交換できないスタンダードのRIのほうが、より割引率が高くなります。 まとめ Reserved Instanceとはそもそも何なのか、について説明しました。 RIの活用はじめ、コストに関してお困りごとがあればぜひSCSKまでご相談ください！ SCSKクラウドサービス（AWS）│SCSK株式会社｜サービス｜企業のDX戦略を加速するハイブリッドクラウドソリューション アマゾン ウェブ サービス（AWS)の最上位パートナーであり、多種多様な業界のシステム構築実績を持つSCSKが、最適なAWS導入をサポート。AWS活用によるお客様のITガバナンス強化とDX推進を強力に支援します。 www.scsk.jp

SCSK 永見です。 Reserved Instance、Savings Plans。 コスト削減の話になると、よく出てきます。 これらを詳しく知ろうとして調べても、詳細な説明に終始して、そもそも何なの？というのがよくわからず困った記憶があります。 この記事は「Savings Plans チョットワカル」私が、この記事の読者に「Savings Plans完全に理解した」状態へ導く記事となっています。 前提事項 この記事は、初めてSavings Plans(以下、SPsと省略します)に触れる人向けに、分かりやすさに重きを置いて執筆しています。正確・詳細な情報は公式ドキュメントなどを参照にしてください。 また、料金はすべて例示の値です。正式な情報は料金表をご確認ください。 Compute Savings Plans – アマゾン ウェブ サービス Savings Plans は柔軟な購入オプションです。1 年または 3 年の契約でさまざまな AWS Compute サービスに対する大幅な割引を提供します。Savings Plans には、Compute Savings Plans と... aws.amazon.com 今回はEC2のSPsを例にとり、説明しています。 Savings Plansとは？ カフェで使えるプリペイドカードをイメージしてみましょう。 ドリンクの種類(全種類、コーヒー、カプチーノ、抹茶ラテ、etc…)、有効期限などを決めたうえで、金額を指定してチャージするようなプリペイドカードです。 このプリペイドカードで、指定したドリンクを購入することができます。 そして、普通に買うよりも割り引かれた金額でドリンクを購入することができます。 例えば、ホットコーヒー(以下、”コーヒー” と省略します)が1杯500円とします。 “コーヒー”用のプリペイドカードから支払うことで、20%引きの400円で飲めてしまいます。 さて、プリペイドカードをSavings Plansに、”コーヒー”をインスタンスに置き換えてみましょう。 SPsは、適用するインスタンスの種類、期間などを決めたうえで、金額を指定します。これをコミットメントといい、「期間中、1時間当たり$〇〇分のリソースを使います！」と宣言するようなイメージです。 このコミットメント額は、指定された条件と一致するEC2インスタンスに対して、その料金として充当されます。 割引後の金額合計がコミット額に達する分まで、割引を適用することができます。 例えば、Linux、t3.largeのEC2インスタンスが、オンデマンドでは1時間あたり$0.1とし、t3系のSPsを$1.00/hのコミットメントを1年間分、つまり$365分購入した とします。 このSPsの料金充当により、1時間あたり$0.06でEC2インスタンスを利用することができます。 じゃあたくさんチャージすればお得になるの？ 安く使えるならたくさんチャージしておけば、お得になるんじゃないの？と思うかもしれませんが、そうはいきません。 このプリペイドカードは毎月一定額しか使えず、かつ1か月間の使用期限があります。使い切れなかった分は失効してしまいます。 なので、毎月コンスタントに”コーヒー”を飲む人にとってはお得ですが、1か月で12杯飲むために使用することはできません。 同じくSPsも、割引は一時間ごとに適用され、一時間のうちに使用されたEC2に対して割引が適用されます。 なので、24時間365日稼働するEC2がある場合にはお得ですが、一時的な開発で大量のEC2を使う という場合にはコストメリットは享受しづらいです。 どうやって使うの？ プリペイドカードは支払いの時に出すことで使うことができますが、SPsは購入するだけで勝手に割引が適用されます。 また、コーヒーは”1杯”に対して割引が適用されますが、SPsは対象のインスタンス”合計利用額”に対して割引が適用されます。 ちょっと難しいので、詳しく説明します。 例えば、このようなケースを想定してみましょう。 t3のEC2 Instance Savings Plans を$1.00/h分購入 t3.largeのEC2インスタンスが20台、1時間稼働。 このt3.largeインスタンスにおけるオンデマンド料金は$0.1/h、SPs料金は$0.06/h。削減率は40%=100%-$0.06÷$0.1 結論はこんなイメージになります。点線内がSPsによる充当で合計$1.00、点線外がオンデマンド価格となります。 細かく計算過程を追ってみましょう。 このケースの利用額は、全額オンデマンド料金と全額SPs料金の場合それぞれ算出すると、以下のようになります。 今回はSPsを$1.00分購入しているので、以下のように一部SPsによる充当、一部オンデマンドによる支払いに分けます。 $1.00のSPsによる充当額と、充当しきれなかった分のオンデマンド相当額の$0.33、計$1.33がかかります。 もっと安くするにはどうしたらいいの？ もっとお得に、つまりもっと安く”コーヒー”を飲むにはどうしたらいいでしょうか。 3つ方法があります。 方法その1：有効期限が長いものを買う このプリペイドのチャージ方式は有効期限1年間(指定金額×12ヶ月分)と3年間(指定金額×36ヶ月分)があります。 3年間のほうが、より割引率が高く、安く”コーヒー”を買うことができます。 ※指定金額を大きくしても割引率は大きくなりません。 さて、プリペイドカードをSPsに、”コーヒー”をインスタンスに置き換えてみましょう。 SPsは、期間が1年間(コミットメント額×24時間×365日)と3年間(コミットメント額×24時間×365日×3年間)があります。 3年間のほうが、より割引率が高くなります。 ※コミットメント額を大きくしても割引率は大きくなりません。 方法その2：先払いする このプリペイドカードには3種類のチャージ方法があります。 1つは最初に全額チャージしてしまう方法、2つ目は一部チャージしてのこりを毎月チャージする方法、3つ目は毎月チャージする方法。 最初にチャージする金額が大きいほど、より割引率が高く、安く”コーヒー”を買うことができます。 さて、プリペイドカードをSPsに、”コーヒー”をインスタンスに置き換えてみましょう。 SPsは、支払い方法が全額前払い、一部前払い、前払いなしの3種類あります。 最初に払う金額が大きい、つまり全額前払い→一部前払い→前払いなし の順番で、より割引率が高くなります。 方法その3：専用プリペイドカードを買う このプリペイドカードは、カフェの全商品に対して使える「なんでもプリペイドカード」と、特定の商品に対して使える「専用プリペイドカード」があります。 なんでもプリペイドカードよりも、専用プリペイドカードのほうが、より割引率が高く、安くコーヒーを買うことができます。 さて、割引券をSavings Plansに、コーヒーをインスタンスに置き換えてみましょう。 EC2に適用できるSPsには、Compute Savings PlansとEC2 Instance Savings Plansがあります。 Compute Savings Plansはあらゆる種類のEC2に適用されますが、EC2 Instance Savings Plansは購入時に指定したインスタンスファミリーのみに適用できます。 指定したインスタンスファミリーにしか適用できないSPsのほうが、割引率は高くなります まとめ SPsとはそもそも何なのか、について説明しました。 SPsの活用はじめ、コストに関してお困りごとがあればぜひSCSKまでご相談ください！ SCSKクラウドサービス（AWS）│SCSK株式会社｜サービス｜企業のDX戦略を加速するハイブリッドクラウドソリューション アマゾン ウェブ サービス（AWS)の最上位パートナーであり、多種多様な業界のシステム構築実績を持つSCSKが、最適なAWS導入をサポート。AWS活用によるお客様のITガバナンス強化とDX推進を強力に支援します。 www.scsk.jp

こんにちは、ひるたんぬです。 最近は暑い日が続いていますね。私はこの時季になると冷房が欠かせないものとなっています。 世間では「春と秋がどんどん短くなっている」と言われており、私もそう思っていたのですが、具体的にどれだけ短くなっているのでしょうか？ 調べてみると、そもそも春夏秋冬の絶対的な定義というものは存在しないようです。 気象学や天文学、伝統的な区切り方がそれぞれあるようですね。 こうなると、「私にとっての春」と「未来の人にとっての春」のイメージは大きく異なるものになりそうですね。 ひまわりは春の花、が常識になる日も…？ ※ 参考… 国立天文台 | 暦Wiki「季節とは？」 さて、今回は標準ユーザーが管理者権限を持つユーザーに昇格した場合に、そのアクティビティをAmazon SNSを用いて通知する方法をご紹介します。 やりたいこと Windows OSにおいて管理者権限を持たないユーザーが、管理者権限を持つユーザーに昇格した場合に、他の管理者に通知したい場合を想定しています。今回のWindows OSはWorkSpaces上で稼働している想定ですが、WorkSpacesに限らず、どこでも通用するかなと思います。 やり方 ここからは、実際にどのように設定していくかをご紹介していきます。 事前準備 通知先のAmazon SNSトピック・サブスクリプションを作成します。 今回はメールでの通知を設定しています。 また、後述するスクリプトがメッセージを送信できるようにIAMユーザーとアクセスキーを作成します。 最小権限の原則から、当該トピックでのSNSメッセージ送信のみ許可されたIAMユーザーを新しく作成することを推奨します。 今回はこれら事前準備の手順は割愛します。詳細は公式ドキュメントなどをご参照ください。 Amazon SNS トピックを作成する - Amazon Simple Notification Service AWS SDKs を使用して Amazon SNS トピックを作成する包括的な手順について説明します。トピックタイプの選択、命名規則、暗号化の有効化、アクセス許可の設定の手順について詳しく説明します。 AWS Management Cons... docs.aws.amazon.com Amazon SNS トピックのサブスクリプションの作成 - Amazon Simple Notification Service を使用して Amazon SNS トピックにエンドポイントをサブスクライブする方法について説明します。トピック ARN の選択 AWS Management Console、エンドポイントタイプ (HTTP/HTTPS、E メール、Amaz... docs.aws.amazon.com AWS アカウント で IAM ユーザーを作成する - AWS Identity and Access Management AWS Identity and Access Management で IAM ユーザーと認証情報を作成するために使用されるプロセスの基本的な概要。 docs.aws.amazon.com IAM ユーザーの新しいアクセスキーを作成する - Amazon Keyspaces (Apache Cassandra 向け) AWS 認証情報を使用してプログラムによって Amazon Keyspaces に接続するために、IAM ユーザーまたはロールのアクセスキーを作成する方法を説明します。 docs.aws.amazon.com なにをトリガーにするか 今回の肝となるのは、「どのように管理者権限を持つユーザーに昇格したことを知るか」です。 調べてみると、これはWindows ログのイベントとしてログが記録されることが分かりました。 今回はこの中でも「セキュリティ」の中に記録されているイベントIDが4648のログに着目します。 このログは明示的な資格情報を使用したサインインを記録するもので、RUNASなどの昇格操作を実施した際に記録されるものです。 実際に昇格操作を実施したところ、確かにログが記録されることを確認したので、今回はこのイベントIDのログを利用することにします。 Amazon SNSでの通知スクリプト トリガーを受けての操作として、Amazon SNSを用いた通知を行います。今回はこの部分をPowerShellのスクリプトで作成しました。 今回は「admin」という名前を含むユーザーに昇格した場合に通知をするという内容にしています。 関数の引数はIAMの認証情報と、通知先のSNSトピックのARNが必須で必要です。適宜付与するようにしてください。 また、エラー処理などはすべて省いております。 function Get-AdminAlert {   param (       [Parameter(Mandatory = $true)]       [string]$AccessKey,         [Parameter(Mandatory = $true)]       [string]$SecretKey,             [Parameter(Mandatory = $true)]       [string]$TopicArn,                [Parameter(Mandatory = $false)]       [string]$Region = "ap-northeast-1"   )   # AWS CLI用の環境変数を設定   $env:AWS_ACCESS_KEY_ID = $AccessKey   $env:AWS_SECRET_ACCESS_KEY = $SecretKey   $env:AWS_DEFAULT_REGION = $Region     # イベントログから管理者に昇格しているログを抽出   $admin_name = "admin"   $now = Get-Date     # 発火時から30秒以内の該当イベントログを取得   $eventlog =  Get-EventLog -LogName Security -Newest 1 -EntryType SuccessAudit -InstanceId 4648 -Message *$admin_name* -After $now.Addseconds(-30)   if ($eventlog -eq $null) {       Write-Host "No relevant event logs found." -ForegroundColor Yellow       return $false   }     # Message内を処理するため、Jsonに変換後PowerShellオブジェクトに変換   $eventlog_json = $eventlog | ConvertTo-Json   $eventlog_object = ConvertFrom-Json $eventlog_json     # 昇格先アカウント名を抽出   $admin_account = $eventlog_object.ReplacementStrings[5]   if ($admin_account -eq $null) {       $admin_account = "Unknown"       Write-Host "No admin account found in the event log."   }     # イベント発生日時を抽出（UTC）   $eventtime = $eventlog_object.TimeGenerated   # イベント発生日時を日本時間に変換   $eventtime_jst = $eventtime.ToUniversalTime().AddHours(9)     # SNSメッセージの作成   $subject = "昇格操作が実行されました"   $snsMessage = "以下の昇格操作が実行されました。`n`n" +                 "昇格先アカウント: $admin_account`n" +                 "イベント発生日時: $eventtime_jst`n"     # Amazon SNSを使用して通知を送信 $messageId = (aws sns publish --topic-arn $TopicArn --subject $subject --message $snsMessage | ConvertFrom-Json).MessageId     finally {       # 環境変数をクリア       Remove-Item Env:\AWS_ACCESS_KEY_ID -ErrorAction SilentlyContinue       Remove-Item Env:\AWS_SECRET_ACCESS_KEY -ErrorAction SilentlyContinue       Remove-Item Env:\AWS_DEFAULT_REGION -ErrorAction SilentlyContinue   } } トリガーの設定 トリガーにしたいイベントと、実行したいスクリプトが完成したので、最後にトリガーを設定します。 ここでは、Windowsのタスクスケジューラを用います。 「全般」タブにおいて、タスク名には任意の名前を設定します。一方、セキュリティオプション内の「タスクの実行時に使うユーザー アカウント」ではSYSTEMユーザーを指定します。 「トリガー」タブでは、トリガーを設定します。先程決定したイベントをトリガーとして設定します。 「タスクの開始」を「イベント時」、「ログ」を「セキュリティ」、「ソース」を「Microsoft Windows security auditing.」、「イベントID」を「4648」とします。 次にトリガーが発火した後の操作を設定します。 「操作」タブから「操作」を「プログラムの開始」、「プログラム/スクリプト」を「PowerShell.exe」、「引数の追加」で「-NoProfile -ExecutionPolicy Bypass -File “ファイルパス”」と指定します。 動作確認 実際に昇格操作を実施してみます。すると… しっかりメールで通知がされました！ 終わりに 今回はWindowsの標準機能とAWSの機能を組み合わせて管理者権限への昇格操作を通知する仕組みをご紹介しました。 タスクスケジューラのトリガーでは、トリガーのきっかけとなったイベントのログIDなどを知ることができないため、どのログによって発火したのかをPowerShellのスクリプトで知ることができません。 そのため、今回は30秒以内の最新の昇格操作を取得し送信するという対処法を取っています。 AWSのEventBridge的な感覚で触っていた私にとっては、この点は少し不便な仕様だな…と思った次第です。 余談 CloudWatch Agentをインストールして、セキュリティログをCloudWatch Logsに出力してゴニョゴニョ…の方がセンスあるかも？とも思いました。

はじめに 当記事は、 日常の運用業務（NW機器設定）の自動化 により、 運用コストの削減　および　運用品質の向上 　を目標に 「Ansible」 を使用し、様々なNW機器設定を自動化してみようと　試みた記事です。 Ansibleは、OSS版（AWX）＋OSS版（Ansible）を使用しております。   PaloAltoの「Objects-サービス」の登録／変更／削除を実施してみた 事前設定 Templateを作成し、インベントリーと認証情報を設定する。 インベントリー：対象機器（ホスト）の接続先を設定。　※ホストには以下変数で接続先IPを指定 ansible_host: xxx.xxx.xxx.xxx 認証情報：対象機器へのログイン情報（ユーザ名／パスワード）を設定。 ユーザ名は　　変数：ansible_user　　　に保持される パスワードは　変数：ansible_password　に保持される   Playbook作成（YAML） 使用モジュール paloaltonetworks.panos.panos_service_object 　を使用。 ※参考ページ：https://galaxy.ansible.com/ui/repo/published/paloaltonetworks/panos/content/module/panos_address_object/   接続情報（provider）の設定 providerには、ip_address／username／password　の指定が必要。 vars: provider:   ip_address: '{{ ansible_host }}'　　　←　インベントリーのホストで設定   username: '{{ ansible_user }}'　　　　←　認証情報で設定   password: '{{ ansible_password }}'　　←　認証情報で設定   Objects-サービスの登録 接続情報とサービス情報を指定して登録（state: ‘present’）を行う。 - name: Add Service1 paloaltonetworks.panos.panos_service_object: provider: '{{ provider }}' name: 'test_service001' protocol: 'tcp' destination_port: '10' source_port: '110' description: 'test_service001' tag: ['test'] state: 'present' register: wk_result 実行結果：対象のサービスが登録された。　※Ansibleの実行結果（diff）を抜粋 "before": "", "after" : "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_service001\">\n\t<protocol>\n\t\t<tcp>\n\t\t\t<source-port>110</source-port>\n\t\t\t<port>10</port>\n\t\t</tcp>\n\t</protocol>\n\t<description>test_service001</description>\n\t<tag>\n\t\t<member>test</member>\n\t</tag>\n</entry>\n"   Objects-サービスの変更　※登録のつづき 接続情報とサービス情報を指定して　登録されたサービスの変更（ state: ‘replaced’ ）を行う。　 ※replacedの場合は、既存設定の置き換えとなる - name: Change Service1 paloaltonetworks.panos.panos_service_object: provider: '{{ provider }}' name: 'test_service001' protocol: 'tcp' destination_port: '20' source_port: '120' description: 'test_service001' # tag: ['test'] state: 'replaced' register: wk_result 実行結果：登録時のtag指定ありのサービスが、Rreplaedによりtag指定なしのサービスに変更された。　※Ansibleの実行結果（diff）を抜粋 "before": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_service001\">\n\t<protocol>\n\t\t<tcp>\n\t\t\t<source-port>110</source-port>\n\t\t\t<port>10</port>\n\t\t</tcp>\n\t</protocol>\n\t<description>test_service001</description>\n\t<tag>\n\t\t<member>test</member>\n\t</tag>\n</entry>\n", "after" : "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_service001\">\n\t<protocol>\n\t\t<tcp>\n\t\t\t<source-port>120</source-port>\n\t\t\t<port>20</port>\n\t\t</tcp>\n\t</protocol>\n\t<description>test_service001</description>\n</entry>\n"   接続情報とサービス情報を指定して　登録されたサービスの変更（ state: ‘merged’ ）を行う。　 ※mergedの場合は、既存設定の上書きとなる - name: Change Service2 paloaltonetworks.panos.panos_service_object: provider: '{{ provider }}' name: 'test_service001' protocol: 'tcp' destination_port: '30' source_port: '130' # description: 'test_service001' tag: ['test'] state: 'merged' register: wk_result 実行結果：上記変更時のtag指定なしのサービスが、mergedによりtag指定ありのサービスに変更された。また、サービス情報にdescriptionを指定しなくても、既存設定が維持されていることを確認。　※Ansibleの実行結果（diff）を抜粋 "before": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_service001\">\n\t<protocol>\n\t\t<tcp>\n\t\t\t<source-port>120</source-port>\n\t\t\t<port>20</port>\n\t\t</tcp>\n\t</protocol>\n\t<description>test_service001</description>\n</entry>\n", "after" : "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_service001\">\n\t<protocol>\n\t\t<tcp>\n\t\t\t<source-port>130</source-port>\n\t\t\t<port>30</port>\n\t\t</tcp>\n\t</protocol>\n\t<description>test_service001</description>\n\t<tag>\n\t\t<member>test</member>\n\t</tag>\n</entry>\n"   Objects-サービスの情報収集　※変更のつづき 接続情報とサービスを指定して情報収集（state: ‘gathered’）を行う。 - name: Get Service Info paloaltonetworks.panos.panos_service_object: provider: '{{ provider }}' name: 'test_service001' state: 'gathered' register: wk_result 実行結果：対象サービスの情報が取得できた。　※Ansibleの実行結果（gathered_xml）を抜粋 "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_service001\">\n\t<protocol>\n\t\t<tcp>\n\t\t\t<source-port>130</source-port>\n\t\t\t<port>30</port>\n\t\t</tcp>\n\t</protocol>\n\t<description>test_service001</description>\n\t<tag>\n\t\t<member>test</member>\n\t</tag>\n</entry>\n",   Objects-サービスの削除　※変更のつづき 接続情報とサービスを指定して削除（state: ‘absent’）を行う。 - name: Delete Service1 paloaltonetworks.panos.panos_service_object: provider: '{{ provider }}' name: 'test_service001' state: 'absent' register: wk_result 実行結果：対象のサービスが削除された。　※Ansibleの実行結果（diff）を抜粋 "before": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_service001\">\n\t<protocol>\n\t\t<tcp>\n\t\t\t<source-port>130</source-port>\n\t\t\t<port>30</port>\n\t\t</tcp>\n\t</protocol>\n\t<description>test_service001</description>\n\t<tag>\n\t\t<member>test</member>\n\t</tag>\n</entry>\n", "after" : ""   最後に 「Ansible」の「paloaltonetworks.panos.panos_service_object」を使用し、「Objects-サービス」の登録／変更／削除　および　情報収集ができたことは良かった。何らかの変更申請の仕組みと連携することで、より　設定変更の自動化　が活用できるようになると考える。 現状　設定情報がベタ書きで使い勝手が悪いので、今後　設定内容をINPUTする仕組みを試みたいと思います。 また、引続き　他にも様々なNW機器設定を自動化してみようと思います。

こんにちは。SCSKの青木です。 Interop Tokyo2025の2日目に参加してきました。 参加したセッションや見に行った展示について感想を書こうと思うので、気になるものがあればぜひ読んでください。 Interopとは 日本を問わず色々な企業が参加し製品紹介やセミナーを行っているインターネットテクノロジーのイベントになります。 以下は公式からの引用となります。 Interop Tokyoはインターネットテクノロジーのイベントです。 1994年の日本初開催以来、毎年国内外から約500の企業・団体が参加し、技術動向とビジネス活用のトレンドを、会場でのデモンストレーションやセミナーを通じてお伝えしてきました。国内のインターネットや技術革新の歴史と共に歩んできたこのInterop Tokyoをご覧いただくことで、インターネット分野のトレンドをいち早く体感いただくことができます。 引用） Interop Interop Tokyo 2025 「Interop Tokyo」は技術動向とビジネス活用のトレンドを会場でのデモンストレーションやセッションを通じてお伝えするインターネットテクノロジーイベントです。 www.interop.jp   参加したセッション この製品チェック！～アワード審査員が今年の注目製品を解説～ 6/12（木）、6/13（金）の二日に分けて注目製品の発表がありました。 物理機器やラックの紹介が多く、クラウド案件を担当しているため、あまり考えたことはなかったですが、データセンターには、このようなネットワーク機器が数多く並んでいるのだと実感しました。 6/12（木）の解説された部門 ・セキュリティ ・デジタルメディア ・産業ネットワーク ・IoT/エッジコンピューティング ・ファシリティ 特に印象に残った製品：Cisco社「Cisco AI Defense」 普段はサーバやクライアントに対してセキュリティ製品を導入するのが一般的だと感じていましたが、日々利用しているAIに対して専用のセキュリティ製品を使用するという発想は思い浮かんだことがありませんでした。 また、AIを活用すること方法については考えたことはありますが、AIに対する攻撃について考えることがなかったのでAIに対する攻撃を知る良い機会となりました。 参考） アワード受賞企業一覧 Interop Tokyo 2025 「Interop Tokyo」は技術動向とビジネス活用のトレンドを会場でのデモンストレーションやセッションを通じてお伝えするインターネットテクノロジーイベントです。 interop.jp Cisco AI Defense Cisco AI Defense AI Defense は、AI の開発、展開、使用によってもたらされる安全性およびセキュリティのリスクを防ぐ、エンドツーエンドの AI セキュリティソリューションです。 www.cisco.com Chrome Enterpriseで実現する、AI時代の生産性とゼロトラスト 主な紹介機能 ・マルチOS対応のブラウザ制御 ・拡張機能のリスク監査と制御 ・悪意のあるサイトへのリアルタイム監査 ・セキュリティログの可視化・分析 管理方法の特徴 ・上記の機能は、ブラウザにログインすることでポリシーとして適用される。 ・ブラウザベースで一元管理できるため、業務をブラウザに集約することでデバイス側の設定が削減可能となる。 Chrome OS活用によるメリット ・Chrome OSを合わせて使用することにより、運用効率化、コスト削減、セキュリティ強化が実現できると紹介がありました。 感想 ・ブラウザに業務を集約することで、利用者のデバイス準備や作業の負担軽減が期待できるため、Microsoft製品によるOSやユーザ管理（AD活用）が多いですが、今後はAD不要でGoogleアカウントとChromeブラウザを活用したGoogle製品による運用に移行する企業も増えていくのではないかと感じました。 ・いただいた資料の情報ですが、2024年5月時点の情報によると、Chrome OSはおよそ15年のリリース期間で、マルウェア／ランサムウェア被害が「ゼロ」、ウイルス攻撃の成功報告も「ゼロ」となっています。非常に高いセキュリティ実績ですごいですね。 参考） Chrome OS ChromeOS - ビジネスに適した安全なクラウド ファーストの OS chromeos.google   展示ブース 各社のブースに訪問させていただいて特に印象に残ったブースを紹介いたします。 社内業務効率化AI KDDI株式会社様 KDDI社内プロジェクトにより、営業の生産性向上を目的として開発された生成AIツールについて紹介していただきました。 社内には膨大な資料が存在し、それらから必要な情報を探すことは時間がかかったり、似たような資料を参考に新規で提案資料等の資料を作成することに時間がかかったりしており、以下の機能を持たせた生成AIツールを作成し業務を効率化したとのことでした。 （情報収集については、社内の利用者のアンケートで74％情報収集時間を削減できたとのことです。） ▼生成AIツールの機能 ・資料の検索 ・資料の要約 ・社内の過去資料を基にドラフト資料を自動生成 ・資料のレビュー 資料の検索、ドラフト版の作成から資料のレビューまでの資料作成全体の効率化ができており、過去の資料というナレッジの蓄積をAIを活用しており、利用ができたらとても便利なサービスだと感じました。 参考） AIエージェント（上記記載の生成AIツールはA-BOSSとなります） AIエージェントとは？生成AIからの進化点や導入事例、注意点など解説 ｜お役立ち情報｜中小企業・法人向け｜KDDI株式会社 ビジネスを推進する新たなAIの活用法「AIエージェント」に関する記事です。AIエージェントの仕組みと、KDDIの実践事例をもとに、業務効率化・コスト削減のポイント、セキュリティやバイアス対策までをコンパクトに解説します。 biz.kddi.com オンプレミス エイム電子株式会社様 ロック機構がついた電源ケーブルを展示しておりました。 ロック機構がついているため、電源ケーブルの抜けの防止や作業中の誤った電源ケーブルの抜線が防げるとのことです。 実際に自分で引っ張って抜けないを体験できる展示もあり、引っ張ってみても全然抜けず、確かに抜け防止になるなといった感じでした。 データセンターでは細部のケーブルまで検討が必要になるのだなと驚きました。 番外編 山口県＆萩市様 行政として山口県＆萩市が参加しており、企業誘致を進めているとのことでした。 ITの技術の展示が多いなか他とは違った観点でおもしろい試みだなと思いました。 実際に山口県＆萩市様のブースで紹介資料を見ると仕事がしやすそうな環境なので少しいいなと思ってしまいました。 観光案内をいただいたので旅行でぜひ行ってみたいですね。   おわりに 5、6年前にもInteropに行かせていただいたことがありますが、業務経験が浅くふわふわしたまま参加したため、色々な製品があるなとか、色々な会社があるなくらいの社会勉強みたいな記憶があります。 今回はトレンドがAIだからAIと何かみたいな組み合わせが多いなだったり、ブースで気になる技術について聞いてみたりと充実して回れたので自身の成長を感じることができました。

今回は、前回投稿した「OSパッチ適用を自動化させた後、結果をメールに通知させる方法」をAWS CDKで実装する方法をまとめました。   AWS Systems Manager の Patch Manager で OS パッチ適用を自動化してみた AWS Systems Manager でパッチ適用を自動化する方法をまとめてみました。 blog.usize-tech.com 2025.01.22 OSパッチ適用結果をメール通知してみた Amazon CloudWatch Logs に出力されたログから、指定した任意の文字列をトリガーに Amazon SNS 経由で適用結果をメールで通知します。 blog.usize-tech.com 2025.02.07 はじめに 前回の記事ではAWSマネジメントコンソールを使って手動でOSパッチ適用の自動化システムを構築しました。 今回は、同じシステムをAWS CDK（Cloud Development Kit）を使ってコード化し、Infrastructure as Code（IaC）として管理できるようにしていきます。   今回作成するリソース SNSトピック: メール通知用 IAMロール: SSM実行用とLambda実行用 パッチベースライン: Windows Server 2022用 メンテナンスウィンドウ: 毎月第1月曜日に実行 Lambda関数: パッチ結果解析とSNS送信 CloudWatchロググループ: パッチ実行ログ保存用 サブスクリプションフィルター: Lambda起動トリガー   AWS CDK ソースコード lib/patch-automation-stack.ts を、以下のように実装します。 最初に各コンポーネント毎に詳細を解説し、最後にソースコードをまとめて記載します。 また、CDKでは名前の自動設定やgrantメソッドなど便利な機能がありますが、実際の案件では様々なリソースに名前を設定する必要があったため名前を定義できるように実装をしています。   SNSトピックとメール通知設定   // パッチ通知用SNSトピックの作成   const patchtopic = new sns.Topic(this, 'PatchNotificationTopic', {     topicName: 'sns-patch-notification',     displayName: 'パッチ適用結果通知'     });   // SNSトピックに通知先メールアドレスを設定   patchtopic.addSubscription(     new subscriptions.EmailSubscription('your-email@example.com')　　　　　　　　//実際のメールアドレスへ変更     ); ポイント: EmailSubscription で通知先メールアドレスを設定 実際のメールアドレスに変更する必要があります   IAMロールの設定   // SSM Run Command実行用のIAMロール   const ssmRunCommandRole = new iam.Role(this, 'SSMRunCommandRole', {     assumedBy: new iam.ServicePrincipal('ssm.amazonaws.com'), roleName: 'SSMRunCommandRole',     managedPolicies: [       iam.ManagedPolicy.fromAwsManagedPolicyName('service-role/AmazonSSMMaintenanceWindowRole'),       iam.ManagedPolicy.fromAwsManagedPolicyName('AmazonSSMManagedInstanceCore'),     ],     description: 'Role for SSM Run Command execution'     });   // Lambda関数のIAMロール作成   const lambdaPatchRole = new iam.Role(this, 'LambdaPatchRole', { roleName: 'LambdaPatchRole',     assumedBy: new iam.ServicePrincipal('lambda.amazonaws.com'),     description: 'Lambda execution role for patch notification',     managedPolicies: [       iam.ManagedPolicy.fromAwsManagedPolicyName('service-role/AWSLambdaBasicExecutionRole')     ]   }); 　　// Lambda関数にSNSの権限を付与   new iam.Policy(this, 'LambdaPatchSnsPolicy', {     policyName: 'LambdaPatchSnsPolicy',     roles: [lambdaPatchRole],     statements: [                                                                 new iam.PolicyStatement({         effect: iam.Effect.ALLOW,         actions: ['sns:Publish'],         resources: ['*']       })     ]     }); ポイント: SSMロール : メンテナンスウィンドウでのパッチ適用実行に必要な権限 AmazonSSMMaintenanceWindowRole : メンテナンスウィンドウ専用権限 AmazonSSMManagedInstanceCore : SSM基本通信権限 Lambdaロール : CloudWatch LogsアクセスとSNS発行権限 AWSLambdaBasicExecutionRole : Lambda基本実行権限 カスタムポリシーでSNS発行権限を追加   パッチベースラインの設定 new ssm.CfnPatchBaseline(this, 'WindowsPatchBaseline', { operatingSystem: 'WINDOWS', name: 'winsv-baseline', approvalRules: {   patchRules: [{     approveAfterDays: 0,                    // リリースから0日後に承認     complianceLevel: 'CRITICAL',            // コンプライアンスレベル：重要     enableNonSecurity: false,               // セキュリティパッチのみを対象     patchFilterGroup: {       patchFilters: [         {           key: 'PRODUCT',           values: ['WindowsServer2022']　　　 // WindowsSrver2022で設定         },         {           key: 'CLASSIFICATION', // Windowsの更新プログラム分類           values: ['CriticalUpdates', 'SecurityUpdates'] // 重要な更新プログラム,セキュリティ更新プログラム         },         {           key: 'MSRC_SEVERITY', // Microsoftが定める重要度           values: ['Critical','Important'] // 致命的な問題を修正,重要な問題を修正         }       ]     }   }] }, patchGroups: ['winsv-patch-group'] // 対象パッチグループ }); ポイント: operatingSystem : 対象OS（WINDOWS、AMAZON_LINUX、UBUNTU等） approveAfterDays: 0 : リリース直後からパッチ適用可能（本番では7-30日を推奨） enableNonSecurity: false : セキュリティパッチのみに限定 フィルター条件 : PRODUCT : 対象Windows製品 CLASSIFICATION : パッチの分類 MSRC_SEVERITY : Microsoftが定める重要度   メンテナンスウィンドウの設定 const patchMaintenanceWindow = new ssm.CfnMaintenanceWindow(this, 'PatchMaintenanceWindow', { name: 'monthly-patch-maintenance-window', schedule: 'cron(0 16 ? * MON#1 *)', duration: 2, cutoff: 0, allowUnassociatedTargets: false, scheduleTimezone: 'Asia/Tokyo' }); スケジュール設定は現在以下のように設定していますので、要件に応じて修正してください。 cron(0 16 ? * MON#1 *) : JST時間で第1月曜日16:00 duration: 2 : 2時間のメンテナンス枠 scheduleTimezone: 'Asia/Tokyo' : 日本時間で管理   パッチ適用対象の設定 const patchTarget = new ssm.CfnMaintenanceWindowTarget(this, 'PatchTarget', { windowId: patchMaintenanceWindow.ref, targets: [{   key: 'tag:PatchGroup',   values: ['winsv-patch-group'] }], resourceType: 'INSTANCE', ownerInformation: 'Patch管理対象インスタンス' }); ポイント: targets: でパッチ適用対象インスタンスを設定 事前にEC2インスタンスでタグの設定が必要 今回の場合必要なタグ設定 -　 キー: `PatchGroup`　 – 値: `winsv-patch-group`   RunCommandタスクの作成 // パッチ適用タスクの作成 const patchExecutionTask = new ssm.CfnMaintenanceWindowTask(this, 'PatchExecutionTask', { // 基本設定 windowId: patchMaintenanceWindow.ref,                          // メンテナンスウィンドウの参照 taskArn: 'AWS-RunPatchBaseline',                               // 実行するSSMドキュメント taskType: 'RUN_COMMAND',                                       // タスクタイプ：RunCommand name: 'SecurityPatchInstallation',                             // タスク名 description: 'セキュリティパッチの自動インストールと再起動',      // タスクの説明 priority: 1,                                                   // タスクの優先度（1が最高） maxConcurrency: '1',                                           // 同時実行数：1台ずつ順次実行 maxErrors: '0',                                                // エラー許容数：0（1台でもエラーなら停止） serviceRoleArn: ssmRunCommandRole.roleArn,                   　// SSM実行用IAMロール targets: [{   key: 'WindowTargetIds',                                      // ターゲット指定方法   values: [patchTarget.ref]                                    // 事前に定義したターゲットを参照 }], taskInvocationParameters: {   maintenanceWindowRunCommandParameters: {     documentVersion: '$LATEST',                                // 最新バージョンのドキュメントを使用     parameters: {       Operation: ['Install'],                                  // 操作：パッチのインストール実行       RebootOption: ['RebootIfNeeded'],                       // 必要に応じて自動再起動       SnapshotId: ['{{WINDOW_EXECUTION_ID}}']                 // 実行IDをスナップショットIDとして記録     },     timeoutSeconds: 600,                                     // タイムアウト（必要に応じて修正）     cloudWatchOutputConfig: {       cloudWatchLogGroupName: 'aws-ssm-patch-execution-logs', // CloudWatch Logsグループ名       cloudWatchOutputEnabled: true                           // CloudWatch Logs出力を有効化     }   } } }); ポイント: taskArn : ‘AWS-RunPatchBaseline’でパッチ適用を実行 priority : 1が最高優先度 maxConcurrency : 同時実行数制御（’1’=順次、’50%’=半数同時） maxErrors : エラー許容数（’0’=1台でもエラーなら停止） 重要パラメータ : Operation: ['Install'] : パッチを実際にインストール RebootOption: ['RebootIfNeeded'] : 必要時のみ再起動 SnapshotId : 実行履歴の追跡用   Lambda関数作成   // Lambda関数作成   const patchNotificationLambda = new lambda.Function(this, 'PatchNotificationFunction', {     functionName: 'lmd-patch-send-sns',                      // 関数名     runtime: lambda.Runtime.PYTHON_3_13,                     // 実行環境：Python 3.13     handler: 'index.lambda_handler',                         // エントリーポイント     code: lambda.Code.fromAsset(                             // ソースコードの場所       path.join(__dirname, 'lambda')     ),     role: lambdaPatchRole,                                   // Lambda実行時IAMロール     environment: {                                           // 環境変数       SNS_TOPIC_ARN: patchtopic.topicArn,                    // SNSトピックのARN       ALARM_SUBJECT: 'パッチ適用結果通知'                     // メールの件名     },     timeout: cdk.Duration.seconds(600),                      // 実行タイムアウト     memorySize: 128,                                         // メモリ割り当て（MB）   }); ポイント: runtime : Python 3.13 code :  lib/lambda ディレクトリからコード読み込み environment : SNSトピックARNとメール件名を環境変数で設定 timeout : 600秒 memorySize : 128MB   関数作成 import logging import json import base64 import gzip import boto3 import os logger = logging.getLogger() logger.setLevel(logging.INFO) def lambda_handler(event, context):   # CloudWatchLogsからのデータはbase64エンコードされているのでデコード   decoded_data = base64.b64decode(event['awslogs']['data'])   # バイナリに圧縮されているため展開   json_data = json.loads(gzip.decompress(decoded_data))   logger.info("EVENT: " + json.dumps(json_data))   # ログデータ取得   log = json_data['logEvents'][0]['message']   instanceid_position = log.find('PatchGroup')   instanceidtmp = log[:instanceid_position]   instanceid = instanceidtmp.replace('Patch Summary for ','')   print(instanceid)   result_position = log.find('Results')   result = log[result_position:]   print(result)   patchGroup_start = log.find('PatchGroup')   patchGroup_end = log.find('BaselineId')   patchGrouptmp = log[patchGroup_start:patchGroup_end]   patchGroup = patchGrouptmp.replace('PatchGroup          : ','')   print(patchGroup)     messagetmp = """ パッチ適用結果を通知します。 対象インスタンス・適用結果は下記となります。 〇対象インスタンス{0} 〇パッチグループ {1} 〇適用結果 {2}   """   message = messagetmp.format(instanceid,patchGroup,result)   print(message)   try:       sns = boto3.client('sns')       #SNS Publish       publishResponse = sns.publish(       TopicArn = os.environ['SNS_TOPIC_ARN'],       Message = message,       Subject = os.environ['ALARM_SUBJECT']       )   except Exception as e:         print(e) ポイント: lib/lambda/index.py にPythonコードを配置します   ロググループ設定   // パッチログ用のCloudWatchロググループ作成   const patchloggroup = new logs.LogGroup(this, 'PatchLogGroup', {       logGroupName: 'aws-ssm-patch-execution-logs', // パッチ適用ロググループ       retention: logs.RetentionDays.ONE_YEAR,       // 保持期間: 1年間       removalPolicy: cdk.RemovalPolicy.RETAIN       // スタック削除時に削除されない         });   new logs.SubscriptionFilter(this, 'PatchSummarySubscription', {     // サブスクリプションフィルターの設定（Lambda関数の起動トリガー）       logGroup: patchloggroup,                                         // 監視対象のロググループ       destination: new destinations.LambdaDestination(patchNotificationLambda),  // 送信先       filterPattern: logs.FilterPattern.literal('Patch Summary'),       // フィルター条件       filterName: 'PatchNotification'                                   // フィルター名     }); } ポイント: logGroupName: はRunCommandタスクの作成で指定したロググループ名と合わせる 保管期間は要件に合わせて修正する 今回実装したスタックファイルまとめ import * as cdk from 'aws-cdk-lib'; import { Construct } from 'constructs'; import * as ssm from 'aws-cdk-lib/aws-ssm'; import * as lambda from 'aws-cdk-lib/aws-lambda'; import * as logs from 'aws-cdk-lib/aws-logs'; import * as iam from 'aws-cdk-lib/aws-iam'; import * as sns from 'aws-cdk-lib/aws-sns'; import * as subscriptions from 'aws-cdk-lib/aws-sns-subscriptions'; import * as path from 'path'; import * as destinations from 'aws-cdk-lib/aws-logs-destinations'; export class PatchAutomationStack extends cdk.Stack { constructor(scope: Construct, id: string, props?: cdk.StackProps) {     super(scope, id, props);   // パッチ通知用SNSトピックの作成   const patchtopic = new sns.Topic(this, 'PatchNotificationTopic', {     topicName: 'sns-patch-notification',     displayName: 'パッチ適用結果通知'     });   // SNSトピックに通知先メールアドレスを設定   patchtopic.addSubscription(     new subscriptions.EmailSubscription('your-email@example.com') // ここを実際のメールアドレスに変更     );   // SSM Run Command実行用のIAMロール   const ssmRunCommandRole = new iam.Role(this, 'SSMRunCommandRole', { roleName: 'SSMRunCommandRole',     assumedBy: new iam.ServicePrincipal('ssm.amazonaws.com'),     managedPolicies: [       iam.ManagedPolicy.fromAwsManagedPolicyName('service-role/AmazonSSMMaintenanceWindowRole'),       iam.ManagedPolicy.fromAwsManagedPolicyName('AmazonSSMManagedInstanceCore'),     ],     description: 'Role for SSM Run Command execution'     });   // Lambda関数のIAMロール作成   const lambdaPatchRole = new iam.Role(this, 'LambdaPatchRole', { roleName: 'LambdaPatchRole',     assumedBy: new iam.ServicePrincipal('lambda.amazonaws.com'),     description: 'Lambda execution role for patch notification',     managedPolicies: [       iam.ManagedPolicy.fromAwsManagedPolicyName('service-role/AWSLambdaBasicExecutionRole')     ]     });   // Lambda関数にSNSの権限を付与   new iam.Policy(this, 'LambdaPatchSnsPolicy', {     policyName: 'LambdaPatchSnsPolicy',     roles: [lambdaPatchRole],     statements: [       new iam.PolicyStatement({         effect: iam.Effect.ALLOW,         actions: ['sns:Publish'],         resources: ['*']       })     ]     });   // パッチベースラインの作成   new ssm.CfnPatchBaseline(this, 'WindowsPatchBaseline', {     operatingSystem: 'WINDOWS',     name: 'winsv-baseline',     approvalRules: {       patchRules: [{         approveAfterDays: 0,                    // リリースから0日後に承認         complianceLevel: 'CRITICAL',            // コンプライアンスレベル：重要         enableNonSecurity: false,               // セキュリティパッチのみを対象         patchFilterGroup: {           patchFilters: [             {               key: 'PRODUCT',               values: ['WindowsServer2022']     // WindowsServer2022で設定             },             {               key: 'CLASSIFICATION',               values: ['CriticalUpdates', 'SecurityUpdates']             },             {               key: 'MSRC_SEVERITY',               values: ['Critical', 'Important']             }           ]         }       }]     },     patchGroups: ['winsv-patch-group']     });   // メンテナンスウィンドウの作成   const patchMaintenanceWindow = new ssm.CfnMaintenanceWindow(this, 'PatchMaintenanceWindow', {     name: 'monthly-patch-maintenance-window',     schedule: 'cron(0 16 ? * MON#1 *)',         // 毎月第1月曜日 JST 16:00     duration: 2,                                // 実行可能時間：2時間     cutoff: 0,                                  // 新規タスク開始の締切時間     allowUnassociatedTargets: false,            // 関連付けされたターゲットのみ実行     scheduleTimezone: 'Asia/Tokyo'              // スケジュールのタイムゾーン     });   // パッチ適用対象の設定   const patchTarget = new ssm.CfnMaintenanceWindowTarget(this, 'PatchTarget', {     windowId: patchMaintenanceWindow.ref,       // メンテナンスウィンドウの参照     targets: [{       key: 'tag:PatchGroup',                    // タグによる対象選択       values: ['winsv-patch-group']             // 対象とするタグ値     }],     resourceType: 'INSTANCE',                   // 対象リソース種別：EC2インスタンス     ownerInformation: 'Patch管理対象インスタンス' // 管理用メモ     });   // パッチ適用タスクの作成   const patchExecutionTask = new ssm.CfnMaintenanceWindowTask(this, 'PatchExecutionTask', {     // 基本設定     windowId: patchMaintenanceWindow.ref,                          // メンテナンスウィンドウの参照     taskArn: 'AWS-RunPatchBaseline',                               // 実行するSSMドキュメント     taskType: 'RUN_COMMAND',                                       // タスクタイプ：RunCommand     name: 'SecurityPatchInstallation',                             // タスク名     description: 'セキュリティパッチの自動インストールと再起動',       // タスクの説明     priority: 1,                                                   // タスクの優先度（1が最高）     maxConcurrency: '1',                                           // 同時実行数：1台ずつ順次実行     maxErrors: '0',                                                // エラー許容数：0（1台でもエラーなら停止）     serviceRoleArn: ssmRunCommandRole.roleArn,               　　　 // SSM実行用IAMロール     targets: [{       key: 'WindowTargetIds',                                      // ターゲット指定方法       values: [patchTarget.ref]                                    // 事前に定義したターゲットを参照     }],     taskInvocationParameters: {       maintenanceWindowRunCommandParameters: {         documentVersion: '$LATEST',                                // 最新バージョンのドキュメントを使用         parameters: {           Operation: ['Install'],                                  // 操作：パッチのインストール実行           RebootOption: ['RebootIfNeeded'],                       // 必要に応じて自動再起動           SnapshotId: ['{{WINDOW_EXECUTION_ID}}']                 // 実行IDをスナップショットIDとして記録         },         timeoutSeconds: 600,                                       // タイムアウト（必要に応じて修正）         cloudWatchOutputConfig: {           cloudWatchLogGroupName: 'aws-ssm-patch-execution-logs', // CloudWatch Logsグループ名           cloudWatchOutputEnabled: true                           // CloudWatch Logs出力を有効化         }       }     }     });   // Lambda関数作成   const patchNotificationLambda = new lambda.Function(this, 'PatchNotificationFunction', {     functionName: 'lmd-patch-send-sns',                       // 関数名     runtime: lambda.Runtime.PYTHON_3_13,                      // 実行環境：Python 3.13     handler: 'index.lambda_handler',                         // エントリーポイント     code: lambda.Code.fromAsset(                             // ソースコードの場所       path.join(__dirname, 'lambda')     ),     role: lambdaPatchRole,                                   // Lambda実行時IAMロール     environment: {                                           // 環境変数       SNS_TOPIC_ARN: patchtopic.topicArn,                     // SNSトピックのARN       ALARM_SUBJECT: 'パッチ適用結果通知'                       // メールの件名     },     timeout: cdk.Duration.seconds(600),                       // 実行タイムアウト     memorySize: 128,                                         // メモリ割り当て（MB）     description: 'パッチ適用結果を解析してSNS通知を送信する関数'  // 関数の説明   });   // パッチログ用のCloudWatchロググループ作成   const patchloggroup = new logs.LogGroup(this, 'PatchLogGroup', {     logGroupName: 'aws-ssm-patch-execution-logs',           // パッチ適用ロググループ     retention: logs.RetentionDays.ONE_YEAR,                 // 保持期間: 1年間     removalPolicy: cdk.RemovalPolicy.RETAIIN                 // スタック削除時に削除されない     });   // サブスクリプションフィルターの設定（Lambda関数の起動トリガー）   new logs.SubscriptionFilter(this, 'PatchSummarySubscription', {     logGroup: patchloggroup,                                         // 監視対象のロググループ     destination: new destinations.LambdaDestination(patchNotificationLambda),   // 送信先     filterPattern: logs.FilterPattern.literal('Patch Summary'),       // フィルター条件     filterName: 'PatchNotification'                                   // フィルター名   }); } }   まとめ 今回は、パッチ自動適用からメール通知までをAWS CDKでモジュール化してみました。 皆さんのお役に立てば幸いです。

こんにちは、SCSK株式会社の小寺崇仁です。 先日Zabbixの7.4がリリースされました。今回はicmppingretryについて検証したいと思います。 7.4の新機能につきましては、公式HPに記載がございます。 What's new in Zabbix 7.4 Create new resource discovery workflows, visualize your data in new ways, enjoy the improved user experience and much mo... www.zabbix.com Zabbix7.4はポイントリリースのため、サポート期間が短くなっています。 本番利用する場合は8.0LTSがリリースされるまでお待ちいただく事をお勧めします。 icmppingretryとは 公式HPでは以下の記載があります。 英語：A new icmppingretry simple check has been added to monitor host responses to ICMP ping with the ability to modify retries 翻訳：ICMP pingに対するホストの応答を監視し、再試行回数を変更するための新しいicmppingretryシンプルチェックが追加されました。 Ping監視で1回失敗した場合、間隔を狭くしてリトライする事ができるようです。 他の有償製品ではリトライをすることができるようで、問い合わせを多く頂いておりました機能になります。   アイテム作成 icmppingretryはアイテムキーのため、通常のPing監視で利用するicmppingとは別アイテムにする必要があります。 今までのicmppingキーにはない「retries」「backoff」が新しく設定できるようになっております。 逆に「interval」「packets」がなくなっております。細かいPingのオプションは指定できないようですね。 「reties」が 再試行回数 となっており、「backoff」で 再試行間隔の係数 を指定できるようです。 公式マニュアル – icmppingretry icmppingretry[<target>,<retries>,<backoff>,<size>,<timeout>,<options>] The host accessibility by ICMP ping with retries. Return value:  0  – ICMP ping fails;  1  – ICMP ping successful. Parameters: target  – the host IP or DNS name; retries  – the number of times an attempt at pinging a target will be made, not including the first try (0 or greater; default 1); backoff  – the number by which the wait time is multiplied on each successive request (1.0-5.0 range; default 1.0); size  – the packet size in bytes; timeout  – the timeout in milliseconds; options  – used for allowing redirect: if empty (default value), redirected responses are treated as target host down; if set to  allow_redirect , redirected responses are treated as target host up. 今回は検証用にicmppingretryとicmppingのアイテムを作成して比較しようと思います。 名前 Ping監視（icmpping） Ping監視（icmppingretry） タイプ シンプルチェック シンプルチェック アイテムキー icmpping[,3,2000,64,3000] icmppingretry[,3,3,256,500] 監視間隔 60s 60s   icmpping[,3,2000,64,3000]の動作について まずは、以前からあるicmmpingキーについて動作を確認していきます。 正常時 1回の監視で2秒間隔で3回パケットを送信します。1分間隔で繰り返します。 20:54:23.056236 IP ip-192-168-1-1.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3048, seq 0, length 72 20:54:25.056876 IP ip-192-168-1-1.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3048, seq 1, length 72 20:54:27.058276 IP ip-192-168-1-1.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3048, seq 2, length 72 20:55:23.068729 IP ip-192-168-1-1.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3055, seq 0, length 72 20:55:25.070759 IP ip-192-168-1-1.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3055, seq 1, length 72 20:55:27.070773 IP ip-192-168-1-1.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3055, seq 2, length 72 異常時 監視対象（192.168.1.1）をダウンさせてみます。 Zabbixから送信するパケットは正常時と変わらないことを確認します。 21:00:23.131611 IP ip-10-0-2-117.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3112, seq 0, length 72 21:00:25.133447 IP ip-10-0-2-117.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3112, seq 1, length 72 21:00:27.131777 IP ip-10-0-2-117.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3112, seq 2, length 72 21:01:23.142971 IP ip-10-0-2-117.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3134, seq 0, length 72 21:01:25.143041 IP ip-10-0-2-117.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3134, seq 1, length 72 21:01:27.143408 IP ip-10-0-2-117.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3134, seq 2, length 72 icmppingretry[,3,3,256,500]の動作について 次に新機能のicmppingretryについて確認いたします。 オプションは再試行回数3回、再試行間隔の係数は３、タイムアウト0.5秒になります。 正常時 1回の監視で1回だけICMPパケットを送信します。1分間隔で繰り返します。 icmppingキーでは細かく、回数や間隔を指定できていましたが、正常時は1回になるようです。 21:04:23.175696 IP ip-192-168-1-1.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3166, seq 0, length 72 21:05:23.185637 IP ip-192-168-1-1.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3174, seq 0, length 72 異常時 監視対象をダウンさせてみると以下のパケットになります。 20:30:40.044485 IP ip-10-0-2-117.ap-northeast-1.compute.internal > ip-10-0-2-194.ap-northeast-1.compute.internal: ICMP echo request, id 2428, seq 0, length 264 20:30:40.545097 IP ip-10-0-2-117.ap-northeast-1.compute.internal > ip-10-0-2-194.ap-northeast-1.compute.internal: ICMP echo request, id 2428, seq 1, length 264 20:30:42.046686 IP ip-10-0-2-117.ap-northeast-1.compute.internal > ip-10-0-2-194.ap-northeast-1.compute.internal: ICMP echo request, id 2428, seq 2, length 264 20:30:46.547698 IP ip-10-0-2-117.ap-northeast-1.compute.internal > ip-10-0-2-194.ap-northeast-1.compute.internal: ICMP echo request, id 2428, seq 3, length 264 再試行回数：３回 通常監視が「20:30:40.044485」に行われ、その後３回、「20:30:40.545097」「20:30:42.046686」「20:30:46.547698」と再試行を行っています。再試行の際は、idが同じ「2428」でseqが連番となっています。   再試行間隔の係数：３ 再試行の間隔は以下の通りになります。 再試行1回目：0.5秒（20:30:40.0 – 20:30:40.5） 再試行2回目：1.5秒（20:30:40.5 – 20:30:42.0） 再試行3回目：4.5秒（20:30:42.0 – 20:30:46.5） 再試行の回数が増えるごとに、間隔が長くなっていることがわかるかと思います。 再試行1回目の0.5秒は、icmppingretryキーの引数で指定したタイムアウトの0.5秒になります。 再試行2回目の1.5秒は、1回目の間隔(0.5)×再試行間隔の係数(3)の1.5秒になります。 再試行3回目の4.5秒は、2回目の間隔(1.5)×再試行間隔の係数(3)の4.5秒になります。 まとめ icmppingretryを使用することで、Ping疎通がNGの場合のみ、再試行することがZabbixでも実現できました。 ZabbixのPing監視の幅が広がったかと思います。　 Zabbix is great! ※検証結果が間違っておりましたら、お知らせください SCSK Plus サポート for Zabbix SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします www.scsk.jp ★YouTubeに、SCSK Zabbixチャンネルを開設しました！★ SCSK Zabbixチャンネル 本チャンネルでは、SCSK株式会社でのZabbixに関するトレンド/事例紹介などを動画にまとめて取り上げております。最新のトピックについては、以下の弊社HPもしくはツイッターアカウントをぜひ参照ください。ツイッターアカウント： www.youtube.com ★X（旧Twitter）に、SCSK Zabbixアカウントを開設しました！★ https://x.com/SCSK_Zabbix x.com  

こんにちは、SCSKの前田です。 私が携わった LifeKeeper の案件で導入を行った ARK について紹介をかねてお話したいと思います。 今回は、日立製作所から提供されているジョブ管理製品である JP1/AJS3 を簡単に冗長化するための ARK の導入事例をご紹介していきます。 おさらい LifeKeeper の ARK について、おさらいしたいと思います。 ARK とは、Application Recovery Kits の略で、LifeKeeper が特定のアプリケーション（オープンソースソフトウェアや商用アプリケーション）を容易にリソースとして組み込むことが可能になる製品です。 ARK による、アプリケーションのリソースへの組み込みはウィザード形式（GUI 上で設定）で作業が可能となり、ARK には、アプリケーションを操作（起動・停止・監視・再起動）するための4つのスクリプトがあらかじめ準備されているため、スクリプトを設計・作成するための開発工数の削減や人的なミスを防止することが出来ます。 概要説明 JP1/AJS3 の ARK としては、下記の通り大きく2つの種類があります。 ① Generic ARK for JP1/AJS3 Manager 「JP1/Base」と「JP1/Automatic Job Management System 3」(略称：JP1/AJS3)の「Manager」を，LifeKeeper の保護対象リソースとして登録し，保護する機能を提供します。 ② Generic ARK for JP1/AJS3 Agent 「JP1/Base」と「JP1/Automatic Job Management System 3」(略称：JP1/AJS3)の「Agent」を，LifeKeeper の保護対象リソースとして登録し，保護する機能を提供します。 JP1/AJS3 ARK は、汎用アプリケーション(Generic Application)リソースとして導入されます。 おさらいでお伝えした通り、「JP1/Base」と「JP1/Automatic Job Management System 3」のそれぞれを操作するため、起動・停止・監視・再起動を行うためのスクリプトが準備されており、リソース作成時にこれらのスクリプトを設定していきます。 この4つのスクリプトのうち、起動と停止は必須で、監視と再起動は任意となり、JP1製品の監視や再起動を実施する要件がなければ、対象のスクリプトを設定する必要もありません。 監視と再起動を導入しなければ、LifeKeeper として JP1/AJS3 の障害を検知することはなく、フェイルオーバーの対象にもなりません。また、監視は行うが、再起動は行わないことも出来ます。ただ、監視は行わず、再起動のみ行うことは出来ません。あくまでも監視で異常と検知された場合のみ、再起動が有効になります。 JP1/ASJ3 ARKを導入するための条件 JP1 が使用する共有ディスクリソースと，JP1 の論理ホスト名に紐づく仮想 IP リソースは、別で作成しておく必要があります。また、JP1 リソース作成後、共有ディスクリソースと仮想 IP リソースに対する依存関係を手動で設定する必要があります。 JP1/ASJ3 ARK の構築例 それでは、実際に JP1/AJS3 ARK の構築についてお話していきたいと思います。 スクリプトの修正 まずは、「JP1/Base」と「JP1/Automatic Job Management System 3」を操作するため、利用する全てのスクリプトを修正する必要があります。 スクリプトのパラメータ変更 次の変更可能なパラメータのうち、必要なパラメータを修正します。 ※下記パラメータ以外を変更してしまうとサポートが受けられなくなりますので注意してください。 ＜Windows版＞ 内容 パラメータ名 設定条件 リソースタグ名 APP 任意 論理ホスト名 VHOSTNAME 必須 JP1環境変数 JP1PATH 任意 タイムアウト値（処理待ち時間） DEFAULT_TIMEOUT 任意 タイムアウト値（後処理の待ち時間） HANDLE_STOP_TIMEOUT 任意 処理モード（※１） PROCESS_MODE 任意 ※１：停止スクリプトのみ提供されるパラメーター ＜Linux版＞ 内容 パラメータ名 設定条件 リソースタグ名 APP 任意 論理ホスト名 VHOSTNAME 必須 タイムアウト値（処理待ち時間） DEFAULT_TIMEOUT 任意 タイムアウト値（後処理の待ち時間） HANDLE_STOP_TIMEOUT 任意 待機時間（※２） APP_FORCE_STOP_WAIT_TIME 任意 ※２：監視スクリプトは設定不要なパラメーター (1)リソースタグ名(APP)の変更 リソースタグ名は保護対象リソースを一意に識別するための名称です。デフォルトで設定がされていますが、案件ごとに命名規則がありますので、案件にあったリソースタグ名に変更する必要があります。 (2)論理ホスト名(VHOSTNAME)の変更 論理ホスト名は JP1/AJS3 ARK で唯一の必須となるパラメータです。クラスタ環境（論理ホスト上）でJP1製品のコマンドを実行するため、論理ホスト名が必要になります。JP1/AJS3 ARK の各スクリプトでもJP1製品のコマンドを実行するため、必要不可欠なパラメータとなります。 (3)JP1環境変数(JP1PATH)の変更　※Windows版のみ JP1環境変数は JP1 製品のコマンドを実行するためのパス名です。各スクリプトにはJP1製品のデフォルトのインストールパス名があらかじめ記載されており、明示的にインストールパスを変更してJP1製品をインストールする場合、このJP1環境変数を変更する必要があります。 (4)タイムアウト値(DEFAULT_TIMEOUT,HANDLE_STOP_TIMEOUT)の変更 タイムアウト値は各スクリプトに設定するタイマー監視用の値です。各スクリプトで実行した JP1 製品のコマンドが無応答となった場合、設定したタイムアウト値によってタイマー監視を行い、各スクリプトを終了させます。 基本的には変更することはありませんが、処理時間が遅いだけで問題もなく各スクリプトがタイムアウトとなってしまう場合、環境に合わせ変更する必要があります。 (5)処理モード(PROCESS_MODE)の設定　※Windows版の停止スクリプトのみ 処理モードはJP1製品の停止処理が失敗した場合における、後続処理の続行可否を判断するためのパラメータです。 処理モードが「0」：JP1製品の停止コマンドが失敗した場合、異常終了と判断し、フェイルオーバーが中断されます。 処理モードが「1」：JP1製品の停止コマンドが失敗した場合、正常終了と判断し、フェイルオーバーが継続されます。 ※デフォルト値は「1」になります。 (6)待機時間(APP_FORCE_STOP_WAIT_TIME)の変更　※Linux版の監視スクリプト以外 待機時間は各スクリプトで実行される JP1 製品の2重起動防止を目的とした強制停止コマンドの終了を待機する時間の値です。 JP1製品の強制停止コマンドの一部処理がバックグラウンドで実施され、待機時間を経過しても終了せず、その後の JP1 製品の開始に失敗することがある場合、デフォルトの5秒から変更する必要があります。 JP1/ASJ3 関連リソースの作成 前述の通り、JP1/AJS3 ARK では「JP1/Base」と「JP1/Automatic Job Management System 3」（Manager または Agent）のリソースを作成することが可能です。 この2つのリソースを LifeKeeper の GUI によって作成する流れを環境毎に例として紹介します。 ＜Windows版＞ 処理内容 JP1/Base JP1/Automatic Job Management System 3 リソース作成前のツリー構造 冗長化対象ノードの選択 保護アプリケーションの選択（汎用アプリケーション） Restore（起動）スクリプトの入力 Remove（停止）スクリプトの入力 QuickCheck（監視）スクリプトの入力 DeepCheck（詳細な監視）スクリプトの入力 ※対象無し LocalRecovery（再起動）スクリプトの入力 アプリケーション情報の入力 ※入力無し LocalRecoveryの有無の選択 ※デフォルト：有効 リソースタグ名の入力 稼働系ノードのリソース作成結果 待機系ノードのリソース作成準備の確認結果 待機系ノードの優先順位の設定 ※デフォルト：10 待機系ノードのリソース作成結果 リソース作成後のツリー構造 ＜Linux版＞ 処理内容 JP1/Base JP1/Automatic Job Management System 3 リソース作成前のツリー構造 保護アプリケーションの選択（Generic Application） 稼働系ノードのSwitchbackタイプの選択 ※デフォルト：intelligent 稼働系ノードの選択 Restore（起動）スクリプトの入力 Remove（停止）スクリプトの入力 QuickCheck（監視）スクリプトの入力 LocalRecovery（再起動）スクリプトの入力 稼働系ノードのアプリケーション情報の入力 ※入力無し リソース作成時の起動有無の選択 稼働系ノードのリソースタグ名の入力 稼働系ノードのリソース作成結果 待機系ノードの選択 待機系ノードのSwitchbackタイプの選択 ※デフォルト：intelligent 稼働系ノードの優先順位の設定 ※デフォルト：1 待機系ノードの優先順位の設定 ※デフォルト：10 待機系ノードのリソース作成準備の確認結果 待機系ノードのリソースタグ名の入力 待機系ノードのアプリケーション情報の入力 ※入力無し 待機系ノードのリソース作成結果 リソース作成後のツリー構造 これで、LifeKeeper による JP1/AJS3 製品 のリソースが完成です。 依存関係の作成 「JP1/Base」と「JP1/Automatic Job Management System 3」（Manager または Agent）のリソースを作成した後、全リソースの起動（停止）する順序を定義するため、リソース間の依存関係（リソースツリーの下から起動され、上から停止される）を作成する必要があります。 例として、別で作成していた共有ディスクリソースと，仮想 IP リソースを始めに起動させるようリソースツリーの下部に配置させ、その後に JP1/Base、JP1/AJS3 の順番で起動させるように依存関係を作成します。 処理内容 Windows版 Linux版 依存関係作成前のツリー構造 JP1/Baseリソースの依存関係作成後 JP1/AJS3リソースの依存関係作成後 これで、JP1/AJS3 製品に関連する LifeKeeper によるリソース構成ツリーの完成です。 まとめ 今回は LifeKeeper ARK の導入事例と言うことで、JP1/AJS3 製品のリソース作成について紹介してみました。 JP1/AJS3 ARK を購入することで、正式なサポートを受けられるほか、LifeKeeper として JP1/AJS3 を操作（起動・停止・監視・再起動）するための4つのスクリプトがあらかじめ準備されており、必要最低限の修正だけで簡単にリソースとして導入が可能となっています。 LifeKeeper では JP1/AJS3 以外にも多数の ARK が用意されていますので、また次の機会に別の ARK について紹介していきたいと思います。 最後に JP1/AJS3 ARK を導入するための手順を纏めます。 ・JP1/Base と JP1/AJS3 で利用されるスクリプト内の変更可能なパラメータを修正する ・LifeKeeper GUI を用いて、JP1/Base と JP1/AJS3 のリソースを作成する ・共有ディスクリソースと仮想 IP リソース含め、リソースの起動順序を定義するため依存関係を作成する   詳しい内容をお知りになりたいかたは、以下のバナーからSCSK LifeKeeper公式サイトまで  

こんにちは！ SCSK株式会社　小鴨です。 海外にあこがれはあるけど英語は全くできないことが悩みです そんな自分ですが、今日も Knowledge 25 　 のご紹介をさせていただきます！！ 本日からはいよいよイベント本番の内容にがっつり踏み込んでいきます。 前回の記事は準備・到着編になります。 まだ読んでいない方は以下リンクからどうぞ！ 【ServiceNow】Knowledge25への参加記録！！その１　～準備・到着～ – TechHarmony 【ServiceNow】Knowledge25への参加記録！！その２　～イベント開始～ – TechHarmony   Knowledgeが…始まる Knowledge25の構成要素 さあいよいよ本番が開幕！の前に そもそもKnowledgeがどのような構成で進められるのかご紹介です。 Knowledgeとは以下の3要素で構成されます。 基調講演 ー参加者全員向けに大会場で行われる公演 ServiceNowの重役が、新技術やこれからの展望について熱く語る セッション ー事前予約制の公演 興味のあるタイトルを選び、自分だけの時間割を組んで参加する エキスポ会場 ー各企業がブースを出展したり、技術者交流の会場が用意されていたり イベント期間中常に実施されている   基本的にイベントが行われる3日間は 朝に全体向けの基調講演が行われ、残りの時間は予約したセッションに参加するといったイメージですね。 その３では基調講演で語られたServiceNowのこれからについてご紹介します。 エキスポ会場の様子や、イベントの雰囲気などはその4以降でお話しする予定です。   基調講演 公演というかもはや演劇 基調講演は大会場で行われるのですが 庶民である私はなんとなく体育館チックな場所でやるのかなと思ってました。 きっと椅子が小綺麗に並べられていて 校長先生みたいな人が演説をするんだろうな～ …と思ってのもつかの間 なんか様子がおかしいぞというのが第一印象。 突然現れたライブ会場みたいな大広間の雰囲気にいきなり圧倒されました！ ライトがバリバリたかれていたり なぜかDJがいたり 公演以外の部分で驚かされっぱなしな私でしたが 公演そのものも一風変わっていて非常に興味深いものでした。 というのも、登壇者が次々入れ替わり 各人が自分のパートを面白おかしく、ハイテンションで語るという形式であり 切り替わりのタイミングでは登壇者が次の登壇者を「Hey, come on John!!」みたいに呼びつけるという まるで一連の演劇を見ているようでした。 CEOが直々に登壇したり 話題が変わると次の登壇者が呼び出されたり なぜか超有名なコメディアンも現れてServiceNowについてディスカッションを始めたり 日本の公演と全然違うなあ。。。 とはっきり感じました。 ServiceNowとAI さて、雰囲気紹介もほどほどに いよいよ基調講演でどのようなことが語られたのか、紹介をさせていただきます。 まず今回のイベントで掲げられていたテーマが 「Where AI gets to the work」 というもので 現在、ServiceNow上でAIがどのような使われ方をしているのか これからどのような使い方ができるようになるのか こうした内容が今回のイベントのポイントになるということでした。 実際、基調講演ではAIの話で持ちきりで 特に力を入れて語っていたポイントは二点 「 2025 年現在の AI の立ち位置」 「なぜ ServiceNow で AI を使うのか」 基調講演では常に、「AI導入を失敗する企業の特徴」と「ServiceNowなら失敗しない理由」の説明に 力が入っていた印象です AI Platformの3要素 公演の中で語られた内容で特に印象深かったのは AIを導入している企業は数多くあるが、6割以上の企業がそれを持て余しており 全く有効活用できていないという話でした。 それはなぜかというと、AIを取り巻く要素を適切に管理できていないからだ、というのが ServiceNowの語る理論でした。 そもそもAIを活用するための3大要素というものがあり それが以下の3つであり、これらを同じプラットフォーム上で管理するのが 理想的な状態とのことです。 AI Data Workflows 多くの企業はAIはこっちのシステムで管理しつつ、ワークフローは別のシステムに任せている といったような体系をとっており、システム間連携のラグ等が影響し 分析やAIによるデータ利用がワンテンポ遅くなったりと、いまいち利便性の低いサービスとなってしまっているようです。 ServiceNowではこの3要素を高い水準で一括管理することが可能であり AI活用を絶対に失敗させないという力強いコメントと共に公演が行われていました。 あとがき 次回は実際に3要素に対し、ServiceNowがどのような取り組みを行っているか 特に機能エンハンス関連の部分に焦点をあててご紹介できればと思います。 一部キーワードを出すと ● Control Tower ●data.worldの買収 ●CRMの改良 といったところになる予定です。 その4になってようやく具体的な技術に入りますが 今後もゆったりとお付き合いいただければと思います。

こんにちは。SCSK 武田です。 先日、幕張メッセにて開催されたInterop Tokyo 2025に参加してきました。 主に生成AIに関するセッションや展示ブースを回ってきたので印象に残った内容をご紹介します。 印象に残った講演 文系人材のためのAIフル活用仕事術 スピーカーは（一財）実用英語推進機構　安河内氏 。 ChatGPTの音声機能を使って英会話授業をしているそうです。 安河内氏はAIからのアウトプットの質を高めるには工夫が必要とのことで プロンプトを書く上での鉄則 として以下5点を挙げていました。 ①シンプルで明確に書け 長い指示は上手く通らないため、短く明確な言葉を使う。 タスクが複雑な場合は、小さなステップや要素に分ける。 例）Aをやってください　→　Bをやってください　→　Cをやってください ②必要なコンテキストを提供せよ 関連する背景情報（誰が何のために）を提供する。 例）「あなたは英語教師です。日本の小学校高学年向けに問題を作成してください。」 フォーマットとスタイルを指定する。 例）「ワークシートで」「200文字以内で」 ③AIのクセを理解せよ 曖昧な指示には曖昧な結果しか出さないため、指示は具体的に明示する。 一度で完璧に出力するのは難しいため、最初の結果が期待通りでなくても内容を調整して再試行する。 ④便利な表現を使い倒せ イラスト作成の場合 例）「アスペクト比を16:9で」「アニメ風にしてください」 問題作成の場合 例）「正解は1つにしてください」（この指定をしないと答えが2つ以上存在する問題を作ってきたりする） 文書作成の場合 例）「フォーマルな文体で」「友達に話しかけるように」 ⑤ルーティンワークを自動化せよ ルーティン業務を洗い出す。 プロンプトを作成・保存し、定型作業を自動化する。 出力結果を確認し、プロンプトの改善を繰り返す。 ※同じ単純作業を3回やったら敗北！ ハルシネーション（AIが事実に基づかない回答をもっともらしく生成する現象）に注意！ 出力された情報が正しいかどうかファクトチェック（複数の信頼できるソースで確認）を行うようにしましょう。   AIで変わるサイバー攻撃からネットワークとアプリを守るために今検討すべきこと スピーカーはA10ネットワークス（株）　高木氏。   ビジネスで生成AIを利用する場合のリスク AIに情報を提供することで、意図せず個人情報や企業機密が漏洩し再利用される。 また、ユーザとAIのやり取りを誰も把握していないことが脅威となるため、AIを見張る存在が必要とのこと。   AIを悪用する新たな脅威 ボットの生成スピードが上がり、ボットによるDDoS攻撃が増えると明言。 現状、通信、ホスティングサービスに対する攻撃が多く、他にも社会インフラ、ブロックチェーン、教育機関（大学等）等も標的となっているが、攻撃にかかるコストが下がることで、今まで対象外だった業種も攻撃対象になる可能性があるという。 また、AIを悪用したDDoS攻撃として適応型攻撃なるものがあり、防御対策に適応して方法を変えて攻撃してくるらしい。   どのような対策を講じるべきか 機密情報漏洩を防ぐツールを導入する →AIにプロンプトを渡す前のチェックとAIからの出力チェックをしたり、生成AIとのやり取りをログに記録する。 DDoS攻撃の防御対策をAIに支援させる →攻撃者の行動を継続的に追跡・分析することで想定外の攻撃を検知したり自動防御する。   生成AIの比較 とある展示ブースにて、複数の有償版生成AIを利用されている方がいらっしゃったので各AIの特徴を伺ってきました。 項目 ChatGPT Claude Gemini 得意なこと 自然な対話、プログラミング 要点をまとめる 画像や音声など複数の形式を理解し情報提供する（マルチモーダル） 弱点 自信満々に誤情報を話すことがある（ハルシネーション） 応答が不安定なことがあり「病弱」な印象 日本語・ロシア語・韓国語の区別が苦手 画像生成 可能 不可 可能（精度はやや劣る） おすすめの活用方法 ・雑談やメンタルケアのための話し相手になってもらう ・プログラムの生成やデバッグ ・契約書や論文の要約 ・ビジネス文書の作成や校正 ・写真や動画の内容説明 ・会議の議事録作成 ・図や表を読み取って分析   まとめ AI活用における実践的なコツやセキュリティ面での留意点、生成AIの特徴についてご紹介しました。 私自身、これまで業務での活用経験はほとんどなく、プライベートでも日常的な質問や簡単な調べ物にCopilotを使う程度でしたが、Interopへの参加を通じて生成AIの可能性と活用方法について理解を深めることができました。 特に、AIが単なる便利ツールではなく、業務の質やスピードを大きく向上させる可能性を秘めていることを実感したので、今後は各AIの特性を踏まえた上で目的に応じて適切に使い分けることで、業務効率化や品質向上に繋げていきたいと思います。 最後までお読みいただきありがとうございました。

こんにちは。SCSK株式会社　中村です。 Interop（インターロップ）とは、 主にネットワークコンピューティング分野における最新技術やビジネス動向を体験できる展示会やイベントのことです。 特に「Interop Tokyo」は、日本最大級のインターネットテクノロジーイベントとして知られています。 そんなInterop Tokyoに初参加してきましたので、会場全体の雰囲気や温度感、印象に残ったセッションなどについて報告したいと思います。当記事が今回参加できなかった方や来年参加しようと思ってる方の参考になれば幸いです。 また、SCSKとしてもいくつか出展を行っていましたのでそちらのブースなどについても紹介していきたいと思います。 事前準備 ①参加登録 Interopは当日思い立って飛び込み参加することは出来ません。 参加するには事前に参加登録を行う必要があります 。 参加登録の際にどの講演に予約をしておくか。という選択もあるので あらかじめ公演一覧から自分の興味のある講演を見つけて予約を行いましょう。 人気の講演はすぐに埋まってしまうため、目当ての講演がある場合は1か月くらい前から登録しないと予約できない可能性があります。 ②入場証の印刷 当日、 会場に入るためには登録後にサイトで発行される入場証が必要となります 。 A4サイズの紙に入場証を印刷して持ってくる必要があるため、こちらも当日忘れずに印刷して持ってくるようにしましょう。 会場までの道のり 海浜幕張駅から幕張メッセへ向かう、Interop参加者たち Interop Tokyo 2025は6/11(水)～6/13(金)の3日間開催され、今年の3日間のトータル来場者数はなんと136,875人にも上ったということです。 私は初日の6/11(水)に参加してきましたが、10:30に幕張海浜駅に着いた状態でも大量の人だかり。そのほとんどがInterop Tokyoの参加者たちでした。 駅から幕張メッセまではおよそ徒歩7～8分ほどですが行列を辿っていけばおのずと開催地に辿り着けると思います。 ブース会場を上から眺めた図。ここから見える範囲で全体の5分の1ほど。 入場証を係員の方に読み取ってもらっていざメインの会場へ。会場入り口は2階に位置しますが、出展ブースなどのメイン会場は1階にあるため、メイン会場の入り口を入るとすぐに広大な出展ブースの数々が目に入り圧巻です。 ぱっと見ただけで個性的なブースがいくつも目に入り、出展者の呼び込みや参加者の賑わいからお祭りにきたような感覚に陥り、自ずと高揚感が高まってきます。 会場の雰囲気 芸人さんが司会となってじゃんけん大会を催すようなブースも。 Interopはコンピュータ分野に特化したイベントであるため、各ブースで紹介されている製品なども業界知識をある程度持っていないと理解できないことは多いと思います。ただ、中にはあまりITに詳しくない方でも楽しく理解できるような催しを行っている企業もあり、そういったイベントを通してサービスや企業自体のことを知ってもらう工夫もInteropを体験する中で面白い観点だと感じました。   会場で行われる様々な講演 冒頭でも記載したように、Interopでは様々な分野の有識者の講演を予約して拝聴することができます。 私は４つの講演を予約しましたが、その中から印象に残った講演を2点簡単にご紹介したいと思います。 ①メールセキュリティ戦略 HornetSecurityの講演では、従来のSPFやDKIMだけではメールのなりすましを完全に防げない現状が指摘されました。そこで、これらの認証技術を強化し、なりすましメールをブロックする「DMARC」の積極的な導入が推奨されました。DMARCはSPFやDKIMの認証結果に基づきポリシーを設定します。 また、企業ロゴを表示する「BIMI」との併用で、視覚的にもメールの正当性を示し対策を強化できると説明されました。DMARCやBIMIは自社だけでなく、脆弱な取引先経由で被害が及ぶリスクがあるため、サプライチェーン全体のセキュリティ向上に向け、全企業での実施が極めて重要だと強調されました。 ②AIによるSASEサービスの運用と利活用 続いてはpaloalto Networks社によるAIを用いたSASEサービスの運用についてご紹介します。 同社は、SASEサービス「Prisma SASE」、セキュリティ運用自動化AI「Cortex XSIAM」、包括的セキュリティサービス「CDSS」を提供しており、これらを連携させることで単体以上の価値を生み出します。 例えば、「Prisma SASE」でクラウドサービスのアクセス状況を把握し、「Cortex XSIAM」でユーザー行動の傾向分析や、ダウンロードされたファイルの危険度を自動検出し削除します。また、「CDSS」と「Prisma SASE」の組み合わせでは、AIの判断を軸としたゼロトラストネットワークにより、動的なアクセス権限設定と運用を実現し、セキュリティ担当者の負荷を軽減します。 Palo Altoが提唱するのは、AIを核とすることで、従来の人手による運用を大幅に削減し、ヒューマンエラーを抑制しながらセキュリティを向上させる、新たな利活用モデルでした。 SCSKグループの出展ブース SCSKおよびそのグループ会社についてもInterop Tokyoにて数々の出展を行っていますので簡単にご紹介いたします。 Zabbix SCSKはZabbixのプレミアムパートナーとして昨年もInterop出展を行っております。今年のブースの場所も会場入口近くで、来場者の目に入りやすいので目にされた方も多いかと思います。 NebulaShift NebulaShift はSCSKが提供するクラウドネイティブ化支援サービスです。その NebulaShift のサービスをAI領域まで拡張した” NebulaShift ai”が昨年末リリースされており、その紹介ブースが設けられておりました。 NebulaShift はSCSKとしても力をいれているソリューションの一つでもあり、セッション講演にて当製品の講演も実施いたしました。(好評のようで、私がInterop申込時には講演予約は既に売り切れでした) SCSK Minoriソリューションズ SCSK MinoriソリューションズはSCSKのグループ会社です。今回の出展ではPlayBackMailというメール誤送信対策ソフトや、PerfectWatchAdvanceという資産管理ソフトについて紹介をしていました。 SCSKセキュリティ SCSKセキュリティもSCSKのグループ会社です。SCSKセキュリティではSplunkと呼ばれるビッグデータの解析ソリューションについて出展を行っていました。SCSKセキュリティは、Splunkの導入、運用、活用を支援する様々なサービスを提供しています。   まとめ 今回私がInterop Tokyo初参加ということで、一般参加者目線で雰囲気やイベントの概要的なものを紹介させていただきました。 本文でも記載したように会場は一種のお祭りのような雰囲気で、様々なブースの賑やかさを感じながら会場を歩き回るだけでも楽しい時間でした。 また、本来Interopは業界従事者が最新のソリューションや技術を体験して販売や自社業務に活用するための情報収集の場でもあり、 業界としてのトレンドや一分野の有識者の考えをいち早く取り入れられる貴重な場ともなっていると感じました。 個人的には全体的に見てやはり今はAIを主軸にしたサービスを展開している企業がほとんどでした。 次回もし参加する機会があったら、それまでに自分の中のクラウドソリューションの知見を深めておき、自らの業務に付加価値を提供できるようなソリューションがないか？といった観点で色々見て回ってお話なども聞きたいと思いました。是非みなさんも興味が湧きましたらご参加ください。

皆さん、こんにちは！SCSK株式会社の大野です。 今年も、Google Cloudが主催するグローバルカンファレンスイベント「 Google Cloud Next Tokyo 」が開催されます！このイベントは、クラウドテクノロジーの最新情報を学び、業界リーダーや専門家とのネットワーキングを行うための絶好の機会です。 ### Google Cloud Next Tokyo 概要 開催日:  2025 年 8 月 5 日（火）、6 日（水） 会場 : 東京ビッグサイト 南展示棟 この度当社は、PlatinumスポンサーとしてExpo会場へのブースを出展し、スポンサーセッションに登壇いたします。 IT 業界のみならず様々な業界のリーダー、意思決定者、エンジニア、そして開発者の皆様にご満足頂けるセッションコンテンツが準備されていますので、この機会をぜひ​ご活用ください。皆様のご参加を心よりお待ちしております。 ご登録がお済でない方は、まずはこちらからご登録ください↓↓ 【招待コード  : NT25_pt030 】 申し込み時にご入力ください ！！ イベントの見どころ Google Cloud Next Tokyoでは、最新の生成 AI はもちろん、進化する AI エージェントやセキュリティ、アプリ開発、 データベース、インフラ、データ分析、生産性とコラボレーションに関するアップデートと、実際に Google Cloud を導入・運用されているお客様の声を基調講演、ライブ セッション、展示やハンズオンなど、様々なプログラムが用意されています。 ☁︎ 基調講演 生成AI、AI Agent を含む最新のクラウド技術を紹介します。また、日本市場をリードするビジネスリーダーを招いて、そのビジョンや Google Cloud を活用した取り組みをお聞きします。 ☁︎ スポンサーセッション 米 Next で発表された最新情報や日本のお客様によるクラウド活用事例をお届けします。セッションの後にスピーカーへ直接質問して、自社のビジネスに役立つヒントを見つけましょう。 ☁︎ Expo Google Cloud 最新技術が集結！パートナー、お客様の事例デモ、エキスパートとの交流を通じて、Google Cloud 製品とソリューションを体験してください。 ☁︎ ハンズオン　セッション Google Cloud の魅力を、実際のハンズオンを通して体験しましょう。生成 AI、データ分析、インフラ構築、アプリ開発まで、直接、講師のアドバイスを受けながら開発を学べるチャンスです。 ☁︎ スペシャル　セッション 公共機関向けやカルチャーをテーマにした Google ならではのトピックを、ワークショップやラウンドテーブルなどの多様なスタイルで体験していただける特別なプログラムです。 ☁︎オープンステージ クラウド テクノロジーの最前線を発信する Silver スポンサーセッションです。生成 AI、データ活用、Google Workspace の革新的なソリューションをデモや事例を交えて紹介します。登録は不要なので、お気軽にご参加ください。 ☁︎ Learning & Certification Google Cloud 認定資格とラーニング プログラムのブースや認定資格者限定のラウンジでは、初心者から上級者まで、どなたにも役立ててもらえる、成長を加速させる情報をお届けします。 ☁︎ Dev Night  AI 時代に、開発者体験も未来に向けて進化しています。 Firebase を含む最新の AI エージェント開発手法やツールについて、コミュニティの人たちと一緒に楽しく学び、話し合いましょう。 SCSK のセッションとブースのご紹介 SCSK セッションのご紹介 開始日時：８月５日（火）12:00 – 12:30 タイトル： Gemini がデータサイエンティストに !? 業務データから始める高度なデータ活用 【概要】 生成AIは日々、進化しています。 その機能強化と導入・実用化の容易化が進む今こそ、データ活用を本格的にはじめてみませんか？これまで生成AIに触れてきたものの、「活用に課題を感じている方」・「イマイチ使いこなせていない方」・「そもそも使い方が分からない方」必見です。数々の大手企業様と共創してきたSCSKならではの視点で、最新技術を用いた高度なデータ活用のコツを『こっそり』ご紹介いたします。 取り上げる主な Google Cloud 製品 / サービス ・BigQuery ・Gemini ・Looker #初級者向け🔰　#全業種向け 【SCSK登壇者のご紹介】 クラウドサービス事業本部 ＡＩ＆クラウドソリューション部 第二課 AI リードエンジニア 島村 裕哉　 SCSKのクラウド専門部隊に所属する、AI/MLサービスのリードエンジニア。  Google CloudのAI/生成AIを活用し、製造業・金融業・食品業界など幅広いお客様のシステム設計・構築を担当。 AIサービス選定から導入コンサルティング、導入サポート、AI基盤・運用構築まで数多くの案件を経験。  Partner Top Engineer 2024/2025 にてCloud AIMLを2年連続受賞。 生成AIを業務活用したい方、ぜひセッションへお越しください！ SCSK ブース SCSKのブースでは、 昨今のクラウド活用に欠かせないテーマとなったAI・データ活用、また普遍的なテーマであるIaaSマイグレーションやセキュリティを中心とした最新サービス を展示いたします。 「データの活用が進まない」「AI導入が実証実験で止まってしまう」「セキュリティ対策に不安がある」「VMwareの今後をどうすればいいか悩んでいる」…。 SCSKは、このような企業が抱えるクラウド時代の複雑な課題に、お客様と「とことん」向き合い、最適な解決策をご提案します。 眠っているデータをビジネスの羅針盤に変えるデータ活用、AIの本格導入、会社の未来を守る強固なセキュリティ、そしてクラウドシフトに関する専門的なご相談まで、お客様の重要なクラウドの未来をトータルでサポートいたします。 貴社の課題解決とビジネス成長を、SCSKのクラウドサービスで実現しませんか。 ぜひご来場いただき、最新のAI技術とSCSKだからできるビジネスへの活用方法についてご確認ください！   では皆様、Google Cloud Next Tokyoを楽しみにお待ちください。 当日はSCSKセッションならびに展示ブースへの来場をお待ちしております！ 【招待コード : NT25_pt030】 申し込み時にご入力ください ！