こんにちは、ひるたんぬです。 この度「 AWS re:Invent 2025 」に参加できることになりましたので、現地での出来事や参加したセッションについてのレポートをお送りしたいと思います！ 今回は、三日目の出来事を振り返ります！ 今回の記事も比較的写真が多めの記事となります。ご了承くださいませ。 Day 3 5K Race Day 3では、re:Invent定番のイベントの一つと言っても過言ではない「5K Race」が開催されます！ 一言で言うと、日の出時刻辺りからラスベガス市街を5km走る、というイベントです。 イベント概要は、以下をご覧ください。 AWS Builder Center Connect with builders who understand your journey. Share solutions, influence AWS product development, and access useful... builder.aws.com 私は初日に参加受付をしていたので、朝5時に起床して会場に向かいました。 ▼ 事前受付後にもらえるゼッケン。ゼッケン（左側の白い帯）にはタイムを記録するためのタグが埋まっているようでした。 ホテルからスタート地点の会場まではバスによる送迎があります。あらゆるイベントにおいて、送迎があるのはとても助かります。 ▼ ウォーミングアップ会場。飲み物や軽食が提供されます。 ▼ レース中。朝の気温は約7℃でしたが、走るにはちょうどよい気候でした。 ▼ やっとの思いでゴール！記念にチェキも撮ってもらえます。 ゴール後は、専用のサイトから自分の順位やタイムを確認することができます。 私は30分程度でゴールできたのですが、半分くらいの順位でした。 上位の方は20分かからずゴールしているので…こちらの攻略は難儀を極めそうです。 ▼ 私の結果。専用のサイトより記録をエクスポートすることができます。 なお、余談ですが当日のレースの様子がFOX Newsに取り上げられているようですね。 ※ あくまで道路封鎖のお知らせですが… Amazon conference 5K shuts down I-15 off-ramp near Las Vegas Strip Amazon’s Web Service conference is in town this week, and every year, attendees participate in a 5K. www.fox5vegas.com AWS Jam: Generative AI 次はAWS Jamへの参加です。 こちらは「NVIDIA」がスポンサーのセッションなので、内容も生成AIに関するものでした。 ▼ 事前説明での一節。生成AIやエージェンティックAIを使いこなし、2026, 2027年以降に備えよう！と説明がありました。 今回は日本人4人でのチームで参加し、前回（Day 1）の参加経験を踏まえて挑みました。 意識したことは、 取り組む問題テーマをチームメンバーと話し合って決める （それぞれの経験有無等によって、取り組む問題の難易度や分野を分けたい） 二問目以降に取り組むときは取り組むテーマを宣言する （同じテーマに取り組んで時間ロスが起きることを防ぐ） ヒントは臆せず使う （30分悩んだ30点よりも、15分で解いた20点を意識する） → 時間が余るということは無さそうだったので、ひたすら解くことを優先するようにしました いざ、ゲーム開始です！ ▼ 途中経過。上位3チームには順位を示す風船が置かれました。 私たちのチームは3位、2位…と調子が良いです！！ 問題と格闘すること約3時間。あっという間に終了しました。 さて、気になる私たちの順位は…？ 4位…惜しい！入賞まで70ポイント弱の差でした。 前回が真ん中（30位前後）であったことを考えると、内容やチームメンバーが変わっているのでなんとも言えないところではありますが、戦略の方向的には間違っていなかったのかなと感じました。 次回こそは、入賞…いや優勝したいですね。。 チーム名「EDLEN」の由来は、テーブルに置いてあったコンセントタップに書かれていた単語です。 記事執筆時に調べたところ、ラスベガスにあるイベントでの用品レンタル会社のようでした… 問題に取り組む中でKiroのSpec駆動開発やVibeコーディングをしたり、MCPサーバの利用設定をしたり…生成AIならではの作業やプロセスが一部でも体験できたことは非常に有意義でした。 ただしJamの形式上、入賞を目指し時間を意識して取り組んだので、改めてゆっくり時間をかけて触れたいなと思いました。 終わりに 三日目は名物のマラソンからAWS Jam参加…と、頭も体もフル活用した一日となりました。 re:Inventも残すところ後二日…最後まで満喫したいと思います！ 次回以降の投稿も引き続きお楽しみに！

こんにちは！2年目の秋葉です！ 入社2年目でまだまだ勉強中ですが、最近業務で「 Amazon FSx for Windows File Server（以下FSx） 」を触る機会がありました。 その中で、“PowerShellからシャドーコピーを設定してみる” という作業を経験したので、 同じようにFSxを扱う方や、これからPowerShell操作にチャレンジする方へ向けて、私の学びを共有したいと思います。 FSx、ボリュームシャドーコピーとは ここで、本記事の要となるFSx・シャドーコピーについて簡単に説明します。 FSx ：WindowsファイルサーバーをAWS上にまるごと構築してくれるマネージドサービスです。 ボリュームシャドーコピー ：ファイルやフォルダの過去バージョンを自動的に保存しておく仕組み 似た言葉で「スナップショット」といわれるものがありますが、シャドーコピーはあくまで「 仕組み 」です。 スナップショットはシャドーコピーで作成される成果物だと考えましょう。   今回使用する構成図 今回はWorkSpacesを使用してFSxのボリュームシャドーコピーを設定していきます。 AWS WorkSpacesとは、AWSが提供するマネージド型の仮想デスクトップサービスです。 クラウド上にWindowsまたはLinuxデスクトップ環境を構築でき、利用ユーザーは自宅や社内、出張先など、 どこからでも安全にアクセスできるようになります。 PowerShellからFSxに接続してみる 早速、WorkSpacesに接続してPowerShellを起動します。 ここでひとつ注意点があります。 ボリュームシャドーコピーの設定は、誰でもできるわけではありません。 FSx構築時に「 委任された管理者グループ 」として登録されたグループに所属しているユーザーのみが設定操作を行えるため、 自分のアカウントにその権限がない場合は、対象の管理者ユーザーとして実行する必要があります。 別ユーザーとしてPowerShellを起動出来たら、以下コマンドを使用してFSxに接続します。 “Windows Remote PowerShell EndPoint”は、FSxのマネコン上で確認可能です。 Enter-PSSession -ComputerName "Windows Remote PowerShell EndPoint" -ConfigurationName fsxremoteadmin 赤枠部分が適切なWindows Remote PowerShell エンドポイントであれば成功です。 シャドーコピーの設定 シャドーコピーの容量設定 今回は以下コマンドを使用して設定しました。 「-Default」 オプションを使用すると、シャドウストレージの量をボリュームの 10% に、シャドウコピーの最大数を 20 に設定します。 Set-FsxShadowStorage -Default スケジュール設定 スケジュールを設定する前に、[exit]コマンドを使用して、一度FSxから切断します。 以下コマンドを使用して、Windows スケジュールタスクトリガーを作成します。 JST時刻 で毎日00:00にシャドウコピーを取得するように取得しています。 $trigger1 = new-scheduledTaskTrigger -weekly -DaysOfWeek Sunday,Monday,Tuesday,Wednesday,Thursday,Friday,Saturday -at 00:00 次に、FSxにもう一度接続し、以下コマンドを使用してシャドーコピーのスケジュールを設定します。 Set-fsxshadowcopyschedule -scheduledtasktriggers $Using:trigger1 -Confirm:$false 設定時刻は UTC時刻 で表記されるので、間違えないように注意してください。 その他コマンド コマンド 説明 Get-FsxShadowStorage シャドウコピーストレージを表示 Get-FsxShadowCopySchedule シャドウコピースケジュールの表示 Remove-FsxShadowCopySchedule シャドウコピースケジュールの削除 New-FsxShadowCopy シャドウコピーの作成（手動） Get-FsxShadowCopies 既存のシャドウコピーの表示 Remove-FsxShadowCopies -Oldest 最も古いシャドウコピーの削除 Remove-FsxShadowStorage シャドウコピーのストレージ、スケジュール、およびすべてのシャドウコピーを削除する   まとめ 今回は、FSxのボリュームシャドーコピーをPowerShellから有効化・スケジュール設定する流れをまとめました。 実際にやってみて感じたことをいくつか挙げます。 GUIよりも仕組みを理解しながら設定できる FSx構築時に「 委任された管理者グループ 」として指定したグループがかなり重要！（最初、ここでハマりました） スケジュール設定時は、一度FSxから 切断 する！（次に、ここでもハマりました） スケジュール設定時刻は JST表記 だが、表示時刻は UTC表記 に注意！（最後に、ここでハマりました） まだまだ学ぶことは多いですが、実際に構築してみると仕組みがぐっと分かりやすくなります。 これからFSxを運用していく方や、PowerShellを活用したい方の参考になれば幸いです。

当記事は、前回の記事「Ansibleを使用してNW機器設定を自動化する（PaloAlto-サービスグループ編①）」からの改善となります。 設定情報がベタ書きで使い勝手が悪い点　を　設定情報をまとめてINPUT（JSON）できる使い勝手の良い仕組みとしました！！ これにより、Anibleとの連携ができるようになりますので、ご参考になれば幸いです。 ※前回記事： https://blog.usize-tech.com/ansible-automation-paloalto-servicegroup-1/ 当記事は、 日常の運用業務（NW機器設定）の自動化 により、 運用コストの削減　および　運用品質の向上 　を目標に 「Ansible」 を使用し、様々なNW機器設定を自動化してみようと　試みた記事です。 Ansibleは、OSS版（AWX）＋OSS版（Ansible）を使用しております。   PaloAltoの「Objects-サービスグループ」の登録／変更／削除を実施してみた 事前設定 Templateを作成し、インベントリーと認証情報を設定する。 インベントリー：対象機器（ホスト）の接続先を設定。　※ホストには以下変数で接続先IPを指定 ansible_host: xxx.xxx.xxx.xxx 認証情報：対象機器へのログイン情報（ユーザ名／パスワード）を設定。 ユーザ名は　　変数：ansible_user　　　に保持される パスワードは　変数：ansible_password　に保持される   事前設定２：設定情報をまとめてINPUT（JSON）できるように、「Survey」を活用 テンプレートが読み込むことができる変数（Survey）を設定する。※今回は、各設定のデフォルト値に値を設定する。 実際の値（JSON） ・input_servicegroup1:{"name":"test_servicegroup001","value":"test_service001"} ・input_servicegroup2:{"name":"test_servicegroup001","value":"test_service002"} ・input_servicegroup3:{"name":"test_servicegroup001","value":['test_service001','test_service003']} ・input_servicegroup4:{"name":"test_servicegroup001","value":"test_service003"}   Playbook作成（YAML） 使用モジュール paloaltonetworks.panos.panos_service_group 　を使用。 ※参考ページ： Ansible Galaxy galaxy.ansible.com   接続情報（provider）の設定 providerには、ip_address／username／password　の指定が必要。 vars: provider:   ip_address: '{{ ansible_host }}'　　　←　インベントリーのホストで設定   username: '{{ ansible_user }}'　　　　←　認証情報で設定   password: '{{ ansible_password }}'　　←　認証情報で設定   変数（Survey）の値取得 vars で　各変数（Survey）の値取得。 ※各変数（Survey）の値は、構造化データのように見えて「文字列」なので、ディクショナリ（構造化データ）として正しく扱えるように、from_json フィルターを使用すること！！                vars: wk_input1: '{{ input_servicegroup1 | from_json}}' wk_input2: '{{ input_servicegroup2 | from_json}}' wk_input3: '{{ input_servicegroup3 | from_json}}' wk_input4: '{{ input_servicegroup4 | from_json}}'   Objects-サービスグループの登録　★ 変数（Survey）の値をそのまま使用した場合…エラーとなる 接続情報と　サービスグループとサービスの関連付け（ Survey：input_servicegroup1 ）　を指定して登録（ state: ‘present’ ）を行う。 - name: Present ServiceGroup1 paloaltonetworks.panos.panos_service_group:   provider: '{{ provider }}' name: '{{ input_servicegroup1.name }}' value: '{{ input_servicegroup1.value }}' state: 'present' register: wk_result 実行結果：構造化データではないので、オブジェクトに項目が無いという エラー となる。　※Ansibleの実行結果を抜粋 "msg": "The task includes an option with an undefined variable. The error was: 'ansible.utils.unsafe_proxy.AnsibleUnsafeText object' has no attribute 'name'. ...   Objects-サービスグループの登録　※サービスグループの新規作成の場合 接続情報と　サービスグループとサービスの関連付け（ Survey：input_servicegroup1 ）　を指定して登録（ state: ‘present’ ）を行う。 - name: Present ServiceGroup1 paloaltonetworks.panos.panos_service_group: provider: '{{ provider }}' name: '{{ wk_input1.name }}' value: '{{ wk_input1.value }}' state: 'present' register: wk_result 実行結果：対象のサービスグループが登録された。　※Ansibleの実行結果（diff）を抜粋 "before": "", "after" : "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_servicegroup001\">\n\t<members>\n\t\t<member>test_service001</member>\n\t</members>\n</entry>\n"   Objects-サービスグループの登録　※サービスグループが既に存在する場合 接続情報と　サービスグループとサービスの関連付け　を指定して登録（ state: ‘present’ ）を行う。　 ※サービスグループが既に存在する場合は、既存設定の置き換えとなる（state: ‘replaced’と同様）   - name: Present AddressGroup1 paloaltonetworks.panos.panos_service_group: provider: '{{ provider }}' name: '{{ wk_input2.name }}' value: '{{ wk_input2.value }}' state: 'present' register: wk_result 実行結果：既存のサービスグループが 上書き更新 された。　※Ansibleの実行結果（diff）を抜粋 "before": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_servicegroup001\">\n\t<members>\n\t\t<member>test_service001</member>\n\t</members>\n</entry>\n", "after" : "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_servicegroup001\">\n\t<members>\n\t\t<member>test_service002</member>\n\t</members>\n</entry>\n"   Objects-サービスグループの変更　※登録のつづき（新たなサービスを関連付けする） 接続情報と　サービスグループとサービスの関連付け　を指定して、サービスグループの変更（ state: ‘replaced’ ）を行う。　 ※replacedの場合は、既存設定の置き換えとなる　（注意：関連付け後の状態を指定すること！！） - name: Replaced AddressGroup1 paloaltonetworks.panos.panos_service_group: provider: '{{ provider }}' name: '{{ wk_input3.name }}' value: '{{ wk_input3.value }}' state: 'replaced' register: wk_result 実行結果：既存のサービスグループが 上書き更新 された。　※Ansibleの実行結果（diff）を抜粋 "before": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_servicegroup001\">\n\t<members>\n\t\t<member>test_service002</member>\n\t</members>\n</entry>\n", "after" : "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_servicegroup001\">\n\t<members>\n\t\t<member>test_service001</member>\n\t\t<member>test_service003</member>\n\t</members>\n</entry>\n"   接続情報と　サービスグループとサービスの関連付け　を指定して、サービスグループの変更（ state: ‘merged’ ）を行う。　 ※mergedの場合は、既存設定を維持した更新（Append）となる。 その為、特定サービスの関連付け解除はできない　（注意：サービス の関連付け解除をしたい場合は　state: ‘replaced’　を使用する必要がある！！）   - name: Merged AddressGroup1 paloaltonetworks.panos.panos_service_group:   provider: '{{ provider }}' name: '{{ wk_input4.name }}' value: '{{ wk_input4.value }}' state: 'merged' register: wk_result 実行結果：既存のサービスグループが 更新（Append） された。 既存設定が維持されていることを確認 。　※Ansibleの実行結果（diff）を抜粋 "before": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_servicegroup001\">\n\t<members>\n\t\t<member>test_service002</member>\n\t</members>\n</entry>\n", "after" : "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_servicegroup001\">\n\t<members>\n\t\t<member>test_service002</member>\n\t\t<member>test_service003</member>\n\t</members>\n</entry>\n"   Objects-サービスグループの情報収集　※変更のつづき 接続情報と　サービスグループ　を指定して情報収集（ state: ‘gathered’ ）を行う。 - name: gathered AddressGroup1 paloaltonetworks.panos.panos_service_group:   provider: '{{ provider }}' name: '{{ wk_input4.name }}' state: 'gathered' register: wk_result 実行結果：対象サービスグループの 情報が取得 できた。　※Ansibleの実行結果（gathered_xml）を抜粋 "gathered_xml": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_servicegroup001\">\n\t<members>\n\t\t<member>test_service001</member>\n\t\t<member>test_service003</member>\n\t</members>\n</entry>\n"   Objects-サービスグループの削除　※変更のつづき 接続情報と　サービスグループと関連付いているサービス　を指定して、削除（state: ‘absent’）を行う。　（ 注意：関連付いているサービスが削除されるのではなく、サービスグループが削除される！！）   - name: Absent AddressGroup1 paloaltonetworks.panos.panos_service_group: provider: '{{ provider }}' name: '{{ wk_input4.name }}' state: 'absent' register: wk_result 実行結果：対象のサービスグループが 削除 された。　※Ansibleの実行結果（diff）を抜粋 "before": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_servicegroup001\">\n\t<members>\n\t\t<member>test_service001</member>\n\t\t<member>test_service003</member>\n\t</members>\n</entry>\n", "after" : ""   最後に 今回、変数（Survey）を活用したことで、Ansibleに INPUT（JSON）を設定 できるようになりました。 設定情報がYAMLにベタ書きではなくなったので、使い勝手は増しましたが、 都度　変数（Survey）のデフォルト値に値を設定しての実行の為、まだまだ　使い勝手が悪い。。。                 今後　外部からAnsibleの INPUT（JSON）に値を連携し実行させる仕組みを試みたいと思います。

こんにちは。SCSKの松渕です。 2025年11月19日、 Gemini 3がリリース されましたね！それと同時にIDEである Antigravity の発表もされました！ 今回は、AntigravityとGemini 3を利用して、簡易WEBサイトを Google Cloud環境上 に実装しました。 以前、Google社提供のコーディングエージェントの Julesを使ったこと があります。が、正直 全く別次元のレベルである と感じました。   はじめに Antigravityとは AWSのKiroと同様に、 AIエージェント型統合開発環境（Agentic IDE） と呼ばれるものです。 Antigravityのポイントとしては、特に以下の点になるかと思っております。 　・ AIによる ブラウザ操作も可能 　・ AIによる 自律的な実装 　・ アウトプット品質の高さ （これはGemini 3のポイントではありますが） ・ Google Cloud環境とのシームレスな連携 類似サービスとの比較は以下の通りです IDE/プラットフォーム 開発元 主な設計思想と特徴 類似サービスとの差別化ポイント Antigravity Google エージェント・ファースト 。AIが自律的にタスクを計画・実行・検証する。 マルチエージェント によるタスクのオーケストレーション。 自律性のレベル と End-to-End （ブラウザ操作を含む）実行能力。開発の 監督 に特化。 Kiro AWS 仕様駆動開発（Spec-Driven Development） 。要件→設計→タスク分解をAIと共同で体系的に進める。 Specモード と Vibeモード 。 開発プロセスの構造化 。ドキュメント（仕様書）を起点とし、 検証可能なコード品質 を重視。エンタープライズ親和性が高い。 Cursor Cursor, Inc. AIアシスタント型IDE 。コードの生成、編集、質問応答を強力にサポートする。AIチャットが非常に軽快で対話的。 AIはあくまで アシスタント であり、線形的なチャットベースの対話が中心。 即応性と軽快さ に優れる。 VS Code Microsoft 広く普及した 高機能なコードエディタ/IDE 。AI機能は 拡張機能 （例: Copilot）として追加される。 AI機能は拡張機能 であり、IDEのコア機能ではない。 私のスキルとブログ記載内容 私自身、普段はインフラが専門 で、アプリケーション開発の経験は多くありません。IDEもほぼ初めての利用になります。この記事では、そんな私と同じような視点を持つ方でも分かるように、初期インストールから詳しく解説しています。 「そんなところいいから、どんなもの作れるの？」って人は後半だけ読んで下さい！   Antigravityのインストール まずは最初に、ローカル環境（PC）へAntigravityをインストールするところからになります。 ダウンロード Antigravityのサイト へアクセス。OSに合わせたモジュールをダウンロードします。 私の場合は、「Download for Windows」を押下し、Windows用の「Download for x64」を押下します。 　→　   セットアップ画面が出てきます。必要に応じて設定内容変更しつつインストールしていきます。 → → → →   初期設定画面 Antigravityが起動し、初期設定画面が起動します。「Next」を押下します   VS codeを利用している場合、設定をインポートすることも可能です。私は使っていないので「Start fresh」を選択します。   画面のトーンも選べます。ここは好みでよさそうです。私は「Tokyo Night」を選択しました。   次の画面は大事ですね。Antigravityにおいて AI エージェントにどこまで自律的な実装権限を与えるか です。 左カラムの「Agent-driven development」や「Agent assisted development」等の選択をすると、 右カラムの「Terminal execution policy」等が変わりますので、ポイントは右カラムになります。   Terminal execution policyについて エージェントが ターミナルでコマンドを実行する際の許可レベル を設定します。 Turbo: エージェントの判断でコマンドを即時実行し、開発速度を最大化します。（上級者向け） Auto: エージェントが安全性を判断し、リスクがない場合のみ自動でコマンドを実行します。（標準設定） Off: ターミナルでのコマンド実行を完全に禁止し、必ずユーザーの承認を求めます。（安全重視） 私は今回、完全お任せにしたかったので Turbo にしてます。   Review policyについて Always Proceed: ユーザーのレビューなしに、エージェントが生成したコードを即座にコミットします。 Agent Decides: エージェントが自信度などに基づいて、コミットを続行するかユーザーにレビューを求めるかを判断します。 Request Review: 生成されたコードをコミットする前に、必ずユーザーにコードの確認と承認を求めます。（推奨） 私は今回、完全お任せにしたかったので Always Proceed にしてます。   JavaScript execution policyについて Turbo: ユーザーの確認なしに、Web関連のスクリプトを即時実行します。 Auto: エージェントが安全性を判断し、リスクがない場合のみJavaScriptを自動で実行します。（標準設定） Always Ask: JavaScriptの実行前に、必ずユーザーに承認を求めます。 Disabled: WebビューなどでのJavaScriptの実行を完全に禁止します。 私は今回、完全お任せ（以下略）   もう一つの要素に「 Use the default allowlist for the browser 」という項目があります。 allowlist とは、エージェントがWebサイトにアクセスしたり、Web上のリソースを使用したりする際の 安全性を担保するためのものです。 チェックを入れる（推奨）: Google Cloudの公式ドキュメント、APIリファレンス、一般的な開発者向けサービスなど、エージェントがコード生成のために参照することが想定される 安全なドメインへのアクセスを許可 し、開発フローを円滑にします。 チェックを外す: あらゆる外部ドメインへのアクセスが厳しく制限されるため、セキュリティは向上しますが、エージェントが情報収集やAPIテストを行う際に ユーザーの承認を頻繁に求める ことになり、作業が滞りやすくなります。 今回はチェック入れております。     キーボードショートカット設定と、言語拡張機能をインストール設定画面が出ます。 こだわりなければ、 Normalを選択 して、 Install 7 Extensions にチェック入れた状態で Next を押下。   ここからGoogle アカウントとの連携設定に入ります。画面に従って、Googleアカウントとの連携設定を行います。  →   →   認証完了したら以下の画面が出てきます。   Antigravityの画面に戻り、「セキュリティ上の注意喚起」と「データ収集への同意」の画面が出てきます。 以下のような内容が記載されております。 ユーザーは、 データ流出 や 意図しないコード実行 を含む潜在的なリスクに注意すべきです。 Googleがユーザーの Antigravity上での操作データ （エージェントへの指示、コードの修正、対話履歴など）を収集し、GoogleおよびAlphabetの研究、製品、サービスの開発・改善（特に機械学習技術の向上）のために使用することに同意します。   Antigravityの起動しました！   日本語化 Antigravityの画面から、左下の拡張機能（□4つあるようなアイコン）を選択。 検索画面で「Japanese」を検索し、 Japanese Language Pack for Visual Studio Code を選択し、 Install を押下。   信頼できる発行元かの確認が出ます。 Trust Publisher ＆ Install を押下。   インストール後、再起動の確認画面が表示されます。 Change Language and Restrat を押下。   再起動後、日本語になりました！ ※ただし、英語の部分もかなり残っています。いずれ日本語になることを期待します・・・！     Hello Worldと表示されるサイト作ってみる エージェントモードで依頼 最初にOpenfileから作業フォルダを指定します。 次に、Antigravityのトップ画面から「Open Agent Manager」ボタンを押下する。 ※ Ctrl + Eボタン押下でも可 AIエージェントの動作を管理・監視する画面 として、「 Agent Manager 」が存在します。 従来のIDEに近い使い方としてコードエディタ画面でもAIを使うことは可能です。が、今回は エージェント・ファースト を体験したかったのでAgent Manager画面を利用します！   Agent Manager画面が表示されます。なおGemini 3以外にもClaude Sonnet 4.5や、GPTも選べました。 今回はGemini 3 pro (High)を選択します。 　→　   「 hello worldと表示するサイト作って 」と雑な依頼を投げました。 計画を立てて自律的にアプリ開発をしてもらえました。   ブラウザ表示許可設定 Antigravityの特徴の一つである、ブラウザ操作を行うための初期設定に入ります。 Antigravity側から設定依頼が来ましたので、「Setup」を押下します。   画面遷移するので、「Install extention」を押下します。   Chromeが立ち上がります。Chromeの拡張機能としてAntigravityを追加することを確認されます。 「Chromeに追加」を押下して、追加します。   →　   計画に沿ってAIが自動で進めてくれます。   見にくいですが、 ブラウザ表示のテストまでエージェントが実施 してくれます。 IDEの画面上に組み込まれてそのまま見れるのも使い勝手としていいですね。   PC上のフォルダを見ると、実際ファイルが作成されています。   PC上のindex.htmlをクリックすると、Hello Worldが出てきました！！     Cloud Run上にデプロイする ここからがAntigravityの本領発揮です。Antigravityの特徴として、 Google Cloudとのシームレスな連携 が挙げられます！！ 主な特徴は以下だと考えてます。 Cloud Run への デプロイ： gcloud CLI の初期設定だけしてあげれば、 「Cloud Runにデプロイして」の一言でデプロイ してくれます。 Cloud Logging の 参照およびアプリの自律的な修正 ： Cloud Runのログを確認し、エラーを見てアプリケーションを改善、修正を自律的に行えます。 早速Cloud Runへのデプロイの手順に入っていきます。   gcloud CLIの設定 前提としてgcloud CLIの設定が必要になります。私の環境では、gcloud CLIの初期設定は実施済でした。 未実施の場合は、　 gcloud CLIのインストール 　および　 初期設定 　を最初に実施する必要があります。   Antigravityで依頼する 雑に 「Cloud Run上にデプロイしてほしいな」と依頼 しました。まさかの、 これだけで一発デプロイ成功 しました！！！ 何かしら失敗、もしくは聞かれるのではないかと思ってたので、 正直びっくり しました。 また、今回も ブラウザ表示のテストまでエージェントが実施 してくれました。   実機確認 Google Cloudの画面に移動します。Cloud Runサービスが新しく作成されていることを確認できました。   各種設定は、基本デフォルト値でデプロイされているように見えます。     最初のプロンプトの通り、Cloud Runの名前、サービスアカウント、Serverless VPC Access connector利用要否等の設定は一切指示しておりません。 すべてGemini 3で自動で設計/実装 されております。基本的にはデフォルト設定のようです。 リージョンについては、gcloud CLIのデフォルトリージョン設定で実装されたと思われます。   Artifact Registryを確認すると、 イメージも自動でアップロード されておりました。 このほか、Cloud Build使ってビルドしているのも履歴に残っておりました。   CloudRunのURLにアクセスしたところ、しっかりとHello Worldが表示されました！ 非常に簡単ですね！     Antigravityを使ってみた感想 素晴らしい点 高品質で自律的に実施してくれる 自然言語で依頼したら、 自身で考えて計画を立て、プログラム作成/修正 まで実施してくれます。 それだけなら今まで通りですが、 品質のレベルが今までと段違い だと感じました。 Hello Worldと表示するだけの機能ではありますが、こんな 雑なプロンプトで一発成功 は正直驚きでした。 Gemini以外の選択肢がある Gemini派、Claude派どちらも使えます！得意分野に応じて使い分け また、 Gemini 3のクォータに引っ掛かったときにClaude使う ということもできます！ ブラウザの自律操作 テスト等で ブラウザ操作を自律的に実施 してくれます。 そして、それがIDEの画面内で完結するというのも、作業継続性が失われないという意味でもうれしいところです。 もったいない点 無料枠のクォータが少ない。 Gemini 3が人気すぎて、すぐ利用クォータの上限に引っ掛かります。これは仕方ないのですが。。   まとめ 今回は、GoogleのAIエージェント型IDE「 Antigravity 」を使って、シンプルなWebサイトを構築し、Cloud Runへデプロイする一連の過程をご紹介しました。AntigravityのようなAIエージェントをうまく活用すれば、 私のようなインフラエンジニアでも、プログラミングの世界に飛び込んでいける時代になったのだ と実感しました。 しかし、これは同時に新たな責任も伴います。これからは、 AIエージェントが 出力する計画やコードを評価し、指揮する という、 AIエージェントのプロジェクトマネージャー としての役割が求められていくでしょう。 セキュリティ上の問題はないか？ 意図しないクラウドコストが発生しないか？ エージェントの作成したデプロイ計画が、本番環境の要件を満たしているか？ これらを判断するには、AIエージェントの出力内容を理解し、 「なぜ、そうなるのか」 という本質的な部分を理解し続け なければなりません。 ぜひ一度 Antigravity を試してみて、新しい開発の波に乗ってみてはいかがでしょうか。

こんにちは。SCSKの井上です。 この記事では、New Relicにおけるユーザー作成の手順や注意点について解説していきます。この記事で、New Relicの運用をより安全かつ効率的に行えるようになることを目指します。   はじめに この記事では、すでにアカウントをお持ちの方を対象に、ユーザー作成過程において有償ユーザーと無償ユーザーの違い、そしてカスタムロールの作成方法についても触れています。New Relic をチームで活用する際、ユーザーごとに適切な権限を設定することは、セキュリティと運用効率の両面で大切になります。この記事が、ユーザー管理の理解を深める一助となれば幸いです。以下の流れで解説していきます。   アカウントとユーザー アクセスの管理に関するチュートリアル | New Relic Documentation A tutorial that will walk you through creating and managing New Relic accounts and users. docs.newrelic.com   組織の作成(自動で作成) New Relicのサインアップが完了していない場合、以下の手順をご参考ください。この記事では割愛します。 【New Relic】使い始めるためのサインアップガイド この記事では実際にNew Relicを使う導入ステップとして、New Relicのサインアップ方法について解説していきます。初めてNew Relicを利用される方でもスムーズに始められるよう、必要な情報を順を追ってご紹介します。 blog.usize-tech.com 2025.11.19   アカウントの追加(任意) New Relicのサインアップが完了後、New Relicのアカウントを環境ごとに分けたい、プロジェクトごとに分けたい場合などは、この手順を参照してください。アカウントの追加は必須ではないため、1つのアカウントで運用する場合は、本手順はスキップしてください。なお、無料プランをご利用されている場合は、アカウントの追加はできません。 １．自身のユーザー名をクリック後、[Administration]を選択します。 ２．「Access Management」をクリック後、「Accounts」タブを開き、 「Create account」をクリックします。 ３．アカウント名を入力し、「Create account」をクリックします。 ４．作成されたアカウントが表示されます。表示されない場合は、ブラウザの更新ボタンを押した後にご確認ください。           認証ドメインの設定(任意) New Relicでは、ユーザーがどうやってログインするか、どうやって追加・管理されるかを認証ドメインという単位で一元管理します。デフォルトではログイン方法はメール＋パスワード、ユーザー追加方法はNew Relicコンソールから手動追加になっています。1つのメールアドレスで複数の認証ドメイン(手動追加とSCIM連携の両方)に参加はできません。また 認証方式はドメイン作成時に決定され、後から変更不可 になります。この記事ではデフォルトのログイン方法にて進めるため、SSO設定手順については割愛します。 項目 説明 ログイン方法(Method of authentication) – メール＋パスワード – SAML SSO（シングルサインオン） ユーザー追加方法(Source) – 手動追加（UIから直接） – SCIM連携（IDプロバイダーから自動追加）   設定されている認証ドメインの確認方法は、左下の自身のアイコン＞Administration＞Authentication Domains の順にクリック後、以下の画面が表示されます。Sourceはユーザー追加方法、Method of authentificationはログイン方法を指します。無料プランでは設定をデフォルトから変更することはできません。ログイン方法はメール＋パスワード、ユーザー追加方法はNew Relicコンソールからの手動追加のみとなります。認証ドメインを作成する場合は、「Create authentication domain」をクリックして設定します。   認証ドメイン: ユーザーのログイン方法と管理方法 | New Relic Documentation New Relic user authentication: how users are added, SAML SSO, SCIM, automated user management, and more. docs.newrelic.com   カスタムロールの作成(任意) デフォルトで利用可能なロールがいくつかあり、これをStandard roleと呼びます。 デフォルトで使用可能なAdminグループとUserグループが作成されており、それぞれに割り当てられます。権限の細分化が不要で、AdminとUserのみで役割分担ができる場合は、Standard roleを利用します。なお、無料プランをご利用されている場合は、カスタムロールを作成することができません。 Standard roleの確認 Standard roleがどのようなものがあるのかを確認します。左下の自身のアイコン > Administration ＞Access Management > Rolesタブの順にクリック後、以下の画面が表示されます。Standard rolesは、以下4つが用意されています。 ロール名 説明 All Product Admin 組織全体の設定、ユーザー管理、請求情報など、すべての管理機能にアクセス可能※。 Standard User データの閲覧・ダッシュボードの作成・アラート設定などが可能※。ただし、ユーザー管理や請求情報にはアクセス不可。 Read Only データの閲覧のみ可能。設定変更やアラート作成などは不可。 Billing Manager 請求情報の閲覧・管理が可能。その他の機能にはアクセス不可。   ※アクセスにはロールとユーザータイプの2つが揃って実現できます。All Product AdminやStandard Userロールが付与されていても、ユーザータイプがBasicであれば、ユーザー設定やアラート設定などはできません。 【New Relic】New Relicアカウントの基本構造 この記事では実際にNew Relicを使う前の導入ステップとして、New Relicアカウントの基本構造について解説していきます。アカウントを管理していく上で、必要となる前提知識のため、ユーザ作成する前に知識を深める一助になれば幸いです。 blog.usize-tech.com 2025.11.12   該当のRole名をクリック後、どこの画面(機能)で何ができるのかが表示されています。細かく制御したい場合は、カスタムロールを作成することで可能です。   ユーザー許可 | New Relic Documentation An explanation of New Relic user permissions and what they govern. docs.newrelic.com   カスタムロールの作成 Standard roleでは対応できない細かな権限設定や、アクセスを最小限に制御したい場合は、カスタムロールを作成します。 １．Administrationをクリック＞Access Management > Rolesの順にクリック後、以下の画面が表示されます。無料プラン以外のアカウントは「Add new custom role」のボタンが表示されていますので、クリックします。   ２．ロール名を入力し、チェックボックスをクリックして、ロールの付与を選択後、「Save」をクリックします。   ３．Custom roles一覧に先ほど作成したロールが表示されます。名前の変更を行いたい場合や、ロールの変更を行いたい場合は、対象のロール名横の「・・・」より「Manage role」をクリックすることで編集が行えます。   グループの作成(任意) グループとは、特定のユーザーに対して、アカウントとロール（権限）をまとめて割り当てるための管理単位です。同じ組織内であれば、複数アカウントにまたがってグループを活用できます。デフォルトでは「Admin」と「User」グループが用意されています。役割毎に作成したい、プロジェクトやサービス毎で分けたいなど、用途に応じてグループを分けたい場合に、グループを作成します。この手順ではグループの作成に加え、グループとロールの紐づけについても説明します。 １．自身のユーザー名をクリック後、[Administration]を選択します。 ２．「Access Management」＞「Create new group」をクリックします ３．Group nameを記載後、「Create group」をクリックします。 ４．作成したグループの設定画面が表示されますので、設定を行います。 ５．グループに所属させたいメンバをプルダウンメニューから選択し、「Add user to group」をクリックします。 ６．作成したグループはアカウントをまたいで利用できます。作成したグループをどこのアカウントのどのロールに紐づけるかを選択し、「Add role」をクリックします。ロールを追加しない場合、ユーザーをグループ追加しても、権限がない状態になります。 ７．【ブランクでも可】このグループが他のグループのユーザー管理できるようにする場合 、管理するグループをプルダウンメニューから選択し、「Add role」をクリックします。※1 ８．【ブランクでも可】この設定はグループ単位でまとめて付与したい場合に設定します。下記表※2を参考の上、「Close」をクリックします。       ※1 Group access group_admin権限を付与することで、他のグループのユーザー管理(追加/削除/変更)が可能になります。上記の手順では、Infra Groupに所属するFull platform権限を持つユーザーがUserというグループに属しているユーザーを管理できることになります。   ※2 Administrative settings New Relicの管理権限を個人単位ではなく、グループ単位でまとめて付与したい場合に設定します。例えば管理者グループを作成し、グループ内すべて同じ権限を付与する場合に使います。管理者や参照のみのユーザーが混在するグループに対して、この設定を行なった場合は、意図しないアクセスができてしまう可能性があります。 ロール名 説明 Organization Settings：組織名の変更、アカウントの追加・削除、エンティティの管理 Organization Manager 組織名の変更、アカウントの追加・削除、エンティティの削除など、組織全体の設定管理 Organization Read Only 上記設定の閲覧 Authentication Domain Settings：SSO設定、ユーザー追加・削除、グループ・ロール管理 Authentication Domain Manager 認証ドメインの設定、ユーザー追加・削除、グループ・ロールの管理 Authentication Domain Read Only 認証ドメイン設定の閲覧 Authentication Domain Add Users 認証ドメインへユーザーの追加 Authentication Domain Read Users 認証ドメインに属するユーザー情報の閲覧 Observability Settings：組織内のすべてのアカウントやエンティティに対して、オブザーバビリティ機能の設定・管理 Organization Product Admin APM、ダッシュボード、アラートなどの機能の設定・管理 Billing：組織のプランや請求情報を変更する機能 Billing User 請求情報の閲覧・管理   重要なユーザー管理の概念 | New Relic Documentation For New Relic user management: how permissions work, including how groups, roles, and permissions work. docs.newrelic.com   ユーザーの作成 New Relicコンソールへアクセスするためのユーザーを作成します。気を付けたいポイントとしては、手順3のTypeは Basicユーザー以外は有償になります。契約数に関わらず、作成できてしまうので注意が必要 です。 １．自身のユーザー名をクリック後、[Administration]を選択します。 ２．[User Management]をクリック後、[Add user]をクリックします。 ３．赤枠の情報を入力して、[Create user]をクリックします。Type欄については、Basic以外は有償ライセンスになります。 ４．「Create user」をクリック後、Accessの設定画面が表示されます。Add user to groupのプルダウンメニューより、どのグループに属するかを選択します(複数選択可)。選択後、「Add user to group」をクリックし、「Close」をクリックして完了します。 ５．アカウント発行後、アカウントをアクティベーションしていない場合は、Emailの横にPendingが表示されます。 Pendingの表示がなくなっている場合は、ログイン済となります。 【補足】メールの再送希望や有効期限内に手続きができなかった場合は、Pendingにカーソルを合わせた後、ポップアップの「Resend email」をクリックして、再度メールを送信します。   ユーザーを作成後、初回サインインやプロフィール設定、権限変更の仕方は、以下の記事をご参照ください。 【New Relic】New Relicのログイン方法とユーザー設定 この記事ではNew Relicへのログイン方法と作成したユーザの権限変更やプロフィール情報変更について解説していきます。 blog.usize-tech.com 2025.11.26   さいごに New Relicのユーザー作成方法について、有償ユーザーと無償ユーザーとの機能の違いに加え、ユーザーごとの権限を柔軟に管理できるカスタムロールの作成方法の解説をしました。New Relicのユーザー管理は、チームの運用効率やセキュリティにも直結する重要なポイントですので、少しでもご理解いただければ幸いです。 SCSKはNew Relicのライセンス販売だけではなく、導入から導入後のサポートまで伴走的に導入支援を実施しています。くわしくは以下をご参照のほどよろしくお願いいたします。

本記事は TechHarmony Advent Calendar 2025 12/4付の記事です 。 こんにちは、アドベントカレンダー第4走者の坂木です。 本記事では、 保存前処理 の中でもテキストデータの加工処理に焦点を当て、以下の5つの機能について、具体的な設定例を交えながら解説します。 正規表現 置換 前後文字列削除 末尾文字列削除 先頭文字列削除 保存前処理について 保存前処理とは、Zabbixが監視対象から取得したデータを データベースに保存する直前に、その値を加工・変換するための機能 です。例えば、取得した値の単位を変換したり、JSONデータから特定の値だけを抽出したり、正規表現で不要な文字を削除したりできます。 これにより、不要なデータを保存せずに済むためデータベースの負荷を軽減できるほか、データを整形することで、より柔軟で高度な監視や分かりやすいグラフ描画を実現できます。 2 アイテムの値の保存前処理 www.zabbix.com   正規表現 正規表現は、取得したテキストデータから 特定のパターンに一致する部分を抽出・加工 できます。 パラメータとして「パターン」と「出力」を指定し、パターンに一致した部分をどのように出力するかを定義します。これにより、複雑なテキストデータも柔軟に扱うことができ、監視の精度を大幅に向上させることが可能です。   ユースケース コマンドの実行結果から、特定の数値だけを抜き出す ログメッセージからステータスコードやエラーメッセージを抜き出す ログからIPアドレスを抽出して接続元を監視する   実例 以下の/var/log/httpd/error_logから、エラーログの内容のみ抽出する保存前処理を設定します。 # cat /var/log/httpd/error_log [Tue Nov 25 04:42:11.673140 2025] [suexec:notice] [pid 2043:tid 2043] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Tue Nov 25 04:42:11.728157 2025] [lbmethod_heartbeat:notice] [pid 2043:tid 2043] AH02282: No slotmem from mod_heartmonitor [Tue Nov 25 04:42:11.729082 2025] [systemd:notice] [pid 2043:tid 2043] AH10497: SELinux is enabled; httpd running as context system_u:system_r:httpd_t:s0 [Tue Nov 25 04:42:11.747259 2025] [mpm_event:notice] [pid 2043:tid 2043] AH00489: Apache/2.4.64 (Amazon Linux) configured -- resuming normal operations [Tue Nov 25 04:42:11.747282 2025] [core:notice] [pid 2043:tid 2043] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'   アイテムおよび保存前処理の設定は以下のとおりです。   設定した正規表現は、行の先頭から見て、最後の” ] “とスペースに続く部分をすべて取得する、という設定となっています。 正規表現のパラメータ 設定値 説明 パターン ^.*\] (.*) 行頭からすべての文字を読み取り、最後の部分をキャプチャ 出力 \1 キャプチャした部分(.*)を返す   こちらのように取得されます。   置換 置換は、収集したデータに含まれる 特定の値や文字列を、データベースに保存する前に別の値や文字列に置き換える 機能です。 これにより、特定のコードを意味の分かりやすいテキストに変換したり、不要な文字を取り除いたりすることが可能となります。   ユースケース MB, GB などの単位や不要な記号を空欄に置換して、必要な文字列だけに整形する UP, DOWN のようなステータス文字列を 1, 0 のような数値に変換して、グラフ化やトリガー条件に使いやすくする   実例 以下のようにメモリの利用量を取得するスクリプトに対し、単位を削除して数値だけに整形する保存前処理を設定します。 ▼監視対象スクリプト # /etc/zabbix/work/mem.sh 1.01 GB   アイテムおよび保存前処理の設定は以下のとおりです。今回利用しているアイテム(system.run)の利用方法は こちら をご参照ください。   置換のパラメータ 設定値 説明 検索文字列 <単位> 削除する(空欄に置換する)単位を記載 置換文字列 <空欄> 単位を削除するため空欄のまま   こちらのように取得されます。   文字列削除 文字列削除は、保存前処理の パラメータに含まれる文字を、アイテムが取得した値の先頭や末尾から削除する 機能です。 文字列削除機能には、以下の3種類があります。 保存前処理名 説明 前後文字列削除 データの先頭と末尾にある特定の文字を削除 末尾文字列削除 データの末尾にある特定の文字を削除 先頭文字列削除 データの先頭にある特定の文字を削除   ユースケース ログ収集の過程で付加される可能性のある、先頭や末尾の余分なスペースを整形する   実例 以下の文字列に対して、指定した文字（今回は「#」）を削除する保存前処理を設定します。 （本来は末尾のスペースを削除したかったのですが、Zabbixのインターフェース上ではスペースの有無が分かりにくいため、見えやすい「#」を削除する例で説明します。） ▼書き込んだ文字列 te##st test### ###test ###test###   アイテムおよび保存前処理の設定は以下のとおりです。   保存前処理名 文字列削除のパラメータ 設定値 説明 前後文字列削除 文字列のリスト # 先頭と末尾の#を削除 末尾文字列削除 文字列のリスト # 末尾の#を削除 先頭文字列削除 文字列のリスト # 先頭の#を削除   こちらのように取得されます。   まとめ Zabbixの保存前処理は、未加工のデータを「使える情報」に変えるための重要な機能です。 正規表現や置換で柔軟な抽出・変換が可能で、前後・先頭・末尾の文字列削除により不要な情報を除去できます。 本記事を参考にぜひ保存前処理を利用してみてください。   弊社ではZabbix関連サービスを展開しています。以下ページもご参照ください。 ★Zabbixの基礎をまとめたeBookを公開しております！★ Zabbix資料ダウンロード｜SCSK Plus サポート for Zabbix Zabbix監視構築に必要な知識と最新機能についての資料をダウンロードできるページです。世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします。 www.scsk.jp   ★SCSK Plus サポート for Zabbix★ SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします。 www.scsk.jp   ★SCSK Zabbixチャンネル★ SCSK Zabbixチャンネル SCSK Zabbixチャンネルでは、最新のZabbixトレンドや実際の導入事例を動画で解説。明日から使える実践的なノウハウを提供します。 今すぐチャンネル登録して、最新情報を受け取ろう！ www.youtube.com

こんにちは、ひるたんぬです。 この度「 AWS re:Invent 2025 」に参加できることになりましたので、現地での出来事や参加したセッションについてのレポートをお送りしたいと思います！ 今回は、二日目の出来事を振り返ります！ 今回の記事も比較的写真が多めの記事となります。ご了承くださいませ。 Day 2 Day 2からは毎日KeyNoteというセッションが開催されます。 そのため、二日目はKeyNoteの聴講からスタートです。 Opening Keynote with Matt Garman KeyNoteでは、AWSにおける新サービスやアップデートなどが数多く紹介されます。 初回のKeyNoteはAWSのCEOであるMatt Garman氏によるKeyNoteです。 本記事では、KeyNoteの具体的な内容には触れません。 ▼ 講演会場オープン時。非常に多くの方で賑わっています。 ▼ DJが会場を盛り上げています。こちらはAWS Summitでも見られる光景ですね。 ▼ Matt Garman氏登場。 上の画像は、Ambassadorの木澤さんよりいただきました。 （前方に座れるのは羨ましいですね…！） ▼ 様々な発表がありました。 コンテンツの内容に応じて、会場が一体となり盛り上がる様子は写真や映像では表現しがたいものがあります。 KeyNoteを聞いてみて、個人的には 今回は「Why not – ?」、日本語で表現すると「〜しませんか？」というテーマがあると思った。 AWSはすべてのステークホルダー（AWS利用者・サービス提供者・パートナーなど）と共創していく、という姿勢を強く感じた。 生成AIを利活用するベネフィットとして「睡眠時間の確保」を挙げていた点が特徴的に感じた。 という感想を持ちました。特に3つ目については、（私が想像する）一般的なベネフィットである「人間が人間にしかできない創造的なことをする時間に充てられる」という視点と異なるものだったので、新鮮な印象を受けました。（ステークホルダーの一員である開発者を大切にする姿勢、といったところでしょうか。。） SWAG回収・Expo巡り AWS re:Inventの特徴の一つといえばSWAGの豪華さ・多さもあるのではないでしょうか。（経験者の多くはスーツケースを半分空けるようおっしゃっているので…） そのため、Day 2の残りはSWAGの回収とAWSやパートナーなどが出展しているExpoを巡りました。 ▼ SWAGの受け取り。日を改めると新しいSWAGに出会えるかも…？ こちらはAWSが開催する「/dev/quest」による景品受け取り時です。 「/dev/quest」の詳細は、以下記事をご覧ください。 AWS Builder Center Connect with builders who understand your journey. Share solutions, influence AWS product development, and access useful... builder.aws.com ▼ 受け取ったSWAGの一例。 「Quack the Code」の帽子は、海外の方に頻繁に話しかけられる・イジられるなど好評でした。 ▼ 実際に言われたセリフ例   Like the hat! ※ 5人くらいに全く同じことを言われました。   Quack! Quack! ※ メガホンを持ったAWSスタッフに… Expoでは、日本では一度も見たことがない企業による出展や、各社の提供するサービスの強みを熱心に説明している姿が印象的でした。 また、一部のブースでは日本語にて説明を受けることができ、英語ができないから何も分からない・楽しめない、という心配は無さそうでした。 日本語対応可能な方の服には、日本国旗が貼り付けられていました。 ※ 実際に「日本語対応可能な方＝日本国旗が貼り付けられている」というルールがあるかは確認をしていません。 ▼ Expo入口。入る前からワクワクが止まりません。 ▼ 展示の一部。こちらの方々は、AWSのデータセンターをVRでツアーされています。 ▼ ラスベガスでは直近でF1レースが開催されていたこともあり、それにちなんだ展示も。 コースはラスベガス市街でした。本物のF1レースのコースと同じなのでしょうか…？ House of Kiro体験 今年のre:Inventに突如現れ話題となっている「House of Kiro」にもお邪魔してきました。 こちらは何かサービスの紹介があるというものではなく、コンセプトを楽しむアトラクションの一つでした。 ▼ 今にも「何か」が出そうな外観。出て欲しくないけど出て欲しい…？ ▼ 無事に生還できました！楽しかった！！ Golden Jacket受け取り 今回のre:Inventでは、会期前にAWS認定資格をすべて取得した方向けにGolden Jacket（通称「金ジャケ」）が渡される「AWS re:Invent 2025 Golden Jacket Program」がありました。 私は、今回上記参加資格をなんとか満たすことができたので、受け取りをしました。 ▼ いただいたGolden Jacketが入っている箱。重厚感がありますね。 ▼ 認定者ラウンジにて。受け取った方はここで写真を撮られていることが多かったです！ Japan Night 最後はre:Invent Japan Tour参加者（及びJapan Night申込者）が参加できる、Japan Nightというイベントに参加してきました。 こちらは主に日本から参加している方の交流が目的とされたイベントとなっており、用意されていたイベントを通じて多くの方と会話することができました。 ▼ 今回はボウリング場を貸し切って行われました。 ▼ 用意されたイベントの一つはラスベガスらしく？コミュニケーションポーカーというオリジナルゲームでした。 ▼ 会場の方と積極的にコミュニケーションを取り、気がついたら「ロイヤルストレートフラッシュ（一等）」に。 豪華な景品をいただきました！ 終わりに 二日目からはKeyNoteが始まり、SWAGやExpo巡りなど、re:Inventならではのイベントを満喫することができました！ また、帽子を通じて外国人の方とさりげないコミュニケーションを取れたのは良い思い出です。 次回以降の投稿も引き続きお楽しみに！

本記事は TechHarmony Advent Calendar 2025 12/3付の記事です 。 こんにちは。SCSKの曽我です。 Zabbixの監視テンプレートを作るの大変と思われている方に送るTipsです。 テンプレートとは？ テンプレートは、以下のセットです。 ・アイテム（監視したい項目。例えばCPU使用率など） ・トリガー（異常検知とする条件の設定。例えば、CPUが90％以上で異常とするなど） ・グラフ（アイテムで収集した値をグラフ化します） ・ダッシュボード（ダッシュボードでは、グラフや一覧などダッシュボードに表示したい項目を設定） ・ローレベルディスカバリルール （ディスクやネットワークインターフェースなど環境により複数あるような場合に、どの情報をもとに複数あることを認識し、 それによりアイテムやトリガーを設定） ・ウェブシナリオ（Webを監視する際のURLや監視方法を指定） このテンプレートを使用することで、例えば同じ機種のネットワークスイッチであれば、同じテンプレートを適用するだけで 監視をすることができます。 テンプレート以外に、直接ホストの監視設定を入れることもできますが、メンテナンス性が悪いため、理由がない限りは お勧めできません。 標準搭載テンプレート Zabbixをインストールすると標準で多くのテンプレートが搭載されています。 以下、テンプレートです。全部で323個（Zabbix7.0）あります。 1 Acronis Cyber Protect Cloud by HTTP 2 Acronis Cyber Protect Cloud MSP by HTTP 3 AIX by Zabbix agent 4 Alcatel Timetra TiMOS by SNMP 5 Apache ActiveMQ by JMX 6 Apache by HTTP 7 Apache by Zabbix agent 8 Apache Cassandra by JMX 9 Apache Kafka by JMX 10 Apache Tomcat by JMX 11 APC Smart-UPS 2200 RM by SNMP 12 APC Smart-UPS 3000 XLM by SNMP 13 APC Smart-UPS RT 1000 RM XL by SNMP 14 APC Smart-UPS RT 1000 XL by SNMP 15 APC Smart-UPS SRT 5000 by SNMP 16 APC Smart-UPS SRT 8000 by SNMP 17 APC UPS by SNMP 18 APC UPS Galaxy 3500 by SNMP 19 APC UPS Symmetra LX by SNMP 20 APC UPS Symmetra RM by SNMP 21 APC UPS Symmetra RX by SNMP 22 Aranet Cloud 23 Arista by SNMP 24 Asterisk by HTTP 25 AWS by HTTP 26 AWS Cost Explorer by HTTP 27 AWS EC2 by HTTP 28 AWS ECS Cluster by HTTP 29 AWS ECS Serverless Cluster by HTTP 30 AWS ELB Application Load Balancer by HTTP 31 AWS ELB Network Load Balancer by HTTP 32 AWS Lambda by HTTP 33 AWS RDS instance by HTTP 34 AWS S3 bucket by HTTP 35 Azure by HTTP 36 Azure Cosmos DB for MongoDB by HTTP 37 Azure Cost Management by HTTP 38 Azure Microsoft SQL Database by HTTP 39 Azure Microsoft SQL Serverless Database by HTTP 40 Azure MySQL Flexible Server by HTTP 41 Azure MySQL Single Server by HTTP 42 Azure PostgreSQL Flexible Server by HTTP 43 Azure PostgreSQL Single Server by HTTP 44 Azure Virtual Machine by HTTP 45 Azure VM Scale Set by HTTP 46 Brocade FC by SNMP 47 Brocade_Foundry Nonstackable by SNMP 48 Brocade_Foundry Stackable by SNMP 49 Ceph by Zabbix agent 2 50 Chassis by IPMI 51 Check Point Next Generation Firewall by SNMP 52 Cisco ASAv by SNMP 53 Cisco Catalyst 3750V2-24FS by SNMP 54 Cisco Catalyst 3750V2-24PS by SNMP 55 Cisco Catalyst 3750V2-24TS by SNMP 56 Cisco Catalyst 3750V2-48PS by SNMP 57 Cisco Catalyst 3750V2-48TS by SNMP 58 Cisco IOS by SNMP 59 Cisco IOS prior to 12.0_3_T by SNMP 60 Cisco IOS versions 12.0_3_T-12.2_3.5 by SNMP 61 Cisco Meraki dashboard by HTTP 62 Cisco Meraki device by HTTP 63 Cisco Meraki organization by HTTP 64 Cisco Nexus 9000 Series by SNMP 65 Cisco SD-WAN by HTTP 66 Cisco SD-WAN device by HTTP 67 Cisco UCS by SNMP 68 Cisco UCS Manager by SNMP 69 ClickHouse by HTTP 70 Cloudflare by HTTP 71 CockroachDB by HTTP 72 Control-M enterprise manager by HTTP 73 Control-M server by HTTP 74 D-Link DES 7200 by SNMP 75 D-Link DES_DGS Switch by SNMP 76 Dell Force S-Series by SNMP 77 Dell iDRAC by SNMP 78 DELL PowerEdge R720 by HTTP 79 DELL PowerEdge R720 by SNMP 80 DELL PowerEdge R740 by HTTP 81 DELL PowerEdge R740 by SNMP 82 DELL PowerEdge R820 by HTTP 83 DELL PowerEdge R820 by SNMP 84 DELL PowerEdge R840 by HTTP 85 DELL PowerEdge R840 by SNMP 86 Docker by Zabbix agent 2 87 Elasticsearch Cluster by HTTP 88 Envoy Proxy by HTTP 89 Etcd by HTTP 90 Extreme EXOS by SNMP 91 F5 Big-IP by SNMP 92 FortiGate by HTTP 93 FortiGate by SNMP 94 FreeBSD by Zabbix agent 95 GCP by HTTP 96 GCP Cloud SQL MSSQL by HTTP 97 GCP Cloud SQL MSSQL Replica by HTTP 98 GCP Cloud SQL MySQL by HTTP 99 GCP Cloud SQL MySQL Replica by HTTP 100 GCP Cloud SQL PostgreSQL by HTTP 101 GCP Cloud SQL PostgreSQL Replica by HTTP 102 GCP Compute Engine Instance by HTTP 103 Generic Java JMX 104 GitHub repository by HTTP 105 GitLab by HTTP 106 GridGain by JMX 107 Hadoop by HTTP 108 HAProxy by HTTP 109 HAProxy by Zabbix agent 110 HashiCorp Consul Cluster by HTTP 111 HashiCorp Consul Node by HTTP 112 HashiCorp Nomad by HTTP 113 HashiCorp Nomad Client by HTTP 114 HashiCorp Nomad Server by HTTP 115 HashiCorp Vault by HTTP 116 Hikvision camera by HTTP 117 HP-UX by Zabbix agent 118 HP Comware HH3C by SNMP 119 HPE iLO by HTTP 120 HPE MSA 2040 Storage by HTTP 121 HPE MSA 2060 Storage by HTTP 122 HP Enterprise Switch by SNMP 123 HPE Primera by HTTP 124 HPE ProLiant BL460 by SNMP 125 HPE ProLiant BL920 by SNMP 126 HPE ProLiant DL360 by SNMP 127 HPE ProLiant DL380 by SNMP 128 HPE Synergy by HTTP 129 HP iLO by SNMP 130 Huawei OceanStor 5300 V5 by SNMP 131 Huawei VRP by SNMP 132 IBM IMM by SNMP 133 Ignite by JMX 134 IIS by Zabbix agent 135 IIS by Zabbix agent active 136 InfluxDB by HTTP 137 Intel SR1530 IPMI 138 Intel SR1630 IPMI 139 Intel_Qlogic Infiniband by SNMP 140 Jenkins by HTTP 141 Jira Data Center by JMX 142 Juniper by SNMP 143 Kubernetes API server by HTTP 144 Kubernetes cluster state by HTTP 145 Kubernetes Controller manager by HTTP 146 Kubernetes Kubelet by HTTP 147 Kubernetes nodes by HTTP 148 Kubernetes Scheduler by HTTP 149 Linux by Prom 150 Linux by SNMP 151 Linux by Zabbix agent 152 Linux by Zabbix agent active 153 macOS by Zabbix agent 154 Mantis BT by HTTP 155 Mellanox by SNMP 156 Memcached by Zabbix agent 2 157 Microsoft 365 reports by HTTP 158 Microsoft Exchange Server 2016 by Zabbix agent 159 Microsoft Exchange Server 2016 by Zabbix agent active 160 Microsoft SharePoint by HTTP 161 Mikrotik by SNMP 162 MikroTik CCR1009-7G-1C-1S+ by SNMP 163 MikroTik CCR1009-7G-1C-1S+PC by SNMP 164 MikroTik CCR1009-7G-1C-PC by SNMP 165 MikroTik CCR1016-12G by SNMP 166 MikroTik CCR1016-12S-1S+ by SNMP 167 MikroTik CCR1036-8G-2S+ by SNMP 168 MikroTik CCR1036-8G-2S+EM by SNMP 169 MikroTik CCR1036-12G-4S-EM by SNMP 170 MikroTik CCR1036-12G-4S by SNMP 171 MikroTik CCR1072-1G-8S+ by SNMP 172 MikroTik CCR2004-1G-12S+2XS by SNMP 173 MikroTik CCR2004-16G-2S+ by SNMP 174 MikroTik CRS106-1C-5S by SNMP 175 MikroTik CRS109-8G-1S-2HnD-IN by SNMP 176 MikroTik CRS112-8G-4S-IN by SNMP 177 MikroTik CRS112-8P-4S-IN by SNMP 178 MikroTik CRS125-24G-1S-2HnD-IN by SNMP 179 MikroTik CRS212-1G-10S-1S+IN by SNMP 180 MikroTik CRS305-1G-4S+IN by SNMP 181 MikroTik CRS309-1G-8S+IN by SNMP 182 MikroTik CRS312-4C+8XG-RM by SNMP 183 MikroTik CRS317-1G-16S+RM by SNMP 184 MikroTik CRS326-24G-2S+IN by SNMP 185 MikroTik CRS326-24G-2S+RM by SNMP 186 MikroTik CRS326-24S+2Q+RM by SNMP 187 MikroTik CRS328-4C-20S-4S+RM by SNMP 188 MikroTik CRS328-24P-4S+RM by SNMP 189 MikroTik CRS354-48G-4S+2Q+RM by SNMP 190 MikroTik CRS354-48P-4S+2Q+RM by SNMP 191 MikroTik CSS326-24G-2S+RM by SNMP 192 MikroTik CSS610-8G-2S+IN by SNMP 193 MikroTik FiberBox by SNMP 194 MikroTik hEX by SNMP 195 MikroTik hEX lite by SNMP 196 MikroTik hEX PoE by SNMP 197 MikroTik hEX PoE lite by SNMP 198 MikroTik hEX S by SNMP 199 MikroTik netPower 15FR by SNMP 200 MikroTik netPower 16P by SNMP 201 MikroTik netPower Lite 7R by SNMP 202 MikroTik PowerBox by SNMP 203 MikroTik PowerBox Pro by SNMP 204 MikroTik RB260GS by SNMP 205 MikroTik RB260GSP by SNMP 206 MikroTik RB1100AHx4 by SNMP 207 MikroTik RB1100AHx4 Dude Edition by SNMP 208 MikroTik RB2011iL-IN by SNMP 209 MikroTik RB2011iL-RM by SNMP 210 MikroTik RB2011iLS-IN by SNMP 211 MikroTik RB2011UiAS-IN by SNMP 212 MikroTik RB2011UiAS-RM by SNMP 213 MikroTik RB3011UiAS-RM by SNMP 214 MikroTik RB4011iGS+RM by SNMP 215 MikroTik RB5009UG+S+IN by SNMP 216 MongoDB cluster by Zabbix agent 2 217 MongoDB node by Zabbix agent 2 218 Morningstar ProStar MPPT by SNMP 219 Morningstar ProStar PWM by SNMP 220 Morningstar SunSaver MPPT by SNMP 221 Morningstar SureSine by SNMP 222 Morningstar TriStar MPPT 600V by SNMP 223 Morningstar TriStar MPPT by SNMP 224 Morningstar TriStar PWM by SNMP 225 MSSQL by ODBC 226 MSSQL by Zabbix agent 2 227 MySQL by ODBC 228 MySQL by Zabbix agent 229 MySQL by Zabbix agent 2 230 NetApp AFF A700 by HTTP 231 NetApp FAS3220 by SNMP 232 Netgear Fastpath by SNMP 233 Network Generic Device by SNMP 234 Nextcloud by HTTP 235 Nginx by HTTP 236 Nginx by Zabbix agent 237 NGINX Plus by HTTP 238 OpenBSD by Zabbix agent 239 OpenStack by HTTP 240 OpenStack Nova by HTTP 241 OpenWeatherMap by HTTP 242 OPNsense by SNMP 243 Oracle by ODBC 244 Oracle by Zabbix agent 2 245 Oracle Cloud Autonomous Database by HTTP 246 Oracle Cloud Block Volume by HTTP 247 Oracle Cloud Boot Volume by HTTP 248 Oracle Cloud by HTTP 249 Oracle Cloud Compute by HTTP 250 Oracle Cloud Networking by HTTP 251 Oracle Cloud Object Storage by HTTP 252 OS processes by Zabbix agent 253 PFSense by SNMP 254 PHP-FPM by HTTP 255 PHP-FPM by Zabbix agent 256 PostgreSQL by ODBC 257 PostgreSQL by Zabbix agent 258 PostgreSQL by Zabbix agent 2 259 Proxmox VE by HTTP 260 QTech QSW by SNMP 261 RabbitMQ cluster by HTTP 262 RabbitMQ cluster by Zabbix agent 263 RabbitMQ node by HTTP 264 RabbitMQ node by Zabbix agent 265 Redis by Zabbix agent 2 266 Remote Zabbix proxy health 267 Remote Zabbix server health 268 SMART by Zabbix agent 2 269 SMART by Zabbix agent 2 active 270 Solaris by Zabbix agent 271 Squid by SNMP 272 Supermicro Aten by SNMP 273 Systemd by Zabbix agent 2 274 Template Module Cisco CISCO-ENVMON-MIB SNMPv2 275 Template Module Cisco CISCO-MEMORY-POOL-MIB SNMPv2 276 Template Module Cisco CISCO-PROCESS-MIB SNMPv2 277 Template Module Cisco Inventory SNMPv2 278 Template Module EtherLike-MIB SNMPv2 279 Template Module Generic SNMPv2 280 Template Module ICMP Ping 281 Template Module Interfaces SNMPv2 282 TiDB by HTTP 283 TiDB PD by HTTP 284 TiDB TiKV by HTTP 285 TP-LINK by SNMP 286 Travis CI by HTTP 287 TrueNAS CORE by SNMP 288 Ubiquiti AirOS by SNMP 289 Veeam Backup and Replication by HTTP 290 Veeam Backup Enterprise Manager by HTTP 291 VMware 292 VMware FQDN 293 VMware Guest 294 VMware Hypervisor 295 VMWare SD-WAN VeloCloud by HTTP 296 Website by Browser 297 Website certificate by Zabbix agent 2 298 WildFly Domain by JMX 299 WildFly Server by JMX 300 Windows by SNMP 301 Windows by Zabbix agent 302 Windows by Zabbix agent active 303 YugabyteDB by HTTP 304 YugabyteDB Cluster by HTTP 305 Zabbix agent 306 Zabbix agent active 307 Zabbix proxy health 308 Zabbix server health 309 Zookeeper by HTTP 310 ZYXEL AAM1212-51 IES-612 by SNMP 311 ZYXEL ES3500-8PD by SNMP 312 ZYXEL GS-4012F by SNMP 313 ZYXEL IES-500x by SNMP 314 ZYXEL IES-6000 by SNMP 315 ZYXEL IES1248-51 by SNMP 316 ZYXEL MES-3528 by SNMP 317 ZYXEL MES3500-10 by SNMP 318 ZYXEL MES3500-24 by SNMP 319 ZYXEL MES3500-24S by SNMP 320 ZYXEL MGS-3712 by SNMP 321 ZYXEL MGS-3712F by SNMP 322 ZYXEL MGS3520-28x by SNMP 323 ZYXEL XGS-4728F by SNMP 標準のテンプレートがない時は？ 標準のテンプレート内にない時は、作らないといけないのですが、その前に ここをチェックしてください。 Zabbix Integrations and Templates 公式Zabbix監視テンプレートとインテグレーションを集めました。 www.zabbix.com ここには監視テンプレートや通報時に使用するメディアタイプ（Teams、Slack連携など）もあります。 例えば、HPEのテンプレートは標準でもいくつかあるのですが、3Parのテンプレートをダウンロードしたい場合は、 検索する際のテキストボックスに検索したい文字列を入れていきます。 今回は、オフィシャルではなく、Community（有志が作成）したテンプレートを使っていきますので 下のHPE 3PAR SMI0S for shareZabbixをクリックします。 ダウンロードしたい機種を選択します。 Compatibilityに5.0+とあるので、Zabbix5.0以上であれば利用できそうです。 Github上に公開されているので、6.0をクリックします。 README.mdでテンプレートの使い方を確認して、template_hp_3par.yamlをクリックします。 ダウンロードします。 あとは、ダウンロードしたテンプレートをインポートするだけです。 インポート！ 無事インポートが行われました。   最後に Zabbixは、オープンソースソフトウェア（OSS）かつ世界中で利用されており、多くの情報が インターネット上で公開されているので、是非活用してください。 また、もし公開できるような情報があれば、発信してみてはいかがでしょうか？ 参考 弊社ではZabbix関連サービスを展開しています。以下ページもご参照ください。 ★SCSK Plus サポート for Zabbix★ SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします。 www.scsk.jp ★YouTubeに、SCSK Zabbixチャンネルを開設しました！★ SCSK Zabbixチャンネル SCSK Zabbixチャンネルでは、Zabbixのトレンドや実際の導入事例を動画で解説。明日から使える実践的な操作ナレッジも提供しており、監視業務の効率化に役立つヒントが満載です。 最新のトピックについては、リンクの弊社HPもしくはXアカ... www.youtube.com ★Xに、SCSK Zabbixアカウントを開設しました！★ https://X.com/SCSK_Zabbix X.com

こんにちは、ひるたんぬです。 この度「 AWS re:Invent 2025 」に参加できることになりましたので、現地での出来事や参加したセッションについてのレポートをお送りしたいと思います！ 今回は、初日の出来事を振り返ります！ Day 1 AWS re:Inventでは各セッションが開かれるホテルにて、朝食（と昼食）が提供されます。 今回は次のセッション会場に近いMGM Grand Hotelで食べることにしました。 初参加で会場も広いため、迷わないかがとても心配でしたが、とても多くのスタッフの方の案内もあり、迷うことなく会場まで朝食会場までたどり着くことができました。 ▼ 朝食会場 @MGM Grand Hotel ▼ 個人的には右上のパイ？がお気に入りでした。様々な事項に配慮した食事も。 栄養補給も終えたところで最初のセッションです。 The Frugal Architect GameDay 初っ端からGameDayへの参加です！ 今回のGameDayは二人一組で取り組む内容だったので、日本から参加していた方と一緒にペアになりました。 題名にもなっている「The Frugal Architect」とは、AWSのCTOであるWerner氏が提唱しているアーキテクトです。 直訳すると「倹しいアーキテクト」といったところでしょうか。 最初の説明を聞くに、コストを意識したアーキテクチャを構築するために必要な規則（Law）をまとめたもののようです。 実際の各規則については、下記ブログをご参照ください。 Achieving Frugal Architecture using the AWS Well-Architected Framework guidance | Amazon Web Services As part of the re:Invent 2023 keynote, Dr. Werner Vogels introduced the Frugal Architect mindset. This mindset emphasize... aws.amazon.com 既存のアーキテクチャをどのようにしてコスト削減していくか、そのアプローチに有用なAWSサービスは何かを学ぶことができ、個人的に普段意識が薄れているコストに関する視点やそのアプローチ方法を学ぶことができました。 ▼ 実際にWerner氏が登場し、ざわつく会場 そして気がついたらあっという間に二時間。私たちのチームの結果は… なんと3位入賞を果たすことができました！🎉 ▼ 入賞時の写真 ▼ いただいた景品（Werner氏のサインも…！） この他にも同じテーブルにいた方と交流を深めることができ、非常に充実した時間となりました。 ▼ 同テーブルで仲良くなったカナダ在住の方と 上記の写真に写っている皆様には、個別に掲載許可をいただきました。 It was so much fun hanging out with everyone. Thank you for the wonderful memories! AWS Jam: DevOps & Modernization 続いてはAWS Jamに参加しました！ AWS GameDayとAWS Jamは似たようなものと言われており、私自身でその違いを見出したい、というのも参加の動機です。 （AWS Jamは今回が初参加でした。） 「LaunchDarkly」が提供するセッションとなっており、LaunchDarklyならではの問題や、DevOpsに関する数多くのトラブルシューティングを体験することができました。CodePipelineやコンテナに関する問題もありましたが、問題の解決にAmazon Q Developerを使うよう指定があったほか、Strands Agentsに触れる機会があるなど、生成AI利活用を見据えた問題も多くあることが印象的でした。 また、GameDayとJamに参加して私が感じた両者の違いをまとめました。 AWS GameDay 一つのシナリオ に対して複数の問題が設定 → それぞれの 問題に何らかの関係性がある 一つのAWSアカウント内 で問題解決を試行 問題に対して、 明示的な難易度設定はない AWS Jam 複数の独立したテーマ に対して、複数の問題が設定 → テーマをまたいだ 問題には関連性が存在しない テーマごとにAWSアカウントが独立している 各テーマごとに「Easy」「Medium」「Hard」などと 難易度が設定 → 難易度によって獲得できる点数が異なる 勝敗の付け方（獲得した得点数）や、ヒント使用による減点などのルールは共通していることから、どちらかを一回でも経験していれば違和感なく取り組めるかなと思いました。ただ、GameDayとJamでは、勝利するための戦略は大きく異なりそうだな、と感じた次第です。（この点は要研究ですね…） 個人的に引っかかったのは、上記の二点目です。 GameDayの感覚で同じコンソール内で解こうとすると、リソースがなかったり権限不足のエラーが出たりするので、毎テーマごとにそのテーマで用意されているコンソールに入り直す必要がありました。チーム内の方も同じように引っかかっていました… なお、とても個人的な感想になりますが、チームの外国人の方に質問を受けた際に、（拙い）英語を使って一緒に問題を解決しハイタッチできたのは良い経験でした。 解決した問題はLambdaのウォームスタート・コールドスタートにおけるグローバル変数の取り扱いでした。 以前何となく見ていた知識が役に立ってとても嬉しかったです。 Lambda 実行環境のライフサイクルの概要 - AWS Lambda Lambda は、実行環境で関数を呼び出します。これにより、安全で分離されたランタイム環境が提供されます。 docs.aws.amazon.com ▼ 実際に取り組んでいる会場内。非常に多くの方が参加されていました。 ▼ 今回いただいた参加賞。初めてJamのステッカーを手に入れることができました。 終わりに 初日はKeyNoteがないことからチーム解決型セッションへの参加を重視しましたが、自身が普段の業務では触れることのないサービスを体験できたり、外国人の方とのコミュニケーションを楽しめたりと充実した一日を送ることができました！ 次回以降の投稿も引き続きお楽しみに！

本記事は TechHarmony Advent Calendar 2025 12/2付の記事です 。 こんにちは、クラウドサービス関連の業務をしている藪内です。 本記事では、AWS 最大規模のイベント 「re:Invent」 のセッション内容と、AWS と量子コンピューティングの関連情報について AWS 入門者として調査した経験談をご紹介します！ 今回の記事は TechHarmony のアドベントカレンダー企画 2 日目の投稿（1 日につき最大 2 つの記事）です🎅 2025年12月1日 〜 12月6日に、ラスベガスで re:Invent という AWS の大規模カンファレンスが開催されています。   最近までこのイベントを知らず、イベント名を聞いた際に「re:Invent とは…？」と疑問に思いました。 また、イベントで行われるセッションの内容を見ても、知らない専門用語が多いために理解できず困ってしまいました。 そこで、セッションの特定のトピック（ 量子コンピューティング ）と AWS に関連する情報を調べていきました。すると、その内容に関しては概要をつかみ始めることができました。 この経験談と調査した内容をまとめて紹介していきたいと思います！   AWS re:Invent とは？ 「re:Invent」と聞いて、まずは検索エンジンで 「AWS re:Invent」 と調べてみました。 以下が re:Invent の概要です。   AWS re:Invent とは？ AWS に関する画期的な講演や実践的な技術セッションなどが 1 週間にわたって行われる最大規模のイベントです。 世界中から AWS コミュニティが集まり 、入門者から熟練の専門家までが スキルレベルに合ったハンズオン に取り組めたり、 AWS サービスに関する最新の発表 を聞くことができたりします。 期間 2025年12 月1日から 12月5日まで 場所 アメリカ合衆国ネバダ州ラスベガス セッション数 2710 個以上 開催形態 対面あるいはライブ配信、オンデマンド 公式サイト AWS re:Invent 2025 | December 1 – 5, 2025 Build the future with us at AWS re:Invent, Dec 1 – 5, 2025 in Las Vegas, NV. Learn new skills, take home proven strategi... reinvent.awsevents.com   セッション内容の解読に至った背景 re:Invent の公式サイトには、実施されるセッションの概要を見ることができる Event Catalog があります。 Event Catalog の画面 公式サイトを初めて見た際に、まずは Event Catalog を見たのですが、 以下の 3 つの特徴 から読み取ることができず困ってしまいました。 公式サイトは 英語で作成 されている セッションが 2710 個以上 と多数あり、どれから見たらいいかわからない 知らない専門用語 が多く書かれている 以下に本記事で扱う「量子コンピューティング」に関連するセッション概要の例を 2 つ載せています。 セッションの概要は英語で書かれていますが、Google 翻訳を活用して日本語訳しました。 Building Quantum-Safe Systems with Post-Quantum Cryptography on AWS (SEC404)   AWS の最新のポスト量子暗号機能を用いて、量子コンピューティング時代に向けたシステムを準備する方法を学びましょう。このハンズオンワークショップでは、AWS KMS と ML-DSA および ML-KEM を用いたポスト量子暗号鍵管理の実装、AWS プライベート認証局を用いたポスト量子暗号証明書のデプロイ、ハイブリッドポスト量子暗号 TLS ハンドシェイクの分析を行います。実践的な演習を通して、ポスト量子暗号アルゴリズムと従来のアルゴリズムのベンチマークを行い、ポスト量子暗号プロトコルを用いた安全なファイル転送を実装します。AWS サービスを用いたポスト量子暗号の実装に関する具体的な経験と、アプリケーションのパフォーマンスへの影響について理解を深めることができます。 Quantum Computing with Amazon Braket: From Exploration to Enterprise (CMP411)   Amazon Braket を通して、量子コンピューティングという新たな分野を探求しませんか。このセッションでは、AWSの量子コンピューティング戦略と最新のサービス機能の概要を説明し、組織が従来のコンピューティングワークロードと並行して量子アルゴリズムの実験を開始する方法を紹介します。上級技術リーダーやビジネスリーダーは、現在の量子コンピューティング機能、実験アプローチ、そして将来の量子コンピュータがHPCシステムとどのように統合されるかについて、明確な理解を得ることができます。 なお、英語で作成されている点に関しては、翻訳機能で対応できました。 しかし、残りの 2 つの特徴によってセッション内容が、 まるで暗号のように 感じたままでした。   セッションが 2710 個以上 と多数あり、どれから見たらいいかわからない 知らない専門用語 が多く書かれている そこで、以下の順で解読することにしました。   特定のトピックでセッションに限定する そのトピックについて AWS の関連情報を収集する セッション概要を読み直す   特定のトピック「量子コンピューティング」 1. の特定のトピックは 「量子コンピューティング」 にしました。 特定のトピックを選ぶにあたって、従来の暗号アルゴリズムは量子コンピュータによって突破されるリスクがあり、機密情報の保護に課題があるという話題が思い浮かびました。この話題の最新性から、AWS re:Invent では、実際に量子コンピューティングに関するどのような最新情報が得られるのか興味を持ち、「量子コンピューティング」を選択しました。 量子コンピューティングとは、量子力学の原理を利用して従来のコンピュータでは困難だった複雑な計算を高速かつ効率的に解く技術分野です。 より詳しく説明したいのですが、本記事では省略します。 具体的な作業として、特定のトピックに限定するために Event Catalog のフィルター機能を用いました。 「quantum」 というキーワードで Event Catalog をフィルタリングすると、関連セッション数は 25 個程度に絞り込めました。 量子コンピューティングと AWS の関連情報のまとめ 次に、セッション概要を読み取るために、量子コンピューティングと AWS の関連情報を調べることにしました。 この章では、調べる中で発見した 過去の re:Invent での発表や関連ニュース、アップデート情報について 紹介したいと思います。 過去の re:Invent での発表 過去の re:Invent では、量子コンピューティングに関してどのような発表がされたのかを調べてみました。 2019 年の同イベントでは、量子コンピューティングサービスである 「Amazon Braket」 が発表されました。 このサービスは研究者や科学者、開発者が量子アルゴリズムを簡単に構築・実行可能なサービスです。 Amazon Braket では、量子アルゴリズムの実装のトラブルシューティングと検証に役立つシミュレーションを利用することができます。 Amazon Braket のアイコン また、昨年度の同イベントでは以下のセッションがありました。 AWS における量子コンピューティングの取り組みについて 量子コンピュータによる攻撃に耐える安全なアルゴリズム（ ポスト量子暗号 ）について 太字で書いている「ポスト量子暗号」は AWS の関連ニュースやアップデート情報にも登場しており、非常に重要な用語です。 量子コンピューティングと AI の組み合わせについて NVIDIA CUDA-Q 環境と Amazon Braket の統合について これらの発表は、Web 記事で日本語でまとめられており、大変参考になります。 AWS の関連ニュース 今年 2025 年の量子コンピューティングと AWS の関連ニュースを 2 つ紹介します。 ポスト量子暗号の移行計画を AWS ブログで発表（2025/02/12）[1] 通信プロトコルとデジタル署名で用いられている既存の公開鍵暗号アルゴリズムは、大規模な量子コンピュータによって解読できる可能性があります。 これに対して、AWSのポスト量子暗号への移行がどこまで進んでいるのかと今後の多層的な移行について発表されていました。具体的な中身としては、暗号化サービスやデジタル署名へのポスト量子アルゴリズムの導入などが書かれています。 暗号化のイメージ図 新しい量子チップ「Ocelot」の開発（2025/03/14）[2] AWSが新しい量子コンピューティングチップを開発しました。 量子コンピューティングは高い演算性能を持つ一方で、振動や熱、電磁干渉のわずかなノイズに敏感な特性を持っています。 そのため、複雑な計算をエラーなく、高い信頼性で実行できる量子コンピュータが求められています。 AWS はエラーの訂正を最優先としたアーキテクチャを設計し、エラー訂正のコストを最大 90% 削減可能な量子チップ 「Ocelot」 を発表しました。 AWS アップデート情報 AWS アップデート情報の中で量子コンピューティングに関連するものを 2 つ紹介します。 AWS の関連ニュースで紹介したポスト量子暗号計画に記載があったように、ポスト量子暗号をへの移行に関連したアップデートが発表されていました。 AWS KMS がポスト量子 ML-DSA デジタル署名のサポートを追加（2025/06/13）[3] AWS KMS が NIST（National Institute of Standards and Technology、米国国立標準技術研究所）によって標準化された量子コンピューティングによる解読に耐性があるデジタル署名アルゴリズムのサポートを新たに開始しました。量子コンピュータによる暗号解読から機密情報を保護する機能が導入されていることが確認できます。 Amazon CloudFront において、ポスト量子をサポートする TLS セキュリティポリシーがリリース（2025/09/05）[4] Amazon CloudFront における既存の TLS セキュリティポリシーで、従来のアルゴリズムとポスト量子アルゴリズムを組み合わせたハイブリッドなキー確立がサポートされるようになりました。 AWS では今後もポスト量子暗号の導入と関連サービスのアップデートが継続して発表されていくと考えられます。   セッション概要に戻る 以上の量子コンピューティングと AWS の関連情報のまとめを調べた上で、セッション概要を再度確認しました。 Building Quantum-Safe Systems with Post-Quantum Cryptography on AWS (SEC404) AWS の最新の ポスト量子暗号機能 を用いて、量子コンピューティング時代に向けたシステムを準備する方法を学びましょう。このハンズオンワークショップでは、 AWS KMS と ML-DSA および ML-KEM を用いたポスト量子暗号鍵管理の実装 、AWS プライベート認証局を用いた ポスト量子暗号証明書 のデプロイ、 ハイブリッドポスト量子暗号 TLS ハンドシェイクの分析を行います。実践的な演習を通して、 ポスト量子暗号アルゴリズムと従来のアルゴリズム のベンチマークを行い、 ポスト量子暗号プロトコルを用いた安全なファイル転送 を実装します。AWS サービスを用いたポスト量子暗号の実装に関する具体的な経験と、アプリケーションのパフォーマンスへの影響について理解を深めることができます。 Quantum Computing with Amazon Braket: From Exploration to Enterprise (CMP411) Amazon Braket を通して、 量子コンピューティング という新たな分野を探求しませんか。このセッションでは、 AWSの量子コンピューティング戦略と最新のサービス機能の概要 を説明し、組織が従来のコンピューティングワークロードと並行して量子アルゴリズムの実験を開始する方法を紹介します。上級技術リーダーやビジネスリーダーは、現在の量子コンピューティング機能、実験アプローチ、そして将来の量子コンピュータがHPC システムとどのように統合されるかについて、明確な理解を得ることができます。 ※Google 翻訳によって元の英文を日本語化しています。 すると、 太字で表示している単語 がわかるようになっており、 概要をある程度解読できるようになっていました！ また、調べた関連情報の内容が含まれており、 興味も増えていました。 これらによって、聞きたいセッションを内容で選ぶことができる状態になっていました。 この経験から、AWS入門者でも特定のトピックでセッションを絞り込み、関連情報を調べることで、re:Invent を活用し、ほかのトピックの最新情報も得ることができると感じました！   まとめ 本記事では、AWS 最大級のイベント「re:Invent」の膨大なセッション数と専門性の高い内容について、 AWS 入門者が “解読” した体験と量子コンピューティングに関する AWS の関連情報 を紹介しました。 「特定のトピックでセッションを限定する」「そのトピックについて AWS の関連情報を収集する」「セッション概要を読み直す」という 3 ステップ で取り組みました。これらによって、AWS 入門者でも re:Invent の内容を掴み、興味を持って積極的に情報収集ができるようになると考えています。 量子コンピューティングを例に取り上げましたが、このアプローチは量子コンピューティングに限らず、AI や セキュリティ、ネットワークなど幅広いトピックにも応用可能であると考えています。 また、学習したいセッションの選択はトピックだけでなく、専門度合いやセッションの紹介記事も参考になります。 re:Invent は量子コンピューティング以外にも多くの革新技術・最新トレンドを網羅しているため、re:Invent を情報収集の場として活用していきたいと思います。 作業の流れ 参考スライド 今回の内容については、スライドを用いて発表する機会があったため、参考としてスライドを載せておきます。 参考文献 [1] Amazon Web Services ブログ (2025)「AWS ポスト量子暗号への移行計画」. https://aws.amazon.com/jp/blogs/news/aws-post-quantum-cryptography-migration-plan/ , (2025/11/19). [2] About Amazon Japan (2025)「AWSが新しい量子コンピューティングチップを発表」. https://www.aboutamazon.jp/news/aws/quantum-computing-aws-ocelot-chip , (2025/11/19). [3] AWS (2025)「AWS KMS がポスト量子 ML-DSA デジタル署名のサポートを追加」. https://aws.amazon.com/jp/about-aws/whats-new/2025/06/aws-kms-post-quantum-ml-dsa-digital-signatures/ , (2025/12/01). [4] AWS (2025)「Amazon CloudFront においてポスト量子をサポートする TLS セキュリティポリシーがリリース」. https://aws.amazon.com/jp/about-aws/whats-new/2025/09/amazon-cloudfront-TLS-policy-post-quantum-support/ , (2025/12/01).  

本記事は TechHarmony Advent Calendar 2025 12/2付の記事です 。 こんにちは！SCSKの新沼です。 「システム監視を始めたいけど、Zabbixの環境構築ってなんだか難しそう…」 「Linuxやデータベースの知識があまりなくて、導入に踏み切れない…」 そんな風に感じている方はいらっしゃいませんか？ 本記事では、そんな悩みを解決する「 Zabbix Appliance 」の初期設定方法を、仮想環境での検証を交えて分かりやすくご紹介します！この記事を読めば、驚くほど簡単にZabbixの監視画面にたどり着けますので、ぜひ最後までお付き合いください。   Zabbix Applianceとは？ Zabbix Appliance とは、一言でいうと「 Zabbixをすぐに使える状態で提供する、オールインワン・パッケージ 」です。 通常、Zabbixを動かすには、 OS（Linuxなど） Webサーバー（Apache, Nginxなど） データベース（MySQL, PostgreSQLなど） Zabbix本体 これらをひとつひとつ手動でインストールし、それぞれを連携させるための設定が必要です。 しかし、Zabbix Applianceには、これらすべてが インストール＆設定済み の状態で提供されています。   通常インストールとの違いは？ ここで、「じゃあ、普通にインストールする場合と何が違うの？」という疑問が湧きますよね。 Zabbix Applianceのメリット・デメリットを、通常版と比較してみます。 項目 Zabbix Appliance 通常インストール 導入の手間 ◎ 非常に簡単 △ 手間がかかる 必要な知識 ◎ 少ない △ 多い 導入時間 ◎ 短い △ 長い カスタマイズ性 △ 低い ◎ 高い こんな人におすすめ ・Zabbixをすぐに試したい人 ・環境構築の手間を省きたい人 ・小〜中規模環境で利用したい人 ・特定のOSやDBで構築したい人 ・大規模環境で細かくチューニングしたい人 ・環境構築の経験を積みたい人 このように、Zabbix Applianceは「手軽さ」「速さ」に特化しており、 まずはZabbixを触ってみたいという方に最適 な選択肢です。 それでは実際に、検証環境を用いて、Zabbix仮想Applianceで監視サーバーを立ち上げてみます。   検証環境 今回検証に使用した環境は以下の通りです。 コンポーネント バージョン 備考 Zabbix Zabbix7.0 LTS 2025/11時点での最新の長期サポート版   実践①：Applianceのインストール Step １: Zabbix Appliance のダウンロード Zabbixの検証用仮想Applianceは、以下のURLからダウンロード可能です。 Download Zabbix appliance Download and install the pre-compiled Zabbix appliance. www.zabbix.com こちらにアクセスし、検証用の仮想Applianceのisoファイルをダウンロードします。   Step ２: VMware ESXiへのデプロイ 次に、ダウンロードしたISOファイルを使って仮想マシンを起動します。ご利用の仮想化ソフト（VMware ESXiやProxmoxなど）で新規仮想マシンを作成し、CD/DVDドライブにダウンロードしたISOファイルをセットしてください。 仮想アプライアンスの最大のメリットは、OSのインストールやZabbixの複雑な設定が一切不要なことです。 以下のスペックを目安に仮想マシンを作成し、起動すれば、あとは全自動でインストールが進みます。 名前：  Zabbix-Appliance-ISOなど任意 ゲストOS：  Linux → Debian系 RAM： ４GB以上 vCPU：  2以上 ディスク容量：  ８GB以上 ※ご利用の環境によって詳細な設定手順は異なるため、ここでは割愛しますが、基本的にこれだけでOKです。   Step 3: 仮想マシンの起動とコンソールログイン デプロイが完了すると、自動的に仮想マシンがパワーオンされます。作成された仮想マシンを選択し、「コンソール」を開いてみましょう。 黒い画面にログインプロンプトが表示されれば成功です！ 以下の初期ユーザー情報でログインしてください。 Username:  admin Password:  zabbix これでZabbix Applianceの準備は完了です。 次はいよいよ、Zabbixサーバーとしての設定を行っていきます。   実践②：Applianceの初期設定方法 ここからは、先ほどログインしたコンソール画面を使って、Zabbixサーバーにアクセスするためのネットワーク設定を行います。 大まかな流れはたったの4ステップです！ コンソール画面でIPアドレスを変更 システム管理インターフェースにアクセス システム設定の保存 Zabbixにアクセス   Step 1: コンソール画面でIPアドレスを変更 ここで行うのは、このZabbixサーバーに、あなたのネットワーク環境に合ったIPアドレスを割り当てる作業です。 ① 以下のコマンドを入力し、ネットワーク設定ファイルを開きます。  $ sudo vi /etc/systemd/network/eth0.network ② ファイルが開いたら、お使いの環境に合わせて [Address] （IPアドレス）と [Gateway] （デフォルトゲートウェイ）を書き換えます。 ＜修正後（例）＞ Addres=192.168.10.50 ←自分のネットワーク環境に合わせる Gateway=192.168.10.1 ←自分のネットワーク環境に合わせる ③ ファイルを保存したら、以下のコマンドでネットワークサービスを再起動し、設定を反映させます。 $ sudo systemctl restart systemd-networkd これで、お使いのPCからZabbixサーバーにアクセスできるようになりました！   Step 2: システム管理インターフェースにアクセス 次に、WebブラウザからZabbix Appliance専用の管理画面にアクセスします。 ここでホスト名やパスワードなど、サーバーの基本的な設定を行います。 お使いのPCのWebブラウザを開き、以下のアドレスにアクセスしてください。 https://<先ほど設定したIPアドレス>:7738 （例:  https://192.168.10.50:7738 ） Username:  admin Password:  zabbix   Step 3: システム設定の保存 管理画面にログインすると、ホスト名やNTPサーバー、ネットワーク設定、パスワード変更などのメニューが表示されます。 今回は検証が目的なので、特に設定は変更せず、 「保存と起動」 にある「 システム設定の保存 」をクリックします。 ボタンを押すと、これまでの設定がシステムに保存され、適用されます。   Step 4: Zabbixにアクセス！ お疲れ様でした！いよいよZabbixのWebインターフェースにアクセスします。 ※先ほどとは別のURLになるのでご注意ください。 Webブラウザで、以下のアドレスにアクセスしてください。 https://<設定したIPアドレス>/zabbix （例:  https://192.168.10.50/zabbix ）  ログイン画面が出るので、 デフォルトのユーザー名とパスワードでログインしてみましょう。 ユーザー名:  Admin パスワード:  zabbix 無事にダッシュボード画面が表示されました！   まとめ いかがでしたでしょうか？ Zabbix Applianceを使えば、 面倒なインストール作業は一切不要 簡単なIPアドレス設定だけで、すぐにZabbixを使い始められる ということを実感いただけたかと思います。まずはこのApplianceでZabbixの基本的な機能に触れてみて、本格的に導入する際には、要件に合わせて通常インストールに挑戦してみる、というステップアップもおすすめです。 今回利用した仮想アプライアンスは、検証用であり本番利用は想定されておりません。本番環境でアプライアンスを利用したい場合、物理アプライアンスをご購入いただくか、サポート加入者に配布される本番用仮想アプライアンスをご利用いただく必要がございます。サポートに関する詳細は、弊社までお問い合わせください。 お問い合わせ 製品・サービスについて 入力 ｜ SCSK株式会社     　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 弊社ではZabbix関連サービスを展開しています。以下ページもご参照ください。 ★SCSK Plus サポート for Zabbix★ SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします。 www.scsk.jp ★YouTubeに、SCSK Zabbixチャンネルを開設しました！★ SCSK Zabbixチャンネル SCSK Zabbixチャンネルでは、Zabbixのトレンドや実際の導入事例を動画で解説。明日から使える実践的な操作ナレッジも提供しており、監視業務の効率化に役立つヒントが満載です。 最新のトピックについては、リンクの弊社HPもしくはXアカ... www.youtube.com ★X（旧Twitter）に、SCSK Zabbixアカウントを開設しました！★ https://x.com/SCSK_Zabbix x.com

こんにちは、ひるたんぬです。 この度「 AWS re:Invent 2025 」に参加できることになりましたので、現地での出来事や参加したセッションについてのレポートをお送りしたいと思います！ 今回は、私が初回参加ということもありますので、事前に準備した荷物や到着までの流れをご紹介していきます！ 事前準備 海外出張（旅行などもですが…）で、悩むことの一つが「何を持っていけば良いのか」だと思います。 少なくとも、私はこれが一番の悩みと言っても過言ではありません。 そのため、過去に参加されていた方のブログや、弊社内で複数回参加されている方のご意見を参考にしたほか、私が過去に海外旅行で持って行って良かったと思ったものをご紹介していきます。 私は「吊り橋が壊れるまで叩き、『ほら、壊れたでしょ？』と言う」ほどの心配性寄りなので、見る方が見れば余計だなぁ…と思う荷物もあるかもしれません。 実際に私が使ったもの・使わなかったものは帰国後に振り返りたいと思います。 預け入れ荷物・手荷物については、それぞれ禁止されている品物が存在します。 詳しくは、搭乗される航空会社が提示している案内をご確認ください。 また、行き先国にて持ち込みが禁止されている品物もありますので、その点も忘れずにご確認ください。 預け荷物 預け荷物のポリシーとしては、 「スーツケースの半分は必ず空けていくこと」 と多くの方がおっしゃっておりました。 これは、会期中に配布されるSWAGやお土産を入れるためのスペースだそうです。 私は、預け荷物として（超過料金のかからない範囲で）最大サイズのスーツケースを持っていたので、それを利用することにしました。 今回の荷物としては、主に以下を入れています。 太文字は他の方はあまり持っていないと思われるものです。 着替え → 6泊分洗濯せずに着替えられる分を持っています。 5K Race用運動着 → 参加予定です！ お風呂・歯磨きセット → 特に乾燥がすごいとのことだったので、保湿グッズを入れました。 折りたたみ傘 → ラスベガスは砂漠地帯ですが、念の為小さいものを入れました。 ボディバッグ → 大きい荷物の持ち込みが制限されているイベントに備えて入れました。 常備薬・風邪薬・胃腸薬 → 薬の現地調達はまだ抵抗があります… 日本のお菓子 → GameDayなどで同じチームになった方に渡すと、親睦が少し深まる(？)という記事を見かけたので… 水（4L）・粉末のお茶 → 私自身胃腸が強くなく、胃腸が弱ったときに海外の水を飲むと悪化する可能性があるので持ちました。 帰りは飲みきっているので空の想定です。 ポータブル給湯器 → 温かい飲み物が飲みたいときに。 給湯器がついていない（有料貸し出し）という記事を見たので持ちました。 サンダル → 機内・ホテル室内で過ごす用です。空港で運動靴と交換します。 ▼ 預け入れ荷物に入れたものたちです。 ▼ 着替えは吊り下げ式の簡易クローゼットになるものに入れています。 ▼ 上記を詰め込んだ結果。きちんと半分空けています！ 手荷物 手荷物は、パソコンや貴重品のほか、機内で快適に過ごすためのグッズとして以下を持ちました。 ヘッドホン（ノイズキャンセリング機能付き） アイマスク 保湿マスク 歯ブラシセット ※ 付属する歯磨き粉は「液体物」扱いになるので注意です。 のど飴 → 保湿グッズと同様、乾燥地対策です。 リップクリーム → こちらも乾燥地対策です。 これらを一つのリュックにまとめています。 ▼ 手荷物と預け荷物。そこそこの量になりました。   いよいよ出発！ ここからは時系列を追っていくため、画像中心の内容となります。 予めご了承ください。 さて、いよいよ出発です。 私は今回JTBさんが企画されているJapan Tourにて参加したため、成田空港発着のプランでした。 ▼ 12月も近づいており、クリスマス色が出てきた成田空港です。 ▼ 今回のツアーでいただいたポシェット。荷物持ち込みが厳しい場面で活躍しそうです！ ▼ 今回お世話になった国際線（成田→サンフランシスコ）便。 飛行機に運ばれること約9.5時間、無事経由地のサンフランシスコ国際空港に到着しました！ 到着後は入国審査を済ませ、いよいよラスベガスへ移動です！ ▼ サンフランシスコ→ラスベガスのチェックインでは、Japan Tour専用の受付が設けられていました。 ▼ 待ち時間に食べたファースト・アメリカンフード。野菜多めで嬉しかったです。 ▼ いよいよ国内線の搭乗が近づいてきました！周りは言語は様々ですが、明らかにエンジニアの方ばかりです。 ▼ 出発直後は夕焼けがきれいに見えました。 ▼ あっという間にラスベガス国際空港に到着！ここの下で写真を撮っている方も多かったです。 ▼ 空港内でre:Inventで用いるバッジの受け取り。事前に必要な情報を登録しているとスムーズにバッジをもらえます。（そして「Perfect!!」と褒められます。） ▼ そして最後はJTBさんが手配してくださったバスにてホテルまで移動。このバスも大きい… ▼ 無事ホテルまで到着しました！（一番手前に写っているのは弊社AWS Ambassadorの木澤さんです。） 終わりに 日本から現地到着まで、待ち時間を含め24時間以上掛かりましたが、徐々に楽しみな気持ちで溢れてきました！ これからAWS re:Invent 2025の会期中、参加したイベントのレポートなどを随時投稿予定です！ 次の投稿もお楽しみに！

こんにちは。SCSKの津田です。 今回は、LifeKeeperによるAzureのリージョンを跨いだHAクラスター構成についてご紹介いたします。 はじめに 昨今の自然災害の増加に伴い、AWSやAzureといったパブリッククラウド環境では、リージョンを跨いだHAクラスター構成（ クロスリージョン構成 ）のニーズが高まっています。 LifeKeeperでは、2023年頃よりAWSでのクロスリージョン構成のサポートが開始されました。 さらに、2025年1月からはAzureでもクロスリージョン構成に対応しています（LifeKeeper for Linux：v9.9.0以降、LifeKeeper for Windows：v8.10.2以降）。 今回はAzureのクロスリージョン環境上にLifeKeeperを構築し、簡単な動作確認を行ってみました。 本記事では、クロスリージョン構成における処理の流れや、LifeKeeper構築のためのAzure設定のポイントについてご紹介します。 ▼AWSのクロスリージョン構成について気になる方はこちらもご参照ください▼ AWSマルチリージョンにおける高可用性方式を実装してみる – TechHarmony AWSマルチリージョンにおける高可用性方式（ルーティング切替編） – TechHarmony LifeKeeper × Azureクロスリージョン構成 について LifeKeeper構築の観点で単一リージョン構成とクロスリージョン構成を比較すると、 Azureのロードバランサーによるヘルスチェックプローブを利用する点では同様になりますが、単一リージョン構成では内部ロードバランサーを利用するのに対し、Azure クロスリージョン構成は、グローバルロードバランサーを使用します。 ▼単一リージョン構成については以下をご参照ください。▼ Azureで仮想IPは使えない？LifeKeeper×ILB構成で解決 – TechHarmony   以下は、今回検証で構築した環境の構成図です。 (※ Windows 環境)    MEMO ●「東日本」、「東南アジア」リージョン間のHAクラスタを想定して構成。 ● クライアントはパブリックIPアドレス(仮想IP)を使用してHAクラスタにアクセス。 ●「東日本」、「東南アジア」リージョン間ロードバランサー( グローバルロードバランサー )を、その近辺の「東アジア」リージョ    ンに配置し、そのバックエンドロードバランサーとして、「東日本」リージョン、「東南アジア」リージョンのそれぞれに パブリ    ックロードバランサー を作成。    ※グローバルロードバランサーが配置されるリージョンは「ホームリージョン」、グローバルロードバランサーのバックエンド       ロードバランサーが配置されるリージョンは「参加リージョン」といい、「ホームリージョン」については選択に制限がある       ので注意が必要。 ( https://learn.microsoft.com/ja-jp/azure/load-balancer/cross-region-overview )    ※ホーム リージョンは、あくまでグローバル ロード バランサーのパブリック IP アドレスがデプロイされる場所であり、       このリージョンがダウンしても、トラフィック フローは影響なし。 ●LifeKeeper コミュニケーションパスとして必要な「東日本」、「東南アジア」リージョン間の通信には、VNet Peering を利用。 それではLifeKeeperを利用したAzure クロスリージョン構成での処理について、簡単に説明します。 まず、グローバルロードバランサーからパブリックロードバランサーを介してヘルスチェックが行われます。 単一リージョン構成での内部ロードバランサ―(ILB)同様、ヘルスチェックは「LB Health Check Kit」リソース(以下図『lbhc』)の機能でヘルスチェック用ポート（今回は26001）に対して行われます。 続いて、ヘルスチェックに応答した稼働系ノードに対して、グローバルロードバランサーから仮想IPにむけた通信が行われます。 LifeKeeperの仮想IPリソース作成時に、グローバルロードバランサーのPublic IPを登録することにより、HAクラスタの稼働系ノードでは、グローバルロードバランサーのPublic IPが仮想IPとして割り当てられています。 これによりクライアントから稼働系ノードへは、グローバルロードバランサーのPublic IP（＝仮想IP）を利用して通信を行います。 ※アクティブ・スタンバイが切り替わると、仮想IPリソースとLB Health Check Kitの両リソースが待機系ノードに切り替わるため、 ヘルスチェックは待機系ノードから応答があり、待機系ノードの仮想IPに向けて通信します。 環境構築・検証 環境構築流れ 構築については、以下の順序で作業を行いました。 作業順 作業内容 備考 ① 仮想ネットワーク作成 東日本、東南アジアリージョンにそれぞれ作成 ② 仮想マシン作成 東日本、東南アジアリージョンで1台ずつ作成 OS：Windows Server 2025 Datacenter ③ ピアリング設定 Azure Vnet Peering ( 東日本 ⇔ 東南アジア間 ) ④ ロードバランサ―作成 パブリックロードバランサー：東日本、東南アジアリージョンで1つずつ作成 グローバルロードバランサー：東日本、東南アジアのリージョン間に1つ作成 ⑤ OS設定 hosts設定、IISインストールなど ⑥ LifeKeeper・DataKeeperインストール Version 8.11.0 ⑦ リソース作成 仮想IP、IIS、lbhcを作成 次に、③ピアリング設定、④ロードバランサー作成について設定例をご紹介していきます。 ③④以外の作業につきましては、以下をご参照ください。 (※2025年10月時点リンク。基本的にAzure単一リージョンでのLifeKeeper構築と差異はありません。) ※リソースにつきましては、この構成特有のリソース作成方法はないため、各ARKのリソース作成手順をご参照ください。 Windows : https://docs.us.sios.com/sps/8.11.0/ja/topic/create-cluster-node-primay-and-standby Linux : https://docs.us.sios.com/spslinux/9.9.1/ja/topic/microsoft-azure-quick-start-guide クロスリージョン構成の設定ポイント ここでは作業の中からクロスリージョン構成でポイントとなる ピアリング設定、ロードバランサー作成 について設定内容をご紹介します。 (Azureの設定項目は、継続的にアップデートされるため)  ピアリング(Azure Vnet Peering)設定 仮想ネットワーク間のピアリング設定は、リージョンが異なるHAクラスターノード間の通信(LifeKeeperのコミュニケーションパス、レプリケーション)に必要となります。 設定はAzureコンソール上から、片方の仮想ネットワークからピアリングを作成することで、リモートの仮想ネットワークにも設定を反映します。以下の設定は、仮想ネットワーク「NW_JapanEast」から追加したピアリング設定です。 設定項目 設定値  備考 リモート仮想ネットワークの概要 ピアリング リンクの名前 GlobalPeering_JE_SA   サブスクリプション (任意のサブスクリプションを選択)   仮想ネットワーク NW_SoutheastAsia ※対向の仮想マシンに紐づく仮想ネットワークを選択 リモート仮想ネットワーク ピアリングの設定 ピアリングされた仮想ネットワーク に ‘NW_JapanEast’ へのアクセスを許可する 有効(チェックを入れる)   ローカル仮想ネットワークの概要 ピアリング リンクの名前 GlobalPeering_SA_JE   ローカル仮想ネットワーク ピアリングの設定 ‘ NW_JapanEast’ に ピアリングされた仮想ネットワーク へのアクセスを許可する 有効(チェックを入れる)     パブリックロードバランサ―作成 Azureコンソールから、LifeKeeperで保護するノードが配置される各リージョン( Japan East、Southeast Asia )でパブリックロードバランサーを構築します。 ＜Japan Eastのパブリックロードバランサ―＞ 設定項目 設定値  備考 プロジェクトの詳細 サブスクリプション (任意のサブスクリプションを選択)   リソース グループ (任意の リソース グループ を選択)   インスタンスの詳細 名前 LKLB-JE   リージョン Japan East   SKU Standard   種類 パブリック ※パブリックを選択 レベル 地域 ※リージョンのロードバランサーであるため地域を選択 フロントエンド IP 構成の追加 名前 LKLB-JE-frontend   IP バージョン IPv4   IP の種類 IPアドレス   パブリック IP アドレス     Gateway Load Balancer なし   パブリック IP アドレスの追加 名前  LKLB-JE-pip   可用性ゾーン 1   ルーティングの優先順位 Microsoft ネットワーク   バックエンドプールの追加 名前 LKLB-JE-backend   仮想ネットワーク NW_JapanEast   バックエンド プールの構成 NIC   バックエンド プールへの IP 構成の追加 LK01JE   負荷分散規則の追加 名前 LKLB-JE-rule   IP バージョン IPv4   フロントエンド IP アドレス LKLB-JE-frontend   バックエンド プール LKLB-JE-backend   プロトコル TCP   ポート  80   バックエンド ポート  8080   正常性プローブ  JKLB-JE-probe   セッション永続化 なし   アイドル タイムアウト (分) 4 デフォルト値 TCP リセットの有効化 無効(チェックを入れる)   フローティング IP の有効化 有効(チェックを入れる)   アウトバウンドの送信元ネットワーク アドレス変換 (SNAT) (推奨)アウトバウンド規則を使用して、バックエンドプールのメンバーがインターネットにアクセスできるようにします。   正常性プローブ設定 名前 JKLB-JE-probe   プロトコル  TCP    ポート  26001    サイクル間隔(秒)  ５ デフォルト値 ※Japan Eastのパブリックロードバランサ―設定後、仮想マシン(LK01JE)のネットワークセキュリティグループで受信・送信セキュリティ規則を追加する。 設定項目 設定値  備考 ソース Any   ソース ポート範囲 *   宛先 Any   サービス Custom   宛先ポート範囲 8080   プロトコル TCP   アクション 許可   優先度 300     ＜Southeast Asiaのパブリックロードバランサ―＞ 設定項目 設定値  備考 プロジェクトの詳細 サブスクリプション (任意のサブスクリプションを選択)   リソース グループ (任意の リソース グループ を選択)   インスタンスの詳細 名前 LKLB-SA   リージョン Southeast Asia   SKU Standard   種類 パブリック ※パブリックを選択 レベル 地域 ※リージョンのロードバランサーであるため地域を選択 フロントエンド IP 構成の追加 名前 LKLB-SA-frontend   IP バージョン IPv4   IP の種類 IPアドレス   パブリック IP アドレス LKLB-SA-pip   Gateway Load Balancer なし   パブリック IP アドレスの追加 名前 LKLB-SA-pip   可用性ゾーン 1   ルーティングの優先順位 Microsoft ネットワーク   バックエンドプールの追加 名前 LKLB-SA-backend   仮想ネットワーク NW_Southeast   バックエンド プールの構成 NIC   バックエンド プールへの IP 構成の追加 LK01JE   負荷分散規則の追加 名前 LKLB-SA-rule   IP バージョン IPv4   フロントエンド IP アドレス LKLB-SA-frontend   バックエンド プール LKLB-SA-backend   プロトコル TCP   ポート  80   バックエンド ポート  8080   正常性プローブ  JKLB-SA-probe   セッション永続化 なし   アイドル タイムアウト (分) 4 デフォルト値 TCP リセットの有効化 無効(チェックを入れる)   フローティング IP の有効化 有効(チェックを入れる)   アウトバウンドの送信元ネットワーク アドレス変換 (SNAT) (推奨)アウトバウンド規則を使用して、バックエンドプールのメンバーがインターネットにアクセスできるようにします。   正常性プローブ設定 名前 JKLB-SA-probe   プロトコル  TCP    ポート  26001    サイクル間隔(秒)  ５ デフォルト値 ※Japan Eastのパブリックロードバランサ―設定後、仮想マシン(LK02SA)のネットワークセキュリティグループで受信・送信セキュリティ規則を追加する。 設定項目 設定値  備考 ソース Any   ソース ポート範囲 *   宛先 Any   サービス Custom   宛先ポート範囲 8080   プロトコル TCP   アクション 許可   優先度 300     グローバルロードバランサ― Azureコンソールから、LifeKeeperで保護するノードが配置されるリージョン間の グローバルロード バランサーを構築します。 設定項目 設定値  備考 プロジェクトの詳細 サブスクリプション (任意のサブスクリプションを選択)   リソース グループ (任意の リソース グループ を選択)   インスタンスの詳細 名前 LKLB-EA   リージョン East Asia   SKU Standard   種類 パブリック ※パブリックを選択 レベル グローバル ※リージョン間のロードバランサーであるためグローバルを選択 フロントエンド IP 構成の追加 名前 LKLB-EA-frontend   IP バージョン IPv4   パブリック IP アドレス LKLB-EA-pip   パブリック IP アドレスの追加 名前 LKLB-EA-pip   可用性ゾーン 1   ルーティングの優先順位 Microsoft ネットワーク   バックエンドプールの追加 名前 LKLB-EA-backend   ロードバランサ― LKLB-JE   ロードバランサ― LKLB-SA   負荷分散規則の追加 名前 LKLB-EA-rule   IP バージョン IPv4   フロントエンド IP アドレス LKLB-EA-frontend   バックエンド プール LKLB-EA-backend   プロトコル TCP   ポート 80   セッション永続化 なし   フローティング IP の有効化 有効(チェックを入れる)   動作確認 単一リージョン構成での 記事 同様に、IISを利用して簡単な動作確認を行いました。 <事前準備> クラスタ内各ノードのIISのドキュメントルートに、サーバ名を記載したテストページ(htmlファイル)を格納します。 ＜LK01JE %SystemDrive%\inetpub\wwwroot\test_page.htm＞              ＜LK02SA %SystemDrive%\inetpub\wwwroot\test_page.htm＞ <動作確認> 想定：クライアント端末から仮想IP(グローバルロードバランサ―のパブリックIP)にアクセスすると、アクティブ側ノードのテストページが返される。 LK01JE がアクティブのとき クライアント端末から仮想IP宛にIISのテストページにアクセスすると、想定通りLK01JEのテストページが表示されました。          LK02SA がアクティブのとき クライアント端末から仮想IP宛にIISのテストページにアクセスすると、想定通りLK02SAのテストページが表示されました。         注意点 クロスリージョン構成では、DataKeeperによるデータレプリケーションも可能です。 ご利用をご検討の際は、データベースに関連するサービスや制限事項についてサイオステクノロジー社へご確認いただくことを推奨いたします。 2025年10月時点では、「JP1/AJS3 – Manager」および「JP1/AJS3 – Agent」のサービス保護はサポート対象外となっておりますのでご注意ください。 今回は2ノード構成を例としておりますが、グローバルロードバランサーの機能を利用することで、3ノード以上への拡張も可能であり、LifeKeeperの観点でもサポート範囲となります。グローバルロードバランサーの制限事項にご留意ください。 グローバル ロード バランサー - Azure Load Balancer Azure Load Balancer のグローバル ロード バランサー レベルの概要。 learn.microsoft.com クロスリージョン構成では、費用、設計、パフォーマンス、運用等、多くの観点で十分な検討が必要となります。本構成は一例となりますので、参考情報としてご活用ください。また、具体的な構成案がありLifeKeeperをご検討される際は、事前にサイオステクノロジー社へのご確認を推奨いたします。 さいごに 今回は、LifeKeeperの観点からAzureにおけるクロスリージョン構成についてご紹介しました。 AWSと比較して、サイオステクノロジー社が発信しているドキュメントはまだ少なく、サポートされていないサービスも存在するなど、十分に展開されているとは言えない部分が見受けられます。しかし、今後は災害対策環境へのニーズの高まりに伴い、サポート範囲の拡充も期待できますので、引き続きその動向に注目していきたいと思います！

こんにちは、SCSK株式会社3年目の愛甲です。 前回、私たちの部署の嶋谷さんが、 MackerelのMCPサーバーに触れてみた という記事を掲載しました。 この記事の内容は、運用に携わっている人からすると、 とても興味深いもので面白かったので、ぜひ確認いただきたいです！ MackerelのMCPサーバーに触れてみた – TechHarmony 今回は、AzureをMackerelで監視してみました。 AzureとMackerelの連携手順から、監視データの見え方について記載しますので、 最後までご一読いただけますと幸いです。 MackerelでのAzureリソースの監視 Mackerelでは、Azureインテグレーションというものを使い、 MackerelとAzureのサービスを接続することで、Azure環境を監視することができます。 Azureインテグレーションについては、以下のMackerelの公式ドキュメントに詳細が記載されています。 Azureインテグレーション – Mackerel ヘルプ MackerelでAzure環境を監視する記事は初めてとなりますので、今回の記事では、設定方法などについて詳しく記載させていただいております。 MackerelでAzure環境を監視したいという方は、ぜひこの記事を見ながら設定を入れていただければと思います。 監視対象について はじめに、監視対象についての情報を軽く説明します。 今回の検証では、Mackerelの監視データを内部のサーバへ連携するためのサービスを構築しました。 システム構成は以下になります。   Application Gateway　　　 　　 仮想マシンの負荷分散を行う WAF　　　　　　　　　　　　　　 Webアプリケーションへの攻撃を検知・防御する Virtual Machine  　　　　　　　  Mackerel連携サーバそのもの VPNゲートウェイ 　　　　　　　 　内部サーバとの接続口 上記のサービスの中でVirtual Machine・Application Gatewayを監視対象として検証しました。 上記の環境の構築手順については、少し長くなってしまうため、この記事では説明を省かせていただきます。 Mackerelでの監視設定手順 では、ここからはMackerelでAzureのサービスを監視するための、設定手順について記載していきます。 設定手順に興味ない方は、このパートはスキップして、「監視データの確認」のパートに飛んでください。 インテグレーション用の各種情報を取得する Azureのサービスの監視を行う場合、インテグレーションの設定を行う必要があります。 Azureインテグレーションの設定には以下3つのデータをAzureポータルで取得し、Mackerelの管理画面に入力する必要があります。 テナントIDを取得する (1) Azure Portalにログインし、「Microsoft Entra ID」＞「プロパティ」をクリックする。   テナントIDが表示されるため、コピーする。 (2) Mackerelの管理画面を開き、「オーガニゼーション」＞「Azureインテグレーション」＞「新しいAzureテナントIDを登録」をクリックする。 (3) テナントIDの欄に先程コピーしたものを張り付ける。 クライアントIDを取得する (1) Azure Portalにログインし、「Microsoft Entra ID」＞「アプリの登録」＞「新規登録」をクリックする。 (2) 名前を入力し、リダイレクトURLはWebを選択し、「登録」をクリックする。 (3) 「登録」をクリック後、以下の画面へ遷移するため、「アプリケーション (クライアント) ID」をコピーし、Mackerelの管理画面のクライアントIDにペーストする。 シークレットキーを取得する (1) 「証明書とシークレット」＞「新しいクライアント シークレット」をクリックし、追加を行う。 (2) 「値」をコピーし、Mackerelの管理画面のシークレットキーにペーストする。 ※「シークレットID」ではなく、「値」をコピーする。 ※この後の手順で行う「権限設定」を行うまでは、「 無効 」と表示される。 権限設定を行う (1) Azure Portalで「サブスクリプション」＞「サブスクリプション名」をクリック。 (2) 「アクセス制御(IAM)」＞「追加」＞「ロールの割り当ての追加」をクリックする。 (3) 「閲覧者」を選択し、「次へ」をクリックする。 (4) 「ユーザー、グループ、またはサービス、プリンシパル」にチェックを入れ、「メンバーを選択する」で上記手順で作成したアプリケーションを選択後、「レビューと割り当て」をクリックする。 (5) Mackerelの管理画面で「 有効 」となっていることを確認する。 Azureインテグレーションの設定を行う (1) Mackerelの管理画面で、監視をしたいサービスを選択する。 (2) サブスクリプションを選択する。 ※選択しなかった場合、すべてのサブスクリプションが対象となる。 (3) 「更新」をクリックする。 これで、インテグレーションが作成できました！ 連携確認 以上で設定は完了です。 ここからは、監視設定を入れたサービスの状態を見ていきます。 ここまでの手順が完了すると、Mackerelの管理画面の「ホスト」のところで 以下のように一覧を確認することができます。 監視データの確認 監視手順としては以上になります。 Azureインテグレーションを使うと、面倒なエージェントのインストールを行うことなく、クラウド環境のサービスを監視することができます。 これまでに投稿してきたMackerelの記事を読んでいただいた方はわかると思いますが、Mackerelで各クラウドサービスを監視した場合、クラウドによってとってこれるメトリックは異なるものの、UIは統一されるため、運用する側としては、とても見やすくて便利だと思います。 これは地味にうれしいポイントだと思うので、ぜひ体感してほしいです。 では、ここからはAzureから連携された監視データがどのように見えているかを、 Virtual Machine・Application Gatewayの2つに絞ってお見せしたいと思います。 Virtual Machineの監視データ Virtual Machineは基本的に以下のメトリックを取得することができます。 グラフ名 メトリック 説明 CPU Percentage CPU 仮想マシンのCPU使用率（パーセンテージ）を取得します。平均値が表示されます。 CPU Credits Remaining/Consumed CPU Credits Remaining 仮想マシンの残りCPUクレジット数を取得します。浮動小数点（float）で表示されます。 CPU Credits Consumed 仮想マシンで消費されたCPUクレジット数を取得します。平均値が表示されます。 Disk IOPS Disk Read Operations/Sec 1秒あたりのディスク読み取り操作数（IOPS）を取得します。平均値が表示されます。 Disk Write Operations/Sec 1秒あたりのディスク書き込み操作数（IOPS）を取得します。平均値が表示されます。 VM Availability Metric VmAvailabilityMetric 仮想マシンの稼働率（可用性）を示します。浮動小数点で平均値が表示されます。 Network In/Out Network In 仮想マシンが受信したネットワークデータ量（バイト単位）を取得します。合計値が表示されます。 Network Out 仮想マシンが送信したネットワークデータ量（バイト単位）を取得します。合計値が表示されます。 Network In/Out Total Network In Total 仮想マシンが累計で受信したネットワークデータ量（バイト単位）を取得します。合計値が表示されます。 Network Out Total 仮想マシンが累計で送信したネットワークデータ量（バイト単位）を取得します。合計値が表示されます。 Disk Read/Write Bytes Disk Read Bytes ディスクの読み取りバイト数を取得します。合計または平均値が表示されます。 Disk Write Bytes ディスクの書き込みバイト数を取得します。合計または平均値が表示されます。 今回は、この中のCPUとDisk Read/Write Bytesのグラフをお見せします。 以下は、CPUの使用率を現したグラフになります。 こちらを見ると、10:16時点で少しCPU使用率が高くなっていることがわかります。 以下はディスクの書き込み・読み取りバイト数を現したグラフとなります。 CPUのグラフと同じ時間帯となりますので、Diskの書き込み処理の影響でCPUの負荷が高まったと予想できます。 Application Gatewayの監視データ 続いて、Application Gatewayは基本的に以下のメトリックを取得することができます。 Application Gatewayで取得できるメトリックはレベルによって異なります。 詳細については、以下をご参照ください。 Azureインテグレーション – Application Gateway – Mackerel ヘルプ 今回は、Throughputのグラフをお見せします。 以下は、Application Gatewayのデータ転送量（毎秒のデータ量）を示します。 これを使うと、通信量の監視や、回線及びシステムのキャパシティ計測に役立てることができます。 このように、Mackerelでは特定の時間のメトリックデータを複数並べて確認することができるため、各データを組み合わせることで、簡単に詳細分析をすることができます。 これだけ多くのメトリックを取得すれば、障害発生時の切り分けもしやすく、復旧時間も大幅に削減できます。 興味がある方はぜひ調べて試してみてください。 おわりに 記事の内容は以上になります。いかがでしたでしょうか。 これまで、３大クラウドAWS、GCP、Azureの順で記事を掲載してきましたが、ほかの２つのクラウドサービスと同様に10分程度で連携完了することができます。 どのクラウドサービスも、監視するサービスを提供しているかと思いますが、「各メトリックをまとめて表示させたい。」「必要な情報だけ確認したい。」などの要望がある方は、是非１度Mackerelを触ってみてください。 また何か気づきや皆様へご紹介したい内容がありましたら記事を掲載します。 最後までお付き合いいただき、ありがとうございました。

LifeKeeperの『困った』を『できた！』に変える！サポート事例から学ぶトラブルシューティング＆再発防止策 こんにちは、SCSKの前田です。 いつも TechHarmony をご覧いただきありがとうございます。 LifeKeeper の運用は、システムの安定稼働を支える重要な役割を担いますが、時には「なぜか動かない」「エラーが出てフェイルオーバーできない」といった『困った』事態に直面することもありますよね。そんな時、サポートに問い合わせて解決した経験は、多くの方にとって貴重な財産となっているはずです。 本連載企画「LifeKeeper の『困った』を『できた！』に変える！サポート事例から学ぶトラブルシューティング＆再発防止策」では、実際に LifeKeeper のサポートに寄せられた問い合わせ事例を基に、よくあるトラブルの原因、究明プロセス、そして何よりも『再発防止策』に焦点を当てて深掘りしていきます。 はじめに LifeKeeper運用の現場で頻繁に遭遇するリソース起動・フェイルオーバー失敗。その中でも特にファイルシステムやIPリソースは、設定ミスや環境要因で予期せぬ問題を引き起こしやすいものです。 本連載の第二弾では、OSアップデート後に発生したファイルシステムリソースのマウントオプション不一致エラー「124011」のサポート事例を通じて、エラーコードから原因を読み解き、適切な解決策と再発防止策を学ぶことで、LifeKeeperクラスタをより安定的に運用するためのヒントを提供します。特に、解決策実施時に遭遇しがちな「権限問題」についても詳しく解説します。 その他の連載企画は以下のリンクからどうぞ！ 【リソース起動・フェイルオーバー失敗の深層 #1】EC2リソースが起動しない！クラウド連携の盲点とデバッグ術 – TechHarmony 今回の「困った！」事例 LifeKeeperクラスタ環境で、 ファイルシステムリソースが 繰り返し ローカルリカバリーを実行 し、それに伴って Webサービスへの接続障害 が発生しました。 事象の概要: お客様環境のLifeKeeperクラスタで、特定の ファイルシステムリソース（/DISK1） において、LifeKeeperログ（ lifekeeper.log ）に以下のエラーメッセージが頻繁に出力され、 ローカルリカバリーが繰り返されている ことが確認されました。 ERROR:filesys:quickCheck:/DISK1: 124011 :”/DISK1″ is mounted but with the incorrect mount options (current mount option list: rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota, expected mount option list: rw,relatime,attr2,inode64,noquota) このエラーコード124011は、「LifeKeeperのファイルシステムリソースで指定したマウントオプションと、実際にマウントされた際のオプションに相違が生じている」ことを示します。 また、この事象と関連があるかは不明でしたが、同時間帯にWebサービスへの接続障害も発生していました。 発生時の状況: エラーメッセージが示す通り、LifeKeeperが監視している ファイルシステム /DISK1 が、LifeKeeperが期待するマウントオプションと異なるオプションでマウントされている状況でした。具体的には、 logbufs=8,logbsize=32k というオプションが追加で付与されていました。 お客様環境では、事象発生の数日前にOS（RHEL 8.1からRHEL 8.3へ）の カーネルアップデート を実施しており、このアップデートが関連している可能性が疑われました。 Web接続障害については、詳細なログ確認の結果、 LifeKeeperが事前に停止されている時間帯 に発生しており、ファイルシステムリソースのエラーとは直接的な関連がないことが判明しました。 Sep 2 07:30:29 LK-NODE-01 quickCheck[1103776]: ERROR:filesys:quickCheck:/DISK1:124011:”/DISK1″ is mounted but with the incorrect mount options  Sep 2 07:30:29 LK-NODE-01 quickCheck[1103776]: INFO:filesys:quickCheck:/DISK1:124013:Attempting Local Recovery of resource Sep 2 01:00:14 LK-NODE-01 lk-start-stop[878561]: NOTIFY:shutdown:::010069:stopping LifeKeeper (options: nofailover noremove) 原因究明のプロセス: サポートとのやり取りを通じて、以下の点が確認されました。 LifeKeeperのマウントオプションの保持:  LifeKeeperはファイルシステムリソースを作成する際、その時点のOS（この場合はRHEL 8.1）が設定しているマウントオプションをリソース情報として保持します。これは  /etc/fstab の情報を自動で読み取るような挙動ではなく、 作成時のマウントされている設定情報を基に値を保持 します。 OSアップデートによる変更:  OSを RHEL 8.3にアップデート したことで、OS側のマウントコマンドが特定のファイルシステムタイプ（XFSなど）に対して デフォルト で追加のマウントオプション（ logbufs=8,logbsize=32k ）を付与するように変更された可能性があります。 オプション不一致の発生:  LifeKeeperはOSの変更に合わせてリソース情報を自動更新しないため、 保持しているRHEL 8.1時代の「期待されるマウントオプション」 と、RHEL 8.3で実際にマウントされた際の 「現在のマウントオプション」 との間で 不一致 が生じました。 監視によるエラー検出:  LifeKeeperの  quickCheck プロセスがこの不一致を検出し、エラーコード124011を出力。これにより、リソースのローカルリカバリーが繰り返し実行される状態となっていました。 判明した根本原因: OSのカーネルバージョンアップ（RHEL 8.1 → RHEL 8.3）により、OS側のファイルシステムマウントオプションの デフォルト値が変更 されたことが根本原因でした。LifeKeeperが保持するリソース設定値がOSの変更に追従しておらず、マウントオプションの不一致が継続的に監視エラーを引き起こしていました。Web接続障害はLifeKeeperの動作停止中に発生しており、直接的な原因ではないと判断されました。 「再発させない！」ための対応策と学び 具体的な解決策: LifeKeeperのファイルシステムリソースに設定されているマウントオプションを、現在のOS（RHEL 8.3）で実際に付与されているマウントオプションに合わせて変更することで、エラーは解消されます。 この変更は両LifeKeeperサーバーで実施する必要があります。 コマンドラインからの変更（推奨）と権限問題の解決:    リソースを停止する必要がないため、運用中のシステムで安全に実施できます。 # lkcli resource config fs –tag <リソース名> –mountopt <設定するマウントオプション> 例: # lkcli resource config fs –tag /DISK1 –mountopt rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota 【重要: コマンド実行時の権限問題】 この lkcli コマンドをrootユーザーで実行した際、 「Permission denied.」エラー が発生する場合があります。これは、 lkcli コマンドを実行するためには、 実行者が lkadmin グループに所属している必要がある ためです。 解決策1: rootユーザーを lkadmin グループに所属させる。  多くの環境ではrootユーザーはデフォルトで  lkadmin  グループに所属していますが、そうでない場合は  usermod -aG lkadmin root  などのコマンドでグループに追加し、セッションを再開（ログアウト/ログイン）して実行します。 解決策2: lkadmin グループに所属する別のユーザーで sudo を利用して実行する。  システム運用ポリシー上、rootユーザーを直接操作しない場合は、 lkadmin  グループに所属するユーザーアカウントを作成し、そのユーザーで  sudo  を使ってコマンドを実行することも可能です。 LifeKeeper GUIからの変更: LifeKeeper GUIから対象のファイルシステムリソースを停止 し、リソースを右クリックして「Change Mount Options」を選択して設定します。GUI操作であれば権限問題に直面する可能性は低いですが、 リソース停止が必要 となります。 再発防止策（チェックリスト形式）: 同様の問題を未然に防ぎ、より安定的なクラスタ運用を行うために、以下の点を確認・実施しましょう。   OS アップデート前のLifeKeeper互換性確認: OSのメジャーバージョンアップやカーネルアップデートを実施する際は、必ずLifeKeeperがそのOSバージョンおよびカーネルバージョンをサポートしているか、 サポートマトリクス で事前に確認する。   OS デフォルト設定の変更点確認:  OSアップデートのリリースノートを確認し、ファイルシステムのマウントオプションやネットワーク設定など、LifeKeeperが管理するリソースに影響を与える可能性のあるOS側のデフォルト設定の変更がないか確認する。   LifeKeeper ログ監視の徹底:  LifeKeeperログのエラーメッセージ（特にエラーコード）を日常的に監視し、異常を早期に検知できるよう運用体制を整える。 エラーコード124011 が検出された場合は、まずマウントオプションの不一致を疑い、 mount  コマンドなどで現状を確認する。   LifeKeeper コマンド実行権限の確認:   lkcli  などLifeKeeper関連の重要なコマンドを実行するユーザーが、適切な権限（例:  lkadmin  グループへの所属）を持っていることを事前に確認し、必要に応じて権限設定を適切に行う。 ベストプラクティス: 環境要件の遵守:  LifeKeeperは特定のOSバージョン、カーネルバージョン、ストレージ、ネットワーク構成で動作が保証されています。導入前だけでなく、運用中のOSアップデートや環境変更時にも、 常にSIOSの動作環境要件や推奨設定を確認 し、遵守することが重要です。 関連ドキュメント:   SIOS オンラインマニュアル (最新版のドキュメントを参照し、ファイルシステムリソースに関する項目や、OS設定に関する項目を定期的に確認しましょう。) エラーメッセージの活用:   LifeKeeperのエラーメッセージは、 問題解決の重要な手がかり です。メッセージカタログやドキュメントを参照し、エラーコードが示す意味を正確に理解することで、迅速な原因究明と対処が可能になります。 テスト環境での十分な検証:   OSのメジャーアップデートやシステム構成の大きな変更を行う際は、本番環境に適用する前に、必ず検証環境でLifeKeeperリソースを含むシステム全体の動作テストを徹底し、 潜在的な問題を洗い出すようにしましょう 。 権限管理の徹底とドキュメント参照の習慣:  LifeKeeperの運用では、コマンド実行時の権限管理が非常に重要です。最小権限の原則に基づき、必要なユーザーにのみ適切な権限を付与し、その権限での操作方法を明確にする必要があります。また、LifeKeeperのマニュアルはバージョンによって内容が更新されるため、 使用しているLifeKeeperの正確なバージョンに合致するドキュメントを参照 し、必要に応じて最新情報もチェックする 習慣が、誤った操作やトラブルの回避に繋がります。 まとめ 今回の事例では、 OSアップデート がLifeKeeperのファイルシステムリソースの設定に影響を与え、マウントオプションの不一致を引き起こしたことが原因でした。さらに、解決策の実施時には lkcli コマンドの実行権限の問題にも直面しました。 この事例から、OSのバージョンアップがLifeKeeperの動作に予期せぬ影響を与える可能性があること、そしてLifeKeeperコマンドの適切な実行権限の重要性を学びました。 事前の互換性確認、変更後のリソース設定の見直し、そして正確なマニュアル参照と権限管理の徹底は、日々の運用でシステムの変更に際してトラブルを未然に防ぐ上で極めて重要です。 次回予告 次回の連載では、「リソース起動・フェイルオーバー失敗の深層」の第三弾として、「クラスタの予期せぬ停止を防ぐ！ネットワーク構成のトラブルシューティング」と題し、LifeKeeper環境におけるネットワーク関連のトラブル事例とその解決策、安定稼働のためのベストプラクティスを深掘りします。どうぞご期待ください！ 詳しい内容をお知りになりたいかたは、以下のバナーからSCSK LifeKeeper公式サイトまで

本記事は TechHarmony Advent Calendar 2025 12/1付の記事です 。 こんにちは。SCSK株式会社の上田です。 毎年恒例、 TechHarmonyのアドベントカレンダー企画 が始まりました！🎉🎉🎉 12/25 までの期間、毎日ブログをお届けしますので、お楽しみください。 今年はアドベントカレンダーでは、前半の約3分の1日程で Zabbix枠 を頂きました！ 12/1～8の8日間 、毎日 Zabbix 関連記事を投稿いたしますので、Zabbixに興味のある方・使用している方は是非ご覧ください！ さて、初日である今回は、 Zabbixの障害通知をTeamsに飛ばす方法 を紹介します。 Zabbixでは、発生した障害を様々なツールに通知することができます。 しかし、 通知先としてメールだけを使っている人 が多い印象です。 そこで、今回は、 Microsoft Teamsへの障害通知 を簡単に設定する方法を紹介します！ はじめに 本記事の環境は以下です。 Zabbix：Zabbix 7.0 LTS Teams：バージョン 25290.205.4069.4894 Teamsはデスクトップ版を使っています。ブラウザ版でもそこまで画面は変わらないと思います。 ただ、TeamsのUIはよく変わるので、記事内のスクショと画面が異なる可能性がありますのでご了承ください。（その場合はそれっぽい設定項目を探してください。。。） 通知を設定する 細かいカスタマイズは後にして、なにはともあれ「 とりあえずZabbixからTeamsに通知を送る 」ということをやってみます。 Teams側での設定と、Zabbix側での設定に分けて説明します。 Teams側の設定 Teamsでは、 通知を送りたいチャネルに対してWebhookの設定 をします。TeamsのUIはよく変わるので正確な手順はその時のバージョンに依存しますが、だいたい以下のような手順で設定できると思います。 ①対象チャネルの右の「…」マークをクリックし、メニューから「チャネルの管理」をクリック チャネルの管理 ②上部タブ「設定」をクリックし、「コネクタ」の編集をクリック コネクタの編集 ③”Webhook”と検索し、出てくる「Incoming Webhook」をクリック Webhookを開く ④Webhookの表示名（今回は”ZabbixTestとしました”）を入力し、ページ下部の「Create」をクリック Webhookの名前入力 ⑤WebhookのURLが出てくるので、コピーして控えておき、「Done」をクリック URLをコピー 以上でTeams側の設定は完了です。 Zabbix側の設定 続いて、Zabbix側で設定していきます。他の監視設定と同じようにWebインターフェースで設定します。 設定するのは、 メディアタイプ・ユーザー・アクション の3項目です。 メディアタイプの設定 ①【通知】＞【メディアタイプ】を開く ②メディアタイプ一覧に「MS Teams」という項目があるので、それをクリック ③（任意ですが）検証用なので、「複製」して、適当な名前を付ける（今回は”MS Teams Test”としました） ④パラメータ欄の”teams_endpoint”の値に、先ほどコピーしたWebhookのURLを張り付ける パラメータ変更 ⑤「有効」にチェックを入れ、「追加」をクリック 有効にする ユーザーの設定 ①【ユーザー】＞【ユーザー】を開く ②適当なユーザー（今回は”Admin”）をクリックし、メディアタブを開く ③「追加」をクリックし、以下のように入力し、右下の「追加」をクリック タイプ：MS Teams Test 連絡先：任意（今回は”Teams”にしました） 有効な時間帯：デフォルトでOK メディアの設定 ④「更新」をクリック （これ忘れやすいので注意！！） 更新を忘れずに！ アクションの設定 ①【通知】＞【アクション】＞【トリガーアクション】を開く ②右上「アクションの作成」をクリック ③名前、実行条件に任意の情報を入れる（実行条件は監視したいホストやトリガーの情報を指定します） 設定入力 ④「実行内容」タブで、実行内容の「追加」をクリック ⑤「ユーザーに送信」で、先ほど編集したユーザーを選択し、「追加」をクリック ユーザーを設定 これで準備完了しました。これで、 実行条件に設定したトリガーで障害がおこると、Teamsに通知が飛びます ！ 通知が飛ぶ 通知をカスタマイズする 今までの手順では、 デフォルトの障害通知メッセージ が デフォルトのTeamsユーザー から投稿されています。それらを カスタマイズ してみましょう！ 通知ユーザー（Teams）を変更する 先ほどWebhookを設定した時の画面で、「 Upload Image 」というボタンがありました。そこから通知するユーザーのアイコンが設定できます。今回は、Copilotで生成した通知用のキャラクターをアイコンに設定してみました！ マスコット？ ・・・何とも言えない、かわいらしいキャラクターが生成されました。 画像をアップロード   アップロードしてみると、ご覧のように設定したアイコンで通知が飛ぶようになります！ アイコンが変更   通知メッセージを変更する 通知メッセージは、メディアタイプ内に記述されているスクリプトに基づくメッセージが適用されており、メディアタイプの「メッセージテンプレート」の内容は反映されません。 「メッセージテンプレート」の内容で通知を行うには、パラメータ”use_default_message”の値を”false”から”true”に変更しましょう。 パラメータ変更 これにより、メッセージテンプレートや、アクションで設定したカスタマイズメッセージが投稿されるようになります。今回は、メディアタイプのメッセージテンプレートを修正してみましょう。 デフォルトのメッセージテンプレート デフォルトだと、英語で分かりにくいですね。情報を日本語に直してみましょう。 変更後のメッセージテンプレート 障害を起こしてみると、通知メッセージも日本語に変わっていました！ 通知メッセージ おわりに 今回は、Zabbixの障害通知をTeamsに送る方法を紹介しました。 Zabbixでは、Teams以外にもSlackなど様々なツールに障害通知を送ることができます。デフォルトで用意されているもの以外にも、スクリプトを作り込めば あらゆるツールと連携して障害通知を送る ことも可能です。 障害通知は、監視ツールにおける重要な要素 です。 ご希望の通知を実装する方法や、通知をカスタマイズする方法など、お困りの点がありましたら、ぜひ弊社までお声がけください！ お問い合わせ 製品・サービスについて 入力 ｜ SCSK株式会社 SCSK株式会社 製品・サービスについてご意見・ご質問をお受けしております。 www.scsk.jp 最後まで読んでいただき、ありがとうございました。明日のアドベントカレンダーもお楽しみに！ 弊社ではZabbix関連サービスを展開しています。以下ページもご参照ください。 ★Zabbixの基礎をまとめたeBookを公開しております！★ FAQ・お問い合わせ｜SCSK Plus サポート for Zabbix 導入をご検討される際、よくあるご質問と回答についてまとめております。 www.scsk.jp ★SCSK Plus サポート for Zabbix★ SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします。 www.scsk.jp ★YouTubeに、SCSK Zabbixチャンネルを開設しました！★ SCSK Zabbixチャンネル SCSK Zabbixチャンネルでは、Zabbixのトレンドや実際の導入事例を動画で解説。明日から使える実践的な操作ナレッジも提供しており、監視業務の効率化に役立つヒントが満載です。 最新のトピックについては、リンクの弊社HPもしくはXアカ... www.youtube.com ★X（旧Twitter）に、SCSK Zabbixアカウントを開設しました！★ https://x.com/SCSK_Zabbix x.com

はじめに 前回 はCortex CloudをAWSに接続し、アラートを取得しました。 今回はそのアラートに相当するCaseとIssueのステータスの変更をしてみようと思います。 CaseとIssueについて Cortex CloudにおけるアラートはIssueと呼ばれ、1つの検知ルールを違反した1リソースに対して、生成されます。CaseはAIと機械学習によって集約・分析・優先順位付けしたIssueのまとまりのことです。CNAPP製品では一般的に大量にアラートが発生し、対処しきれないという課題があり、Cortex CloudではIssueをCaseでまとめて本当に対処しなければならないアラートに集中できる仕組みが用意されています。そのため、Cortex CloudではCaseに対応するのが基本コンセプトとなっています。 ステータスの変更 ここから実際にCaseとIssueのステータス変更を行っていこうと思います。 Caseのアラートステータスの変更 1. 左ペイン 「Cases & Issues」>「Cases」に移動します。 2. ステータスを変更したいCaseを右クリックし「Change Status」にカーソルを合わせると以下画像の様に 「New」「In Progress」「Resolved」の3つが表示されます。 3. 今回は3つのステータスの中の「Resolved」を押下します。     押下すると以下画像の様に遷移します。 Mark This Case As: リストの中から対応するステータスの変更理由を選びます ケースのリストの説明は以下URLから対応したステータスの変更理由を選択してください 解決理由 説明 Resolved – True Positive そのCaseおよびIssueは、Cortex Cloudによって実際の脅威として正確に特定され、正常に処理・解決されました。 ※True PositiveおよびFalse Positiveとして解決されたケースと問題は、Cortex Cloudが将来のCaseとそれに関連する問題を解決済みのCaseと比較することで、お客様の環境における真の脅威を特定するのに役立ちます。そのため、将来のケースの処理とスコアリングは、これらの解決内容に影響を受けます Resolved – False Positive そのCaseおよびIssueは、実際の脅威ではありません。 ※CaseをTrue PositiveおよびFalse Positiveとして解決すると、Cortex Cloudは解決済みのCaseと将来のCaseおよび関連Issueを比較し、お客様の環境における真の脅威を特定するのに役立ちます。そのため、将来のCaseの処理とスコアリングは、これらの解決結果に影響を受けます。 Resolved – Security Testing このCaseおよびIssueは、BAS（Breach and Attack Simulation）、ペネトレーションテスト、レッドチーム活動といった、セキュリティテストやシミュレーション活動に関連しています。 Resolved – Known Issue そのCaseおよびIssueは既存の問題や、すでに処理されている問題に関連しています。 Resolved – Duplicate Case そのCaseおよびIssueは別の事件と重複しています。 Resolved – Risk Accepted このCaseおよびIssueは、既知の緩和策や影響に関連しています。 Commnet:コメントを入力 Also mark all issues as resolved: Case内Issuesをすべてresolvedにしたい場合はこれにチェックマークを入れてください。 入力後「Resolve」を押下してステータスの変更は完了です。 Caseのステータスの変更後の確認 変更後赤線のように「Resolved – <選択したケース>」になっていると思います。 今回はSecurity Testingを選択したので「Resolved – Security Testing」になっています。 上記画像の右側の赤線の「Resolved – Security Testing」の右にあるアイコンをクリックすると以下画像の様に遷移し Resolvedにしたときのコメントが確認/変更できます。 Also mark all issues as resolvedにチェックを入れた場合の確認 Case内IssueがすべてResolvedになっているかを確認します。 ※Also mark all issues as resolvedがチェックが入っている状態でResolvedにした場合の確認方法です 1. 左ペイン 「Cases & Issues」>「Cases」> 対象のケースをクリックし「Issues & Insights」に移動します。 2. 確認したいIssueを押下します。 押下すると以下画像の様に開いて、Statusが「Resolved」に変更されていることが確認できます。 Issuesのステータス変更 1. 左ペイン 「Cases & Issues」>「Issues」に移動します。 2. 対象のステータスを変更したいIssueに対して右クリックをします。 同じく「Change Status」>「Resolved」を押下します。 3. 押下するとCaseのステータスの変更と同じ画面が出てきます。 Mark This Case As: リストの中から対応するステータスの変更理由を選びます ケースのリストの説明は以下URLから対応したステータスの変更理由を選択してください 解決理由 説明 Resolved – True Positive そのCaseおよびIssueは、Cortex Cloudによって実際の脅威として正確に特定され、正常に処理・解決されました。 ※True PositiveおよびFalse Positiveとして解決されたケースと問題は、Cortex Cloudが将来のCaseとそれに関連する問題を解決済みのCaseと比較することで、お客様の環境における真の脅威を特定するのに役立ちます。そのため、将来のケースの処理とスコアリングは、これらの解決内容に影響を受けます Resolved – False Positive そのCaseおよびIssueは、実際の脅威ではありません。 ※CaseをTrue PositiveおよびFalse Positiveとして解決すると、Cortex Cloudは解決済みのCaseと将来のCaseおよび関連Issueを比較し、お客様の環境における真の脅威を特定するのに役立ちます。そのため、将来のCaseの処理とスコアリングは、これらの解決結果に影響を受けます。 Resolved – Security Testing このCaseおよびIssueは、BAS（Breach and Attack Simulation）、ペネトレーションテスト、レッドチーム活動といった、セキュリティテストやシミュレーション活動に関連しています。 Resolved – Known Issue そのCaseおよびIssueは既存の問題や、すでに処理されている問題に関連しています。 Resolved – Duplicate Case そのCaseおよびIssueは別の事件と重複しています。 Resolved – Risk Accepted このCaseおよびIssueは、既知の緩和策や影響に関連しています。 Commnet:コメントを入力 入力後「Resolve」を押下してステータスの変更は完了です。 Issueのステータス変更後確認 1. 変更したIssueを押下すると以下画像が見れます。     左のStatusが「Resolved」に変更されていることが確認できます。   ResolvedとしたCaseを戻したい 変更後に再度Openにした時もあると思います。 ResolvedとしたCaseを戻す方法をCaseを使用して説明していこうと思います。 ※Issueも手順は同様です。 1. 左ペイン 「Cases & Issues」>「Cases」に移動します。 2. 対象のResolvedになったCaseに対して右クリックをし「Change Status」>「New」を押下します。 3. 押下後赤線部分のStatusが「New」に変わっていることがわかります。 これでResolvedとしたCaseを戻すことができました。 おわりに 今回はアラート(Cases & Issues)のステータスを変更してみました。 他にもSeverity(重要度)の変更やCaseやIssueにアサインするユーザーを選択することができます。 当社では、複数クラウド環境の設定状況を自動でチェックし、設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。 マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 ご興味のある方は是非、お気軽にお問い合わせください。

Catoクラウドへ接続するための専用デバイスであるCato Socketについて、 初期設定にまつわる新機能が実装されました。本記事では、その紹介を行います。 はじめに：Cato Socketと初期設定 Catoクラウドに限らず、SASEはサービスへ接続するための何らかの手段が必要となります。 Cato Socketは、各種オフィスなどの物理拠点向けにCatoが提供しているエッジデバイスです。 これを拠点へ配置、接続することで、Socket配下の機器からCatoクラウドへ接続可能となります。 いくつかのモデルが存在しており、下記の記事で詳しく説明されています。 【Catoクラウド】Socket X1500, X1600, X1700の仕様比較・選択方法 この記事では Cato Socketの物理デバイス3モデル（X1500 / X1600 / X1700）について解説しています。 blog.usize-tech.com 2025.05.26 一般的なアプライアンスで言うところのルータ、ファイアウォールに相当する役割を持つSocketは、 「ゼロタッチデバイス」 として簡単に設定できることをウリにしています。 各地に支店や事業所を持つお客様の場合、支店にはネットワークやITに詳しいメンバーがおらず、支店メンバーで設定の対応を行うというのは難しい……というご相談をよくいただきます。 これまでも現地での配置におけるやり取りはかなり低減できていたのですが、今回の新機能で「現地では本当に差し込むだけ」の導入が可能になりました！   新機能：Cato Socketの事前アサイン 従来のアサイン方法 従来、到着したCato Socketを接続するSiteにアサインするためには、 「Socketを現地でインターネットに接続してから、CMAの[Notification]に現れる通知を使用する」 という手順を踏む必要がありました。 IPsecの設定のような複雑な設定こそ必要としないものの、Socket配下とは別でインターネットへ接続できる（CMAにアクセスできる）機器やCMAを操作できるメンバーを配備する必要があり、場合によっては現地メンバーにCMAのアクセス方法から説明しなければならない（あるいは、本社のシステム担当者が出張対応ということも……）ケースが考えられました。 Socketの事前アサイン 今回、新機能としてSocketの事前アサインが実装されました。 これは、実物のSocketが インターネットに接続されていない状態で、手元に無くとも （発送中でも！）事前にSiteへの紐づけを行えるという機能です。 CMAの[Account] > [Sockets & Accessories]にて、ご利用のアカウント向けに提供されたSocketの一覧を確認できます。 この画面の「Site」列に、Siteへの割り振りが行われていないSocketは「Assign to Site」というリンクが表示されます。 このリンクをクリックすることで、従来の手順と同じように当該のSocketをSiteへアサインすることが可能です。   ゼロタッチを目指すSocket配置フローチャート 今回の新機能を踏まえて、「Socketを配置する現地での作業を極力無くす」を目標として、どのような対応をすれば良いのか、簡単に流れを説明していきます。 必要な設定は本社のような技術者のいる拠点でまとめて行い、その後各拠点へ配備するような形となります。 ① Socketの発送先決定 Cato Socketを注文する上で、発送先を指定することになります。 拠点現地での作業を減らす前提においては、接続の方式で指定すべき発送先が変わります。 Cato Socketは、DHCP / 固定IP / PPPoE の3種類のWAN接続方式に対応しています。 DHCP接続を使用する場合： この場合は、個別の設定は必要ありません。使用する予定の拠点宛に、直接発送を依頼して問題ありません。 固定IP / PPPoEを使用する場合： この場合、Socket本体に直接設定を行う必要があります。 いちど設定作業を実施できる拠点に発送を依頼し、設定を行った後で使用予定拠点へ自前で送ることになります。 ② SocketのNW設定実施 固定IPまたはPPPoEでの接続を行う場合、Socket本体に対して設定を行う必要があります。 この設定は、残念ながらSocketの到着前に実施することはできません。Socket使用予定の拠点で作業を行わない場合は、一度設定作業用の拠点でSocketを受け取り、そこで設定作業を実施することになります。 Socketが手元にありさえすれば、インターネット接続が無くても設定は可能です。 まず、事前作業として設定作業用PCを用意し、IPアドレス設定以下のように変更します。 IPアドレス：169.254.100.2 サブネットマスク：255.255.0.0 次にLANケーブルを用意し、Socketのモデルに応じた以下のポートにLANケーブルで接続します。 X1500：2番ポート X1600：6番ポート X1700：MGMTポート Socketを電源に接続してから（電源接続により、自動でONになります） 任意のブラウザで「https://169.254.100.1」にアクセスします。 デフォルトパスワードは以下の通りです。 ユーザ：admin パスワード：admin Socket Web UIが開くので、上のタブから「Network Settings」に移動します。 利用する接続方式に応じて、「WAN1 → Cato」の設定を変更しましょう。 ③ 設置拠点へ配送 Socket本体へのNW設定を済ませたら、実際に利用する拠点へSocketを送ります。 これは、発送手配などお客様自身で行う必要があります。 ④ CMA上で事前アサイン 利用する拠点へのSocket配送が開始されたら、CMAの[Account] > [Sockets & Accessories]にて、当該のSocketを利用予定のSiteへ割り振ります。これはCMA上での作業なので、インターネットにさえ繋がっていればどこからでも実施可能です。 ⑤ Socketを接続 これまでの準備が完了していれば、利用する拠点にSocketが到着した後 WANポートをインターネットに、LANポートを拠点内につなげるためのスイッチやハブに接続するだけでCato接続の準備が整います。 正常に繋がっているかどうかは、CMAから確認することが可能です。 CMAの[Network] > [Sites]から、当該Siteが「Connected」となっていることを確認しましょう。 これで、新拠点へのSocket配備は完了です。 現地で行うことは「ケーブルをつなぐ」だけなので、1か所で複数の拠点向けのSocket事前設定をまとめて行い、後は各地に配送して状況をCMAでチェックするだけ、という流れで簡単にSocketを配備することができます。   まとめ 本記事では、Socketの初期設定にまつわる新機能追加について紹介しました。 地味な機能ではあるのですが、特に複数の拠点を持つお客様の場合は拠点毎に行わなければならない作業が減るため、なかなか侮れないアップデートとなっています。新しくSocketを配置する予定がある場合、ぜひご利用ください。

(※本記事は、2025年11月時点の内容となります) LifeKeeperでは、製品購入後に充実した保守サポートをご提供していますが、 導入したOSやバージョンにより、サポートの種類や期間が異なるため、 複雑でどれを選べばよいか迷われる方も多いのではないでしょうか。   LifeKeeperとしては、2025年11月11日に最新バージョンであるv10のリリースがございましたが、 旧バージョンであるLinuxのv9、Windowsのv8 をご利用しており、 引き続き、現行バージョンにて長きに渡り利用されるケースも多くあるため、 本記事では、旧バージョンにおけるLifeKeeperのサポート体系の全体像と、「ライフサイクル延長」「ライフサイクル延長プラス」に焦点を当てて解説します。   LifeKeeperのサポート概要と種類について そもそもLifeKeeperのサポートは、「サポートの種類」と「サポートの期間」の二つの考え方があります。 サポートの種類としては、以下となります。   サポート種類 概要 1 標準サポート 平日日中サポート（平日 9時～17時半） 2 Premiumサポート 24時間365日サポート システム停止などの重大な障害時の対応 etc… 3 拡張Premiumサポート 24時間365日サポート ※Premiumサポートの上位サポート システム停止時の障害対応＋システム稼働時の障害対応etc… 4 拡張Premium++サポート 24時間365日サポート ※拡張Premiumサポートの上位サポート 拡張Premiumサポートの内容＋4時間以内回答の対応など 詳細なサポート内容の違いなどについては、以下記事をご参照下さい。 どれを選べば良いの？LifeKeeperのサポート種類について解説します – TechHarmony   サポートの期間については、以下となります。    サポートフェーズ サポート内容 サポート終了日 1 フルサポート 未知の製品不具合に対するパッチを作成し提供する。 最新バージョンのリリースから３年間 2 メンテナンスサポート 既知の不具合に対するパッチを提供する。本フェーズ以降に発見された未知の不具合については最新バージョンへのアップデートを案内する。 製品のフルサポート終了日から２年間 3 ライフサイクル延長 標準のサポート契約に加え「ライフサイクル延長サポート」もご契約いただいた際、メンテナンスサポートと同レベルのサポートを提供する。 製品のメンテナンスサポート終了から５年間 4 ライフサイクル延長プラス ライフサイクル延長期間が終了したバージョンに対して、更にサポートを延長利用いただくための契約オプション。 ※拡張Premium ++サポートをご購入頂いているお客様は『ライフサイクル延長』および『ライフサイクル延長プラス』が付帯しております 契約が継続される限り、長期的な利用が可能です。   LifeKeeper for Linux ver.9.4　を例にとると、以下のような期間となります。   サポートフェーズはLinuxかWindowsかなどで変わってくるため、 概要と詳細については、以下記事をご確認下さい。 LifeKeeperのプロダクトライフサイクル(サポート)を解説します – TechHarmony     「ライフサイクル延長」と「ライフサイクル延長プラス」について ここからが本題ですが、 本記事では、サポート内容の中にある「ライフサイクル延長」と「ライフサイクル延長プラス」という製品についてフォーカスを当てて解説をしていきます。 まず、「ライフサイクル延長」と「ライフサイクル延長プラス」とは一言で説明すると、 製品のメンテナンスサポート期間が終了したバージョンに対して、サポートを継続するための有償オプションです 両者は似たような名前ですが、違いとしては以下のような内容があります。 項目 ライフサイクル延長 ライフサイクル延長プラス 対象 メンテナンスサポート期間が 終了したバージョン ライフサイクル延長期間が 終了したバージョン 契約開始日 延長開始日まで遡って契約が必要 – 例：2022/07/01に契約しても、延長開始日が2021/08/01ならその日から契約扱い 遡及契約は不要 （契約開始日以降でOK） 延長期間 Windows版：最大2年 Linux版：最大5年 契約が継続される限り、長期的な利用が可能です。 提供内容 メンテナンスサポートと同等の技術支援 インストールガイダンス、既知の不具合対応、最新バージョンへの案内など メンテナンスサポートと同等の技術支援 ライフサイクル延長と同様の技術支援 契約単位 1ヶ月単位 1ヶ月単位 定価 6,800円 10,200円   注意点としては、使用するノード数分の購入が必要になってきます。 つまり、１か月単位での購入となるので、「ライフサイクル延長」を購入する場合、 ２台構成の環境で１２か月分購入するとなると、、、 2台　×　12か月　×　6,800円(定価)　＝　163,200円 ほどが定価ベースでかかってくるイメージです。 ※実際の価格につきましては、契約条件や割引などにより異なる場合があります。   ライフサイクル延長を購入しないとどうなる？ 購入しない場合、 障害発生時のテクニカルサポートが受けられない 新バージョンの利用不可(アップデートの提供が停止) ハードウェア交換時のライセンス再発行不可 などのサポートの提供が受けられない状況になります。 基本的にLifeKeeper利用者の方は購入されますが、 購入されないお客様の理由として環境自体が撤廃するなどのことがあると購入しないパターンがあります。   切替や購入タイミングのシミュレーション 実際にライフサイクル延長とライフサイクル延長プラスを購入するタイミングや費用のシミュレーションをしてみたいと思います。 今回は、LifeKeeper for Linux v9.5.2を2021年9月1日から利用しており、 1年ずつ保守更新をしている環境を想定していきます。 v9.5.2のライフサイクルについては以下の通りです。 バージョン リリース日 フルサポート終了日 メンテナンスサポート終了日 ライフサイクル延長終了日 V9.5.2 2021年8月 2024年10月末 2026年10月末 2031年10月末   レッツ、シミュレーション🎮 年度（期間） 保守サポート内容 ライフサイクル延長購入期間 備考 2021年9月1日～2022年８月末 保守サポート – 最新バージョンがリリースされてから5年間は通常の保守サポート利用のみで問題ないです。 2022年9月1日～2023年８月末 保守サポート –   2023年9月1日～2024年８月末 保守サポート –   2024年9月1日～2025年8月末 保守サポート – メンテナンスサポートが2026年10月末に切れるため、次回の更新時にはライフサイクル延長が必要となります。 契約が切れる前に、ライフサイクル延長を含めた次回更新時の内容を見積し、次の更新に備えます 2026年9月1日～2027年8月末 保守サポート ライフサイクル延長 10か月 (購入の開始月：2026年11月1日～) この更新時期に、ライフサイクル延長の購入をします。 ライフサイクル延長は1か月単位での購入が可能となりますので、この時期の契約では2027年8月末での更新となるので、 10か月間 のライフサイクル延長の購入が必要になります。 2027年9月1日～2028年8月末 保守サポート ライフサイクル延長 12か月 ライフサイクル延長の購入期間が 12か月 必要となります。 2028年9月1日～2029年8月末 保守サポート ライフサイクル延長 12か月   2029年9月1日～2030年8月末 保守サポート ライフサイクル延長 12か月   2030年9月1日～2031年8月末 保守サポート ライフサイクル延長 12か月   2031年9月1日～2032年8月末 保守サポート ライフサイクル延長 ライフサイクル延長プラス 2か月 10か月 ついにライフサイクル延長のサポート期間が終了を迎えたので、ライフサイクル延長プラスの購入が始まります。 2031年10月末にサポート終了となるので、2031年11月1日～2032年8月末までの 10か月分 を購入します。 なお、ライフサイクル延長やライフサイクル延長プラスを購入するにあたり何か特別な申請などは不要なので、 通常の保守更新時にライフサイクル延長分の費用を見積もっていただければ問題ございません。   最後に LifeKeeperの延長サポート内容について解説を行いました。 運用中のバージョンや契約状況、ご利用の環境の事情などにより、最適な対応策は異なります。 今回の内容を参考に、LifeKeeperの運用についてご確認・ご相談をいただければと思います。 詳しい内容をお知りになりたいかたは、以下のバナーからSCSK  Lifekeeper公式サイトまで    

こんにちわ、田原です。 お客様対応でpostgresqlの バキューム処理 について調査する機会があり、 まとめましたので、内容を紹介します。 なぜpostgresqlにバキューム処理が必要なのか postgresqlには以下の点を解決するため、バキューム処理が実装されています。 PostgreSQLのMVCC（Multi-Version Concurrency Control）の影響 PostgreSQLは同時実行制御にMVCC（Multi-Version Concurrency Control）を使用しており、 これが「デッドタプル」を生成する原因となります。 UPDATE操作 : 既存の行を物理的に更新せず、新しいバージョンの行を作成し、古い行を「デッド」としてマーク DELETE操作 : 行を物理的に削除せず、削除マークを付けるだけ      この場合、デッド、削除マークの領域はそのままpostgresql管理として残っていて、 OSに領域を返すということはありません。 また、Insertやupdateを実行しても、その領域を再利用されることはなく、 残り続けてしまいます。 上記の動作から以下の問題点があります。 パフォーマンスの劣化 テーブルサイズの肥大化により、スキャン時間が増加 インデックスも肥大化し、検索効率が低下 ディスク容量の無駄遣い システムリソースの圧迫 不要なディスクI/O増加 メモリ使用量の増加 バックアップ時間の延長 統計情報の最新化 データの変動があった場合、統計情報を最新化しないと適切な実行計画が立てられず、パフォーマンスが劣化する可能性が高くなります。 そのため、システムを解析して統計情報を最新化する必要があります。 バキューム処理の役割と種類 ・データベースの不要領域 ・統計情報の最新化 前述の課題を解決するため、バキューム処理が用意されており、実行する必要があります。 また、バキューム処理にも以下の種類がありますので、そちらを役割ごとに説明していきます。 バキューム処理 ---+--- 自動実行 --- 自動バキューム処理(AUTO VACUUM)                   |                 +--- 手動実行 --- VACUUM コマンド ---+--- 標準 VACUUM                                                   |                                                     +--- VACUUM FULL ※VACUUMコマンドのオプションの一つという扱い データベースの不要領域の回収 バキューム処理は、デッドタプルとなっている領域を回収します。 ※タプル　　　：データベースでは「レコード」のこと。 ※デッドタプル：レコードから削除や更新されて非表示となったレコードのこと。 自動バキューム処理(AUTO VACUUM) 領域を回収し、再利用可能な状態に変更します。(デッドタプルにする)。 排他的ロックを取得しないため、テーブルへの通常の読み書き操作と並行して実行することが可能です。 しかし、余った領域は OS には(ほとんどの場合)返されず、同じテーブル内で再利用できるように保持されるだけとなります。 索引に対しても同様の効果があります。 自動バキューム処理の注意点 CREATE TEMP TABLE で作成された一時表に関しては処理の対象から外れる。 パーティション化テーブルに対して ANALYZE コマンドを発行しない。 標準 VACUUM 動作は「自動バキューム処理」と同じです。 ※一般的に管理者は標準 VACUUM を使用してください。。 【コマンド例】vacuum <テーブル名>; VACUUM FULL テーブルの内容全体を新しいディスクファイルに領域を余すことなく書き換えて、 OS に未使用の領域を返します。 合わせて索引の再構築も実施されます。 以下の点に注意が必要です。 ・実行速度がかなり低速。 ・処理中のテーブルに対する「排他ロック」が必要。 ※一般的に管理者は VACUUM FULL の使用を避けるべきです。 【コマンド例】vacuum full <テーブル名>; 統計情報の取得 より良い実行計画を作成するのに、テーブルに関する統計情報が必要です。 ANALYZE コマンドで統計情報を取得することができますが、バキューム処理も同様に取得が可能となっています。  自動バキューム処理(AUTO VACUUM) テーブルの内容が大きく変更されたときはいつでも自動的に ANALYZE コマンドを実施して、統計情報を取得します。 なお、パーティション化テーブルに対しては、ANALYZE コマンドを実施しません。 標準 VACUUM VACUUM 単独では実施されません。 オプションの「ANALYZE」を付与する必要があります。 もちろん、このオプション付きで実施することで、「不要領域の回収」と「統計情報の取得」が行われます。 VACUUM FULL 意外と思いますが、VACUUM FULL だけでは実施されません。 オプションの「ANALYZE」と一緒に実行する必要があります。 　【コマンド例】vacuum full analyze <テーブル名>; vacuum analyze full <テーブル名>; で実行するとエラーになります。 vacuum full analyze <テーブル名>; で実行すると、内部では vacuum full → analyze の順番で実施されています。(実行時を監視した結果より判断しています。) VACUUM FULL と REINDEX の違い VACUUM FULLとREINDEXの双方とも索引の再構築が実施されます。 索引の再構築中の出力例 postgres=> select * from pg_stat_progress_cluster; -[ RECORD 1 ]-------+----------------- pid | 2119 datid | 5 datname | postgres relid | 106524 command | VACUUM FULL phase | rebuilding index ★ cluster_index_relid | 0 heap_tuples_scanned | 15436442 heap_tuples_written | 15436442 heap_blks_total | 237483 heap_blks_scanned | 237483 index_rebuild_count | 2 なお、VACUUM FULLとREINDEXコマンドでは目的や対象が異なります。 また、索引が破損した場合はVACUUM FULLでは対応できません。 ■VACUUM FULL 目的：ディスクスペースの回収 対象：テーブルと索引 索引の破損：修復不可 ■REINDEX 目的：索引の再作成 対象：索引 索引の破損：修復を試行 関連ビュー pg_stat_all_tablesビュー VACUUM と ANALYZE を実行したタイミングを確認できます。 select relname , last_vacuum , last_autovacuum , last_analyze , last_autoanalyze  from pg_stat_all_tables where relname = ‘<テーブル名>’ ; 各列の説明 列 説明 last_vacuum テーブルが手作業で VACUUM された最終時刻 （VACUUM FULLは含まれない） last_autovacuum AUTO VACUUM の影響によりによりテーブルが VACUUM された最終時刻 last_analyze 手動でテーブルを ANALYZE した最終時刻 last_autoanalyze AUTO VACUUM の影響により自動でテーブルを ANALYZE した最終時刻 pg_stat_progress_vacuumビュー VACUUM の進捗状況を確認するビューです。 ただし、VACLUUM FULL に関しては pg_stat_progress_clusterビュー側で確認する必要があります。 phase 列の出力※マニュアル抜粋 フェーズ 説明 initializing VACUUM は、ヒープをスキャンし始める準備をしています。 このフェーズは、非常に短時間であると予想されます。 scanning heap VACUUM は、現在ヒープをスキャン中です。 必要であればそれぞれのページを切り取り、デフラグし、場合によってはフリーズ活動を実行します。 スキャンの進捗状況の監視に heap_blks_scanned 列が使用できます。 vacuuming indexes VACUUM は、現在インデックスをバキューム処理中です。 テーブルにインデックスが存在する場合、ヒープが完全にスキャンされた後に、バキューム実行ごとに少なくとも１回発生します。 maintenance_work_mem が、発見された無効タプルの数量を格納するのに不十分な場合（または、自動バキュームの場合は autovacuum_work_mem が設定されている場合）は、バキューム実行ごとに複数回発生する可能性があります。 vacuuming heap VACUUM は、現在ヒープをバキューム処理中です。 ヒープのバキュームは、ヒープのスキャンと異なり、インデックスをバキューム処理するそれぞれのインスタンスの後に発生します。 heap_blks_scanned が heap_blks_total より少ない場合、システムはこのフェーズの完了後にヒープのスキャン処理に戻ります。 さもなければ、このフェーズの完了後にインデックスの整理を始めます。 cleaning up indexes VACUUM は、現在インデックスの整理処理中です。 これは、ヒープが完全にスキャンされ、インデックスとヒープが完全にすべてバキューム処理された後に発生します。 truncating heap VACUUM は、現在リレーションの終点の空のページをオペレーティングシステムに戻すためにヒープを切り詰めています。 これは、インデックスの整理処理後に発生します。 performing final cleanup VACUUM は最終クリーンアップを実行しています。 このフェーズ中に、 VACUUM は空き領域マップをバキュームし、 pg_class 内の統計を更新し、累積統計システムに統計を報告します。 このフェーズが完了すると、 VACUUM は終了します。 pg_stat_progress_clusterビュー VACUUM FULL の進捗状況を確認するビューです。 ビューの名称から主に CLUSTER コマンド用ですが、VACUUM FULL は CLUSTER の一種のため、 このビューで進捗状況を確認します。 phase 列の出力※マニュアル抜粋 フェーズ 説明 initializing コマンドはヒープのスキャンを開始する準備をしています。 本フェーズはごく短時間になると予想されます。 seq scanning heap コマンドは現在、テーブルをシーケンシャルスキャンを使ってスキャンしています。 index scanning heap CLUSTER は現在、インデックススキャンを使ってテーブルをスキャンしています。 sorting tuples CLUSTER は現在、タプルをソートしています。 writing new heap CLUSTER が新しいヒープに書き込んでいます。 swapping relation files コマンドは現在、新たに構築したファイルを置き換えて設置しています。 rebuilding index コマンドは現在、インデックスを再構築しています。 performing final cleanup コマンドは現在、最終クリーンアップを実行中です。 このフェーズが完了すると、 CLUSTER や VACUUM FULL は終了します。 pg_stat_progress_analyzビュー ANALYZE の進捗状況を確認するビューです。 VACUUM ANALYZE や VACUUM FULL ANALYZE のうち、ANALZYE フェーズはこちら側で進捗を確認する必要があります。 phase 列の出力※マニュアル抜粋 フェーズ 説明 initializing コマンドはヒープをスキャンし始める準備をしています。 このフェーズは非常に短時間であると予想されます。 acquiring sample rows コマンドはサンプル行を得るため、 relid で指定されたテーブルを現在スキャンしています。 acquiring inherited sample rows コマンドはサンプル行を得るため、子テーブルを現在スキャンしています。 列 child_tables_total 、 child_tables_done 、 current_child_table_relid はこのフェーズの進捗情報を含みます。 computing statistics コマンドはテーブルスキャンの間に得られたサンプルから統計情報を計算しています。 computing extended statistics コマンドはテーブルスキャンの間に得られたサンプルから拡張統計情報を計算しています。 finalizing analyze コマンドは pg_class を更新しています。 このフェーズが完了すれば、 ANALYZE は終わります。 最後に vacuum処理は意外と奥が深く、postgresqlにはなくてはならないものだと感じました。