こんにちは、石原です。 最近、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つです。 引き出しが多いと、焦らずに対応できる バージョンや前提条件は、必ず確認する習慣をつけるべき 新人としてまだまだ未熟ですが、こうした試行錯誤を積み重ねて、少しずつ成長していきたいと思っています。 この記事が、同じように悩んでいる方のヒントになれば幸いです。ここまで読んでいただき、ありがとうございました！

初めまして。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つです。 引き出しが多いと、焦らずに対応できる バージョンや前提条件は、必ず確認する習慣をつけるべき 新人としてまだまだ未熟ですが、こうした試行錯誤を積み重ねて、少しずつ成長していきたいと思っています。 この記事が、同じように悩んでいる方のヒントになれば幸いです。ここまで読んでいただき、ありがとうございました！

こんにちは。New Relic技術担当の井上です。 この記事では実際にNew Relicを使う導入ステップとして、New Relicのサインアップ方法について解説していきます。初めてNew Relicを利用される方でもスムーズに始められるよう、必要な情報を順を追ってご紹介します。サインアップ後の初期設定やユーザ管理に関するポイントについても、今後の記事で順次ご紹介していきます。 はじめに この記事は、New Relicを全く触ったことがないユーザを対象としています。New Relicの無料プラン※を利用して操作を行いますので、New Relicに関しては費用無しで実施いただくことができます(New Relicさん、ありがとうございます！)。10分程度で作業は完了します。 ※無料プランに含まれる内容は、月間100GBまでのデータ容量と全機能にアクセスできるユーザー1名です。無料プランの場合一部機能に制約がある可能性はあります。   事前準備 New Relicを使うにあたり、以下が必要になります。クレジットカードの登録が不要のため、安心ですね。 ・インターネットへ接続できる環境 ・メールアドレス(これがログインIDになります。メーリングアドレスは不可。) ・New Relicを使う意気込み！   サインアップ 手順 では、さっそくサインアップしていきましょう。 1.New RelicのURLにアクセス後、「ログイン」をクリックします。 New Relic URL: https://newrelic.com/jp/   2.ログイン画面が表示されます。 「Create a free account」をクリックします。   3.メールアドレス欄と名前欄に入力後、「Get Started Free」をクリックします。メールアドレスと名前は後で変更することもできます。   4.入力したメールアドレスボックスを確認する旨の画面が表示されますので、メールボックスを確認します。   5.メールボックスにNew Relicから招待メールが届いていますので、「Verify Email」をクリックします。   6.パスワードの設定画面が表示されますので、設定後、「Save password」をクリックします。 パスワードは次の最小要件を満たす必要があります。詳しくはパスワードポリシーは以下を参照ください。 8～50文字 1文字以上（a-z、A-Z） 1つ以上の数字（0-9）、特殊文字、またはスペース   パスワードを設定または変更する | New Relic Documentation How to set or change your New Relic password. docs.newrelic.com   7.データの保存をどの地域に設定するかを選択後、「Save」をクリックします。 この設定は後から変更できません。 New Relicは米国とEUのデータセンターが用意されています。EUリージョンを選択した場合、最低限必要なNew Relicエージェントのバージョンが定められています。また、非推奨の製品や機能は利用することができません。これはEU圏内でのGDPR(一般データ保護規則)に基づく法規制によるものと考えられます。EU内でのデータ管理が求められるケース（例：GDPR対応など）を除けば、 基本的には米国リージョンの利用 がより柔軟で便利です。     データセンターの選択（米国またはEU） | New Relic Documentation The New Relic global data hosting structure consists of two regions: the EU region and the US region. docs.newrelic.com   8.すべての設定が終わるとNew Relicのコンソール画面が表示されます。これにてセットアップは完了です。        さいごに New Relicを初めて利用される方でも迷わず始められるよう、サインアップの流れや初期設定のポイントを中心に手順を解説しました。今後は、実際の運用に役立つ具体的な活用方法について、データ収集の仕方、ダッシュボードの作成、アラート設定など、主要機能を取り上げながら順を追って解説していきます。New Relicの理解と効果的な活用の一助となり、日々のシステム運用に少しでもお役立ていただければ幸いです。 SCSKはNew Relicのライセンス販売だけではなく、導入から導入後のサポートまで伴走的に導入支援を実施しています。くわしくは以下をご参照のほどよろしくお願いいたします。

はじめまして。こんにちは。SCSKの髙橋です。 ServiceNowのライセンスの考え方が複雑でわからない、と質問いただくことが多いので 今回はITOM（IT Operations Management）について書いてみようと思います。   ※ITSMについて知りたい人は、こちらの前回投稿をどうぞ。   基本的な考え方 課金の単位 ITSM、CSMなどはユーザー単位の課金です。 ServiceNow社の資料などは月額で書かれていることも多いので注意です。   ITOM、HAMなどはサブスクリプションユニット単位。 SAMはサーバー単位。 SecOpsは脆弱性管理は、デバイス単位、セキュリティインシデント監理はユーザー単位だったりします。   契約期間 月額で書かれていることも多いですが、契約は1年単位ですが、3年契約がおすすめです。 1年契約だと割高になってしまうようです。   ライセンスのパッケージ だいたいStandard／Professional／Enterpriseと三段階用意されていることが多いです。 三段階に分かれていないサービスもあります。 主な違いは使える機能の種類です。 カスタムテーブルを作れる数の上限など、一部数量的な違いがあるサービスもあります。   オプションやアドオン データの暗号化とか生成AI機能とかはオプション購入する必要があります。 Professional以上じゃないと使えないオプションなどライセンスのパッケージと関係がある場合があります。 これが結構複雑なので、自分達のやりたいことがどのライセンスパッケージで使えるのか、 きちんと確認しましょう。   ITOMのサブスクリプションユニット課金の考え方 ITOMは、IT運用高度化ソリューションです。   ITOMはサブスクリプションユニット（SU）単位の課金です。 ServiceNow独自の重み付けがされたデバイス単位、という感じでしょうか。         具体的に書いてみますと、、、 物理サーバーや仮想サーバーは、1台で1SUですね。これはわかりやすいです。 PaaS 3個につき、、というのは、例えばAWS RDSとかAzure Active Directoryとかを1個とカウントします。 FaaSは、AWS Lambdaとかですね。 PCは、エージェントを入れて情報収集しているものに限るようです。 エージェントレスで情報収集できる場合は、課金対象外。   ITOMの機能群 ITOMは、大きくわけて3つの機能群に分かれます。 Visibility Health Cloud Accelerate Visibilityは、構成管理を自動化します。システム構成情報を自動収集、構成管理データベース（CMDB）を最新状態に 保ちます(Discovery)。構成情報とサービスを紐付け、グラフィカルに見えるようにします(ServiceMapping)。   Healthは、障害対応を自動化します。AIを活用し、イベントを一元管理します。 イベントの相関関係を可視化し、根本原因の対処を早期化します。   Cloud Accelerateは、クラウド運用をプロセス化し、管理を効率化します。 マルチクラウドのコストを一元管理し、サービスカタログを使ってプロビジョニングを自動化します。   ITOMのライセンスのパッケージ ITOMは、ライセンスの種類によって使える機能が違います。 Visibility Cloud Accelerate AIOps Professional AIOps Enterprise   Visibilityの機能（DiscoveryやServiceMapping）を使いたいなら、Visibilityのライセンスです。 Cloud Accelerateの機能（マルチクラウド管理やクラウドプロビジョニングの自動化）をしたいなら、 Cloud Accelerateのライセンスとなります。   AIOpsは、Professionalだと、Visibilityの機能に加えて、Health（イベント管理の一元化など）が利用できます。 Enterpriseになると、Cloud Accelerateの機能も加わって、IT運用全体の高度化が可能となります。   ちなみに、CMDBは、プラットフォームで提供される機能なので、 ITOMに限らずServiceNowを契約すると利用できるものです。 一つ一つ登録するか、データをインポートする等でCMDBを作成することが可能ですが、 煩雑な更新作業により最新化が漏れてしまうこともあります。   鮮度の高いCMDBは、運用を高度化させるためのまさに基盤、土台と言えるでしょう。   アドオン、オプションの種類 アドオンもたくさんあって、増え続けているので書ききれないのですが、最低限こんな感じかと。 ITOM Professional Plus：Now Assist for ITOMというAIを使うためのライセンスで同じくSU単位課金です。 Visibility関連では、構成情報に関する履歴をサマリ出来たり、自然言語で検索することができます。 Healthでは、アラートのトリアージやビジネス影響の分析が可能です。 ※Pro Plusを購入するには、前述のAIOps Pro以上の契約が前提となっていますので、注意してください。 Platform Encryption：インスタンス全体の暗号化オプションです。 Impact：ServiceNow社のサポート契約で、ライセンスとは別に有料の契約が必要です。 サポートのサービスレベルによってプランが複数用意されています。業務の重要性に応じて検討しましょう。 専任のエンジニアがつく最高位のプランもあります。   あとは、様々な他社製品のデータをServiceNowで統合したい場合は、 Workflow Data Fabricという別のサービスの購入が必要です。   他は、、、 ITSM、ITOMと書いてきましたが、ServiceNowにはまだまだたくさんの製品があります。 次は、Security書いてみようかな。 乞うご期待。   最後まで読んでいただき、ありがとうございました。

こんにちは、ひるたんぬです。 前回のブログに続き醤油についての話題です。 ※ 最近ふと思いつく小ネタが、たまたま醤油になってしまっているだけです。 「濃口醤油」と「淡口醤油」の違い、皆さんはご存知ですか？ 色が違うというのは字面からイメージできますし、それに伴い製法や材料も異なるんだろうなぁ…とは想像できます。 では、どちらがしょっぱいのでしょうか？ 私はてっきり「色が濃い濃口醤油の方がしょっぱいでしょ。漢字にも「濃」ってあるし。」と思っていたのですが、実は、淡口醤油の方がしょっぱいのです。 うすくちの塩分は、こいくちよりやや高め うすくちしょうゆというと、塩分も低いと思われがちですが、実際はやや高めです。色や香りがつきすぎないよう、食塩をこいくちより1割ほど多く含むためです。 引用：しょうゆ情報センター「 種類 」 しょうゆ情報センターなる機関が存在することを、この調査を通じて初めて知りました。 さて、今回は題名にもありますが、Amazon SNSでテキスト情報を送る際に何度が躓いた点があったので、その点と実際の解決策の一つをご紹介いたします。 やりたかったこと・試したこと 物理コンピュータ（Windows）で所有しているテキストファイルの内容を、Amazon SNSを利用してメールで送る、という作業です。テキストファイルのファイルサイズ（≒文字数）はファイルによって大きく異なります。 案① CLIでそのまま書き込む 後述する案では、メールの本文をカスタマイズできないため、最初はCLIの引数として、直接テキストファイルの内容を与えることを検討しました。 この場合、Amazon SNSのpublishコマンドにより実行が可能です。 aws sns publish --topic-arn "arn:aws:sns:[リージョン]:123456789012:[トピック名]" --subject "[題名]" --message "[本文]" 実際に送ってみましょう。 問題なく送れますね。実際に受信メールも確認してみます。 題名も本文も問題ないですね。 さて、ここからが本題です。 先程は本文が一文と短かったのですが、これが長くなってくるとどうでしょうか？ 例えば、「吾輩は猫である」の一節を送りたいとき、ありますよね。うんうん。 先程と同じような手順で送ってみます。 本文をテキストファイルに保存し、本文内容を引数として格納したうえで、メール用に追記してから送ってみます。 本文は青空文庫（ 吾輩は猫である ）より引用しております。 「吾輩は猫である」は著作権の切れている作品であるため、青空文庫の ファイルの取り扱い規準 を確認の上利用しております。 $contents = Get-Content "[読み込みたいテキストファイル]" -Raw $message = "以下は夏目漱石の「吾輩は猫である」の一節です。`n`n" + $contents aws sns publish --topic-arn "arn:aws:sns:[リージョン]:[アカウントID]:[トピック名]" --subject "おすすめ小説" --message $message エラーが出てしまいました。 この原因は、AWSによるものではなく、PowerShellによるものです。 ピッタリ該当する公式のドキュメントは見つからなかったのですが、PowerShellなどで使える最大文字数は32,767文字とされています。 https://learn.microsoft.com/ja-jp/windows/win32/fileio/maximum-file-path-limitation?tabs=registry 実際に検証もしてみましたが、32,767文字前後にてエラーが出ることを確認しました。 公式ではありませんが、redditでも同様の議論がされています。 https://www.reddit.com/r/PowerShell/comments/8ylspm/fun_fact_windows_has_a_command_line_character/?tl=ja 今回送ろうとしていた「吾輩は猫である」の一節は、およそ5.6万文字のため、今回の制限に引っかかっているものと考えられます。 案② テキストファイルの内容の箇所を、ファイルパスとして引数で与える 案①の制限を踏まえ、少し手間ではありますが、メールの本文にカスタマイズしたファイルを別途作成し、そのファイルパスを引数として与えることを検討しました。 ただ手順としては、先程のコマンドを少し変更するのみです。 $contents = Get-Content "[読み込みたいテキストファイル]" -Raw $message = "以下は夏目漱石の「吾輩は猫である」の一節です。`n`n" + $contents Set-Content "[メール本文のテキストファイル]" $message aws sns publish --topic-arn "arn:aws:sns:[リージョン]:[アカウントID]:[トピック名]" --subject "おすすめ小説" --message file://[メール本文のテキストファイル] ここでの注意点としては、最後のmessageの引数の値の先頭に「file://」を忘れないことです。これがないと、パスそのものが送られてしまいます。 …さぁ、これでどうでしょうか。 送れていますね！実際のメールも見てみましょう。 しっかり届いていますね！ …ここまで来たら、全文送ってみたくなりますよね？ （メールで小説は読まない、というご意見は一旦受け付けないでおきます。） 同じようにやってみましょう。 （読み込ませるファイルが変わるだけなので、コマンド例は省略します。） エラーが出ましたね。ただ、先程とは異なり、今度はAWS CLI側のエラーのようです。 こちらのエラーはAmazon SNSのクォータに抵触したために出たものになります。 メッセージの最大サイズは 262,144 バイト (256 KiB) です。…（後略） 引用：AWS 公式ドキュメント「 Amazon Simple Notification Service エンドポイントとクォータ 」 キロバイト（KB）表記ではないんですね。。 今回送ろうとしていたファイルは約680KiBだったため、上記クォータに抵触していることが分かりました。 最終的な解決策 クォータのページを見てみると、以下のような記載がありました。 （前略）… 256 KiB を超えるメッセージを発行するには、 Amazon SNS 拡張クライアントライブラリ を確認 します。最大ペイロードサイズは2GBです。 引用：AWS 公式ドキュメント「 Amazon Simple Notification Service エンドポイントとクォータ 」 ただ、こちらはJavaやPythonにて実行するものと記載があり、今回はPowerShell（AWS CLI）のみで完結させたかったため、この手順は使いません。 拡張クライアントライブラリを使うことによって、2GBまでのメールを送ることが可能になります。 ここはGiBではなく、GBなんですね…謎です。 今回はメールの受信者が、テキストファイルの内容を確認できることがゴールだったため、 「S3にテキストファイルをアップロードした後に署名付きURLを発行、そのURLをAmazon SNSにて送付」 という手段を取ることにしました。 下準備 上記を実現するためには、テキストファイルを格納するためのS3バケットが必要です。 設定はデフォルトで問題ありません。 作成されたS3にライフサイクルを設定しておくと、送信するファイルが溜まり続ける点を解消できます。 実行 一番肝となるのが、署名付きURLです。 バケットポリシーを更新せずに、Amazon S3 内のオブジェクトへの時間制限付きのアクセス権を付与するには、署名付き URL を使用できます。…（後略） 引用：AWS公式ドキュメント「 署名付き URL を使用したオブジェクトのダウンロードおよびアップロード 」 これにより、メールの受信者に対して、期限を設けてファイルを共有することができます。 設定可能な時間制限は、署名付きURLの発行方法により異なります。 コンソールから作成する場合は1分～12時間、CLIやSDKの場合は1秒～7日間まで設定可能です。 参考：AWS公式ドキュメント「 署名付き URL を使用したオブジェクトのダウンロードおよびアップロード 」 AWS CLIを使う場合は、以下で署名付きURLを発行可能です。 aws s3 presign "[S3URI]" --expires-in [有効期限(秒)] 有効期限を設定しない場合は、既定で1時間有効の署名付きURLが発行されます。 今回は10分（600秒）に設定します。 これを使って「吾輩は猫である」の全文を送ってみましょう。 aws s3 cp "[送りたいテキストファイル]" "s3://[バケット名]" $presignurl = aws s3 presign "s3://[バケット名]/[テキストファイル名]" --expires-in 600 $message = "以下は夏目漱石の「吾輩は猫である」の全文です。`n`n全文はこちら！`n" + $presignurl aws sns publish --topic-arn "arn:aws:sns:[リージョン]:[アカウントID]:[トピック名]" --subject "おすすめ小説" --message $message 無事に送れました！一安心… では、同じくメール本文を確認してみます。 メールが届いており、最後に全文のリンクが付いていますね！ こちらにアクセスしてみると… 呪文のように表示されました。しっかり見れますね。 （もちろん保存も可能です。） ちなみに有効期限（10分）が経過した後はどうなるのでしょうか？ アクセスが拒否され、閲覧ができなくなっていることが確認できました。 そのため、受信者が閲覧できる時間をしっかり設定する必要がありますね。 まとめ 今回遭遇・調査したクォータ（制限）をまとめると以下のようになります。 S3を用いることで、より大きなテキストファイルを送ることが可能になりますね。 おわりに AWSのクォータだけでなく、PowerShellのコマンドにも制限があるなど、様々な制約があるということを痛感する出来事でした。 …でも、Amazon S3の保存容量（データ総量）は事実上無制限なんですよね。。どう実現しているのでしょう🤔 Amazon S3 に格納可能なデータの総量とオブジェクトの数には制限はありません。 引用：AWS「 Amazon S3 よくある質問 」

こんにちは、SCSKの伊藤です。 LifeKeeperで「リソース階層の拡張解除」をしようとしたら、誤って「リソース階層の削除」をしてしまった！ そんな経験はありませんか？ 英語表示では「Unextend Resource Hierarchy」「Delete Resource Hierarchy」と似た表記がされていることもあり、誤って自分で削除してしまったことや、同僚が削除してしまい真っ青な顔で「削除してしまいました。」と連絡を受けたことがあります。 そんな時に復旧方法を知っていると、被害を最小限に留めることができます。 本記事では、LifeKeeper構成情報のバックアップとリストアについてご紹介します。   LifeKeeper構成情報のバックアップ・リストア機能について LifeKeeperのバックアップ・リストア機能について 　「LifeKeeperのバックアップ・リストア機能をシステムの障害復旧に使えないのか。」 　「システムリストア後にLifeKeeperのリストアは必要なのか。」 　「LifeKeeperのバージョンアップや構築には使えないのか。」 などのご質問を受けるケースがあります。 LifeKeeperのバックアップ・リストア機能は、 同一環境でのLifeKeeper構成情報の復元に特化した機能 です。 システム障害時にはシステムのバックアップから復旧が必要 であり、 復旧後にLifeKeeper構成情報のリストアは基本的に不要 です。 但し、システムリストア後にLifeKeeperが正常に動作していない場合は、LifeKeeper構成情報のリストアで復旧するケースはあります。 LifeKeeper構成情報のバックアップは、 同一環境かつ同一LifeKeeperバージョンでの利用のみサポートされます 。 このため、構築用途やバージョンアップ後環境のリストアで使用することは保障されておりません。 また、LifeKeeper構成情報のバックアップ・リストア機能はLinux版のみ提供となり、 Windows版では利用することができません 。   LifeKeeper構成情報バックアップの取得方法 LifeKeeper構成情報バックアップは、下記2パターンの方法で取得します。 CRONにより毎日午前3時に自動バックアップする 「autmatic backup」 任意のタイミングにコマンドを手動実行することでバックアップする 「lkbackup」 どちらも「/opt/LifeKeeper/config」配下にバックアップファイルが作成されます。 「autmatic backup」は /etc/crontab の内容を修正することで取得タイミングを変更することが可能   lkbackupでLifeKeeper構成情報のバックアップとリストアやってみた。 今回は、「lkbackup」コマンドを使用してLifeKeeper構成情報のバックアップとリストアを試していきます。 ■環境情報 ホスト名 アクティブサーバ　＝　rhel01 スタンバイサーバ　＝　rhel02 OS Red Hat Enterprise Linux release 8.6 (Ootpa) LifeKeeper製品 LifeKeeper for Linux v9.9.1 LifeKeeper Web Management Console v1.3.1 ■リソース階層 /kdump ファイルシステムリソース 　datarep-kdump データレプリケーションリソース 　　ip-192.168.10.100 IPアドレスリソース   ①事前にアクティブサーバ・スタンバイサーバ両方でlkbackupコマンドを実行してLifeKeeper構成情報バックアップを取得します。 [root@rhel01 ~]# /opt/LifeKeeper/bin/lkbackup -c Executing on rhel01 Creating archive /opt/LifeKeeper/config/archive.2511041601.tar.gz [root@rhel02 ~]# /opt/LifeKeeper/bin/lkbackup -c Executing on rhel02 Creating archive /opt/LifeKeeper/config/archive.2511041601.tar.gz 「lkbackup -c」＝　LifeKeeper構成情報バックアップを作成   ②「datarep-kdump」リソース上の右クリックメニューから、 誤って「リソース階層の削除」を実行 します。   ③サーバとリソースが表示されますが、そのまま「確認」をクリックします。   ④リソース階層の削除の実行確認が表示されますが、そのまま「削除」をクリックします。   ⑤ 成功 が表示されたら、「閉じる」をクリックします。   ⑥リソースが何もなくなりました。   ⑦アクティブサーバ・スタンバイサーバ両方でlkstopコマンドを実行してLifeKeeperサービスを停止します。 [root@rhel01 ~]# /opt/LifeKeeper/bin/lkstop Removed /etc/systemd/system/lifekeeper-graphical.target.requires/lifekeeper.service. Removed /etc/systemd/system/lifekeeper-multi-user.target.requires/lifekeeper.service. [root@rhel02 ~]# /opt/LifeKeeper/bin/lkstop Removed /etc/systemd/system/lifekeeper-graphical.target.requires/lifekeeper.service. Removed /etc/systemd/system/lifekeeper-multi-user.target.requires/lifekeeper.service.   ⑧アクティブサーバ・スタンバイサーバ両方でLifeKeeper構成情報のリストアを実行します。 [root@rhel01 ~]# /opt/LifeKeeper/bin/lkbackup -x -f /opt/LifeKeeper/config/archivve.2511041601.tar.gz Executing on rhel01 You are about to restore LifeKeeper configuration files from archive /opt/LifeKeeper/config/archive.2511041601.tar.gz Are you sure? (yes/no) yes Extracting files from archive /opt/LifeKeeper/config/archive.2511041601.tar.gz [root@rhel02 ~]# /opt/LifeKeeper/bin/lkbackup -x -f /opt/LifeKeeper/config/archivve.2511041601.tar.gz Executing on rhel02 You are about to restore LifeKeeper configuration files from archive /opt/LifeKeeper/config/archive.2511041601.tar.gz Are you sure? (yes/no) yes Extracting files from archive /opt/LifeKeeper/config/archive.2511041601.tar.gz 「lkbackup -x -f <バックアップファイル>」＝　指定のバックアップファイルからリストア   ⑨アクティブ・スタンバイ両方のサーバでlkstartコマンドを実行してLifeKeeperサービスを起動します。 [root@rhel01 ~]# /opt/LifeKeeper/bin/lkstart Created symlink /etc/systemd/system/lifekeeper-graphical.target.requires/lifekeeper.service → /usr/lib/systemd/system/lifekeeper.service. Created symlink /etc/systemd/system/lifekeeper-multi-user.target.requires/lifekeeper.service → /usr/lib/systemd/system/lifekeeper.service. [root@rhel02 ~]# /opt/LifeKeeper/bin/lkstart Created symlink /etc/systemd/system/lifekeeper-graphical.target.requires/lifekeeper.service → /usr/lib/systemd/system/lifekeeper.service. Created symlink /etc/systemd/system/lifekeeper-multi-user.target.requires/lifekeeper.service → /usr/lib/systemd/system/lifekeeper.service.   ⑩削除してしまったリソースが復旧していることが確認できました。   さいごに 今回は、LifeKeeper構成情報のバックアップとリストアについてご紹介させていただきました。 使用するタイミングは限定的ですが、少しでも参考になれば幸いです。   詳しい内容をお知りになりたいかたは、以下のバナーからSCSKLifekeeper公式サイトまで  

こんにちは　SCSK 野口です。 前回の記事 『LifeKeeper for Linux のインストール要件』 では、 Linuxへインストールするための要件をまとめてみました。まだ、お読みでない方は上記リンクからご覧ください。 本記事では「LifeKeeper for Windows のインストール要件」についてご紹介いたします。 Windows版は Linux版とは異なる要件がありますので、ご注意してお読みください。 基本要件について システム要件 LifeKeeper for Windows は、以下のシステム要件を満たす必要があります。(2025年10月時点) ※ プロセッサーについてはこちらのリングからご確認ください。 Windows Server プロセッサーの要件   ちなみに、DataKeeperをインストールする際に必要な容量は 53 MB だよ！ オペレーティングシステム LifeKeeper for Windows v8 は、以下のオペレーティングシステム（OS）がサポートされています。(2025年10月時点) ※ 全てのバージョンで Microsoft .NET Framework 4.5.2 が必要です。     こちらのリンクからダウンロードできます。 http://www.microsoft.com/net Windows版は、サーバ と ユーザーインターフェイスによってサポートOSが違うのね！ ストレージとアダプタ LifeKeeper for Windows は、以下のストレージとアダプタ要件を満たす必要があります。(2025年10月時点) また、共有ストレージを使用することも、複製ストレージを使用することもできます。 ■ストレージデバイス ・アプリケーション要件に基づき、必要なデータストレージの種類と数を判断する ・共有ファイルを使用する場合、ディスクアレイ(RAID)に配置する ・多数のハードウェア RAID 周辺機器を使用することができる ■アダプタ ・構成タイプと周辺機器数から、必要な SCSI または FCホストアダプタの種類と数を判断する ・選択したアダプタを Microsoft がサポートしており、ドライバを入手できることが重要である ※ ストレージとアダプタ、それから周辺機器については、Microsoft のサポートが前提となります。 詳細情報については、こちらのリンクからご確認ください。 Microsoft のハードウェア互換リスト ■ 共有ストレージ構成 ・LifeKeeper for Windows によって保護されるディスクはすべてパーティションに分割する ・Windows ディスクの管理ユーティリティを使用し、共有ディスクアレイのパーティション (ボリューム)を構成する ・パーティションは NTFS ファイルシステムで フォーマット する ・コミュニケーションパスに使用する小さい raw(未 フォーマット ) パーティションを指定 *¹ ・クラスタ内の他のサーバの電源を投入して、すべてのサーバが共有ディスクを認識している ・バックアップサーバから、共有ボリュームのドライブの割り当てが最初のサーバとまったく同じにする ・ディスクの管理ユーティリティを開くのは 1 度に 1 台のサーバだけにする (推奨) ・クラスタ内の各サーバで、これらのフォルダのファイル共有属性をオンにする *² ※ ダイナミックディスクは共有ストレージではサポート対象外です。 *¹ 共有ディスクコミュニケーションパスを使用する場合に 必要です。 *²  共有ボリュームでファイル共有を作成した場合に必要です。 ■ 複製ボリューム構成 (DataKeeper) ・Windows ディスクの管理ユーティリティを使用し、複製されるディスクパーティション (ボリューム) を作成する ・パーティションは NTFS ファイルシステムで フォーマット する ※ ソースボリューム と ターゲットボリュームには同じドライブレターを割り当ててください。 ちなみに、 ソースボリューム と ターゲットボリュームは 、 「 プライマリーサーバ 」と「 バックアップサーバ 」のボリューム のことだよ！ Core ソフトウェア LifeKeeper for Windows Core は、以下で構成されています。(2025年10月時点) ■ LifeKeeper ソフトウェア ・Perl (CPAN v5.32.1) ・Cygwin 2.8 ・Java OpenJDK v21.0.2 ・LifeKeeper GUI（サーバーとクライアントの両方） ‣Microsoft Visual C++ 2015-2019 Redistributable (x64) package (v14.29.30319) ・Curl for Windows v 8.10.1 ■ Coreリカバリーキット ・ボリューム ・IP ・DNS ・LAN Manager ・ファイル共有 ・汎用アプリケーション ・Internet Information Services (IIS) ・PostgreSQL Server ・Recovery Kit for Route53 ・Recovery Kit for EC2 ■ DataKeeper ・DataKeeperドライバー (ExtMirr.sys) ・DataKeeperサービス (ExtMirrSvc.exe) ・コマンドラインインターフェース (EMCMD.exe) ・DataKeeper GUI (Datakeeper.msc) ・パッケージファイル、LifeKeeper for Windowsスクリプト、ヘルプファイルなど LifeKeeper for Windows は Perlが使用されているわね！ ノード設定について コンピューター名/名前解決と留意点 LifeKeeper for Windows は、各ノードにコンピューター名を設定する必要があります。 また、コンピューター名を設定後は各ノード間で名前解決ができるようにしてください。 ちなみに、Windows 2008 R2 および 2012 の hostsファイルは、以下の場所にあります。 ・ %SystemRoot%\system32\drivers\etc\HOSTS ・ C:\windows\system32\drivers\etc\HOSTS ■インストール時の留意点 ・コンピューター名に 小文字が含まれると 起動に失敗します *¹ ・インストールするには 管理者権限が必要 となります *² ・各サーバの ローカルディスクへ個別 にインストールする必要があります *³ ・インストールパスを変更する場合、 空白を含まず、8文字以内 のパスを選択してください *⁴ ※ こちらは悪いパスの例となります。(例) C:\Program Files\LK や C:\LifeKeeper * ¹  インストールする前にコンピューター名を大文字に変更する必要があります。 *² セットアッププログラムは実行できますが、必要な権限がない場合、インストールはすぐに終了します。 *³ 共有ストレージへインストールすることはサポートされていません。 *⁴ スクリプトの問題があるため、アプリケーションエラーが発生します。 コンピューター名に小文字を使用しないように注意してね！ ファイアウォール LifeKeeper for Windows は、以下のポートを開放し、各サーバーで相互に通信できるようにします。 設定してもインストールできない場合、 一時的にファイアーウォールを無効にしてください。 ファイアウォールの設定 ■ クラスタ対象サーバ間の双方向で許可が必要 ・TCP 1500 ～ 10000  : コミュニケーションパスの通信で使用 ・TCP 10001 ～          : DataKeeperの同期で使用 ■GUIクライアントとクラスタ対象サーバ間の双方向で許可が必要 ・TCP 81, 82              : GUI サーバ通信で使用 ・TCP 1024 ～ 65535  : GUIのためのRMI通信で使用 GUIクライアントおよびクラスタ対象サーバを動作させるシステムで、これらのポートを開放する必要があります。 ファイアウォール設定は、インストールやGUIからの管理、そしてクラスター間の通信で重要となります。 DataKeeper を使用する場合、DataKeeper同期で使用されるポートの開放を忘れないでね！ メトリクスとページングファイル LifeKeeper for Windows は、2つ以上のネットワークアダプターを付与する際は、 LifeKeeper のGUI表示が遅くなる場合があります。 そのため、それぞれのネットワークアダプターに対して以下のメトリクスの設定を行ってください。 ■ メトリクスの設定 1.[コントロールパネル] -> [ネットワークとインターネット] -> [ネットワーク接続]から Ethernet0 のプロパティを開く。 2.TCP/IPV4のプロパティを選択 3.「詳細設定」を選択 4.「自動メトリック」の設定を外し、インターフェースメトリックに「1」を入力し、確認 (以降も「確認」) ※ Ethernet1についても同様に設定し、インタフェースメトリックに「2」を設定     Ethernet2についても同様に設定し、インタフェースメトリックに「3」を設定 (以降も同様に設定) LifeKeeper for Windows は、DataKeeper を使用する場合、 「全てのドライブのページングファイルサイズを自動で管理する」を無効にする必要があります。 有効だと、ミラーの一部であるボリューム上の OSによってページファイルが作成されます。 そうすると、DataKeeper は完全な保護に必要なボリューム上で操作を実行できなくなります。 ■ ページングファイル 1.[コントロールパネル] -> [システム] -> [システムの詳細設定]からシステムのプロパティを開く。 2.「詳細設定」を選択 3.「パフォーマンス」セクジョンの「設定」を選択 4.「詳細設定」タブの「仮想メモリ」セクジョンの「変更」を選択 5.「すべてのドライブのページング ファイルのサイズを自動的に管理する」の設定を外し、OK (以降も「OK」) ※ 設定後、DataKeeper の保護下にあるボリュームにページファイルが設定されないようにしてください。 メトリクス と ページングファイル設定を忘れないでね！ ログ LifeKeeper for Windows と DataKeeper におけるログについては、Windowsのイベントログ に出力されます。 そのため、LifeKeeper/DataKeeper の動作状況を確認する際は、Windowsのイベントログをご確認ください。 ■ イベントソース ・LifeKeeper   :LifeKeeper、LK_EISM ・DataKeeper :ExtMirrSvc、DataKeeperVolume、SIOS.SDRSnapIn、ExtMirr ※ ExtMirr のみ、アプリケーションではなく、システム側に記録されます。 Windows のイベントログ 「 アプリケーション 」を見て確認するのよ！ まとめ 今回は、LifeKeeper for Windowsのインストール要件について、ご紹介しましたがいかがでしたか。 ・システム要件では、条件を満たしているか、 余裕を持ったディスク設計かを確認する。 ・OSやアダプタ、それからストレージでは、LifeKeeper/Microsoftのサポート対象であることを確認する。 ・ノード設定では、コンピュータ名/名前解決や留意点、それからファイアウォール設定等を確認する。   詳細情報をご希望の方は、以下のバナーからSCSK Lifekeeper公式サイトまで

こんにちは。SCSKの星です。 本日はバージョンアップ日時を変更する方法を記載していきます。 また業務影響などでバージョンアップ期限が間に合わないときに、ServiceNowに直接バージョンアップの対応期間延長をお願いする方法もあるのですが、それは別の記事に書きたいと思います。   バージョンアップの日時変更方法と期限について ご存じの方も多いと思いますが、ServiceNowのサポートを受けられるバージョンは2つ後のバージョンがリリースされるまでになります。この記事を書いている時点ではZurichが最新バージョンになりますので、２つ前のXunaduバージョンはサポート外になります。 また、このメジャーバージョンアップは半年に一度、大体3月と9月にリリースされます。 そのため、ServiceNowでサポートを受けるには最低年1回のバージョンアップが必要です。 では「一旦サポート範囲外になってもいいから放っておこう」でよいかというとそんなことはなく自動的にバージョンアップをスケジューリングされ、知らぬうちにバージョンアップされてしまいます。 もしかしたらどこかの設定でこちらの機能をOFFにできるかもしれませんが、今はその知見は持ち合わせておりません。 期限内であれば、バージョンアップする日時は自分で設定することができますので、計画的にバージョンアップを行いましょう。   バージョンアップの日時変更方法 まずはNowSupportにログインします。 https://support.servicenow.com/now ※誰でも作成可能なServiceNowIDではなく、NowSupportアカウント用のアカウントが必要です。わからない場合はライセンス管理者にお問い合わせいただくとよいかと思います。 ログイン後、上部にあるタブから インスタンス > インスタンスダッシュボード を開きます。 インスタンスダッシュボードからバージョンアップを延長したいインスタンスを選択します。 予定されている変更一覧から、メジャーバージョンアップに関するものの変更番号をクリックすることで開きます。 「Family EOL Upgrade…」と書いてあるのが該当します。 開いた変更スケジュールページの画面上部にある「アップグレードの予定変更」を押下し、候補日時を選択します。               これでバージョンアップ時期を設定することができます。 バージョンアップの所要時間は場合によりますが目安は3～4時間です。 深夜にやっておくのが業務影響が少なくておススメです。   Family EOL Upgradeがない場合 Family EOL Upgradeがない場合は以下が考えられます。 新バージョンがまだリリースされていない 新バージョンがリリースされる時期は3月と9月あたりのため、それ以外の時期はそもそも新バージョンがリリースされていない可能性があります。 ServiceNowによる自動設定がまだ行われていない 新バージョンはリリースされているはずなのに、ServiceNowによる自動設定がまだ行われていない場合は自分で設定することも可能です。 インスタンスダッシュボードに戻りバージョンアップを延長したいインスタンスの右側にあるアクションボタンから 「インスタンスをアップグレード」を選択することで、自分で変更スケジュールを作成できます。   バージョンアップの期限について 上記方法でバージョンアップ日時を変更することはできますが、いつまでも先伸ばしできるわけではありません。 ある時期を超えて設定しようとすると、エラーメッセージが表示され、スケジュール設定もできません。 ここがバージョンアップの期限となるため、この日時までにバージョンアップ対応を完了させる必要があります。 正式版リリースから約2ヶ月後といったところですね。   補足：詳細画面 「アップグレードの予定変更」ボタンがある画面（インスタンスダッシュボードからバージョンアップを延長したいインスタンス選択→予定されている変更一覧から変更番号をクリックしたら開く画面）にある詳細タブでバージョンアップに関する詳細設定をすることができます。                       こちらからターゲットバージョンの選択ができたり、ウォッチリスト追加することができます。 特にターゲットバージョンの選択には注意が必要です。 同じZurichでも、Patchの違いによって動作や画面表示に差異が生じる場合があります。 例えば、検証時と本番リリース時で適用されるPatchが異なると、検証した内容が網羅できなくなったり、本番環境で予期しないスキップレコードが発生する可能性があります。 バージョン選択時には、検証・本番ともに同一Patchで作業を行うことを推奨します。   以上になります。 冒頭で述べたように、どうしても期限内にバージョンアップができない時の延長願いについても別の記事で書いていこうと思います。

こんにちわ。SCSKの曽我です。 普段、扱っているZabbixの導入作業をオンプレだけでなくAzure上に構築することもあります。 その際、負荷テストを行うことがあります。スクリプトを使ってテストする方法もあるのですが、 もっと簡単にかということで、AzureのAzure Load Testingを使います。 Let’s Try! 環境 AzureのVirtual MachineにRedhat Enterprise Linux＋Zabbixを事前に用意します。 また、App Load Testingが、Virtual MachineにアクセスできるようにNSGを設定します。   Azure Load Testingの器を作成 初めに、テストの大枠となる設定を作成し、その中で、具体的なテスト内容を定義していきます。 ここではまず、大枠となる設定を作成していきます。 ①Azure App Testingを開き、左メニューより[ワークスペース]-[Azure Load Testing]を開き、「作成」をクリックします。   ②以下の項目を入力し、「次へ」をクリックします。 ③暗号化はデフォルト（MMK）まま、「次へ」をクリックします。 ④今回、タグは設定しないので、「次へ」をクリックします。 ⑤「作成」をクリックします。   URL負荷テスト ①作成された「LoadTest-Zabbix」をクリックします。 ②[テスト]-[テスト]をクリックし、[作成]-[URLベースのテストを作成する]をクリックします。 ③「テスト名」を入力し、「次へ」をクリックします。テスト名は今回デフォルト名とします。 ④「要求の追加」をクリックし、負荷を与えるURLを入力し、「追加」ボタンをクリックします。 元の画面に戻ったら、「次へ」ボタンをクリックします。 ⑤「次へ」をクリックします。 ⑥テスト期間を10分に短縮して、「次へ」をクリックします。 ⑦メトリックを取得したいサーバを指定します。 ⑧テストの抽出条件は、デフォルトにして、「次へ」をクリックします。 ⑨「作成」をクリックします。 ⑩作成後にテストを実行するように設定したので、テスト結果が出力されます。 JMX負荷テスト ※あらかじめJMeterのスクリプトを用意しておきます。 ①作成された「LoadTest-Zabbix」をクリックします。 ②「作成」-「テストの作成」をクリックします。 ③テスト名を入力します。今回はデフォルトのまま、「次へ」をクリックします。 ④ロードテストフレームワークが「JMeter」になっていることを確認し、ファイルの選択で事前に用意したJMXファイルを 指定して、アップロードボタンをクリックし、「次へ」ボタンをクリックします。 ⑤「読み込み」は変更しないで、「次へ」をクリックします。 ⑥「パラメーター」も特に指定しないで、「次へ」をクリックします。 ⑦「監視」で監視したいサーバを指定します。今回は、Zabbixサーバを指定します。 ⑧「テストの抽出条件」もデフォルトのまま、「次へ」をクリックします。 ⑨最後に「作成」をクリックします。 ⑩作成後に、負荷テストが実行され結果が出力されます。   テスト結果について テスト結果として、「クライアント側のメトリック」「サーバー側のメトリック」「読み込みエンジンのメトリック」の3種類が グラフとして表示されます。それぞれは、以下のような意味です。 a.クライアント側のメトリック 利用者を想定した視点のパフォーマンスを評価 b.サーバー側のメトリック サービス（アプリケーション）を提供している視点でのパフォーマンスを評価 c.読み込みエンジンのメトリック テストを行っている仕組みのフォーマンスの評価（テストエンジンがボトルネックになっていないか） 以下が、URLのテストをした結果です。 統計のところには、どれくらいのリスクエスとを行い、エラーがどれくらいあったか、応答時間などが表示されます。 ２つ目にクライアント側のメトリックが表示されます。 ３つ目にサーバのメトリックが表示されます。 今回の場合、最大ユーザー数がアクセスした１分後に100%に張り付いてます。 ４つ目に読み込みエンジンの正常性メトリックが表示されます。 ここを見る限りではエンジンによる問題は無さそうです。  

こんにちは。廣木です。 ネットワーク運用を担当していると、「障害が起きていたのに気づくのが遅れた」という経験はありませんか？ ネットワーク障害は、業務停止やサービス品質低下といったビジネスリスクを引き起こします。こうしたリスクを最小化するためには、障害を即座に検知し、通知する仕組みが不可欠です。 CatoのLink Health Rulesを利用すると、 「 Connectivity （接続性 ) 」や「Quality（品質）」状態を監視し、通知 を行うことができます。 今回、前編・後編の2記事に分けてLink Health Rulesの機能をご紹介します。 前編となる本記事では「Connectivity Health Rule（接続性監視）」にフォーカスし、その概要と活用方法を解説します！ 次回の後編では「Quality Health Rule（品質監視）」について投稿予定です。 Link Health Ruleとは？ 「Connectivity Health Rule」についてご紹介する前に、まずは「 Link Health Rule」 の機能概要からご説明します。 Link Health Ruleには2種類あります。Connectivityは「接続性」、Qualityは「品質」を対象とし監視を行い、ルールに従って通知を行うことでネットワークの安定運用を支援します。 Link Health Ruleの種類 Connectivity Health Rules 接続性（Connectivity）を監視し、接続性に関するイベントをトリガーに通知を行います。 Quality Health Rules 品質指標（Quality）を監視し、設定した閾値を超えた場合に通知します。 CatoのBest Practiceでは、 これらの設定を行うことが推奨 されています 。 ただし、具体的な設定値は定義されていないため、各企業様の環境に応じて設定する必要があります。 Connectivity Health Rulesとは？ それでは 「Connectivity Health Rule」についてのご紹介です。 まずは、具体的に何を監視できるのか？を確認してみましょう。 Connectivity Health Rulesでは表1にある接続性に関するイベントの発生状況を監視します。                    表1：Connectivity Health Rulesで選択可能なイベント一覧 No イベントの種類 説明 １ Failover プライマリリンクとセカンダリリンク間、またはその逆のフェイルオーバー ２ Active WAN Link Disconnect アクティブ状態のリンクの切断 ３ Passive WAN Link Disconnect パッシブ状態またはラスト リゾート ステートのリンクの切断 ４ Socket Failover HA 構成のソケット間のフェイルオーバー ５ Internet as a Transport インターネット(Cato Cloudではない)を介してデータを転送しているリンクの切断 選択するイベントは構成により異なります。 例えば、Socketがシングル構成でWANリンクも非冗長の場合は 「Active WAN Link Disconnect 」を選択するのが一般的です。また、SocketがHA構成の場合やWANリンクが冗長構成の場合は、必要に応じてさらに「Failover」「Socket Failover」「Passive WAN Link Disconnect 」を追加することで、障害発生時の状況をより正確に把握することができます。   なお、複数イベントを選択した場合は 「ＯＲ」の関係 が成り立ちます。つまり、選択したイベントのうちいずれかのイベントが発生したら通知が行われます。 Connectivity Health Rulesの設定例 次に、具体的な設定例を見ていきます。 ※本記事でご紹介するのはあくまで一般的な設定例です。実際の設定は、各企業の環境に応じて設定いただきます。 今回はこんなシナリオを想定して設定を行っていきます。 拠点 「 SCSK-Demo-Site 」の 「 Active WAN Link Disconnect」イベントをトリガー に管理者へ通知 する 設定方法 2025年11月現在、Connectivity Health Rulesの設定項目は以下の通りです。 * は任意の設定項目で、その他は必須です。 ※実際にはTrackingも任意ですが、通知先を指定する項目なので基本的には設定必須とお考えください。 表3：Connectivity Health Rulesの設定項目 No 設定項目 設定内容 １ General Name 任意のルール名を入力 ２ Source – 監視対象をSite/Group/System Groupから選択 ３ Condition On Event トリガーとするイベントを選択 ４   Alert Upon * 通知の条件を設定 ５ Tracking Frequency Immediate/Hourly/Daily/Weekly ６   Send notification to Mailing List/SubscriptionGroup/Webhookから選択 2025年1月2日以降、頻繁な接続・切断による通知過多を防ぐため、ユーザーやユーザーグループをSourceとして定義できなくなりました。 設定値はこちらです。任意の設定項目である Alert Uponは未設定としています。   General Name ： Test Source Site ： SCSK-Demo-Site Condition On Event ： Active WAN Link Disconnect Alert Upon ： – Tracking Frequency ： Immediate( 即時 ) Send notification to ： Mailing List(All Admin)   設定を行うと、下図のような表示になります。 通知タイミング この時、通知のタイミングをまとめるとこうなります。 通知タイミング リンクダウン検知後、2.5 分以上ダウン状態を継続している場合に Disconnect イベントを生成し通知 リンクダウン検知後、2.5分以内に再接続があった場合に、 Reconnect イベントを生成し通知 Reconnect イベントは、接続が復元されてから最大 30 秒の遅延で検出される場合があります。 リンクアップ検知後、30 秒間アップ状態を継続していることを確認後 Connected イベントを生成し通知 POINT この結果から、押さえておきたいポイントは2つあります。   1. 即時通知されない Catoではリンクダウン後、2.5分間の評価期間を設けています。この間に再接続があれば「瞬断」扱いとなり、Disconnectイベントは生成されません。そのため、リンクダウンを検知しても即時で通知はされない仕様となっています。 Catoのイベント生成ルール リンクダウン検知 → 「Session Disconnected」ジョブ開始（トリガー時間：2.5分） この時間内に再接続が発生した場合：     同じPoPへ再接続 → 「Session Disconnected」ジョブ開始ジョブキャンセル → 「Session Reconnect」ジョブ開始（30秒） 異なるPoPへ再接続 → 「Session Disconnected」ジョブ開始ジョブキャンセル → 「Session Changed PoP」ジョブ開始（5秒）   2. 切断時だけでなく復旧時も通知される 2025年8月の機能拡張により、復旧イベント（Connected・Reconnected・Changed PoP）も通知される仕様に変更されています。 次に説明するオプション設定で通知回数を調整する際には、この点に注意が必要です。復旧イベントも回数にカウントされるため、設定値は慎重に検討することを推奨します。 オプション それでは、瞬断を検知し即時通知したい場合や、切断/復旧時の通知が大量に発生してしまっている場合はどうすればよいでしょうか？ このようなケースでは、オプション機能を利用し通知条件をカスタマイズすることで、環境やご要件に応じてチューニングを行うことができます！ なお、この設定は先ほどご紹介した設定項目の中で任意となっていた Alert Uponで行います。 リンクダウン期間の調整 瞬断を検知し即時通知したい場合は、Alert Uponでリンクダウン時間を設定します。 例えば、「1分間リンクダウン状態が継続した場合に通知したい」という場合は、リンクダウン期間を1分に設定します。 この時、通知のタイミングをまとめるとこうなります。 通知タイミング リンクダウンを検知後、 1 分間リンクダウン状態を継続している場合にDisconnectイベントを生成し通知 リンクダウンを検知後、2.5 分以内に再接続された場合 Reconnect のイベントは生成されない リンクアップを検知後、30 秒間アップ状態を継続していることを確認後 Connected イベントを生成し通知   このリンクダウン期間は、 極端に短い期間を設定すると通知が大量に発生する可能性があるので注意が必要です。 通知回数の調整 また、切断/復旧時の通知が大量に発生してしまっている場合はAlert Uponでイベント発生回数を設定します。 例えば、「1時間に4回イベントが発生したら」という条件を設定することで、通知回数を調整できます。 この回数は、 実際のイベント発生状況を確認しながら、適切な値を設定することを推奨 します。 また、繰り返しになりますが 復旧イベント（Connected・Reconnected・Changed PoP）も回数にカウントされる ため、設定時には注意が必要です。 さいごに 今回は、Link Health Rulesの中でもConnectivity Health Rulesについてご紹介しました。 障害を迅速に検知し、通知する仕組みを構築することで、ネットワーク運用の安定性を高めることができます。 ぜひ本記事を参考に、貴社の運用にお役立ていただければ幸いです！

  こんにちは！SCSKの三浦です。 前回に引き続き、ServiceNow World Forum25 Day2の参加レポートをお届けします！ Day1レポートはこちらからどうぞ   Day2 スタート！ 2日目も開場するとすぐに多くの人でにぎわい始めました。 弊社ブース説明員も担当しましたが、1日目以上に多くの方にITSM領域についてご説明することができました。 この日は基調講演と初心者向けのセッションに複数参加しました！   基調講演 2日目の基調講演も和太鼓やけん玉を用いた華やかなパフォーマンスからスタートしました。 この基調講演で語られたのは AIエージェント について。 AIと人の協働を実現するために、生成AIの先を行くテクノロジーが紹介されていました。 先輩社員によると、昨年のWorld Forumでは生成AIに関するセッションが多かったそうですが、今回は減っていたとのことです。 私自身、生成AIが最新のテクノロジーだと思っていたので、さらに進化した技術が存在し、すでに活用している企業があることに驚きました。   AIエージェントとは では、生成AIとAIエージェントの違いとはなんでしょう。 生成AIは人の依頼に対し、学習データをもとに提案・回答という形で業務を手助けする、あくまでサポート役でした。一方AIエージェントは、一連の業務の計画から実行までを自律的に行うことができます。 つまりAIがサポート役から、人の代わりに仕事を行う段階へと進んだということです！ ServiceNowはそんなAIエージェントを搭載しており、既に活用している企業もいくつか紹介されていました。 基調講演で紹介されていた活用例からAIエージェントで具体的に何ができるかについてご紹介します！   具体的なAIエージェントの活用例 ～出張申請～ 出張日を決めたり、予算を確認したり、各部署から承認をもらったり…… 出張申請には多くの工程がありますが、AIエージェントに依頼すれば、人間は仕上がった申請案を承認するだけで済みます。 AIエージェントに出張申請を依頼すると、AIエージェントは次に実行すべきフローエージェントを順番に呼び出していきます。 例えば、日程調整エージェントが出張候補日を抽出し、その後ポリシーエージェントが社内規定の確認を行う、といった流れです。 各エージェントはOutlookやSharePointと連携しており、必要な情報を効率的に検索できます。 こうしてAIエージェントが一連のフローを回し、依頼者には完成した出張案の承認依頼だけが届く仕組みです。 従来のように複数人から承認を得て、その都度マニュアルを参照する必要があった時と比べ、時間も工数も大幅に削減できます。 まさにその名の通り、自分専属のエージェントがいるような感覚ですね！   基調講演では、AIエージェントに関する話題が中心でした。 私はまだServiceNowでAIエージェントを使ったことはありませんが、AIを「AI」と意識せずに日常で使う日が近いと感じました。   Day2 セッションレポート ここからは2日目に参加したセッションで学んだこと、感じたことをご共有します！   はじめてのServiceNow 初学者として、絶対に参加しようと決めていたセッションです。 ここで学んだことをもとに、改めて「ServiceNowとは何か」をご説明します！ ServiceNowとは、 企業の業務用アプリケーションの集まり です。 IT部門、セキュリティ部門、人事など、企業の各部門に合わせてパッケージ化されたアプリケーションを、SaaS製品として提供しています。 例えば ITSM ：インシデント・問題・変更などのITサービス管理 SecOps セクオプス ：インシデント対応や脆弱性管理 CSM ：カスタマーサービス管理 このように、さまざまな製品があります。 さらに、ServiceNowは業務アプリ(SaaS)だけでなく、その基盤となるアプリ開発・運用プラットフォーム(aPaaS)も提供しています。 つまり、アプリを「使う」だけでなく、自社用に「作る」「拡張する」ことができる総合プラットフォームです。ServiceNowがあれば、ワンプラットフォーム上で複数の部門の業務を統合して進められるということですね！   このセッションを通じて、ServiceNowの概要やできることを詳しく学ぶことができました。 来年World Forumに参加する際には、1年間でどれだけ理解度が上がったかを確かめるために、またこのセッションに参加したいと思います！   クロージングセッション 今回のWorld Forumを締めくくるクロージングセッションにも参加しました。 まず、Creator Hackathon決勝の優勝者が発表され、SCSKは見事3位入賞でした！おめでとうございます👏 もっといい写真があればよかったのですが、、、舞台で表彰されているところです。   クロージングセッションでは、AI推進の第一人者である小澤健祐氏が登壇し、「これからのAIの未来」について講演されました。 講演では、「これからの時代、顧客体験はAIエージェントが創り出す」と語られていました。 印象的だったのは、プロンプトエンジニアリングからコンテキストエンジニアリングへ進化していくという見解です。 これからは、単に指示を工夫するだけでなく、利用するデータや状況を踏まえた設計が重要になるとのことでした。 AIに適切なコンテキストを与えることで、より精度の高いアウトプットを得ることが求められるようになるそうです。   World Forumを終えて World Forumに両日参加し、たくさんの学びと気づきを得ることができました。 セッションでは、ServiceNowの概要だけでなく、各企業がどのようにこのプラットフォームを活用しているのかを知ることができ、非常に参考になりました。 特に印象的だったのは、ServiceNowがただ製品を提供する会社ではなく、 AI企業としての側面を持っていること です。生成AIの先を行く「AIエージェント」というテクノロジーには驚かされました。今後は、まずServiceNowの使い方を覚えて基礎力を身につけ、そのうえでAI活用にも挑戦していきたいと強く感じています！ また、ブース対応では、実際にServiceNowを導入した企業の担当者と直接話す機会がありました。その中で、「導入したものの使いこなせていない」「工数削減が思うように進んでいない」というリアルな声を聞き、自分たちのサービスでこうした課題を解決したいという思いが強まりました。 2日間を通して、ServiceNowの可能性と現場の課題、その両方を肌で感じることができたのは大きな収穫です。次は、この学びをどう行動につなげるか。基礎力を固め、AI活用を視野に入れながら、現場に寄り添うServiceNowエンジニアを目指して引き続き頑張ります！！   最後まで読んでいただき、ありがとうございました！

こんにちは。SCSKの松渕です。 今回は、Google Cloudで VPC SC(VPC Service Controls)の設定 をしたいと思います。 概念だけは知っていましたが、実際に設定するのは初めてでした。 はじめに VPC Service Controlsとは VPC SC(VPC Service Controls) とは、Google Cloud リソースの周囲に 論理的な境界 を確立し、APIレベルでアクセスを制御する高度なセキュリティサービスです。IAMと組み合わせて 二重の防御 を構築することで、盗まれた認証情報や設定ミスによる データ流出のリスク を大幅に低減します。 IAMとの併用を推奨や、VPC SCの目的がデータ流出防止である点はGoogle公式ドキュメントにて明記されてます。 VPC Service Controls の概要(Google Cloud ドキュメント) 理解しにくい人のために 要するに、 Google Cloud APIの呼び出しを制御するサービス とシンプルに捉えることができますが、私は最初は理解に時間がかかりました。 個人的に VPC SCの理解が難しかった 大きな理由が、 AWSに同様の機能がない ことが挙げられます。サービス単位でいえばS3バケットポリシーとかが近い気がしますが、サービス単位ではなくGoogleCloud全体にまたがるものです。 また、 “VPC”と名前につくが、いわゆるネットワークレイヤ（L3,L4）ではない 点も混乱する原因かと思っております。 “VPCとは別物だ”と理解したほうが個人的にはしっくり きました。 IAMに近いサービスで、データ漏洩に重点を置いてIAMとで二重の境界線を設定するサービス というイメージで理解しております。 IAM制御との違いと今回の目的 今回は、 Google Cloudを利用する際に特定のIPからのアクセス制限を実装 するために利用します。 上記サービス説明である通り、似た目的でIAMでの制御でも実装可能な側面もあります。 今回 IAMではなくVPC SCを利用 した意図としては、 権限制御よりデータ漏洩防止に主眼 を置いているため、 VPC SCのほうが適していると判断したためです。 特徴 👤 IAM (Identity and Access Management) 🛡️ VPC Service Controls (VPC SC) 主眼（目的） 権限制御 と アクセス制御 データ漏洩防止 制御の焦点 誰が (Who) 、 何の操作 を 実行できるか 。 データ が どこへ (Where) 、 どのように 移動できるか。 制御レイヤー 認証・認可 レイヤー（リソースへのアクセスを制御）。 API レイヤー（Google Cloud API呼び出しを制御）。 制御方法 ユーザー/サービスアカウントに ロール を付与し、操作の許可/拒否を定義。 サービスの周囲に 境界 を設定し、境界をまたぐAPIリクエストを 強制的にブロック 。 セキュリティの役割 第一の防御線 ：最小権限の原則を適用する。 最後の防御線 ：IAM設定ミスや認証情報盗難時のデータ流出を阻止する。   事前準備 前提条件 VPC SCにせよIAMにせよ、IPアドレスでアクセス制限するには Access Context Manager を利用します。 前提として、プロジェクト単体では利用できないため、 組織へ所属 する必要があります。 【GoogleCloud】組織の作成および既存プロジェクトの組織への移動方法 Google Cloud の組織作成方法と、プロジェクトの移動方法を紹介します。 blog.usize-tech.com 2025.06.11 実装したい制御方法（要件）の整理 どんな制御したいのか？をイメージしましょう。いかに、基本的なポイントを箇条書きします。 制御対象のGoogle Cloudサービス（どのAPIを境界内に入れるか）を検討します。 VPC SCの基本は、保護したい Google Cloud プロジェクト を丸ごとサービス境界に含めることです。すべて含めて不都合がなければ基本的にはすべて含めることをお勧めします。 IPアドレスに加え、アクセス元の デバイスポリシー（暗号化状況など）や特定のリージョン/国 といった、より詳細なコンテキストでの制限も可能です。 「このユーザはこのIPアドレスから」といったユーザ/グループ　といった単位での制御も可能です。 ただし、グループ制御の場合はGoogle Workspace側でグループ作成が必要になります。   default policyの確認 組織のポリシー確認 「セキュリティ」の左カラムから、「ゼロトラスト」の中の 「VPC Service Controls」を押下 します。   以下のような画面が出たら、プロジェクトが選択されている状態です。 VPC SCの設定は組織が前提 になります。 「組織スコープに切り替え」を押下して、所属組織を選択 します。 同一スコープのポリシーは1つだけ 私がはまった箇所です。 デフォルト状態であれば、以下のように “default policy” というのが選択されている状態になるかと思います。 初期で作成されているポリシーで、 組織全体をスコープにしています 。境界の設定は入っていないものになります。   「ポリシーを管理」を押下して、中身を確認 します。   「組織レベルのポリシーの範囲外」 と表記されていれば、 組織全体をスコープとしていることを示しており 、想定通りです。 今後、この “defaut_policy”を利用 します。 ドキュメント上の明記は少ないものの、 リソースの排他性 の原則に基づき、 同一スコープ（組織全体）での複数ポリシーの作成は不可能 です。 defaultポリシー使うのが気持ち悪かったので、 組織全体スコープにしたポリシーを別途作成 しようとしたのですが うまくいかず 。 原因をGeminiに聞いたら上記回答でした。   Access Context Managerの作成 Access Context Managerの作成 境界の設定の前に、境界設定に必要となるAccess Context Manager（ACM）を作成します。 「セキュリティ」の左カラムから、「ゼロトラスト」の中の 「Access Context Manager」を押下 します。 ※プロジェクトではなく、 組織を選択した状態で操作 します   「アクセスレベルを作成」を押下します。   アクセスレベルを作成します。 ここでの設定は、制御までは設定せずに 「どういうアクセス条件を識別するか」のみを設定 します。 IP制限を目的としているので、特定IPアドレスからのアクセスであることを識別するようにします。（Trueで返すように設定します） 入力したら「保存」を押下。 地域制御（日本からのアクセスを識別）や、デバイスポリシー（組織管理下デバイスからのアクセス識別）等も設定可能です。 なお、デバイスポリシーの設定は Chrome Enterprise Premium が必要になります。               また、GUI以上の細かな制御も詳細設定というもので可能とのことですが、 こちらも Chrome Enterprise Premium が必要。   ACMの一覧画面に戻ります。作成されたことを確認します。     境界の作成 ドライランモードでの作成 VPC SCの画面に戻ります。 「セキュリティ」の左カラムから、「ゼロトラスト」の中の 「VPC Service Controls」 を押下します。 default policyを選択している状態で、 「+新しい境界」を押下 します。   サービス境界の作成画面に遷移します。 「テストを実行」を選択して、「続行」を押下 します。 「テストを実行」を選ぶことで、ドライランモードとなります。 境界外からのアクセスがあった際、 アクセス拒否はさせないが、 監査ログ上でをエラーとして出力 するモードです。 設定を入れる前に影響調査のために利用されます。               今回は検証のため、いきなり適用も可能でしたが、ドライランの挙動を確認するためにこのモードを選択しました。   次の画面では、 制限する対象プロジェクトを選び、続行を押下 します。   次の画面では、 制限する対象プロジェクトを選び、続行を押下 します。    今回の検証ではDiscovery EngineとCloud Storageのみ設定してます。 基本的な考えとしては 可能な限り多くのサービスを設定したほうがデータ漏洩リスクは低くなります。 しかし、設定した際の影響も考慮した現実的な検討を行いましょう。 BigQuery、Cloud Storage、Cloud SQL等の リスクが高いサービスから優先的 に検討/実装を行うのが現実的 です。   VPCのアクセス可能なサービスを選びます。 VPCネットワーク内部からPrivate Google Accessを利用してGoogle API にアクセスする際の アクセス先（出口）を制限する設定 です。 今回はVPC内部ネットワークからのアクセスを想定しないため、この設定はスキップしました。 そのまま続行を押下。   次の画面では 、前章で作成したアクセスレベルを追加して、続行を押下 します。 「アクセスレベル」の画面で設定したことは、 すべてのユーザに対しての設定に なります。 特定ユーザのみ等、詳細設定したい場合は次の「上りポリシー」等で設定しましょう。   上りポリシーと下りポリシーの設定画面に移動します。 ここでは、 「アクセスレベル」の画面での設定を上書きする例外設定 が可能です。 特定ユーザのみは許可を行ったり、特定サービスについては条件緩める等の設定です。 今回は例外はないためそのまま作成します。   ドライランモードでのログ確認 ドライランモードでの作成が完了したら、VPC SCの画面に移動します。 ログでの動作確認のため、右上にある 「監査ログ」を押下 します。   Cloud Loggingの画面に遷移します。 境界外からのアクセスが確認できるクエリ があらかじめ設定されています！ とても便利・・・！ ただ、いくつか設定してあげないといけなかったです。 組織が選択されていると思いますので、「プロジェクト」を選択 します。 ログ表示の期間を適切に修正します。 そうすることで、画面下部に境界外からのアクセスが確認できました。 今回、私が意図的に境界外からアクセスしていたものをしっかり検知できていました。 ちゃんと動いていそうです。   境界の適用 適用して大丈夫だと判断できたら、ドライランから適用します。 VPC SCの画面から、「ドライランモード」を選択し、適用したい境界を押下 します   画面右上の 「構成を適用」を押下。 確認画面が出ますので、それもＯＫを押下。        「自動適用モード」に移動すると、境界が表示 されており、 適用プロジェクト数が選択したプロジェクト数になっています。 これで、適用されております。   動作確認 今回はCloud StorageとNotebook LM Enterpriseで確認します。うまく制御できていることを確認できました。 Cloud Storageの画面   NotebookLM Enterpeiseの画面   まとめ 本記事を通して、VPC Service Controls（VPC SC）は、その名称から連想される従来のネットワーク制御とは一線を画した、 Google Cloud 独自の高度なセキュリティレイヤー であることをご理解いただけたかと思います。 1. 役割の明確な区別 IAM が「 誰が リソースにアクセスできるか」という 権限 を制御するのに対し、VPC SC は「 データ が どこへ 流出するか」という データ漏洩防止 に主眼を置いています。 AWSには単一のサービスとして相当するものがなく、 複数の機能（バケットポリシーなど）を組み合わせる必要がある ため、VPC SCの「統一された境界」というコンセプトの理解が難しい原因となっていました。 2. VPC SCの基本と強力な防御 VPC SCは、IAMと連携して 二重の防御線 を構築します。 API レベルでの制御: VPC SCは、L3/L4ではなく、Google Cloud APIの呼び出しという L7レベル で機能し、境界外への不正なアクセスやデータ持ち出しを強制的にブロックします。 Access Context Manager (ACM): ACMの アクセスレベル （IPアドレス、デバイスなど）を VPSC に適用することで、境界へのアクセスをさらに厳格化できます。 ドライランモード: 導入前に ログで影響をシミュレーション できるため、安心して高度なセキュリティを実装できます。 VPC SCは、貴社の機密データを IAMの設定ミスや盗まれた認証情報 から守るための「 最後の砦 」です。データを Google Cloud で安全に扱う上で、この強力なセキュリティ境界の導入をぜひご検討ください。

こんにちは。SCSKの和田です。 2025年10月16日・17日、東京国際フォーラムで開催された 「日経クロステックNEXT東京2025」 に、 SCSKの国産プライベートクラウド「USiZE（ユーサイズ）」 としてブース出展してきました！ 本記事では、イベント全体の雰囲気や注目ポイント、ブース出展で得た気付きやクラウド選びのヒントまで、まとめてお届けします。 ちなみに・・・「USiZEって何だろう？」と思われた方、または「ちょっと気になる！」という好奇心旺盛なあなた！ USiZEの世界を覗いてみたくなったら、まずはこちらをクリック↓ データ主権を担保したソブリンクラウド ユーサイズ│SCSK株式会社｜サービス｜クラウド移行だけでは描けない、理想のDXを実現する 高可用性、高機密を備えた国産のSCSKのプライベートクラウドです。ファシリティスタンダード最高レベルのティア4に適合する日本国内のデータセンター上で稼働し、お客様データの保護とデータ主権を確保します。 www.scsk.jp イベント概要 「日経クロステックNEXT東京2025」は、 AI・DXの総合展として98社が出展、2日間で10,535人が来場 ！ セミナーや展示ブースは満席・盛況で、最新技術動向や課題解決のヒントを求める声がたくさん聞こえてきました。 変革の最前線がわかるAI/DXの総合展 – 日経クロステックNEXT 東京 2025 イベント会場マップ   SCSKブースの展示内容と来場者のリアルな反応 SCSKブースでは、 VMware問題に悩む企業向けに「USiZE」の活用方法 を中心に展示。 一番の推しポイントは 「クラウド移行のハードルをグッと下げて、最適な移行先をじっくり検討できる！」 ということ。 オンプレミスのVMware環境からUSiZEへの移行は、 アプリケーション をそのまま移行 IPアドレス をそのまま移行 レガシーOS をそのまま移行 という ３つの「そのまま」移行で、塩漬けシステムも移行が可能 ！しかも、USiZEは 20年以上の実績を持つ国産プライベートクラウド 。 運用もSCSKにお任せできるマネージドサービスなので、「クラウドにしたいけど運用が不安…」という方も安心して使えます。 さらに、 パブリッククラウドとの接続性も抜群 で、 クラウドネイティブ化の支援も 充実！ ブースで展示していたパネルをご紹介 また、イベント会場内のオープンシアターでは 『VMware問題の駆け込み寺！国産マネージド型クラウド「USiZE」が解決！』 と題したセミナーも開催しました！ オープンシアターでのセミナーの一幕 セミナーの資料も少しだけご紹介 ✨ さらにイベント会場内メインシアターの「日経クロステックNEXTで学ぶ、最新トレンド総ざらい」プログラムでも 「仮想化」が取り上げられ、SCSKブースの紹介もありました。 メインシアターでSCSKブースの紹介が！！ 実際のブースでは、資料を手に取ってじっくりご覧いただく方や、移行や運用について個別にご質問くださる方もいらっしゃいました。 「移行のハードルが低いのはありがたい」「運用も任せられるのは安心」「ハイブリッドクラウドやクラウドネイティブ化も相談できるのは心強い」といった声もいただき、USiZEの“使いやすさ”や“柔軟さ”に興味を持っていただけたのが印象的でした。   AIブースの盛況とちょっとした反省 イベント会場内では 「生成AI」「AIデータ活用」「AIエージェント」 といったAI関連のブースやセミナーが特に盛り上がっていました。 来場者アンケートでも 関心度のTOP3はこの3つだったとの情報もあり、まさにAIが主役のイベント！ 実はUSiZEでも、 AIを活用したランサムウェア対応サービス を提供しているのですが、 今回は「クラウド移行のハードルをグッと下げて、最適な移行先をじっくり検討できる！」というポイントでの紹介に注力しすぎて、 AI×セキュリティの強みをもっとアピールすれば良かったかも…と少し反省。。。 次回は「クラウド×AI」「AIによるセキュリティ強化」など、もっと“攻め”の提案をしていきたいと思います！ ちなみに、ランサムウェア対応サービスって？AI活用の技術ってどんなもの？と思った方はこちらの記事も↓ ランサムウェア攻撃に備える！最後の砦といえるバックアップ ランサムウェア対策の最後の砦であるバックアップの重要性とポイントについて解説します。USiZEの新オプションサービス「ランサムウェア対応サービス」についてもご紹介します。 blog.usize-tech.com 2024.07.02 Rubrikのランサムウェア対策：仕組みとシミュレーションで確認 「Rubrikのランサムウェア対策」を徹底解説！ふるまい検知や脅威ハンティングの仕組みと、実際にシミュレーションを行った結果をご紹介。 blog.usize-tech.com 2025.01.28   まとめ：クラウド選びの“使える”ヒント 今回のイベントを通じて、 クラウド・仮想化基盤選びで考えるべきポイント を改めて整理してみました。 移行容易性 ：今のシステム・アプリケーションは、特に大きな変更せずにスムーズに移行できる？ 運用・サポート ：移行後の運用負荷はどうなる？技術面やサポート体制は十分？ 拡張性・柔軟性 ：パブリッククラウドとのハイブリッド化や、クラウドネイティブ化へのステップアップは可能？ セキュリティ ：ランサムウェアなどのサイバー攻撃が増える中、AI活用も含めて、必要なセキュリティ対策や機能は備わってる？ 例えば、「今のシステムってそのまま移行できる？」「移行後の運用はどう？逆に負荷が増えたりしない？」 「今後AI活用も考えたいし、パブリッククラウドも使いたい。でも重要データや機微な情報は国内でデータ主権も確保したい…」 ――そんな視点で自社の状況や課題を整理しながら、最適なクラウド・仮想化基盤を選ぶことが大切だと改めて感じました。 クラウドの選択肢は広がっていますが、それぞれの企業やシステムの状況に合ったポイントをしっかり見極めて選んでいきたいですね。

こんにちは。New Relic技術担当の井上です。 この記事では実際にNew Relicを使う前の導入ステップとして、New Relicアカウントの基本構造について解説していきます。アカウントを管理していく上で、必要となる前提知識のため、ユーザ作成する前に知識を深める一助になれば幸いです。 はじめに New Relicでアカウントを作成する前に、運用目的・組織構成・セキュリティなど、複数の観点から整理することが必要です。やみくもにアカウントを作成した後、運用を変更したいと思ってもなかなか難しいと思います。まずは、New Relicのアカウントの構造を確認後、それぞれどのように使い分けしたらよいかを解説していきます。   アカウントの全体像 New Relicのアカウントを設定する上で3つの要素があります。APIキーについては別の記事にて解説します。 項目 説明 組織(Organization) New Relic の顧客単位。1契約につき1つの組織が払い出される。 アカウント(Account) 環境ごとにアクセスを分離、プロジェクトごとにデータを分けたいなど、組織に属するデータの集まりを管理する単位。1組織に複数アカウントを持つことが可能。アカウントは7桁の数字を指します。 ユーザー(User) New Relicコンソールを操作する人。ロールとユーザータイプを組み合わせて、柔軟に権限のコントロールが可能。ユーザーは1つ以上のグループに所属する必要があります。   アカウントとユーザーの意味が混乱しそうですが、アカウントはシステムの箱、ユーザーは使う人と置き換えてとらえることが良いかもしれませんね。 参考： 組織とアカウント構造 | New Relic Documentation           アカウント設定のベストプラクティス | New Relic Documentation   組織(Organization) New Relicに初回サインアップした後に、自動的に作成 されます。組織単位の中で、アカウントの作成やユーザーの作成を行うことになります。New Relicに対する契約を分割したい場合、別のOrganizationを作成する必要があります。   アカウント(Account) New Relicに初回サインアップと同時にデフォルトで1つ作成 されます。環境やプロジェクトに応じて、複数アカウントを作成することができますが、運用の複雑化や共有の制限も伴うため、構成は目的に応じて選ぶ必要があります。ただし、無料枠での利用の場合は、デフォルトで作成された1つのアカウントのみ利用可能です。下の表はアカウントを分けることのメリット・デメリットをまとめた一例になります。 項目 メリット デメリット データ分離 環境（本番・開発）ごとにデータを明確に分離できる 統合的な可視化が難しくなる（ダッシュボードやトレースの横断が不可） アクセス制御 役割ごとにアカウント単位で権限を細かく設定できる ユーザー管理が複雑化（グループ・ロール・アカウントアクセスの調整が必要） セキュリティ アカウント単位でアクセス制限をかけることで、情報漏洩リスクを軽減できる アラートやダッシュボードなどの共有ができず、再設定が必要になる 契約管理 データ量の管理をアカウント単位で把握しやすくなる 実際の契約は組織単位なので、有償ユーザー数やデータ量の合算管理が必要   ユーザー(User) New Relicのコンソールの操作には、ロールとユーザータイプの2つがそろって初めて操作することができます 。ここの設定を誤ると予期しない操作ができてしまったり、課金に関わる部分もあるため、注意が必要です。それぞれ解説していきます。   ロール ロールは、操作権限 を意味します。ダッシュボードを作成できる、アラートを設定できる、ユーザーを管理できるなどを決める操作権限を指し、グループに割り当てをします。初期設定で用意されているロールは以下になります。 ロール名 説明 All Product Admin 組織全体の設定、ユーザー管理、請求情報など、すべての管理機能にアクセス可能。 Standard User データの閲覧・ダッシュボードの作成・アラート設定などが可能。ただし、ユーザー管理や請求情報にはアクセス不可。 Read Only データの閲覧のみ可能。設定変更やアラート作成などは不可。 Billing Manager 請求情報の閲覧・管理が可能。その他の機能にはアクセス不可。   ユーザータイプ ユーザータイプは、機能アクセスできる範囲 を制御します。APMやInfrastructureなどのNew Relicの機能そのものを決めるアクセス権限でユーザーごとに割り当てをします。New Relicはユーザー数課金とデータ従量課金で構成されています。 ユーザー数課金対象のユーザータイプはCoreとFull Platformユーザーの数 となります。 ユーザータイプ 権限の概要 有償アカウント Basic マネジメント層向け オペレータ (アラートとログの確認のみの運用者) ダッシュボードの閲覧、アラートの確認、ログの確認 ー Core 調査・修正だけを業務とする開発者 Basicの機能に加え、Errors Inbox（エラー集約）、ログ管理UI ※機能が限定的のため、利用非推奨 〇 Full Platform サービス品質に責任のある開発者・運用者 (SRE/Ops) 全機能にアクセス可能 〇 Adminロールを持っていても、Basicユーザーであれば、APMなどの機能にアクセスできません。逆にFull Platform Userであっても、Read Onlyロールしか持っていなければ、Read Onlyロールでアクセス許可されている画面しか閲覧できません。 参考： ユーザータイプ：ベーシックユーザー、コアユーザー、フルプラットフォーム ユーザー | New Relic Documentation   グループ設定 ロールはグループに割り当てる必要 があります。直接ロールをユーザーに割り当てることはできません。ユーザーは、1つ以上のグループに所属することで、グループに割り当てられたロール（権限）とユーザータイプを通じて、New Relicの機能にアクセスできます。 ユーザーが複数のグループに所属している場合、各グループに割り当てられたロールの権限がすべて合算 されます。アカウントの管理の観点から、1つのグループに1つのロールが望ましいと考えます。 参考： 重要なユーザー管理の概念 | New Relic Documentation   サードパーティ製品と連携する場合のアカウントの考え方 サードパーティ製品との連携(例：AWSやAzure、PagerDuty等)には、 専用のユーザーを作成 することが推奨されています。必要な権限のみを割り当てることでセキュリティリスクを低減させます。 サードパーティ製品との連携には、APIキーと呼ばれる鍵が必要です。この APIキーは、発行したユーザーのアカウント権限を継承 します。例えば、管理者権限を持つユーザーがAPIキーを発行した場合、そのキーは設定変更やユーザー追加など、管理者レベルの操作が可能になります。そのため、サードパーティ製品との連携に使用するAPIキーは、 必要最小限の権限を持つ専用のユーザーから発行 することが望ましいとされています。クラウドサービスなどからメトリクス取得のみであれば読み取り専用のみを持つユーザー、アラートを外部連携(PagerDuty,Servicenow等)であれば、書き取り権限を持つユーザーから作成する使い分けが必要になります。 参考： インテグレーション ユーザー向けのベストプラクティス | New Relic Documentation   アカウント設計を考える ここまでで、New Relicのアカウント構造について解説していきました。では、実際にアカウント設計をしていく上で、「組織」、「アカウント」、「ユーザー」の観点でどのように設計を進めたらよいかをまとめてみました。下記がすべてではないので、例として記載しています。 観点 考慮要素 作成する(分ける)かどうかの検討ポイント 組織 組織構造 部門や担当ごとの分離が必要か？ 請求管理 アカウントごとに請求を分けたいか？ アカウント 環境分離 開発・ステージング・本番など、運用・デプロイのために環境を分ける必要があるか？ プロジェクト分離 サービスやアプリなど、全くかかわらない異なるチーム・目的で運用されるか？ アラート制限 数千件のアラート設定が必要か？(アカウントごとに上限があるため) ユーザ ー 権限管理 管理者・運用担当者・開発者などの役割分担が必要か(グループ・カスタムロール作成要否) インテグレーション AWSやSlack、PagerDutyなどとの連携に使うか？ アクセス範囲 最小権限の原則に則り、アクセスさせるか？(カスタムロールの作成要否)   参考： アカウント設定のベストプラクティス | New Relic Documentation   さいごに New Relicのアカウント構成や、コンソールにアクセスする際に必要となる権限について、概要を解説しました。アカウント構成は、組織の運用形態や監視対象の規模に応じて設計することが重要です。また、ユーザー権限の設計においては、最小権限の原則を意識することで、不要な操作や情報漏洩のリスクを低減できます。この記事が、New Relicの安全かつ効率的な運用に少しでもお役立ていただければ幸いです。 SCSKはNew Relicのライセンス販売だけではなく、導入から導入後のサポートまで伴走的に導入支援を実施しています。くわしくは以下をご参照のほどよろしくお願いいたします。