SCSKクラウドソリューション の技術ブログ
全1141件
初めまして。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のライセンス販売だけではなく、導入から導入後のサポートまで伴走的に導入支援を実施しています。くわしくは以下をご参照のほどよろしくお願いいたします。
2025年10月9日から10日の2日間、ラトビアの首都リガで開催されたZabbix Summit 2025に初参加してきました。今年はZabbix SIAが設立されて記念すべき20周年。そんな節目の年に、世界中から集まった監視のプロフェッショナルたちと交流し、Zabbixの最新動向を学ぶ貴重な機会を得ることができました。 SCSKとしては、シルバースポンサーとして協賛を行い、 本記事では、2日間にわたるカンファレンスで得た知見や印象に残ったセッションについて、レポートします。 Zabbix Summitとは Zabbix Summitは、オープンソース監視ソリューション「Zabbix」の年次カンファレンスです。Zabbixの開発元であるZabbix SIAが主催し、開発者、システム管理者、ネットワークエンジニアなど、世界中から監視に携わるプロフェッショナルが集結します。 今年の開催概要 開催地 : Radisson Blu Hotel Latvija, リガ、ラトビア 期間 : 2025年10月9日〜10日（2日間） トラック : 複数のステージで同時進行のセッション、ワークショップ 会場となったRadisson Blu Hotel Latviaは、リガの中心部に位置するホテルで、広々としたカンファレンスルームとラウンジスペースが印象的でした。 今年は20周年記念ということもあり、会場には歴代バージョンの変遷を示す展示や、コミュニティの成長を示すインフォグラフィックスが飾られ、20年の歴史の重みを感じさせる雰囲気でした。 セッション/ワークショップ 会場ではいろいろなセッションが開催されるのですが、その中のごく一部を紹介します。 当日のセッションは、 こちら より確認ください。当日の動画や資料が公開されています。 （１） Zabbix 8.0: A New Chapter in Monitoring カンファレンス初日の基調講演は、Zabbix創設者でありCEOのAlexei Vladishev氏による発表でした。 これまでのZabbixの歩み、先日リリースされた Zabbix Academy そして、 2026年1Qリリース予定 のZabbix8.0の話がありました。 Zabbix 8.0では、CEP（Complex Event Processing)/APM&OpenTelemetry+AIを活用して、例えば1つの処理の フローの中でどの処理がボトルネックになっているのか、ヴィジュアル的にわかるようになるようです。 また、モバイルアプリ対応として、複数のZabbixサーバ/ZabbixCloudを統合して閲覧できる機能もリリース予定とのこと。 その他にもいろいろと話がありました、詳細は こちら を確認ください。 （２）Develop Your Own Widget Zabbix Summitでは、メインセッション以外にDev Trackという開発者向けのセッションも同時進行で開催されており、 その中で、ウィジェットの開発に関するセッションに参加してきました。 ウィジェットを作成する際の 構造 についての基本的な説明や登壇者のAndrejs Verza氏の Github で公開されている ウィジェットを使って実際にコードを書いて作ってみるハンズオンを実施しました。 （３）Troubleshooting Zabbix Perfomance and Configuration Issues with Diaginfo こちらはメインセッションとは別のワークショップで開催された内容になります。 こちらもハンズオンのセッションで、実際のデモ環境を使用して、Zabbixサーバに 負荷をかけ、実際にどの処理がその負荷の原因（どのLLD処理、HistoryCacheなど）となっているのかを DiagInfo を利用して調査する方法を学びました。 環境によって、以下のコマンドを実行し、ステータスを確認するという感じです。 zabbix_server -R diaginfo=historycache zabbix_server -R diaginfo=preprocessing 登壇 Zabbix×AI Agentについて話をさせていただきました。 AI Agentを利用して、運用効率できないかという視点で、監視情報の登録や障害検知した際の 障害の原因/対策の支援などをAIを活用できるかという内容で発表しました。 結論は記載しませんが詳細は こちら をご覧ください。 今回は、初のZabbixSummit参加で、初の英語でのプレゼンということで、不安も多かったですが、 終わってから参加者からのフィードバックなど多くのことを得たと思ってます。 最後 今回、ZabbixSummitに初めて参加しましたが、Zabbixの活用例、次のZabbixに実装される機能についての情報や カスタマイズ方法をハンズオンで学べるとても魅力的なイベントでした。 場所は遠いですが、来年も参加できればと考えています。 参考 弊社では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
こんにちは。SCSKの新沼です。 先日、2日間にわたって開催されたZabbixの一大イベント「Zabbix Conference Japan 2025」に参加してまいりました！ SCSKはプラチナスポンサーとして本カンファレンスに参加し、僭越ながら私も登壇の機会をいただきました。 本記事では、会場の雰囲気やZabbixの未来を感じさせるセッションの様子、そして私自身の登壇について、レポートをお届けします。 Zabbixコミュニティの熱気に包まれた2日間 会場には、Zabbixを愛用するユーザーや開発者、私たちのようなパートナー企業のエンジニアが全国から集結し、まさに熱気に満ち溢れていました。 オープニングでは、ラトビアから来日されたZabbix社CEOのアレクセイ・ウラディシェフ氏が登壇。Zabbixのこれからの展望や、次期LTS（長期サポート）バージョンとなる 「Zabbix 8.0」 についての発表があり、多くのユーザーの関心が一段と高まっていく様子が伝わってまいりました。Zabbixがこれからも進化し続けていくという力強いメッセージに、とても感銘を受けました。 各パートナー企業によるセッションでは、多種多様な環境でのZabbix活用事例や、より便利に使うためのノウハウなどが惜しみなく共有され、私自身も「そんな使い方があったのか！」と、発見の多い二日間でした。 SCSK登壇：『AIエージェントが変えるZabbix運用の未来』 そして、カンファレンス2日目の11時25分から、SCSKのセッションとして私が登壇させていただきました。 多くのパートナー企業が参加する中、プラチナスポンサーとして30分という貴重な発表の機会をいただき、大変光栄に思います。 私の発表タイトルは 「AIエージェントが変えるZabbix運用の未来」 。 AI技術をZabbixの運用に組み込むことで、障害検知や原因分析がどのように進化していくのか、その未来像についてお話しさせていただきました。 私自身、このような大舞台に立つのは初めてで、当日はかなり緊張しましたが、ご清聴くださった皆様の温かい眼差しのおかげで、無事に発表を終えることができました。登壇後には、多くの方々が声をかけてくださり、関心を寄せていただいたことに心より感謝申し上げます。 特に注目を集めた「オブザーバビリティ」への進化 今回のカンファレンスで、特に大きなテーマとして語られていたのが「オブザーバビリティ（可観測性）」です。 Zabbix Japan代表の寺島氏によるセッションでは、今後のZabbixが目指す方向性として、このオブザーバビリティの重要性が強調されていました。 これまでの「監視」が、システムに”何が起きているか”を検知すること（ Monitoring ）だとしたら、「オブザーバビリティ」は、”なぜそれが起きたのか”をシステム内部の様々なデータを元に深掘りし、分析すること（ Observability ）を指します。 特に、クラウドネイティブな環境で標準となりつつある「OpenTelemetry」との連携強化は、Zabbixがオブザーバビリティツールへと進化していく上で欠かせない要素です。この連携が深まることで、これまで捉えることが難しかったアプリケーション内部のトランザクションまでZabbixで追跡できる、そんな未来がすぐそこまで来ているのだと、大きな期待を感じました。 ※最新技術に関する詳細な言及は控えますが、Zabbixがシステムの安定稼働を支えるプラットフォームとして、新たなステージに進もうとしていることは間違いありません。 交流の輪が広がった懇親会 カンファレンス終了後には懇親会が開かれ、登壇者の方々やZabbix開発者、他のパートナー企業のエンジニアの皆様と直接お話しする機会をいただきました。 セッション中には聞けなかった裏話や、より踏み込んだ技術的なディスカッションをすることができ、非常に刺激的な時間でした。Zabbixという共通のテーマで、これだけ多くの方と繋がれるのは、カンファレンスならではの醍醐味ですね。 まとめ 今回、Zabbix Conference Japan 2025に参加し、登壇まで経験させていただいたことは、私にとって非常に大きな経験となりました。 SCSKとしても、このカンファレンスで得た最新の知見やお客様のニーズを活かし、より一層価値のあるZabbixソリューションを提供してまいります。 また私自身も、今回の貴重な経験を通して、技術者としてさらに成長していけるよう日々精進してまいります！ 最後になりましたが、本カンファレンスを主催・運営してくださったZabbix社の皆様、ご来場いただいた皆様、そして私たちの発表に足を運んでくださった皆様に、心より感謝申し上げます。 ありがとうございました！ 弊社では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
こんにちは。SCSKの星です。 最近XanaduバージョンからZurichバージョンへのバージョンアップを行いました。 その際に行った修正について記録しておきます。 はじめに 今回私が担当したバージョンアップは、バージョンアップによる修正点をすべて受け入れるのではなく、現在の運用が維持できるように修正したり、ユーザが混乱しそうな機能は非表示にしたりという対応が求められました。 またYokohamaバージョンからMFA認証が必須化されましたが、こちらの機能も今まで通り必要としない設定にすることが求められました。 これらを満たすように行った修正とその修正方法について書いていきます。 公式ドキュメントなどを参考に慎重に対応しておりますが、あくまで「こうしたらできた」というものになります。他の手法でも対応可能かもしれませんし、ベストプラクティスではない可能性もあります。ご了承ください。 修正 修正①：サービスポータルのパフォーマンスアナライザーアイコンの非表示 パフォーマンスアナライザーに関するアイコンが表示されるようになっておりました。 こちら全ユーザが使うことを想定しておりませんので、こちらのアイコンを非表示にします。 【方法】 システムプロパティ（sys_properties）のsp_allow_perf_debug_option_for_portalsを開き、Value(値)にある「sp」を削除する。 修正②：サービスポータルや管理者画面のMFAに関するメッセージの非表示 こちらはMFAを設定していない場合に表示されます。今回はMFAを設定しない＆ユーザにも毎回表示されるので非表示対応します。 【方法】 システムプロパティ（sys_properties）のglide.authenticate.multifactor.enforcement.show_user_info_messageを開き、Value(値)をfalseに変更する。 修正③：サービスポータルのMFAに関するセキュリティメッセージの非表示（adminのみ表示） こちらはadminロールを持つユーザがログインした場合に表示されます。adminのみに表示されるため、必須対応ではありませんが、今回は非表示としました。 【方法】 システムプロパティ（sys_properties）のglide.authenticate.multifactor.enforcement.acknowledgedを開き、Value(値)をtrueに変更する。 修正④：サービスポータルのプロフィール内の「マルチファクター認証を構成します。」というリンクの非表示 MFA設定に使用するリンクです。MFAを設定する場合は表示しておくべきですが、今回はMFAは避けるので非表示対応とします。 【方法】 Service Portal > ウィジェット からユーザー設定[user-preferences]ウィジェットを開き、本文HTMLテンプレートから以下行をコメントアウトして更新。 ※コメントアウト方法はHTMLなので <!– –>で囲みます。 </div> <div class="list-group-item" ng-if="data.preferencesEnabled.mfaEnabled"> <button class="btn btn-link" ng-click="triggerMFAConfigurationModal()" aria-haspopup="dialog">${Configure Multi-Factor Authentication}</button> </div> 修正⑤：管理者画面のMFAに関するバナーメッセージの非表示（adminのみ表示） 管理者画面でadmin権限を持っている場合にMFAに関するバナーが表示されます。 こちらもadminだけの表示のため非表示は必須ではなかったですが、非表示対応としました。 【方法】 バナーのアナウンスメントテーブル（sys_ux_banner_announcement）の「セキュリティ更新：MFA 実装」の終了フィールドを過去の日時にする。 こちら更新セットに記録されなかったのでレコードの個別エクスポートでリリース。 修正⑥：フォームの上部にあるディスカッションボタンの非表示 こちらはZurichバージョンより前から実装されてました。（Vancouverバージョンの時点で既に存在していた記憶があります。）便利な機能ですが運用側で「ない方が混乱しなくてありがたい」とのことで非表示にしてます。元々非表示にしていましたが、Zurichバージョンへのアップデートで再度表示されるようになったため、再度非表示対応を行いました。 【方法】 アプリケーションスコープをOmni-Experience Standard Feature Setに変更。対話型インターフェース（Conversational Interfaces） > 設定を開き、Sidebarの「アクティブ化」トグルをOFFにする。 修正⑦：全ユーザをMFA認証の対象外とする MFA認証を有効にした方がセキュリティ上安全なのは間違いないですが、社内の規約や運用の対応が追い付かず、一時的に全ユーザをMFA認証の対象外にしたい場合の方法です。 全ユーザを「MFA Exempted User Group」グループに追加 特別なことは何もありません。全ユーザを「MFA Exempted User Group」グループに追加しただけです。 【方法】 グループテーブル（sys_user_group）から「MFA Exempted User Group」を開き、グループメンバータブから『編集…』を押下し、全員を所属させます。ユーザが多い場合は一度に全員を所属させることができないため、何回かに分けて実施します。 ユーザ作成時に「MFA Exempted User Group」グループに自動追加するフローを作成 今後ユーザを作成する度に手動で「MFA Exempted User Group」グループに所属させるのは手間なのでフローを作ってしまいました。トリガーと１つのアクションだけの簡単フローです。 【方法】 ●トリガー ●アクション ※待機アクション入れていますが、レコード作成が完了する前に最初のアクションが開始され、データが引用できずエラーが発生する場合があるため、念のため待機アクションを入れています。状況によっては不要ですが、念のためです。 「MFA Exempted User Group」グループをadminロール以外は見られないようなACLを作成 環境によっては全く必要ない設定だと思いますが、本環境の運用ではロールのないユーザもサービスカタログからグループテーブルを参照することがあるので、見られないようにしています。 【方法】 security_adminに昇格し、下記の図のようなACLを作成。 他はConditional Script Writerグループの対応もしたのですがそれは下記の記事をご覧ください。 https://blog.usize-tech.com/servicenow-conditional-script-writer-zurich/ 残りは環境依存が強すぎて参考にならないため、以上となります。 バージョンアップする度に学びがありますね。
AWS Certificate Manager（ACM）で証明書管理をしていた経験から、 Azureにおける証明書発行やドメイン検証 の仕組みに興味を持ちました。特に DNSレコードの種類 や 検証方法 に違いがあり、クラウド間の設計の差が垣間見えて興味深いポイントです。 今回は、Azureの App Service 証明書 を使って証明書を発行し、ドメインに適用するまでをやってみました。 事前作業に作成しておくリソース ・KeyVault 証明書からKeyVaultへの操作を可能にするため、アクセス許可モデルは 「コンテナーのアクセスポリシー」 を設定。 ・DNSゾーン testtomi.com 証明書を実際に発行してみる 証明書作成 まずApp Service証明書を作成していきます。 Azureポータルから「App Service 証明書」で検索 ネイキッドドメインのホスト名は、 DNSゾーンで作成したドメイン を指定します。 証明書名はリソース名のため、ホスト名と 合わせる必要はありません 。 証明書が作成され、状態は 発行の保留中 であることが確認できます。 証明書発行 発行のため、証明書の構成を行います。 左ペイン 設定>証明書 の構成 を選択し、 手順1：格納 をクリックします。 キーコンテナーから選ぶで事前に作成していたKeyVaultを選択してください。 証明書の構成タブに戻ると手順1：格納にチェックが付いてます。次に 手順2：確認 をクリックします。 ドメインの検証を選択すると、 ドメイン確認トークン がTXTレコードに自動で追加されます。 DNSゾーンにTXTレコードが追加された後、ドメインの検証の画面に戻って確認を押下します。 通知でドメイン確認トークンの作成が表示されたら成功です。 画面更新かけると、証明書はドメイン確認済みになります。 証明書の構成タブに戻ると手順2：確認、手順3：割り当てに対して 同時に チェックが付いてます。 ここまで完了するとApp Service 証明書が 発行済み になりました！ TXTレコードかCNAMEレコードか 気になったのが証明書のドメインをレコードセットに登録する際の種類です。 Azureだとドメインの検証の際に、TXTレコードが自動的に追加されました。 公式ドキュメントも参考にしてみます。 チュートリアル: Web アプリのカスタム Azure DNS レコードの作成 Azure DNS において Web アプリのカスタム DNS レコードを作成する方法について説明します。 カスタム ドメインを有効にするように A、TXT、CNAME レコードを構成します。 PowerShell、CLI、ポータルの手順が... learn.microsoft.com 対してAWSでACMを発行した時は、自動でCNAMEレコードに割り当てられました。 公式ドキュメントにも書いてありますし、 AWS Certificate Manager DNS 検証 - AWS Certificate Manager DNS レコードを使用して、ACM 証明書をリクエストしているドメインの所有権を検証します。 docs.aws.amazon.com 私が行った際もCNAMEレコードでした。 ACMのDNS検証が保留中なのは、NSレコードのせい【Certificate Manager, Route 53】 AWS Certificate Managerの証明書を発行する際に学んだことを記載。 NSレコードの理解が求められました。 blog.usize-tech.com 2025.10.17 AzureではTXTレコード、AWSではCNAMEレコードと、証明書検証のDNSレコード種類に差異がありました。 今回は理由まで調べきれませんでしたが、この差異の背景についてはさらに調査・勉強していきます。
こんにちは。SCSK星です。 Zurichバージョンを行う際にConditional Script Writerに振り回されたため、 今回はその時の学びと記録を書いていこうと思います。 Conditional Script Writerとは Conditional Script WriterはZurichバージョンから追加されたグループになります。 このグループは少なくともロールを一つ以上持っている人が自動的に所属し、Zurichバージョン時にロールを所持していた人は自動的にこのグループに追加されます。「Script Writer」と書いてある通り、スクリプトを書くためにロールを付与するためのグループとなります。そのため、全員が所属する必要はありません。 今回でわかったことのまとめ 先にわかったことを記載いたします。 ①HTMLタイプの入力欄もスクリプト扱いになるため、Conditional Script Writerグループは運用者も必要になる場合がある。 ②Conditional Script Writerグループはユーザに直接ロールを付与した場合は即時所属するが、他のグループに所属させることでロールを付与した場合は即時反映されない。 ③自動所属されるためにはシステムプロパティの「glide.security.scripting_role.auto_provisioning」の値がtrueになっている必要があるが、こちらはfalseにしてしまうと元に戻せないので検証目的で変更してはならない。 ④security_adminに昇格することでConditional Script Writerグループに関する「Scripting Governance Tool」というモジュールを参照することができる。 ⑤他のグループに所属させることでロールを付与した場合はsys_triggerテーブルにある「Update Users in Conditional Script Writer Group」ジョブが動くのを待つ必要がある。 これ以降は上記５点がどんな流れで分かったかを記載していきます。経緯も含めた備忘録のようなものなので、 ご興味あればご覧いただく程度でよいと思います。 わかった経緯 ①HTMLタイプの入力欄もスクリプト扱いになるため、Conditional Script Writerグループは運用者も必要に なる場合がある。 ServiceNowのバージョンアップを行う際は、開発環境を用いて動作確認を行い、必要に応じて修正を加える形式で行っておりました。この際に現在の運用が問題なく行えるように動作確認としてバージョンアップテストを行っています。 今回のZurichバージョンアップも同様にバージョンアップテスト・軽微な修正を行い、運用側へ動作確認を依頼しました。 しかし、運用担当から「問題管理に使用している項目が記入できなくなった」と報告を受けました。 それが以下のような項目です。ServiceNowでは「HTML」タイプの入力欄と名付けているようです。 ②Conditional Script Writerグループは ユーザに直接ロールを付与した場合は即時所属するが 、他のグループに所属させることでロールを付与した場合は即時反映されない。 なぜバックアップテスト時にこちらに気付けなかったかというと、バージョンテスト用のユーザを作成し動作確認していたのですが、このロールの付与の仕方が良くなかったからです。 テストユーザとして「運用者ロールを持つユーザ」を作ってこれらのユーザを使ってテストしていたのですが、この運用者ロールを持つユーザはグループに所属によるロール付与ではなく、ユーザに直接itilロールなどを付与していました。 この際に運用者ロールを持つユーザはConditional Script Writerグループに所属されていたのです。 よってテストユーザはConditional Script Writerグループに所属した状態でテストしたことになります。そのため、問題なく今まで通り運用が行えると判断したという経緯になります。 また、動作確認を行っている中で、Conditional Script Writerという新たなグループが追加されていることにも気づき、調査をしスクリプトを書くためのロールということで認識いたしました。 スクリプトを書くのは開発者のみの運用だったため、開発者のみがこのグループに所属していればよいと思い、 Zurichバージョン後に多数のユーザがConditional Script Writerグループに所属していましたが、 わざと開発者のみが所属するように設定しました。（運用担当らのユーザは所属を外してしまいました。） 運用担当からの不具合報告を受け、Conditional Script Writerを運用者にも付与する方向で修正・再検証を行いました。 その際にもう一つ課題が出てきました。それが「 他のグループに所属させることでロールを付与した場合はConditional Script Writerグループに自動所属されない 」というものです。 普段の運用ではグループに所属させることでロールを与えていたため、グループ所属でConditional Script Writerグループに自動所属されない（運用者に必要なロールが揃わない）のは非常にまずく、何とか解決できないかと調査をしました。 ③自動所属されるためにはシステムプロパティの「 glide.security.scripting_role.auto_provisioning 」の値がtrueになっている必要があるが、こちらは一度 falseにしてしまうと元に戻せないので検証目的で変更してはならない。 グループなどに自動所属させるためにはシステムプロパティの「glide.security.scripting_role.auto_provisioning」の値がtrueになっている必要があると調査の結果分かりました。しかし、この値は元々trueだったためここが原因ではなかったです。 また、この値は 一度falseにしてしまうとsecurity_adminでも戻せない ので絶対に触らないことをおススメします。 ④security_adminに昇格することでConditional Script Writerグループに関する「Scripting Governance Tool」というモジュールを参照することができる。 調査していく中でConditional Script Writerに関する「Scripting Governance Tool」モジュールがあることもわかりました。 発見した際は早速、インスタンスで見てみようと検索をかけましたが、出てこず。何かしらのPluginかとも思いましたがそういうわけでもなく。頭を抱えながら調査していたらsecurity_adminへの昇格が必要とのこと。（さりげなく書かれていて気づきませんでした…） 「Scripting Governance Tool」モジュールを表示すると以下のような画面に遷移します。 こちらの「自動アサイン」トグルがOFFなのが原因かと思って、アクティブにしようとしましたがONにできず。 結局原因はここではなかったので、これ以上の情報は持ち合わせていませんが、こちらのページもConditional Script Writerに関わるものなのでご参考になれば。 ⑤他のグループに所属させることでロールを付与した場合はsys_triggerテーブルにある「Update Users in Conditional Script Writer Group」ジョブが動くのを待つ必要がある。 「他のグループに所属させることでロールを付与した場合はConditional Script Writerグループに自動所属されない 」 という問題を解決したのは、sys_triggerテーブルにある「Update Users in Conditional Script Writer Group」ジョブでした。 こちらはデフォルトで月曜日の20時にConditional Script Writerグループに所属資格のあるユーザをそのグループに所属させるようなものでした。ですので実際は 「他のグループに所属させることでロールを付与した場合はConditional Script Writerグループに自動所属されない 」ではなく 「他のグループに所属させることでロールを付与した場合はUpdate Users in Conditional Script Writer Groupが起動するまで自動所属されない 」が正確なところでした。 運用上資格がある場合は即時、Conditional Script Writerグループに所属させてほしいのですがそのためにFlowやスクリプトを書くのも管理工数がかかりそうなので、とりあえずはこのスケジュールの頻度を上げて対応しました。 以上になります。 丁寧にやったつもりですが、バージョンアップは丁寧に慎重にやっていかないとダメですね。
SCSK 池田です。 2025年11月12日(日本時間)に、ついにLifeKeeper v10がリリースされました。 Linux版はv9がリリースされた2015年9月から10年ぶり、Windows版はv8.0.1がリリースされた2014年3月から11年半ぶりのメジャーバージョンアップとなります。 今回は、v10になりどのような点が変わったのかについて、ご紹介したいと思います。 ライセンス体系 Linux版とWindows版が統合 こちらの図が示すように、これまでLinux版とWindows版とは別のバージョンでリリースされており、同じLifeKeeperという名前であっても、製品仕様が異なるなどとても解り辛い状況にありました。しかしv10からはLinux版とWindows版が統合されます。これは単にバージョンが同じv10になるというだけでなく、OSによる仕様の違いは多少は残るものの、製品として設計思想ができるだけ共通化されるようになりました。 プロダクトライフサイクルもわかりやすく これによりプロダクトライフサイクル(サポートフェーズ)の考え方も変わります！ これまではLinux版(5年)とWindows版(2年)とで延長サポートの期間が異なるなど、OSごとに考え方が異なっていましたが、こちらも見直されフルサポート3年、メンテナンスサポート3年、延長サポート4年と統一されました。 OSごとに異なっていたものが、統一されて解りやすくなったわね ライセンスのラインナップがシンプルになりました さらに、以下の図にもありますように、これまでOracleやSQLserverなど製品ごとに別れていたApplication Recovery KitもRecovery Kit for Databaseという製品に統一されるなど、ライセンスのラインナップがシンプルになっています。 Web Management Consoleの標準搭載 これまでは、別途入手が必要となっていたWeb Management Consoleが標準搭載されます。Linux版とWindows版で共通の見た目と操作性を備え、OSの違いによる操作ミスの防止や運用手順の共通化の実現に寄与します。 Web Management Console画面イメージ サイオステクノロジー社の公式サイトより引用 サイオステクノロジー、新バージョン「LifeKeeper v10」を提供開始｜プレスリリース｜サイオステクノロジー株式会社 まとめ 約10年ぶりにメジャーバージョンアップを果たしたLifeKeeperですが、「 全てをシンプルに、より分かりやすく、より使いやすく 」をコンセプトに今回ご紹介した改変が行われました。これにより利用者は製品選択が容易となり、構築者は短期間での構築、運用者は運用管理の負担を軽減することができるようになります。細かいところでは、他にも変わった点がありますが、また別の機会にご紹介させていただこうと思います。 LifeKeeperについて、詳しい内容をお知りになりたいかたは、以下のバナーからSCSK LifeKeeper公式サイトまで
こんにちは！2年目の秋葉です！ 手動で予算を設定したり、コストを監視するのは意外と面倒ですよね…。 AWS Budgets を使えば、一定のコストや使用量を超えた際に自動で通知を送ることができますが、 これを手動でコンソールから設定するのはスケールしにくいですよね。 そこで今回は、AWS CDK（Cloud Development Kit） を使って AWS Budgets をコードで管理・デプロイ してみた手順を紹介します。 今回作成するリソース AWS Budgets アーキテクチャ概要 AWS CDK ソースコード 通知設定 //=========================================== // 通知先メーリングリスト //========================================== const emailAddresses = [ 'xxxxxx@scsk.jp', 'xxxxxxx@scsk.jp', ]; // subscribers配列への変換 const subscribers = emailAddresses.map(address => ({ subscriptionType: 'EMAIL', address: address, })); ポイント: 複数の管理者への通知配信 予算を超えた際に、通知するメールアドレスを指定 コスト予算の設定 // コスト予算の設定 const monthlyBudget = new budgets.CfnBudget(this, 'MonthlyBudget', { budget: { budgetType: 'COST', // 予算タイプ：コストベース timeUnit: 'MONTHLY', // 集計単位：月次 budgetLimit: { amount: 1000, // 予算上限：1000USD unit: 'USD' // 通貨単位：米ドル } }, ポイント: 集計単位: 月次 予算上限: 1,000 USD 予算アラートの設定 // 予算アラートの設定 notificationsWithSubscribers: [{ notification: { comparisonOperator: 'GREATER_THAN', // 比較演算子：超過 threshold: 80, // 通知閾値：予算の80% notificationType: 'ACTUAL', // 通知タイプ：実績値 thresholdType: 'PERCENTAGE' // 閾値タイプ：パーセンテージ }, subscribers:subscribers, }] ポイント： 予算上限額の80%を超えたら通知 今回実装したコンストラクトファイルまとめ import * as cdk from 'aws-cdk-lib'; import { Construct } from 'constructs'; import * as budgets from 'aws-cdk-lib/aws-budgets'; export interface CostAlarmConstructProps { // 必要に応じて追加のプロパティを定義 } export class CostAlarmConstruct extends Construct { constructor(scope: Construct, id: string, props?: CostAlarmConstructProps) { super(scope, id); //=========================================== // 通知先メーリングリスト //=========================================== const emailAddresses = [ 'xxxxxx@scsk.jp', 'xxxxxxx@scsk.jp', ]; // subscribers配列への変換 const subscribers = emailAddresses.map(address => ({ subscriptionType: 'EMAIL', address: address, })); //=========================================== // AWS Budgetsの作成 //=========================================== // コスト予算の設定 const monthlyBudget = new budgets.CfnBudget(this, 'MonthlyBudget', { budget: { budgetType: 'COST', // 予算タイプ：コストベース timeUnit: 'MONTHLY', // 集計単位：月次 budgetLimit: { amount: 1000, // 予算上限：1000USD unit: 'USD' // 通貨単位：米ドル } }, // 予算アラートの設定 notificationsWithSubscribers: [{ notification: { comparisonOperator: 'GREATER_THAN', // 比較演算子：超過 threshold: 80, // 通知閾値：予算の80% notificationType: 'ACTUAL', // 通知タイプ：実績値 thresholdType: 'PERCENTAGE' // 閾値タイプ：パーセンテージ }, subscribers:subscribers, }] }); } } まとめ 今回は、AWS CDK を使って AWS Budgets をコード化し、自動でデプロイする方法 を紹介しました。 Budgets を CDK に組み込むことで、手動設定の手間を減らしつつ、環境ごとのコスト監視を一貫して管理できるようになります。 どなたかの役に立ててたら幸いです！
管理者
