本記事は 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にはなくてはならないものだと感じました。

こんにちは、石原です。 最近、PostgreSQL で実行計画を見る機会が多かったため、そこから気になった内容について記載していこうと思います。 今回は「INDEX ONLY SCAN」について触れていきます。 ※本内容で載せる検証結果は、AWS RDS (PostgreSQL 15.12) 上で実施した内容となります。 実行計画 一般的なところからになりますが、クエリの実行において正しい結果を返すことは当然ですが、クエリを投げてから結果を返すまでの時間が変化することがあります。 色々な要因によって変化はしますが、その中でも重要なのが「実行計画」です。 ユーザーがクエリを投げた際、内部では受け取ったクエリの内容を分析し、「どのようにテーブルを確認するべきか」、また「どの順番で結合させていけば良いのか」など、いち早く結果を返す方法を中で計算して道のりを示してくれるのが「実行計画」です。 本内容では、その中の「どのようにテーブルを確認するべきか」の部分に注目します。 索引の有無 テーブルを確認する方法としてよくあるのが「索引」を用いるか否かです。 一般的に索引を用いることでクエリのパフォーマンスが上がることがあります。 クエリの条件やテーブルのレコード数などにもよりますが、特定のレコードを探そうとした場合、索引が存在しない場合はテーブルをフルスキャン(すべてのレコードをチェック)する動作となる分、不要なブロックアクセスを行うため遅延を招きます。 索引が存在する場合、索引作成時に指定した列の情報を使って、目的のレコード情報をテーブルフルスキャンするよりも早く探し出すことができる可能性があります。 索引作成時に指定した列の値を索引自体が持つので条件などによっては、テーブルへのアクセスを行わずに結果を返すことも可能となります。 なお、索引に実データが入っていることを確認する方法として「 bt_page_items 」の data 列から確認可能です。 以下の場合、索引で用いている ID1 と ID2 に対して 3 と 9 をデータとして挿入しています。 結果として、data 列に 3 と 9 の出力を確認することができます。 ---サンプル表の作成 postgres=> create table exam3(id1 integer,id2 integer,name text); CREATE TABLE ---複合索引の作成 postgres=> create index exam3idx1 on exam3(id1,id2); CREATE INDEX ---データの挿入 postgres=> INSERT INTO exam3 values (3,9,'AAA'); INSERT 0 1 ---索引の確認 postgres=> select * from bt_page_items('exam3idx1',1); itemoffset | ctid | itemlen | nulls | vars | data | dead | htid | tids ------------+-------+---------+-------+------+-------------------------+------+-------+------ 1 | (0,1) | 16 | f | f | 03 00 00 00 09 00 00 00 | f | (0,1) | (1 row) 索引を使った検索 索引を使用した検索は大きく二つに分けられます。 通常の INDEX を使った検索 (INDEX→TABLE にアクセスする) 以下の流れでアクセスを行います。 TABLE にアクセスが必要な分、処理時間が長くなります。 ①INDEX を使って対象の行を探す。 ②ヒープ（TABLE のデータ領域）にアクセスして実際のデータを取得する。 INDEX ONLY SCAN（INDEX だけで完結） ヒープにアクセスせずに INDEX だけで必要なデータを取得できます。 これにより、TABLE アクセスを行う必要がないため、検索が高速になります。 INDEX ONLY SCAN が使用できる条件 検索が早くなる INDEX ONLY SCAN はどうしたら使用されるようになるのでしょうか。 まとめると以下の条件を全て満たす必要があります。 ※条件を満たしても、内部の計算で INDEX ONLY SCAN よりも別の方法の方が早いと PostgreSQL が判断した場合はそちらが選ばれます。 索引の種類が対応していること B-tree 索引は常に対応しています。 他の索引は非対応ですが、GiST や SP-GiST は一部の演算子クラスのみ対応しています。 クエリが索引に含まれる列だけを参照していること 索引で完結するということは、索引作成時に指定した列情報だけでクエリが完結している必要があります。 以下の例の場合、ID1 列と ID2 列の索引を作成していますが、実行したクエリにおいて ID1 と ID2 のみで完結している場合、INDEX ONLY SCAN が確認できます。 しかしながら、索引に含まれていない ID3 を使用するクエリの場合はINDEX ONLY SCAN にはなっていません。 ※実行計画は、クエリ実行前に「 explain(analyze,buffers) 」といった記載を行うことで確認できます。 ---サンプル表の作成 postgres=> create table exam4(id1 integer,id2 integer,id3 integer); CREATE TABLE ---ID1とID2の複合索引を作成 postgres=> create index exam4idx1 on exam4(id1,id2); CREATE INDEX ---1000件挿入とVACUUMの実施 postgres=> INSERT INTO exam4 (id1,id2,id3) SELECT i,i,i FROM generate_series(1, 1000) as i; INSERT 0 1000 postgres=> vacuum exam4; VACUUM ---ID1とID2を利用したクエリ ⇒ INDEX ONLY SCAN になる postgres=> explain(analyze,buffers) postgres-> select id1,id2 from exam4 where id1=1; QUERY PLAN ---------------------------------------------------------------------------------------------------------------------- Index Only Scan using exam4idx1 on exam4 (cost=0.28..4.29 rows=1 width=8) (actual time=0.015..0.016 rows=1 loops=1) Index Cond: (id1 = 1) Heap Fetches: 0 Buffers: shared hit=3 Planning Time: 0.090 ms Execution Time: 0.032 ms (6 rows) ---ID1とID3を利用したクエリ ⇒ INDEX ONLY SCAN にならない postgres=> explain(analyze,buffers) postgres-> select id1,id3 from exam4 where id1=1; QUERY PLAN ----------------------------------------------------------------------------------------------------------------- Index Scan using exam4idx1 on exam4 (cost=0.28..8.29 rows=1 width=8) (actual time=0.019..0.021 rows=1 loops=1) Index Cond: (id1 = 1) Buffers: shared hit=3 Planning Time: 0.097 ms Execution Time: 0.036 ms (5 rows) 検索された各行が問い合わせのスナップショットに対して 「可視」 であること 実は実行計画上では上記の2つの条件を満たすことで「 Index Only Scan 」が選択される可能性が出てきます。 ここがこの INDEX ONLY SCAN のトラップとも言える個所です。 実行計画上で 「 Index Only Scan 」となっていても、実際は INDEX ONLY SCAN として 実行されていないことがある ということです。 ここで一度動作を整理しておきます。 INDEX ONLY SCAN の動作 ①索引にアクセスする ②「可視性マップ」でページの確認   　⇒ 「可視」となっている ⇒ ヒープを見に行かずに済む ⇒ 索引だけの検索になるため早い！   　⇒ 「可視」となっていない ⇒ ヒープを見に行く ⇒ テーブルアクセスが発生するため遅い！ 上記について補足します。 クエリを実行した場合、「読み取り一貫性」を実現する動きがあるため、単純に該当のテーブルの全レコード情報を対象としません。 トランザクションを意識し、そのセッションが見えてもよいレコード情報を元にして、そこから条件などによって返すべき結果が出力されます。 ただし、索引にはトランザクションの状況に関しては情報を持っていないため、厳密には索引だけで結果を返すことができません。 厳密に確認するためにテーブル(ヒープ)を見に行く必要がありますが、PostgreSQL ではそこに一工夫加えています。 それが「可視性マップ」です。 可視性マップとは各テーブルの更新状況を応じてページ単位で管理しています。 例えば、あるテーブルのあるページに属するレコードが更新されることによって可視性マップに更新がかかります。 具体的に以下をご確認ください。 ---①サンプル表の作成 postgres=> create table exam4(id integer,name text); CREATE TABLE postgres=> INSERT INTO exam4 (id,name) SELECT i,md5(random()::text) FROM generate_series(1, 241) as i; INSERT 0 241 postgres=> create index examidx4 on exam4(id); CREATE INDEX postgres=> vacuum exam4; VACUUM ---②可視性マップの確認 postgres=> select * from pg_visibility_map('exam4'); blkno | all_visible | all_frozen -------+-------------+------------ 0 | t | f 1 | t | f 2 | t | f (3 rows) ---③テーブルの状況 postgres=> select ctid,xmin,xmax,id from exam4; ctid | xmin | xmax | id ---------+-------+------+----- (0,1) | 62700 | 0 | 1　┓ (0,2) | 62700 | 0 | 2　┃ ： ┣ ページ：０ (0,119) | 62700 | 0 | 119　┃ (0,120) | 62700 | 0 | 120　┛ (1,1) | 62700 | 0 | 121　┓ (1,2) | 62700 | 0 | 122　┃ ： ┣ ページ：１ (1,119) | 62700 | 0 | 239　┃　 (1,120) | 62700 | 0 | 240　┛ (2,1) | 62700 | 0 | 241　━ ページ：２ (241 rows) ---④UPDATE の実行 postgres=> update exam4 SET id = 1 WHERE id = 1; UPDATE 1 ---⑤可視性マップの確認 postgres=> select * from pg_visibility_map('exam4'); blkno | all_visible | all_frozen -------+-------------+------------ 　　　0 | f　★　　　　 | f 　　　1 | t 　　　　　　| f 　　　2 | f　★　　　　 | f (3 rows) ---⑥テーブルの状況 postgres=> select ctid,xmin,xmax,id from exam4; ctid　　 | xmin　| xmax | id ---------+-------+------+----- ★1 (0,2) | 62700 | 0 | 2 ： (1,120) | 62700 | 0 | 240 (2,1) | 62700 | 0 | 241 (2,2) | 62717 | 0 | 1 ★2 (241 rows) ①サンプル表の作成   ここでは簡単なテーブル、索引の作成、レコードを241件挿入、vacuum を実行してます。 ②可視性マップの確認   「pg_visibility_map」より確認可能です。   blkno 列が各テーブルのページ番号、all_vasible 列が可視を判断する列です。   「t」は可視 OK, 「f」は可視 NG です。   この段階では全て「t」になっているのでテーブルアクセスは不要な状況です。 ③テーブルの状況   暗黙的に定義されたシステム列を指定しています。   ctid 列は（<ページ番号>, <レコード番号>）となっており、この行がどのページに属しているか確認することができます。   現在、0 ～ 2 ページを使用しており、これは可視性マップで確認した結果と関連付けることができます。 ④UPDATE の実行   データ上では変更ないが ID=1 を ID=1 へ UPDATE しています。   理由については⑥をご参照ください。 ⑤可視性マップの確認   UPDATE の実行により、可視性マップに変化が確認できます。   ページ番号が 0 と 2 の可視性が t から f へと変わっています。 ⑥テーブルの状況   1 から 1 へ UPDATE しましたが、内部では元々あったレコード(★1)を消し、1 のレコードを追加(★2)する動きをします。   ★1 のレコードはページ番号1、★2 のレコードはページ番号2 に属しています。   結果、ページとしては更新があったと認識し、可視性マップでは可視ができない状態へと変更が行われています。 まとめると、可視性マップは各ページに属するレコードが1つでも更新があれば「可視」NG となる動作です。 つまり、「可視」とは更新がないページのことであり、更新がないからわざわざヒープを確認する必要がないため、そのまま索引で確認できた結果を使って返せばよいということがわかります。 また更新があれば、テーブルアクセスが必要になってしまうという動作となります。 よって実行計画を立てる段階では、可視性マップを確認することがないため、一旦は 「 Index Only Scan 」を選択しますが、実際は実行タイミングで可視性マップをみて判断を行っている状況です。 実行計画上における判断 実行計画上から、「 Index Only Scan 」になっているが、実際にヒープアクセスの有無はどのように判断するべきか説明します。 以下は上記の続きとして WHERE 句に特定の値を指定して実行計画を出力させたものです。 単純に実行しただけではレコード数が少ない分、INDEX ONLY SCAN の条件を満たしてもその通りにならないため、ヒント句も使用しています。 では、判断箇所ですが一緒に出力されている「 Heap Fetches 」になります。 この値が 1 以上であれば、ヒープアクセスを行っていることになります。 上記の pg_visibility_map の結果から、ページ番号が 0 および 2 は all_visible 列の値が f となり、1 は t となっています。 それを踏まえ、各ページ数に属する値を WHERE 句で指定して実行した結果が以下のとおりです。 ページ番号が 0 および 2 では、「Heap Fetches」が 1 となっており、1 は 0 になっています。 よって、ページ番号 1 に属する値で絞り込みを行った場合のみ、索引だけで結果を返しているといえます。 ---ページ番号：０ postgres=> explain(analyze,buffers) postgres-> /*+ IndexOnlyScan(exam4 examidx4) */ postgres-> select id from exam4 where id=2; QUERY PLAN --------------------------------------------------------------------------------------------------------------------- Index Only Scan using examidx4 on exam4 (cost=0.14..8.16 rows=1 width=4) (actual time=0.017..0.018 rows=1 loops=1) Index Cond: (id = 2) Heap Fetches: 1 ★ Buffers: shared hit=3 Planning Time: 0.118 ms Execution Time: 0.030 ms (6 rows) ---ページ番号：１ postgres=> explain(analyze,buffers) postgres-> /*+ IndexOnlyScan(exam4 examidx4) */ postgres-> select id from exam4 where id=240; QUERY PLAN --------------------------------------------------------------------------------------------------------------------- Index Only Scan using examidx4 on exam4 (cost=0.14..8.16 rows=1 width=4) (actual time=0.014..0.015 rows=1 loops=1) Index Cond: (id = 240) Heap Fetches: 0 ★ Buffers: shared hit=2 Planning Time: 0.143 ms Execution Time: 0.026 ms (6 rows) ---ページ番号：２ postgres=> explain(analyze,buffers) postgres-> /*+ IndexOnlyScan(exam4 examidx4) */ postgres-> select id from exam4 where id=241; QUERY PLAN --------------------------------------------------------------------------------------------------------------------- Index Only Scan using examidx4 on exam4 (cost=0.14..8.16 rows=1 width=4) (actual time=0.017..0.018 rows=1 loops=1) Index Cond: (id = 241) Heap Fetches: 1 ★ Buffers: shared hit=3 Planning Time: 0.166 ms Execution Time: 0.028 ms (6 rows) 「可視」への更新 最後に、「可視」できなくなったページを「可視」に戻す方法をまとめます。 戻す方法は VACUUM コマンドになります。 勿論、AUTOVACUUM でも大丈夫です。 ---可視性マップの確認 postgres=> select * from pg_visibility_map('exam4'); blkno | all_visible | all_frozen -------+-------------+------------ 0 | f | f 1 | t | f 2 | f | f (3 rows) ---VACUUM の実施 postgres=> vacuum exam4; VACUUM ---可視性マップの確認 postgres=> select * from pg_visibility_map('exam4'); blkno | all_visible | all_frozen -------+-------------+------------ 0 | t　★　　　　 | f 1 | t | f 2 | t　★　　　　 | f (3 rows) なお、ANALZYE や VACUUM FULL では対応できません。 ---可視性マップの確認 postgres=> select * from pg_visibility_map('exam5'); blkno | all_visible | all_frozen -------+-------------+------------ 0 | f | f 1 | f | f (2 rows) ---ANALYZE の実施 postgres=> analyze exam5; ANALYZE postgres=> select * from pg_visibility_map('exam5'); blkno | all_visible | all_frozen -------+-------------+------------ 0 | f | f 1 | f | f (2 rows) ---VACUUM FULL の実施 postgres=> vacuum full exam5; VACUUM ---可視性マップの確認 postgres=> select * from pg_visibility_map('exam5'); blkno | all_visible | all_frozen -------+-------------+------------ 0 | f | f 1 | f | f (2 rows) AUTOVACUUM で解消するのであれば気にしなくてよいという判断もできますが、INSERT や UPDATE などの DML の更新量によっては対象に選ばれないことがあります。 その場合は明示的に実行する必要が出てきます。 ただし、VACUUM コマンドは必ずしも全てのレコードに対して実施されないことがあります。 その場合は「INDEX_CLEANUP」オプションを使用し、「ON」をつけて実行してください。 そのため、明示的に実施する場合はこちらを実行することをお勧めします。 ---①サンプル表の作成 postgres=> create table exam5(id integer); CREATE TABLE postgres=> INSERT INTO exam5 (id) SELECT i FROM generate_series(1, 1000000) as i; INSERT 0 1000000 postgres=> create index examidx5 on exam5(id); CREATE INDEX postgres=> vacuum exam5; VACUUM ---②可視性マップの確認 postgres=> select all_visible,count(*) from pg_visibility_map('exam5') group by all_visible; all_visible | count -------------+------- t | 4425 (1 row) ---③UDPATE の実施 postgres=> update exam5 set id=id where id <= 20000; UPDATE 20000 ---④可視性マップの確認 postgres=> select all_visible,count(*) from pg_visibility_map('exam5') group by all_visible; all_visible | count -------------+------- f | 179　★179ページ分「可視」できていない t | 4335 (2 rows) ---⑤VACUUM の実施 postgres=> vacuum exam5; VACUUM ---⑥可視性マップの確認 postgres=> select all_visible,count(*) from pg_visibility_map('exam5') group by all_visible; all_visible | count -------------+------- f | 89　★89ページ分「可視」できていない t | 4425 (2 rows) ---⑦INDEX_CLEANUP ON で実施 postgres=> vacuum (INDEX_CLEANUP on) exam5; VACUUM ---⑧可視性マップの確認 postgres=> select all_visible,count(*) from pg_visibility_map('exam5') group by all_visible; all_visible | count -------------+------- t | 4514　★ (1 row) 最後に 今回は INDEX ONLY SCAN について検証と共に見えた結果をまとめてみました。 改めて、AUTOVACUUM は PostgreSQL にとって重要であり、またかなり依存しているようにも思えます。 実行計画の表示だけで、簡単に判断すると痛い目にあうという本内容でしたが、実行計画の奥深さに感動しました。 もし実行計画を確認することがあれば本内容を気にしてもらえると幸いです。

大西です。 Azure virtual Desktop（AVD）を用いてシンクライアント環境を構築している際に、 各セッションホストへAzure Monitor Agent（AMA）の導入が正常に完了せず、 WindowsOSのパフォーマンスカウンターをAzureへ取得できないため監視ができないといった事態が発生しました。 原因を探ってみると、マスターイメージをベースに展開されたWindows仮想マシンに対して誤った操作をしていたことが分かりましたので、 本記事にて共有させていただきます。 原因 本事象の原因は、仮想マシンを「AMAを導入した既存のイメージから展開」して作成したことでした。 仮想マシンを新規作成した場合は成功し、イメージから展開した場合は失敗したことから、これが原因だと特定しました。 プロビジョニングに失敗する原因ですが、一度AMAを導入した仮想マシンにはAMAのインストールフォルダが作成されています。 そのデフォルトフォルダが『C:\WindowsAzure\Resource\AMADatastore. 仮想マシン名 』です。（画像黒枠部分） AMAのバージョン1.60以降では、AMAが正常に動作するために、ホスト名と内部データストアのパスに含まれる仮想マシン名が厳密に一致している必要があります。 イメージ展開された新しい仮想マシンには、展開前のマスターイメージに残存していた古い（元イメージの）仮想マシン名が付与されたデータストアフォルダが引き継がれてしまいます。 展開した仮想マシンにAMAをAzureポータルからインストールを実施しても、「C:\WindowsAzure\Resource」配下に空のデータストアフォルダが作成されるだけでした。 そのため、既存のインストールフォルダを削除する必要があります。具体的に次の項目で対応手順をご説明します。 対応 AMAをプロビジョニングしていない仮想マシンを複数台展開する前のベースマシンに対応しておくのが最も負荷が少ないです。 既に展開済みの場合、各仮想マシンに対して作業を実施する必要があります。 1.AMAをアンインストール ※AMA導入前の場合は不要です。 ①[Azureポータル]-[モニター](「監視」で検索)-[設定]-[データ収集ルール]を開き、対象仮想マシンに設定しているルールを開く。 ②[構成]-[リソース]にて対象の仮想マシンにチェックを入れ、「関連付けの削除」を実施する。 ③[Azure ポータル]-[Virtual Machines]-[対象の仮想マシン]-[拡張機能とアプリケーション]を開く。 ④「AzureMonitorWindowsAgent」を選択し、[アンインストール] を選択する。 2.AMAインストールフォルダの削除 ①仮想マシンにログインする。 ②「C:\WindowsAzure」をエクスプローラーで開き、「Resources」フォルダを削除する。 3.レジストリの削除 ※レジストリの操作を誤ると、システムが不安定になる可能性があります。 ①レジストリエディター(Windows + R 後、「regedit」を実行)を開く ②「コンピューター\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AzureMonitorAgent」の「Secrets」キーを選択し、削除する。 4.AMAをインストール ①[Azureポータル]-[モニター](「監視」で検索)-[設定]-[データ収集ルール]を開き、対象仮想マシンに設定するルールを開く。 ②[構成]-[リソース]を開き、「追加」からAMAをインストールする仮想マシンを選択し、適用する。 上記手順を実施すると、AMAのプロビジョニングが正常に終了し、OS内のリソース情報などが転送されます。 最後に 仮想マシン監視のためAMAを導入すること、イメージから展開して構築期間を短くすることどちらも多くの方が行っていると思います。 プリインストールされているAMAがイメージから展開時に問題になるとは思い至りませんでした。 今後も皆様のインフラ運用の一助となるよう、予期せぬ事象に遭遇した際には原因を究明し、本ブログにて情報を共有してまいります。

こんにちは。New Relic技術担当の井上です。 この記事ではNew Relicへのログイン方法と作成したユーザーの権限変更やプロフィール情報変更について解説していきます。同じメールアドレスでNew Relicのアカウントを複数保持している場合、ログイン手順が少し変わってきますので、この記事を読んで参考になれば幸いです。 はじめに 部署異動や役割変更に伴い、ユーザーの権限やプロフィール情報を更新する必要があるケースは多くあります。また、同一メールアドレスで複数の組織に所属している場合、ログイン方法にも注意が必要です。この記事では、複数組織に所属する場合のログインの注意点、ユーザー権限の変更方法、プロフィール情報の編集手順を解説していきます。 既に作成したNew Relicアカウントにて初回ログインは済んでいることを前提で解説します。もし、New Relicのアカウント作成が済んでいない場合は、過去の以下の記事をご参照いただければ幸いです。   【New Relic】使い始めるためのサインアップガイド この記事では実際にNew Relicを使う導入ステップとして、New Relicのサインアップ方法について解説していきます。初めてNew Relicを利用される方でもスムーズに始められるよう、必要な情報を順を追ってご紹介します。 blog.usize-tech.com 2025.11.19   New Relicコンソールへのログイン方法 まずはNew Relicコンソールへのログイン方法について解説します。New Relicコンソールへのログイン方法は2つのパターンがあります。ログインするだけならガイドに沿って簡単ですが、この記事では躓きやすいポイントも踏まえてお伝えできればと考えています。 パターン1:初回以降のログイン方法 このパターンでは同一メールアドレスでNew Relicのアカウントを複数保持していない場合のログイン方法になります。 1.下記、URLにアクセス後、Emailとパスワードを入力してログインします。　　 https://login.newrelic.com/login     2.下記のNew Relicコンソール画面が表示されたら、ログイン完了です。権限により、表示は異なることがあります。     【備考】 1ユーザーにつき、同時に保持できるアクティブセッションは最大3つまで です。ログアウトせずに4回目以降のログインを行う際には、下記画面が表示される場合があります。その場合は、古いセッションを「End」で終了してください。 パターン2:同一 Email で複数の New Relic アカウントを保持している場合 同一のメールアドレスで複数のNew Relicアカウントを保持している場合、New Relicへのログインには、最後にログインしたアカウントに自動的にログインされることがあります。そのため、特定のアカウントにログインしたい場合は、ログイン画面で明示的にアカウントを選択する必要があります。   最後にログインしたアカウントがわかる場合 以下の手順にて確認することができます。 1.下記、URLにアクセス後、Emailを入力し、「Next」をクリックします。　　 https://login.newrelic.com/login 2.EmailとPasswordを入力し、「Remember my email」にチェック後、ログインします。 3.左下部に表示されている自身のユーザーアイコンをクリック後、「Log out」をクリックします。 4.次回ログイン画面にて、ログイン先の選択画面が表示されます。アカウントを明示的に選択してログインすることができます。           最後にログインしたアカウントがわからない場合 以下の手順にて確認することができます。 １.同一EmailでNew Relicのアカウントを複数保持している場合、ログイン時に下記の画面が表示されます。「Verify your email」をクリックします。 2.登録済のEmailが表示されていますので、誤りがないことを確認後、ロボット認証を対応し、[Send email]をクリックします。 3.下記画面が表示されます。前画面で入力したメールアドレス宛にメールが届いていることを確認してください。この画面は閉じても問題ありません。 4.New Relicからメール認証に関するメールが届いていることを確認してください。本文中の記載されたURLをクリックします。 5. Emailに紐づけられたNew Relicアカウントの一覧が表示されます。ログインするアカウントをクリックし、ログインを実施してください。       組織名の変更 1つのメールアドレスで複数の組織と契約している場合、ログイン時に表示されるデフォルトの組織名だけでは、どの契約に関連しているのか分かりづらいことがあります。表示される組織名を変えることで、ログイン時の混乱を防ぐことができます。この操作はFull Platform User権限かつAdmin権限を持ったユーザーにて実施する必要があります。 1.左下部に表示されている自身のユーザー名をクリックし、「Other Users」から、変更前の組織名を確認後、「Administration」をクリックします。 2.「Access Management」をクリック後、組織名にカーソルを合わせます。「Rename」が表示されますので、クリックします。 3.名前を変更し「Save」をクリックします。変更を反映させるためには、一度ログアウトが必要になります。 4.ログアウト後、Organizationの表示名が変更されていることを確認し、完了です。           ユーザー権限の変更 ログインしている自身が自身のユーザータイプ変更やAdmin権限が付与されたグループから抜けることはできません。そのため、ユーザー権限の変更を行う場合は、Full Platform User権限かつAdmin権限を持ったユーザーにて操作をする必要があります。 1.左下部に表示されている自身のユーザー名をクリック後、「Administration」を選択します。 2.「User Management」をクリック後、権限変更したいユーザーを選択します。 ３.この画面で各種変更を行えます。Emailを変更する場合、認証URLをクリックし、認証完了させる必要があります。 4.User Typeを変更する場合、「Change user type to Basic」をクリックします。Basic以外は有償アカウントになります。無料プラン以外で契約されている場合は、契約内容の数量をご確認の上、変更ください。 5. グループ所属を外す場合 、対象グループ名の横の[・・・]をクリックします。「Remove user from group」を、クリックしてグループから外れます。 グループは一つ以上参加していることが必要です。「Close」をクリックして完了です。 6. グループ所属を追加する場合 、所属させるグループを選択後、「Add user to group」をクリック後、下部のGroupのリストに表示されていることを確認してください。最後に「Close」をクリックして完了です。   User type: basic, core, and full platform users | New Relic Documentation An explanation of New Relic user types: basic users, core users, and full platform users. docs.newrelic.com   プロフィール情報の変更 ログインしている自身が変更できるプロフィール情報は、名前、パスワード、メールアドレス、タイムゾーン、メール配信設定です。名前やパスワードの反映は即時になります。メールアドレスの変更については、変更後のEmailアドレス宛に送られる認証URLをクリックして、認証完了させなければ変更はできません。 1.左下部に表示されている自身のユーザー名をクリック後、「User Preference」を選択します。 2.名前やEmail、パスワード、タイムゾーン、メール配信の設定変更をすることができます。 【備考】New Relicから新機能に関するメールとパフォーマンスレポートに関するメールが送信されます。配信許可設定は以下で行います。   メール設定 | New Relic Documentation How to subscribe to and unsubscribe from New Relic emails, and change your email address. docs.newrelic.com   New Relicコンソール表示されるタイムゾーンを日本時間に変更する場合もこの手順にて行いますが、UIに反映されるまでに最大で24時間かかる可能性はあります。また、この設定を実施しても以下については、指定しない限りデフォルトのUTC時間で表示されます。 アラート通知 ：常にUTCで表示されるため、通知テンプレートでタイムゾーンを指定 APIレスポンスのタイムスタンプ ：UTC固定のため、クライアント側で変換が必要 クエリ検索  ：WITH TIMEZONE を明示的に使う必要   タイムゾーンの設定 | New Relic Documentation How to change the default date/time displayed in the New Relic UI. docs.newrelic.com   クエリの時間範囲の設定 | New Relic Documentation A detailed description of how to set the timerange of a NRQL query. docs.newrelic.com   通知メッセージテンプレート | New Relic Documentation Read about various notification message templates you can use and apply. docs.newrelic.com   さいごに New Relicのログイン方法、ユーザー権限の変更方法、そしてプロフィール情報の編集手順について解説しました。特に、同一Emailで複数のNew Relicアカウントを保持している場合は、ログイン時に対象アカウントを選択する必要があり、意図しないアカウントにアクセスして作業してしまうケースもあるため注意が必要です。 ユーザータイプ（Basic、Core、Full platformなど）を変更する際には、課金体系に影響する可能性があるため、事前に料金プランや利用状況を確認することが重要です。プロフィール情報の編集についても、表示名や通知先のメールアドレスなど、日常的な運用に関わる項目が含まれており、正確な設定が求められます。この記事が、New Relicのユーザー管理に関する理解を深める一助となれば幸いです。 SCSKはNew Relicのライセンス販売だけではなく、導入から導入後のサポートまで伴走的に導入支援を実施しています。くわしくは以下をご参照のほどよろしくお願いいたします。

リソース構築をする中でBastion経由でVMへ接続することがありますが、ポータル上からのBastion接続では通常、ファイル転送をすることができません。私自身VMへアプリケーションを導入する際に、ローカルPCからVMへ実行ファイルを転送しようとしましたが、できず、少々焦りました。そのため今回はCLIを利用したBastion経由でのファイル転送方法について紹介します。この方法であれば、ファイル転送のために追加でAzure Storageサービスなどのリソースを構築する必要がなく、余計な工数やコストが発生しません。 Bastion設定 Bastion作成時または作成後の「構成」にて「ネイティブクライアントサポート」を有効化します。これは、ローカルPC上のネイティブ クライアント (SSH または RDP) から仮想ネットワーク内のVMへの接続を受け入れる設定です。これにより、Azure CLI を使ってBastion経由でターゲットVMに接続し、ファイル転送ができるようになります。 CLIからVMへの接続 CLIは以下よりインストールしてください Windows に Azure CLI をインストールする Windows に Azure CLI をインストールするには、PowerShell または MSI インストーラーを使用する必要があります。これにより、Windows コマンドプロンプト (CMD) を使用して CLI にアクセスできるよ... learn.microsoft.com CLIへ「az login」によりログインしたのち、以下コマンドを入力してください az network bastion rdp --name "＜Bastion名＞" --resource-group "＜Bastionが属するリソースグループ名＞" --target-resource-id "/subscriptions/＜サブスクリプションID＞/resourceGroups/＜VMが属するリソースグループ名＞/providers/Microsoft.Compute/virtualMachines/＜VM名＞" その後VMへの接続情報（ユーザ名、パスワード）を入力する画面が表示されるのでそれぞれ入力するとVMへ接続できます。接続できたら転送したいファイルをコピー&ペーストすると転送できます。 おわりに 今回はAzureCLIを用いたVMへのBastion経由でのファイル転送について紹介しました。構築する中でローカルPCからVMへファイルを転送する場面はあると思いますので是非ご利用ください。

こんにちは SCSKの庄司です。 今回は、ServiceNowの環境間における画像の移送方法を紹介していきます。 本記事は執筆時点（2025年11月）の情報になります。最新の内容は製品ドキュメントを参考にしてください。 添付ファイルは更新セットに含まれない ServiceNowでは通常、環境間での変更の移送は更新セットを利用して実施します。 しかし、更新セットにはすべてのレコードを含められるわけではなく、タスク（Task）ベースのレコードやユーザーデータなど、対象外となるものが存在します。 添付ファイルもその一つです。 そのため、画像のアップロードなどを含む更新セットの移送には、別途で画像データも移送してあげる必要があります。 そこで本記事では、画像などの添付ファイルを環境間で移送する手順を解説します。   添付ファイル関連テーブル ServiceNowでは、添付ファイルに関連するデータは以下の2つのテーブルに格納されています。 添付ファイル（sys_attachment）テーブル：ファイル名、サイズ、table_name/table_sys_id（どのレコードに付いているか）などのメタ情報。 添付ドキュメント（sys_attachment_doc）テーブル：ファイルの実データ情報。1つの添付に対して複数レコードが紐づく場合があります。 添付ファイルを完全に移送するには、これら両方のテーブルのレコードを移送する必要があります。   移送手順 それでは、更新セットで移送されない添付ファイルをどう移送するか解説します。 今回は視覚的にわかりやすい例として、カタログアイテムの「リッチテキスト」タイプ変数に画像を添付してみます。 ポータル画面からは以下のような状態です。 画像をアップロードしたことで、裏側では該当の「添付ファイルレコード」と「添付ドキュメントレコード」が作成されています。 更新セットに入らないレコードの移送は、XMLファイルとしてエクスポートし、対象環境でインポートすることで実施できます。 リストのコンテキストメニュー（ヘッダーを右クリック） > エクスポート > XML を選択します。 これでXMLファイルのエクスポートが出来ました。 本来であれば、カタログアイテム自体を含んだ更新セットを移送した後に、このXMLファイルをインポートします。 ただ、今回は検証用のPDI環境しかないため、更新セットのみ適用済みの状態（＝添付ファイルレコード、添付ドキュメントレコードがない状態）を再現するために、あえて該当の添付ファイルレコードと添付ドキュメントレコードを削除します。 削除後のカタログアイテムフォームでの表示は以下のようになります。 削除前は左上の赤枠の中にファイル名が表示されていましたが消えており、右の赤枠あたりにあった画像も「画像なし」の表示になっています。 レコードと添付ファイルとの紐づき情報を含む「添付ファイルレコード」と、中身である「添付ドキュメントレコード」が存在しないため、どちらも表示できない状態です。 ポータル画面でも同様に、画像が表示されていません。 では、添付ファイル情報をインポートして復旧させていきます。 まずは「添付ファイルレコード（sys_attachment）」のXMLをインポートし、カタログアイテムフォームを確認してみます。 リストのコンテキストメニュー（ヘッダーを右クリック） > XMLのインポート（Import XML） から、先ほどエクスポートしたXMLファイルをアップロードします。 左上に添付ファイルの表示が復活しました。 しかし、実データである「添付ドキュメントレコード」がまだ取り込まれていないため、肝心の画像プレビューは表示されていません。 引き続き、先ほどと同じ手順で「添付ドキュメントレコード（sys_attachment_doc）」をインポートします。 両方のデータがインポートされたので、カタログアイテムフォームとポータル画面を確認します。     画像がしっかりと表示されていることが確認できました。   まとめ ServiceNowの環境間での添付ファイルの移送は、該当テーブルのレコードをXML形式でエクスポート/インポートすることで実施できます。 実施の際の重要な注意点として、更新セットを先に適用してから、添付ファイル関連のレコードをインポートするようにしてください。 添付ファイルは「どのレコードに紐づくか」という情報（Sys_ID）を持っています。 そのため、紐づけ先のレコードが存在しない状態で先に添付ファイルをインポートしてしまうと、リンク切れを起こしたり、データが正しく反映されなかったりする事象が発生する可能性があります。 ぜひ、環境間での画像の移送の際には参考にしてみてください。

こんにちは。SCSKの松渕です。 半年ほど前から、エンジニア界隈のSNSや技術ブログで「 DeepWiki 」という名前を見かけることが増えていませんか？ この記事では、「Deepwikiって結局何がすごいの？」「どうやって使うの？」という初学者向けのブログとなってます！ 本記事は、筆者個人の見解に基づき、DeepWikiの使用経験を共有することを目的としています。Cognition社の公式見解を示すものではありません。 DeepWikiとは DeepWikiの概要 このサービスを提供するのは、 アメリカ合衆国・サンフランシスコ を拠点とし、自律型AIソフトウェアエンジニア「 Devin 」を開発した話題のAI企業、 Cognition AI です。2023年11月の創業からわずか半年で企業評価額が20億ドルに達した、AI界の超新星が生み出したプロダクトです。 類似サービスとの違い/強みとは以下のようなところではないでしょうか。 手軽な利用 ：GitHubのURLの github.com を deepwiki.com に書き換えるだけで、AIがリポジトリを瞬時に解析し、ドキュメントを自動生成します。 ※公開レポジトリが前提 個人的にはこの 手軽さという要素は非常に大きい のではないかと思います。 (2025/11現時点では)費用も無料 です。 コード構造の可視化 ：単なるテキストの要約ではなく、依存関係やクラス構造を可視化したアーキテクチャ図も作成します。 対話型Q&A ：生成されたWikiの内容について、AIにチャット形式で質問し、コードベースに基づいた明確な回答を得られます。 類似サービスとの違い 類似サービスは、Cursor等の コーディングエージェントに対してドキュメント化したりQ&Aする ことになるかと思います。 ある程度似たことはできると思いますが、 Deepwikiはコード理解/可視化に特化したサービスとして提供 しているという点が ユニークである と理解してます。 比較項目 DeepWiki (AIドキュメント) Cursor等 (コーディングエージェント) GitHub Wiki (手動ドキュメント) Confluence等 (総合ナレッジ) 主な目的 コードベース全体の可視化、理解 コードを書く・編集する （アウトプット・開発効率化） チーム内共有 （ルール・仕様の定義） 全社・チームの知識管理 （議事録・人事情報など） 強み 全体像の自動把握 、高精度な図、対話型Q＆A IDE内でのシームレスな質問 、コード生成・リファクタリング、 デバッグ支援 GitHubとの親和性、手動での高いカスタマイズ性 汎用性、豊富な表現力、コード以外のナレッジも一元管理 弱み コードの編集・デバッグ不可 （Devinを利用する必要有） プロジェクト全体の俯瞰には向かない 、大規模なドキュメント生成が目的ではない 作成・更新が完全手動 （陳腐化しやすい） コードの自動解析はできない コスト感 無料（Devinでのコード編集は有料） 月額課金制が多い 無料（GitHubプランによる） 無料枠があり、機能に応じて有料が多い   ですが・・・！！ 11月13日にGoogleから、 Code Wikiというサービスの発表 がありました。 まだ公開プレビュー中ですが、 目的がDeepWikiと似通っている ように思えました。 利用可能になったら使ってみて違いをレポートしていきます！ そもそも、Code Wikiが出てくると聞いて調べているうちにDeepWikiにたどり着いたのが今回のブログのきっかけでした。 公開レポジトリのDeepWikiを見てみる 前章で説明した通り、 公開リポジトリならGitHubのURLの github.com を deepwiki.com に書き換えるだけ です。 つまり、 公開リポジトリのDeepWikiはだれでも作成と参照が可能 です。 たとえば、 GeminiCLIのdeepwiki のページはこちらです。非常に詳細にドキュメント化されているのがわかります。 アーキテクチャー図やフロー図、表など あらゆる出力形式を駆使して可視化 されているのがわかるかと思います。     プライベートリポジトリに対してDeepWikiの作成 前置きが長くなりました。ここからプライベートリポジトリに対してDeepWikiを使ってみたいと思います。 Devin用ユーザ作成 DeepWikiはDevinの一機能として提供されているようですのでDevin用のアカウント作成が必要となります。 こちら にアクセスします。「Sign UP」を押下。   アカウント作成画面になりますので、作成します。私はGoogleアカウントを利用しました。   作成後、GitHubもしくはGitLabとの連携画面に遷移します。 私はGitHubと連携しました。 また、組織管理者か、単独での開発者かを選びます。 Devinの中にもOrganizationという概念があります。 GitHub Organizationを使っている場合は、 GitHubのOrganizationとDevinのOrganizationを一致させて、 Devin上で共同作業をさせるためには左を選ぶ べきとのこと。 今回は検証で一人で開発しているものなので右を選びました。   github CLIでの認証が走ります。「Run」を押下します。   ワンタイムパスワードが発行されます。表示されているURLクリックします。   先ほどのワンタイムパスワードを入力します。   Authorize githubを押下します。   連携が成功しました！ 　　   自動でDevinの画面に戻ります。リポジトリを選ぶ画面になります。 ※このタイミングでは3つまでしか選べないようですが、 時間がたったら他のものも追加で選べました。     indexingになるので、作成完了まで待ちます。10-30分程度。     DeepWikiの動作確認 日本語化 出てきた！！と思ったら 英語でした 。落ち着いて考えれば当然です。世界の標準言語は英語です。   DeepWikiは日本語にも対応していますので、日本語で出力させます。 「Devin’s Settings」の「Customization」を押下 します   ページ下部に移動し「DeepWiki languages」の中から Japaneseを選択 。 結構いろんな言語対応してますね。   そうすると、DeepWikiの画面に戻った時にプルダウンで選べるようになります。 Japaneseを選び、「Start wiki generation」を押下 してindex再作成まで待ちます。 10-30分程度待ちます。   出力確認 出力されたものを確認してみます。 まずは概要です。AIっぽい文章であることは否めないですが、 概要わかりやすくまとまってます ね。   アーキテクチャ図も出力 されてました。これはすごいですね！！ 可視化方式がさらに向上すれば そのまま運用ドキュメント化できそうなレベル です。 パイプライン、AIサービス、サマリサービス、ストレージ層等で区分けされてキレイに見えます。 アウトプットが何かも2つ明確になってます。   そもそもこのアプリですが、ネット上からAI関連のニュースをRSSで集め、各ニュースを要約してteamsに投稿します。 ちなみに Jules使って開発 したアプリです。 上記の処理の流れのうちの、各ニュース記事を 要約する処理部分だけのアーキテクチャ図 　などもありました。 DeepWikiが生成したドキュメントは 合計28ページにもなり、1ページあたり約8,000文字 のたっぷりボリューム感です。 処理の 細かい部分まで詳細にドキュメント化/可視化 してくれています。   Q&Aしてみる 途中でVertex AI Search使って過去のニュースをRAG化しかけた痕跡とかが残ってます。 ので、おそらく無駄な部分があると思いDevinに聞いてみたところ、 コード全体をスキャンしたうえで、 以下のように応答を返してきました。 コードに対する 質問だけなら無料 でDevinが回答してくれます。 Devinでのコード編集作業等をする場合は、 月額$20～の従量課金と、月額$500、企業向け個別プランの3タイプ です。 詳細は Devinの公式サイト 参照ください。   まとめ 本記事では、Cognition AIが提供するAIコードドキュメントサービス 「DeepWiki」について、その概要から具体的な使用方法までを解説 しました。 DeepWikiは、公開リポジトリであれば GitHubリポジトリのURL（ github.com ）を deepwiki.com に書き換えるだけ で、AIがリポジトリを瞬時に解析し、ドキュメントを自動生成する 手軽さが特徴 です 。 記事内では プライベートリポジトリで利用するためのDevinアカウント作成手順 、GitHub CLIを使った認証方法 、さらに生成されたWikiを日本語化する設定 を画像付きで紹介 しました。 DeepWikiの強み は、単なるテキスト要約に留まらず、 依存関係を可視化したアーキテクチャ図を自動生成する点 や、コードベースについてAIと対話型でQ&Aができる点 です 。 2025年11月13日には Googleからも類似サービス「Code Wiki」が発表 されており 、コード理解・可視化AIの分野は今後さらに注目されるでしょう！！   ＿＿＿＿＿ 「Devin」「DeepWiki」および関連する名称は、Cognition社またはその関連会社の商標または登録商標です。

初めまして。2025年にSCSKに入社した新人の大原悠利と申します。現在、所属部署の伝統であるクラウド研修に参加しています。 今回はその研修の中で、自分が特に苦戦した「 AWS CloudFormationの出力をAnsibleで利用する方法 」についてご紹介します。この記事が、同じように悩む方の助けになれば嬉しいです。   実装する要件 概要 AWS CloudFormationと構成管理ツール（Ansible）を用いて、Amazon EC2上にアプリケーションを自動デプロイします。 プライベートネットワーク環境のPCからEC2にアクセスし、Webページが表示されることを確認します。   Ansibleとは？ Ansible® は、プロビジョニング、構成管理、アプリケーションのデプロイメント、オーケストレーション、その他多くの IT プロセスを自動化する、オープンソースの IT 自動化ツールまたは自動化エンジンのこと 参照： Ansible (アンシブル) とは？をわかりやすく解説   アーキテクチャ 本構成は以下の2つの観点で示します。 アーキテクチャ全体像   ユーザーはSCSK PCからRoute53を介してELBにアクセスし、プライベートサブネット内のEC2に接続します。 EC2はElastiCacheと連携し、HTTPS通信はCertificate Managerで管理します。   EC2インスタンス詳細 EC2にはJavaアプリケーションをホストし、Ansibleでデプロイを自動化します。 S3からアプリケーションを取得し、Systems Managerで運用管理、IAMで権限を制御します。   苦戦したところ 細かい要件はいろいろありますが、実装するにあたり特に苦戦した要件は次の1点です。 CloudFormationで取得したElastiCacheのエンドポイントを、Ansible経由でJVM引数としてアプリに渡す。 この要件を満たすために、私はAnsibleの amazon.aws.cloudformation_info モジュール を使う方法が良いと考えました。   amazon.aws.cloudformation_infoモジュールとは Ansible公式ドキュメントには、以下のように記載されています。 Obtain information about an AWS CloudFormation stack （AWS CloudFormationスタックに関する情報の取得） 参照： amazon.aws.cloudformation_info module – Obtain information about an AWS CloudFormation stack — Ansible Community Documentation つまり、amazon.aws.cloudformation_infoモジュール（以降 CloudFormation_infoモジュール）を使えば、CloudFormationスタックの情報（Outputsなど）をAnsible上で取得できるということです。   使用例（抜粋） - name: Get summary information about a stack amazon.aws.cloudformation_info: # amazon.aws.cloudformation_infoモジュールを使用 stack_name: my-cloudformation-stack # 取得したいCloudFormationスタック名 register: output # 実行結果をoutput変数に格納 Outputsを取得するには以下のようにします。 - set_fact: stack_name: my-awesome-stack # 対象のCloudFormationスタック名を指定 - amazon.aws.cloudformation_info: # amazon.aws.cloudformation_infoモジュールを使用 stack_name: "{{ stack_name }}" # stack_name変数を参照して情報を取得し、my_stack変数に格納 register: my_stack - debug: msg: "{{ my_stack.cloudformation[stack_name].stack_outputs }}" # my_stack.cloudformation[stack_name].stack_outputsでOutputsを取得 CloudFormation_infoモジュールの戻り値では、Outputsは stack_outputs キーに格納されます。例えば、 register で my_stack とした場合、 my_stack.cloudformation[stack_name].stack_outputs.ElastiCacheEndpoint で取得できます。 このように、CloudFormation_infoモジュールを使えば、 CloudFormationのOutputsをAnsibleで取得できる ことがわかります。   実装手順 実際には、CloudFormationのOutputsセクションンの設定とAnsible Playbookの設定を行いました。 CloudFormationのOutputs設定 まず、CloudFormationテンプレートの Outputs セクションにElastiCacheのエンドポイントを記述します。 Outputs: ElastiCacheEndpoint: Value: !GetAtt ElastiCacheCluster.ConfigurationEndpoint.Address # ElastiCacheのエンドポイントを取得 Export: Name: ElastiCacheEndpoint # CloudFormation_infoモジュールで参照するための名前   Ansible Playbookの設定 次に、Ansibleでこの出力を取得するために、以下のようなPlaybookを作成しました。 - name: Get ElastiCache endpoint from CloudFormation amazon.aws.cloudformation_info: # amazon.aws.cloudformation_infoモジュールを使用 stack_name: my-app-stack # 子スタックの名前（仮にmy-app-stackとおく） region: 'ap-northeast-1' # リージョンの指定 register: cf_output # 実行結果を変数に格納 - name: Set ElastiCache endpoint as a fact set_fact: elasticache_endpoint: "{{ cf_output.cloudformation['my-app-stack'].stack_outputs.ElastiCacheEndpoint }}" # CloudFormation Outputsで定義したElastiCacheEndpointを取得 この elasticache_endpoint をJVM引数としてアプリに渡すことで、動的にエンドポイントを設定することができると予想しました。 しかし結果はうまくいきませんでした。   なぜうまくいかなかったか 子スタック名がわからなかった CloudFormation_infoモジュールを使うには、対象のスタック名が必要です。親スタックの名前は作成時に指定できるため問題ありませんが、 ネストされた子スタックはCloudFormationが自動で名前を生成 するため、事前に把握するのが難しく、結果としてCloudFormationのOutputsを取得できませんでした。   Amazon Linux 2の環境制約 Amazon Linux 2では、デフォルトで古いバージョンのAnsibleやbotocoreがインストールされているため、使用要件に満たさずCloudFormation_infoモジュールが正常に動作しませんでした。研修の要件でAMIを変更できなかったため、ここも大きな制約でした。 実際にCloudFormation_infoモジュールを使うには、以下の環境が必要です Ansible-core ：2.13.9以上 Ansible amazon awsコレクション : 10.1.2以上 Python ：3.6以上 boto3 ：1.34.0以上 botocore ：1.34.0以上 研修環境ではAmazon Linux 2を使用していたため、これらのバージョンが古く、モジュールがうまく動作しませんでした。 参考：研修環境（Amazon Linux2の設定） Ansible-core：2.9.25 Ansible amazon awsコレクション：未インストール Python：3.7.16 boto3：未インストール botocore：1.18.6 そこで、対策としてEC2インスタンスにログインして環境を修正しました。その後、再度Ansible Playbookを実行してアプリをデプロイしました。   対策 Ansible Playbookに子スタック名を直接記入 一度スタックを作成した後に、直接マネジメントコンソール上で確認したスタック名をAnsible Playbook内に記載しました。 - name: Get ElastiCache endpoint from CloudFormation amazon.aws.cloudformation_info: # amazon.aws.cloudformation_infoモジュールを使用 stack_name: hrd-d0-cfs-y-oohara-ApplicationquickstartStack-1902NZ480MKZ8 # 子スタックの名前 region: 'ap-northeast-1' # リージョンの指定 register: cf_output # 実行結果を変数に格納 - name: Set ElastiCache endpoint as a fact set_fact: elasticache_endpoint: "{{ cf_output.cloudformation[ 'hrd-d0-cfs-y-oohara-ApplicationquickstartStack-1902NZ480MKZ8 '].stack_outputs.ElastiCacheEndpoint }}" # CloudFormation Outputsで定義したElastiCacheEndpointを取得   各ソフトウェアのアップデート CloudFormation_infoモジュールの使用要件を満たすために、EC2インスタンスへ接続し古いAnsibleを削除し、各ソフトウェア (Ansible, Python3, boto3, botocore, Ansible amazon awsコレクション)をインストールしました。その後、Ansible Playbookを実行しました。 sudo yum remove ansible # 古いAnsibleを削除 sudo yum install python3 -y # Python3をインストール sudo python3 -m pip install ansible boto3 botocore # 最新のAnsibleとAWS SDK（boto3, botocore）をpipでグローバルインストール ansible-galaxy collection install amazon.aws # Ansible amazon awsコレクションのインストール ansible-playbook -c local /home/ssm-user/ansible/web_ui_startup.yml # AnsibleのPlaybookをローカルモードで実行 改善した結果、Webページが表示されることを確認することができました。   別解（ペアのyabuさんの方法） 実際に研修中は、自分の方法では実装がかないませんでした。研修ではペアで作業しており、ペアのyabuさんが別のアプローチでこの問題を解決してくれました。自分とは考え方が違っていて、非常に勉強になったのでご紹介します。 大原の考え方 CloudFormationのOutputsからElastiCacheのエンドポイントを取得 Ansibleでその出力を受け取り、JVM引数としてアプリに渡す この方法は理論上は正しいのですが、環境の制約（バージョンやスタック名の取得）でうまくいきませんでした。 yabuさんの考え方 CloudFormationのUserDataで、EC2インスタンスの環境変数にElastiCacheのエンドポイントを直接出力 その環境変数をAnsibleで参照してアプリに渡す EC2インスタンスのUserData設定 UserData:   Fn::Base64: !Sub |     #!/bin/bash     yum install -y aws-cfn-bootstrap  # CloudFormationのcfn-initやcfn-signalを利用するためにインストール     echo ENDPOINT=${ElastiCache.RedisEndpoint.Address} | sudo tee -a /etc/environment  # ElastiCacheのRedisエンドポイントを環境変数に設定     /opt/aws/bin/cfn-init -v \  # CloudFormationのMetadataに基づいて設定を適用       --stack ${AWS::StackName} \  # 現在のスタック名を指定       --resource EC2Instance \     # テンプレート内のEC2リソース論理ID       --region ${AWS::Region} \    # デプロイ先リージョン       --configsets Default         # 適用するConfigSet名（Ansible Playbookに記載） Ansible Playbookの設定 - name: Run Spring Boot application   shell: |     source /etc/environment \  # ElastiCacheのエンドポイントなど環境変数を利用するため /etc/environmentを読み込み     java -jar \       -Dspring.profiles.active=d0 \       -Dspring.data.redis.host=$ENDPOINT \ # Redis接続先を環境変数から設定       /home/appuser/my-spring-app.jar この方法なら、CloudFormation_infoモジュールのバージョン制約を気にする必要がなく、環境変数として扱えるため非常にシンプルです。   感想 このコードを見たとき、「なるほど！」と目から鱗でした。自分がモジュールにこだわりすぎていたことに気づき、柔軟な発想の大切さを学びました。この考え方を踏まえると、環境変数に子スタック名を記載すると、CloudFormation_infoモジュールが利用できるのかなと思います。 参考：yabuさんの記事 https://blog.usize-tech.com/aws-certification-five-study-methods/   実際のユースケース 今回の研修を通じて、「CloudFormation_infoモジュールを使う方法」と「EC2のUserDataで環境変数として渡す方法」の2つのアプローチを学びました。それぞれのユースケースを整理してみると、使い分けのポイントが見えてきました。そこで、Microsoft Copilotに二つのユースケースの違いを聞いてみました。以下回答になります。 Copilotによる回答 方法  向いているケース  メリット デメリット CloudFormation_infoモジュール 複数環境で構成管理 CI/CDで最新情報反映 最新情報を動的取得 冪等性が高い コード一元管理 AWS API呼び出し必須 実行速度やや低下 環境要件あり（Ansible/Python/boto3など） UserDataで環境変数を渡す方法 単一環境で固定構成 AWS認証を避けたい場合 AWS認証不要 高速 バージョン依存が少ない 更新に弱い 冪等性低い セキュリティリスク   🤖 Copilotからの補足 このように、 CloudFormation_infoはAnsible中心の構成管理に向いていて、UserDataはインスタンス起動時の初期設定に向いている という違いがあります。   この回答を踏まえて、どちらが優れているというよりは、 目的に応じて使い分けることが重要 だと感じました。   最後に 今回の研修では、CloudFormationの出力をAnsibleで取得してアプリに渡すというシンプルな要件に対して、予想以上に多くの課題がありました。環境制約やスタック名の取得など、技術的な壁に直面しましたが、ペアのyabuさんの別解やEC2インスタンスへの直接の対応を通じて、柔軟な発想の大切さを学びました。 この経験から得た教訓は次の2つです。 引き出しが多いと、焦らずに対応できる バージョンや前提条件は、必ず確認する習慣をつけるべき 新人としてまだまだ未熟ですが、こうした試行錯誤を積み重ねて、少しずつ成長していきたいと思っています。 この記事が、同じように悩んでいる方のヒントになれば幸いです。ここまで読んでいただき、ありがとうございました！