ＳＣＳＫ　LifeKeeper担当　池田です。 みなさんLifeKeeperと言えばどのようなことを思い浮かべますか？ 「HAクラスター」「可用性」などの声が想像できますが、ではこの「HAクラスター」や「可用性」の目的は何なのかについて、これまでとは少し違った視点でお話ししたいと思います。 LifeKeeperを導入する目的 LifeKeeperをシステムに導入する目的は各社いろいろあると思います。一般的なものとしては、 Activeサーバで障害が発生したとしても、Standbyサーバに切り替わることによって、システムが完全に停止してしまう時間を極小化し、 ビジネスの機会損失を最小限に抑えること が挙げられると思います。あるいはawsであれば、Availabilty Zone(AZ)レベルの障害が発生した場合に、別のAZでシステム稼働を継続できるという目的の場合もあると思います。 いずれにしても、障害が起きても業務を継続できることが、主目的になることがほとんどかと思います。 では少し視点を変えて、 システムを運用している、ユーザ企業の情報システム部のかた にとって、Lifekeeperが導入されることによるメリットがないか考えてみたいと思います。 情報システム部の方々が受ける恩恵 「LifeKeeperは保険のようなもの」と言われることがあります。事実、いつ発生するか判らない障害の為にお金をかけて、ともすると５年とも１０年とも言われるシステム稼働期間中に一度もフェイルオーバが発動しないこともあります。それゆえに「結果的に必要なかったよね」との判断から、次のサーバ更改では不要とされてしまうなんてこともありました。 しかし、冗長化していない１台のサーバで構成されたシステムで障害が発生した場合のことを想像してみてください。障害が発生した場合、サーバが復旧するまでの間、システムは停止し、業務や提供サービスがストップしてしまいます。 もちろん利用者が少ない、あるいは使用頻度が少ないなどの理由で復旧に時間をかけられるシステムでしたら、復旧を焦る必要はないのかもしれません。しかし、もし利用者が多く、使用頻度も高いシステムだったとしたら、夜間休日を問わず早期の復旧と原因究明もという相反する対応を求められることとなるでしょう。 この場合の情報システム部門の方々へのプレッシャーはとてつもなく大きなものになります。 一方、可用性が確保されたシステムの場合、障害が発生したとしても、一時的なシステム停止は生じるものの、 もう一台のサーバでシステム利用できることから、復旧最優先という呪縛からは開放され、落ち着いて原因究明と、冗長構成へ戻す対応に専念することができる のではないでしょうか。 もちろん冗長構成に戻るまでは、単一障害点となり、更なる障害が発生した場合はシステム停止に直結する為、のんびり対応して良い訳ではないことは言うまでもありません。 まとめ いかがでしたでしょうか？ これまでは、LifeKeeperを始めとする冗長構成システムを利用するかたのメリットが語られることは多かったと思いますが、運用する皆さまのメンタルに対しても導入するメリットがあることがお判りいただけたのではないでしょうか。 冗長構成にすることのメリット ・利用者・・・使いたい時に使える ・会社　・・・障害時の機会損失の極小化 ・運用者・・・障害時の原因究明に専念することができる   詳しい内容をお知りになりたいかたは、以下のバナーからSCSK LifeKeeper公式サイトまで

こんにちは、SCSKの齋藤です。 本記事では、TMetric というタイムトラッキングツールからデータを自動で抽出し、BigQueryにロードするまでのプロセスを、Cloud RunとPythonを活用して実装した事例を紹介します。日々の業務で利用するトラッキングツールのデータ分析に活用したい、自動化して効率的にデータ収集を行いたい、という方にとって参考にしていただける内容となっています。TMetric のデータを活用し、 プロジェクトの進捗状況の把握、メンバーの稼働状況の分析、リソース配分の最適化 などを実現したい方は必見です。   この記事でわかること Cloud Run の活用 : Cloud Run を利用して、データ抽出処理を自動化するメリットと実装方法 Python によるデータ処理 : データ抽出、CSV ファイルへの書き込み、GCS へのアップロード、BigQuery へのロードといった一連の処理を Python で行う方法 TMetric API の活用: TMetric API を利用して、普段業務で使用しているタイムトラッキングツールからデータを取得する方法 なぜCloud RunとPythonなのか？　-それぞれの強み 今回の実装で Cloud Run と Python を選んだ理由は、それぞれの持つ強みがデータ抽出処理に最適だったからです。 Cloud Run のメリット Cloud Run は、コンテナイメージをデプロイして実行できるサーバーレス実行環境です。以下のメリットがあります。 サーバーレス ：インフラの管理が不要で、コードの実行に集中できる。サーバーのプロビジョニングやスケーリング、メンテナンスといった運用作業からも解放されます。 自動スケーリング ：トラフィックの増減に応じて自動的にスケールするため、リソースを効率的に利用可能です。 従量課金 ：実際に利用したリソースに対してのみ課金されるため、コスト効率が高いです。 CI/CD連携 ：継続的インテグレーション/継続的デリバリーパイプラインとの連携が容易で、デプロイを自動化できます。 Pythonのメリット Pythonは、汎用性の高いプログラミング言語であり、データ処理やAPI連携に強みを持っています。 豊富なライブラリ ： requests (HTTPリクエスト)、 csv (csvファイル操作)、 google-cloud-storage  (GCS 操作)、 google-cloud-bigquery (BigQuery 操作) など、データ処理に必要なライブラリが豊富に揃っています。これらのライブラリを活用することで、複雑な処理も比較的簡単に実装できます。 柔軟性 ：データ抽出、変換、ロードなど、データパイプラインの様々な処理をPythonで柔軟に実装できます。 Cloud Run × Pythonの相乗効果 Cloud Run の持つサーバーレスの利点と、Python の持つデータ処理能力を組み合わせることで、スケーラブルでコスト効率の高いデータ抽出パイプラインを構築できます。Cloud Run がインフラの管理を担い、Python が複雑なデータ処理を担うことで、開発者はビジネスロジックに集中できます。 実装の概要　- Cloud Run と Python の連携 今回の実装では、以下のステップで TMetric のデータを BigQuery に自動的にロードします。Python スクリプトは Cloud Run 上で実行されます。 Cloud Run へのデプロイ:  Python スクリプトを Docker イメージとして Cloud Run にデプロイします。Dockerfile には Python のバージョン、必要なライブラリ、スクリプトの実行コマンドなどを記述します。 Python スクリプトの実行:  Cloud Run が Docker イメージを実行し、Python スクリプトが TMetric API からデータを抽出します。 データ変換:  抽出したデータを CSV 形式で一時ファイルに書き込みます。この際、タイムゾーンを JST に変換するなど、データ分析に適した形式に変換します。 GCS アップロード:  作成した CSV ファイルを Google Cloud Storage (GCS) にアップロードします。 google-cloud-storage  ライブラリを使用します。 BigQuery ロード:  GCS にアップロードされた CSV ファイルを BigQuery にロードします。 google-cloud-bigquery ライブラリを使用します。 自動実行:  Cloud Run にデプロイされた Python スクリプトを、Cloud Scheduler でスケジュール設定し、定期的に自動実行します。 実装のポイント TMetric API の活用とデータ構造の理解 TMetric API を利用する上で、以下の点に注意しました。 API エンドポイントの選定:  TMetric API には、様々なエンドポイントが存在します。今回は、時間エントリーデータを取得するために、 /accounts/{accountId}/timeentries  エンドポイントを使用しました。 認証:  TMetric API へのアクセスには、認証トークンが必要です。環境変数を使用してセキュアにトークンを管理し、 Authorization  ヘッダーに含めてリクエストを送信します。 パラメータの設定:  TMetric API には、様々なパラメータを設定できます。今回は、 startDate 、 endDate 、 userId  パラメータを使用して、特定の期間とユーザーの時間エントリーデータを取得しました。 データ構造の理解:  TMetric API から返される JSON データは、ネストされた構造を持っています。必要な情報を抽出するために、データの構造を理解し、適切なキーを指定する必要があります。時間エントリーデータには、 startTime 、 endTime 、 task 、 user  などの情報が含まれています。 TMetric API レスポンス例 [ { "id": 12345, "startTime": "2023-10-26T09:00:00Z", "endTime": "2023-10-26T17:00:00Z", "task": { "id": 67890, "name": "開発タスク", "externalLink": { "caption": "JIRA-123", "link": "https://example.com/browse/JIRA-123" } }, "user": { "id": 11223, "name": "tarou" } }, ... ] Python コード – TMetric API からのデータ抽出例 import requests import json from datetime import datetime, timezone, timedelta from pydantic_settings import BaseSettings class Settings(BaseSettings): TMetric_WORKSPACE_ID: str TMetric_TOKEN: str class Config: env_prefix = "" settings = Settings() def fetch_tmetric_data(user_id, start_date, end_date): url = f"https://app.tmetric.com/api/v3/accounts/{settings.TMetric_WORKSPACE_ID}/timeentries" headers = {"Authorization": f"Bearer {settings.TMetric_TOKEN}"} params = {"startDate": start_date, "endDate": end_date, "userId": user_id} try: response = requests.get(url, headers=headers, params=params) response.raise_for_status() return response.json() except requests.exceptions.RequestException as e: print(f"API request failed: {e}") return None # Example usage # TMetric_WORKSPACE_ID, TMetric_TOKEN を設定する settings = Settings() user_id = 123 # Replace with the actual user ID start_date = "2025-01-01" end_date = "2025-01-31" data = fetch_tmetric_data(user_id, start_date, end_date) if data: print(json.dumps(data, indent=2)) # Print the formatted JSON data else: print("Failed to retrieve data.")    環境変数の設定 TMetric API のトークンなどの機密情報は、環境変数として Cloud Run に設定します。Google Cloud Secret Manager と連携することで、よりセキュアに管理できます。Cloud Run の設定画面から、環境変数を設定します。 サービスアカウントの設定 Cloud Run のサービスアカウントに、GCS への書き込み権限、BigQuery への書き込み権限を付与します。最小限の権限を与えることで、セキュリティリスクを低減します。IAM & 管理画面から、サービスアカウントの権限を設定します。 Python コード – ライブラリ活用 Python コードでは、必要なライブラリをインポートし、それぞれの機能を活用します。 import csv from datetime import datetime, timedelta, timezone import requests from google.cloud import bigquery, storage # ... (省略) 例えば、GCS にファイルをアップロードするには、以下のコードを使用します。 from google.cloud import storage def upload_to_gcs(bucket_name, source_file_name, destination_blob_name): """GCSにファイルをアップロードする関数""" try: storage_client = storage.Client() bucket = storage_client.bucket(bucket_name) blob = bucket.blob(destination_blob_name) blob.upload_from_filename(source_file_name) print(f"File {source_file_name} uploaded to gs://{bucket_name}/{destination_blob_name}") except Exception as e: print(f"GCSへのアップロード中にエラーが発生しました: {e}") BigQuery にデータをロードするには、以下のコードを使用します。 from google.cloud import bigquery def load_csv_to_bigquery(bucket_name, blob_name, dataset_id, table_id, project_id, start_date, end_date): """GCS上のCSVファイルをBigQueryにロード""" try: # BigQueryクライアントの初期化 client = bigquery.Client(project=project_id) dataset_ref = client.dataset(dataset_id, project=project_id) table_ref = dataset_ref.table(table_id) # BigQueryジョブの設定 job_config = bigquery.LoadJobConfig( skip_leading_rows=1, source_format=bigquery.SourceFormat.CSV, field_delimiter="\t", write_disposition=bigquery.WriteDisposition.WRITE_APPEND, ) # GCS URI gcs_uri = f"gs://{bucket_name}/{blob_name}" # ロードジョブの開始 load_job = client.load_table_from_uri(gcs_uri, table_ref, job_config=job_config) load_job.result() # ジョブの完了を待機 print(f"GCS上のファイル {gcs_uri} を BigQuery の {dataset_id}.{table_id} にロードしました。") except Exception as e: print(f"BigQueryへのロード中にエラーが発生しました: {e}") Cloud Schedulerの設定 Cloud Run にデプロイした Python スクリプトを自動的に実行するため、Cloud Scheduler を設定します。 Cloud Scheduler は、指定したスケジュールに基づいて HTTP リクエストを送信し、Cloud Run Job をトリガーします。 Cloud Scheduler の設定手順 Cloud Run Job のエンドポイントの確認 Cloud Run にデプロイした Job の詳細画面から、トリガーに使用する URL を確認します。この URL は、Cloud Scheduler から HTTP リクエストを送信する先となります。 (例: https://asia-northeast1-run.googleapis.com/apis/run.googleapis.com/v1/namespaces/[プロジェクトID]/jobs/[ジョブ名]:run) サービスアカウントの作成 Cloud Scheduler が Cloud Run Job を実行するための権限を持つサービスアカウントを作成します。サービスアカウントに、Cloud Run 起動元のロールを付与します。これにより、サービスアカウントは Cloud Run Job を起動できるようになります。 Cloud Scheduler 設定例 gcloud scheduler jobs create http tmetric-data-schedule \ --schedule="0 23 * * *" \ --time-zone="Asia/Tokyo" \ --location="asia-northeast1" \ --uri="https://asia-northeast1-run.googleapis.com/apis/run.googleapis.com/v1/namespaces/[プロジェクトID]/jobs/tmetric-data:run" \ --oauth-service-account-email="[サービスアカウント名]@[プロジェクトID].iam.gserviceaccount.com" \ --description="TMetric データ抽出スケジュール" \ --project="[プロジェクトID]" よりセキュアな環境を構築するためには、Cloud Run Job に Identity-Aware Proxy (IAP) を設定し、Cloud Scheduler からのアクセスのみを許可することも可能です。 Cloud Logging を活用することで、ジョブの実行履歴やエラーログを詳細に確認できます。 Cloud Monitoring と連携することで、ジョブの実行状況を監視し、異常発生時にアラートを送信できます。 工夫 -自動化と運用の効率化 設定ファイルの利用:  環境変数だけでなく、設定ファイル（YAML など）を利用することで、より複雑な設定を管理しやすくしました。 ログ出力の強化: 詳細なログの出力による、問題発生時の原因特定容易化。Cloud Loggingとの連携によるログの一元管理。 テストの自動化: 単体テストや結合テストの自動化による、コード品質の向上。 エラー通知: エラー発生時にSlackなどのチャットツールに通知を送信する設定による、迅速な対応が可能に。 Cloud Schedulerの利用: Cloud Run Jobsでのスケジュール実行を目的とした、Cloud Schedulerによるhttpsリクエストの送信。 まとめ Cloud Run と Python を組み合わせることで、 TMetric のデータを自動的に抽出し、BigQuery にロードする パイプラインを構築することができました。Cloud Run のサーバーレス環境がインフラ管理の負担を軽減し、Python の豊富なライブラリがデータ処理を容易にしました。この自動化によって、手作業によるデータ収集の手間を省き、より効率的にデータ分析を行うことができます。 今回の実装で得られた知見は、他のトラッキングツールや API からのデータ抽出にも応用できます。ぜひ、Cloud Run と Python を活用してみてください。

こんににちは。SCSKの大野です。 IT業界の熱気が最高潮に達するイベント、 Google Cloud Next Tokyo 開催まで1週間を切りました！ 今年のSCSKの出展内容は以前発信した記事に掲載していますので、ご確認ください。 Google Cloud Next Tokyo へ出展のお知らせ – TechHarmony 最新技術、刺激的なセッション、そしてネットワーキング…楽しみは尽きません。しかし、忘れてはならないのが8月の日本の気候。 そう、 灼熱の暑さ です。 基調講演を待つ長い列、熱気あふれる会場内の移動、ちょっと一息つきたい屋外スペース…想像するだけで汗が噴き出してきませんか？ 「もうダメだ…集中力が…」「暑さで頭が回らない…」 そんな未来のあなたを救うため、我々SCSKが一肌も二肌も脱ぎました。 今年のGoogleイベント、SCSKブースで皆様にお届けするのは、単なるノベルティではございません。 あなたのイベント体験を、灼熱地獄から快適なフロンティアへと変える 最終兵器 です。 これぞ真髄！脳天直撃の”ドン冷え”体験「瞬間冷却パック」 数あるアメニティの中でも、我々がマニアックなまでにこだわり、身体を張ってオススメしたいのが、この **「瞬間冷却パック」** です。   パッケージには「スポーツ、レジャーのお供に」と、一見フレンドリーなことが書かれています。しかし、その言葉に油断してはいけません。この冷却パックの本気度は、その名が示す通りの「瞬間冷却」能力にこそあるのです。 使い方は至ってシンプル。 袋を拳で、ドンッ！と叩く。 すると、中の水袋が破れ、薬剤と混ざり合うことで化学反応がスタート。 次の瞬間、あなたの手の中には氷点下のオアシスが爆誕します。 この冷たさ、もはや「ひんやり」なんて生易しいレベルではありません。 まさに**「ドン冷え」** 。 首筋に当てれば、灼熱の太陽の下で失いかけた意識を強制的に引き戻すほどの衝撃。火照った顔に当てれば、CPUを強制冷却するかのようなリフレッシュ感。 正直に言います。 これがないと、今年のGoogle Cloud Next Tokyo は乗り切れません。 長いセッションの合間に。満員電車のようなシャトルバスを待つ間に。ランチタイムの火照った身体に。 この「ドン冷え」パックが、あなたの思考をクリアにし、次のアクションへの活力を与えてくれるはずです。 「SCSKのブースでもらったアレ、マジで神だった…」 イベントの終わり、きっとあなたはそう呟いていることでしょう。   …他にも何かあるらしい ちなみに、我々の優しさは”ドン冷え”だけにとどまりません。 SCSKロゴの入った、クールな**「クーリングタオル」**なるものもご用意しているとか、いないとか…？水に濡らして軽く振れば、気化熱でひんやり感が持続する、こちらも地味に嬉しい便利アイテムらしいです。（画像にもひっそりと写っていますね！） ですが、まず皆様に体験していただきたいのは、あの衝撃的な「ドン冷え」です。   さあ、SCSKブースへ急げ！ SCSKブースのスタッフを見かけたら、ぜひお声がけください。 我々は、この「ドン冷え」体験を皆様と分かち合えることを心から楽しみにしています。 この夏最高のイベントを、最高のコンディションで楽しむために。 合言葉は** 「SCSKで、ドン冷え！」 ** 皆様のお越しを、ブースでお待ちしております！

こんにちは、広野です。 生成 AI 界隈の技術の進化がすさまじく、以前開発したチャットボットのアーキテクチャも陳腐化が見えてきました。この記事を執筆している時点での最新のアーキテクチャで改めて作り直してみたので、いくつかの記事に分けて紹介します。 今回 (初回) はアーキテクチャ概要編です。実装編を以降執筆します。 インスピレーションを受けた記事 私がチャットボットを作り直そうと思ったきっかけは、以下の記事を読んだことでした。 re:Invent 2024: AWS AppSyncでAmazon Bedrockの AI Gateway構築 zenn.dev re:Invent 2024: AWS AppSync Eventsによるリアルタイムイベント処理 zenn.dev   いずれも re:Invent 2024 のセッション動画から AWS さんが 生成 AI (Amazon Bedrock) で自動作成した記事なので、つまりは re:invent 2024 がインプットなわけですが、 生成 AI チャットボットからの流れるようなレスポンスを表現する UI をサーバーレスで開発するにはどのようなアーキテクチャがベストなのか？ を考えたときに、 ああ、今だったらこうすればいいんだ　 というように腹落ちさせてくれた記事でした。 実際には、この記事の内容に改良を加えています。 つくったもの 以下のアニメーション GIF をご覧ください。 テキスト問い合わせのみのチャットボットです。 自動スクロール機能はありません。 会話履歴は残りません。 上の画像ではわかりませんが、マークダウンに対応しています。 UI パーツは MUI を使用しています。 生成 AI 基盤モデルは Amazon Nova micro です。 フロントエンドで使用している言語、モジュール等 React 19.1.0 : 開発フレームワーク react-router 7.7.1 : 画面遷移制御 @mui/material 7.2.0 : UI パーツ aws-amplify 6.15.4 : AWS リソース連携 aws-amplify/ui-react 6.11.2 : UI パーツ axios 1.11.0 : API 呼出 markdown-to-jsx 7.7.12: マークダウン vite 7.0.6 : ビルドツール アーキテクチャ 以下のアーキテクチャで基盤を構築しています。 全体的な流れの解説 アプリケーションは AWS Amplify Hosting で配信、認証システムには Amazon Cognito を使用しています。 アプリ UI からチャットボットに問い合わせると、Amazon API Gateway にリクエストを投げます。 API Gateway は問い合わせ内容を受け付けた後、背後にある AWS Lambda 関数にリクエストを渡した後、処理完了をアプリに返します。(非同期呼出) 呼び出された Lambda 関数は Amazon Bedrock の生成 AI 基盤モデルにリクエストを投げます。この部分の認証は IAM です。 Amazon Bedrock はレスポンスを細切れに (チャンク分割して) AWS AppSync Events API にパブリッシュします。AWS AppSync Events はいわゆる Pub/Sub 機能を提供するサービスです。 AppSync Events API は、パブリッシュされたメッセージ (細切れのレスポンス) を、クライアントからサブスクライブしてもらうエンドポイントを持っています。アプリがあらかじめ指定のエンドポイントをサブスクライブしておけば、メッセージがパブリッシュされたタイミングでリアルタイムにアプリに配信されます。 アプリが受け取ったメッセージは細切れになっているので、受け取った順に結合してアプリ画面に表示します。これにより、テキストが順番に流れるような表現 (ストリームレスポンス) を実現できます。 特長（良いところ） フルサーバーレスである 基盤がマネージドサービスなので、その辺りのメンテや拡張性を基本気にすることがありません。 利用料金が安いです。 認証を Amazon Cognito に統一している アプリの認証ができれば、その認証情報を元に Amazon API Gateway, AWS AppSync の認証が通るようになっています。 アプリから認証に必要な ID 等を改ざん可能なパラメータとして Amazon API Gateway, AWS AppSync には渡さず、それぞれのリクエスト受け取り側リソースで証明書から ID を取得し、ID 偽装をチェックしています。 AppSync Events の Pub/Sub 権限設計が柔軟で使いやすい AWS AppSync Events API はチャンネルという単位で Pub/Sub メッセージ授受範囲を管理します。チャンネル名は / 区切りで階層構造を持たせ、それを利用した権限制御が可能です。 チャンネルは最上位層だけ固定名で設定が必要ですが、以降はクライアントから Pub/Sub するときに無いものは自動で作成されます。あらかじめ、パブリッシュ側、サブスクライブ側で決めたチャンネル命名ルールを守っていればやり取りができます。チャンネル名のセキュアな共有と権限設定ができれば、1対多、多対1、多対多の Pub/Sub が容易に実装できます。 チャンネル名に Amazon Cognito ユーザーの属性を含めることができます。今回の例ですと、Amazon Cognito ユーザー ID をチャンネル名に含めており、メッセージが自分だけに配信されるようにすることができます。 従来のアーキテクチャと比較して 一番嬉しいのは、GraphQL を一切使用しない点です。従来の AppSync GraphQL API でも Pub/Sub はできましたが、GraphQL のスキーマやリゾルバ設定が難解で、理解できたとしても複雑で面倒でした。AppSync Events API はそのストレスから解放してくれました。 以下は、従来のアーキテクチャを紹介したブログ記事です。AWS AppSync GraphQL API を使用していました。 AWS AppSync + Amazon DynamoDB + React で簡易チャット WEB アプリをつくる AWS AppSync のプッシュ通知機能を活用して、簡易なチャット WEB アプリをつくってみましたので紹介します。主に AWS AppSync で必要になる GraphQL 周りのコード例です。 blog.usize-tech.com 2023.02.27   AWS Lambda 関数へのリクエストが非同期になり、行き (リクエスト) と帰り (レスポンス) で経路が異なります。これにより、API Gateway が持つレスポンスタイムアウト制限が無制限に解放されました。 とは言え、デメリット (と言うか未解決事項) として AWS Lambda 関数の実行時間がかさむことが残っています。レスポンスが終了するまで AWS Lambda 関数を実行し続けなければなりません。 以下は、従来の AWS Lambda 関数 URL を使用した同期呼出のアーキテクチャ紹介記事です。 AWS Lambda 関数を API 化するとセキュリティ設定が難しくなったり、面倒な設計をしないといけなくなったりするので、API が API Gateway REST API に戻ったのもセキュリティ面、可用性面でもメリットがあると感じています。 やってみたら面倒くさい、React アプリからの Amazon Cognito 認証付き AWS Lambda 関数 URL 呼出 Amazon Cognito 認証を施した React アプリから、認証済みユーザのみ AWS Lambda 関数を呼び出せるようにする React コードを紹介します。 blog.usize-tech.com 2024.01.15 React アプリに Amazon Bedrock への問い合わせ画面を組み込む [レスポンスストリーミング対応] React アプリに Amazon Bedrock に問い合わせる画面をつくってみたので React と AWS Lambda 関数のコードを紹介します。 blog.usize-tech.com 2024.01.16   今時点の設計でイケてないと思うのは、サブスクリプションを張りっぱなしのため、Amazon Bedrock からのレスポンスの明確な終了がわからないところです。問い合わせに対するレスポンスの終了フラグがないんです。 そのため、例えばレスポンス生成中は 待ち状態のグルグルアイコン を表示して、レスポンスが完了したら消す、というエフェクトを入れたいのですが入れられず。実はやり方があるのかもしれませんが調べきれていません。Lambda 関数を閉じる直前に何か送る、というのを考えたいですね。 続編記事 実装編記事が出来次第、この章を更新します。   まとめ いかがでしたでしょうか。 生成 AI 界隈は進化が速いので、この記事の賞味期限もいつまでなのやら・・・。でも、AWS AppSync Events は AI に関係なく使いやすいサービスに仕上がっているので、今後多用していきたいと思っています。 本記事が皆様のお役に立てれば幸いです。

結合テスト時に、 Microsoft Entra Privileged Identity Management（PIM） を使用しました。 PIMの有効化から利用後の無効化まで、どのような操作が必要でどのような画面が表示されるのか紹介します。 ちなみに「ピム」と読みます。 PIMとは PIMは、Microsoft Entra IDが提供する 特権アクセス管理 の機能です。 共同作成者などのロールを「常時」付与するのではなく、「 必要な時だけ一時的に有効化 」が可能です。 例えば、普段は 閲覧者 の権限のみを持つユーザーがリソース作成をする必要があるとき、有効期間を限定して 作成者権限 を有効化できます。 申請時には理由の記載や承認プロセスがあり、権限の濫用防止も可能です。 一連の操作は全て監査証跡として記録され、ガバナンスや監査にも有効です。 Privileged Identity Management とは? – Microsoft Entra ID Governance | Microsoft Learn Microsoft Entra PIM で Microsoft Entra ロールの監査ログ レポートを表示する – Microsoft Entra ID Governance | Microsoft Learn フローで比較します。 ■通常の権限運用 一般ユーザー（作成者権限が常に付与）　→　特権操作が常に可能 誤操作リスクが高まります。 ■PIMによる権限運用 一般ユーザー（権限なし）　→　PIM申請 + 管理者による承認　→　一般ユーザー（作成者権限が 一定時間のみ 付与） →　作業終了　→　一般ユーザー（権限なし） 権限が自動で解除され安心かつ、監査証跡に記録されます。 権限申請してみた 1. ポータルからMicrosoft Entra Privileged Identity Managementを選択します。                            2. 自分のロール>グループと移動。 申請したいロールを選んで、操作欄のアクティブ化を押下します。   　     3. 開始時刻とその期間の設定します。最大8時間まで選べます。 アクティブ化の理由を書いて、送信します。 これで申請完了です。                                       4. 申請すると、管理者にメールが飛びます。                         5. 承認されると、権限が付与されていることを確認できました。（上から5個目の権限です。）               具体的なPIMのメリット ケーススタディとしてテスト時のメリットを、管理者とテスト担当者の視点から考えてみます。 管理者 ロールの割り当てに関する メールを受け取ることができる 持 ち続けるべき権限かどうかを定期的にチェック でき、不必要な権限を削除できる 特定のロールの アクティブ化の履歴 を確認できる テスト担当者 テストの要件に沿うように、 期限付きの一時的な 管理者ロールの割り当て許可を取得できる   感想ですが、自身がどの権限でAzureにアクセスしているかを意識しながら作業することの重要性を学びました。 PIMは権限の安全な運用を実現できるため、特に経験の浅いメンバーが参加するプロジェクトでも安心して活用できる有用な仕組みだと感じております。 PIMに関するブログは現状少ないので普及していないかもしれませんが、今後一般的になる技術かも？ さいごに 今回は権限申請する側からのPIM操作を体験できました。 いつか管理者側のPIM操作を体験し記事にしたいです。

AWS CDKでAmazon RDSリソースを構築する際、「なぜParameterGroupでは名前を直接設定できるのに、OptionGroupではできないのか？」という疑問を持ったことはありませんか？ 実際にコードを書いてみると、ParameterGroupではnameプロパティが使えるものの、OptionGroupでは同じようにはいきません。 統一された命名規則を適用したいプロジェクトでは、この違いが思わぬ障害となることがあります。 この記事では、AWS CDKの公式ドキュメントを参照しながら、OptionGroupで物理名を設定する方法について詳しく解説します。 問題：OptionGroupに名前設定プロパティが存在しない AWS CDK公式ドキュメントのOptionGroupプロパティを確認すると、以下のプロパティのみが提供されています。 class OptionGroup (construct) · AWS CDK # class OptionGroup (construct) docs.aws.amazon.com   configurations?  – オプションの設定 description?  – オプショングループの説明 engine  – データベースエンジン 注目すべき点は、 ParameterGroupには存在する name プロパティが、OptionGroupには存在しない ということです。 OptionGroup（名前設定不可） // ❌ OptionGroupには物理名を設定するプロパティが存在しない const optionGroup = new rds.OptionGroup(this, 'RDS-OptionGroup', { engine: rds.DatabaseInstanceEngine.mariaDb({ version: rds.MariaDbEngineVersion.VER_11_4_5 }), configurations: [], // optionGroupName: "..." // このプロパティは存在しない // name: "..." // このプロパティも存在しない }); この制限により、統一された命名規則を適用したい場合や、既存リソースとの互換性を保つ必要がある場合に問題となります。 CDK APIドキュメントとの対比 同じRDSリソースでも、ParameterGroupとOptionGroupで提供されているプロパティが異なります。 class ParameterGroup (construct) · AWS CDK # class ParameterGroup (construct) docs.aws.amazon.com ParameterGroup（名前設定可能） // ✅ ParameterGroupには name プロパティが存在 const parameterGroup = new rds.ParameterGroup(this, 'RDS-ParameterGroup', { engine: rds.DatabaseInstanceEngine.mariaDb({ version: rds.MariaDbEngineVersion.VER_11_4_5 }), parameters: { character_set_server: 'utf8mb4', character_set_client: 'utf8mb4', collation_server: 'utf8mb4_unicode_ci', }, name: 'ParameterGroup' // 直接指定可能 });   解決策：エスケープハッチを使用した物理名設定 この問題を解決するには、CDKのエスケープハッチ機能を使用してCloudFormationの AWS::RDS::OptionGroup リソースの OptionGroupName プロパティを直接操作する必要があります。 /** * オプショングループの作成 */ const optionGroup = new rds.OptionGroup(this, 'RDS-OptionGroup', { engine: rds.DatabaseInstanceEngine.mariaDb({ version: rds.MariaDbEngineVersion.VER_11_4_5 }), configurations: [] // MariaDBでは通常空で問題なし }); Tags.of(optionGroup).add('App', 'Cpe'); // エスケープハッチでオプショングループの物理名を設定 const cfnOptionGroup = optionGroup.node.defaultChild as rds.CfnOptionGroup; cfnOptionGroup.addPropertyOverride('OptionGroupName', `OptionGroup`); エスケープハッチの動作原理 L2コンストラクトの作成 : CDKの高レベルAPI（L2）でOptionGroupを作成 L1コンストラクトへのアクセス :  node.defaultChild でCloudFormationリソース（L1）にアクセス 型キャスト :  rds.CfnOptionGroup 型にキャストして適切な型情報を取得 プロパティオーバーライド :  addPropertyOverride() でCloudFormationプロパティを直接操作 なぜエスケープハッチが必要なのか CDKの設計思想では、リソースの物理名は自動生成されることが推奨されています。しかし、実際のプロジェクトでは以下のような理由で明示的な命名が必要になることがあります。 統一された命名規則の適用 既存リソースとの互換性保持 環境間でのリソース名の一貫性 運用チームでのリソース識別の簡素化 ParameterGroupでは name プロパティが提供されているにも関わらず、OptionGroupでは提供されていないのは、CDKの実装が完全に統一されていないことを示しています。 まとめ AWS CDKの公式ドキュメントで確認できる通り、RDSのOptionGroupには物理名を設定するプロパティが提供されていません。この制限を回避するには、エスケープハッチを使用してCloudFormationレベルでのプロパティ操作が必要です。 一見すると複雑に見えるかもしれませんが、一度パターンを理解すれば、他の似たような制約がある場合にも応用できる汎用的な解決策となります。実際のプロジェクトでは、本記事で紹介した方法を活用して、統一された命名規則を実現することができます。

Amazon Nova は、AWSが提供する基盤モデルです。 2024年12月3日にリリースされ、Amazon Bedrockで利用することができます。 サービス開始後約半年が経過し、モデルの追加や活用事例なども出てきました。   この記事では、改めてAmazon Novaについて基礎から理解し、活用方法をイメージできるような内容をまとめました。 Amazon Novaについて知らないので理解したい方、おさらいしたい方におすすめです。   Amazon Novaとは さて、Amazon Novaについて詳しく見ていきましょう。   Amazon Novaって何なのかな？ AWSが提供するAIモデルで、テキストだけでなく画像、動画、音声を扱うことができるんだよ。   Amazon BedrockではAIプロバイダーより提供される多くのモデルを選ぶことができますが、AWSが提供するモデルも含まれており、それがAmazon Novaです。 モデルファミリー 入力 出力 特徴 対象言語 対応リージョン Amazon Nova Micro テキスト テキスト ・極めて低レイテンシー、非常に低コスト・高速応答 200以上 アジアパシフィック (東京、シドニー)、米国東部 (バージニア北部)、欧州 (ロンドン)、AWS GovCloud (米国西部) Amazon Nova Lite テキスト, 画像, 動画 テキスト ・超高速、非常に低コストのマルチモーダル ・インタラクティブでハイボリュームな用途に最適 200以上 アジアパシフィック (東京、シドニー)、米国東部 (バージニア北部)、欧州 (ロンドン)、AWS GovCloud (米国西部) Amazon Nova Pro テキスト, 画像, 動画 テキスト ・精度、速度、コストのバランスが取れた高性能マルチモーダル ・動画要約、AIエージェントなどほぼ全てのタスクに対応 200以上 アジアパシフィック (東京、シドニー)、米国東部 (バージニア北部)、欧州 (ロンドン)、AWS GovCloud (米国西部) Amazon Nova Premier テキスト, 画像, 動画 テキスト ・ファミリーで最も高性能・複雑なタスクや、他モデルを教育する「教師役」に最適 200以上 米国東部 (バージニア北部) Amazon Nova Canvas テキスト、画像 画像 ・プロ級の画像を生成・編集できる画像モデル ・配色の調整やレイアウト制御も可能 英語 アジアパシフィック (東京)、米国東部 (バージニア北部)、欧州 (アイルランド) Amazon Nova Reel テキスト、画像 動画 ・高品質な動画を簡単に作成できる動画モデル ・自然言語でカメラモーションなども制御可能 英語 アジアパシフィック (東京)、米国東部 (バージニア北部)、欧州 (アイルランド) Amazon Nova Sonic 音声 文字起こし、音声 ・人間のようなリアルタイム音声会話を実現する音声モデル ・スムーズな対話や関数呼び出しに対応 英語 (米/英アクセント)、スペイン語 アジアパシフィック (東京)、米国東部 (バージニア北部)、欧州 (ストックホルム) *2025/7下旬時点での情報です 詳細は以下AWS公式ページを参照ください。 Amazon Nova 基盤モデル Amazon Nova とは何ですか？   ほとんどのモデルは東京リージョンで使えるんだね。 テキストのモデルはAmazon Nova Micro, Lite, Pro, Premierがあり、それぞれ賢さと費用が異なります。 200以上の言語に対応しているため、幅広く利用することができます。   Amazon Novaを使ってみる 実際にAmazon Novaを使ってみましょう。 どのような手順で利用できるかを見ていきます。 モデルを使えるようにする AWSマネジメントコンソールより、Bedrockを選択します Configure and learnより、モデルアクセスを開きます モデルアクセスを変更より、Novaファミリーにチェックをつけ送信を押します 少し待つと、アクセスが付与されましたと表示され、利用できるようになります   何故すべてのモデルが最初から有効化されていないのでしょうか。 気になったためAmazon Qに聞いたところ、いくつかの重要な理由からアクセスリクエストを求めているようです。 いくつかポイントを抜粋します。 リソース管理 ：明示的なアクセスリクエストを要求することで、AWS はこれらの強力なモデルのリソースをより適切に管理および割り当て、すべてのユーザーに最適なパフォーマンスを確保できます。 コスト管理 ：基盤モデルは計算負荷が高い場合があります。アクセスリクエストを要求することで、お客様がこれらのリソースを積極的に利用することを保証し、予期せぬコストの発生を防ぐことができます。 コンプライアンスとガバナンス ：組織によっては、特定のコンプライアンス要件や社内ガバナンスポリシーを設けている場合があります。アクセスリクエストプロセスにより、管理者はこれらのポリシーに沿ってモデルの使用状況を確認し、承認することができます。 ユースケースの検証 ：Anthropic などの一部のモデルでは、AWS はユーザーにユースケースフォームへの記入を求める場合があります。これは、モデルが適切に使用され、AWS の責任ある AI 原則に準拠していることを確認するためです。 ライセンス契約の承諾 : 一部のモデルでは、アクセスを許可する前に、特定のエンドユーザーライセンス契約 (EULA) を確認し、同意する必要があります。 Playgroundで使ってみる Bedrockの Chat / Text playgroundを選択します モデルを選択にて、Amazon Nova Proなどのモデルを選びます 設定欄でパラメータを選択し、チャットを実行します   こんなに簡単に使えるんだね。 Playgroundは、Amazon Bedrockをマネジメントコンソール上で簡単に試すことができるんだ。 Chat / Text playgroundではテキストを出力するモデルを扱うことができますが、Image / Video playgroundを選択することで、Nova CanvasやNova Reelといったモデルを試すこともできます。   Amazon Novaのビジネス活用 Amazon Novaは利用できるようになってからまだ半年程度ですが、実際に企業でビジネス活用した事例も出ています。 Amazon Nova Canvas / Reel マーケターの時間を“解放”する。生成AIで切り拓く次世代マーケティングの兆し 電通デジタルさんにおけるAmazon Nova CanvasとNova Reelの活用事例です。 広告バナーを作成するため、過去人手で行うことで数週間かかっていた工程が、Nova Canvasの導入により最短10分程度になっています。 また、Nova Reelにより動画背景の作成や修正も効率化しています。 AWSの環境で画像や動画を生成できるというのは、既にAWSを利用している場合にはハードルが低く使いやすいのかもしれません。   おわりに この記事ではAmazon Novaに関する基本的な内容と活用事例をご紹介しました。 生成AIをビジネスに導入する際、様々なモデルがあり比較検討に迷うことがあるかもしれません。 また、モデルの進歩は日進月歩であり変化しています。   今回ご説明した内容が少しでもお役に立てれば幸いです。 また、実際にAWSのコンソールから触ってみると、よりイメージがつきやすいのでおすすめです。

みなさん、こんにちは！ 本日は、基本の基本に立ち返って、「 ServiceNowってなに？ 」について書いてみたいと思います。 ServiceNow社ってどういう会社？ ServiceNow社はアメリカのカルフォルニア州で2004年に設立されました。日本ではServiceNow Japan合同会社が2013年に設立されています。 ServiceNow Japan合同会社単体でのの売上情報等は公開されていませんが、ServiceNow社全体で5年で株価は３倍以上、売上は右肩上がりで、時価総額も24兆円越え（2024年3月時点で）、Fortune500にも認定されています。 一言で言ってしまえば「 ノリに乗ってるイケイケ企業 」なんです！ ServiceNowとは？ 国内だとITSMツールとしての認知度が高いように思いますが、ServiceNowはITSMツールではありません！ 「企業のあらゆる業務」を「デジタルワークフロー化」し、仕事の流れの全体を効率化、見える化、自動化するプラットフォーム、それがServiceNowです。 ServiceNowのコンセプトはServiceNow社の社名からもよみとれます。 すべての業務を サービス として定義し、人や企業が、あらゆるサービス（Service）をすぐに（Now）届ける会社 という意味が込められています。 なので、ServiceNow社のロゴにのoの部分は人が隠れてるんですね。（えっ？！とおもったそこのあなた。ServiceNowのロゴをぐぐってながめてみてください）   上の図でわかるように、ServiceNowのベースは「 Now Platform 」です。ここに基礎となる様々なコンポーネントが載っています。Now Platform上のコンポーネントに、さらに各領域の標準的なプロセスを盛り込んだデジタルワークフローをバンドルさせたものを、ITSMやCSMなどのSaaSアプリケーションとして展開しています。 そういった形で最初に展開させたのがITSM領域だったのです。 現在、ServiceNowが提供するアプリケーションはIT部門が管理する領域だけにとどまらず、人事や総務、法務といった領域（非IT領域という言い方をよくします）のアプリケーションも用意されています。 さまざまな業務で利用されるアプリケーションをワンプラットフォームで一元管理することで IT部門の業務や、非IT部門の業務の可視化、効率化、自動化が期待できることがServiceNowの価値です。 まさに、ServiceNowは 会社全体の業務アプリケーション ともいえるのではないでしょうか。 ちなみに余談ですが・・、ServiceNowって契約更新率が99％なんです。これはすごいですね。   ServiceNowの特長とは？ ServiceNowを語るうえで特に欠かせないのは以下２つです。これがまさにServiceNowの大きな特長といえるでしょう。 デジタルワークフロー One Platform デジタルワークフロー デジタルワークフローってワークフローとちがうの？って思いませんか？ これが一般的なワークフローです。ワークフローというと、「承認する」という部分にフォーカスされますが、実際この承認の前後には、業務があるわけです。上記の例であれば、依頼者との調整や督促であったり、承認後であれば作業内容確認、実施、報告などの業務です。 この ワークフローの前後の業務までも含めたフローそれがデジタルワークフロー です。前後の業務までも含めた全体をデジタルワークフローとすることで、プロセス全体の効率化ができるわけです。 One Platform ServiceNowは全アプリケーションが一つのプラットフォーム上で稼働します。マスタ情報だけでなく、業務プロセスやユーザデータ等、各アプリケーションで生成されたデータは、プラットフォーム上のデータとして共有されます。 一つに集まることで何がいいのか。 それは、 アプリケーション連携やAPI連携を考えずに複数業務においてデータの活用ができる ということになります。ServiceNowを新しい業務領域へと拡張したいとき、すでにあるデータをそのまま活用できるので、ビジネスのスピードが上がるわけです。 幅広い業務のデジタルワークフローを展開しながら、データモデルもレベルでも一つに集約ができている、そういったサービスはなかなかなく、まさにServiceNowの特長といえるのです。   ServiceNowってなに？をざっくりと説明してきました。なんとなくイメージつきましたでしょうか。 最後までお読みいただき、ありがとうございました。

はじめまして。こんにちは。SCSKの髙橋です。 ServiceNowのライセンスの考え方が複雑でわからない、と質問いただくことが多いので 慣れているITSMについて概要を書いてみようと思います。   基本的な考え方 課金の単位 ITSM、CSMなどはユーザー単位の課金です。 ServiceNow社の資料などは月額で書かれていることも多いので注意です。   ITOM、HAMなどはサブスクリプションユニット単位。 SAMはサーバー単位。 SecOpsはデバイス単位。   契約期間 月額で書かれていることも多いですが、契約は1年単位ですが、3年契約がおすすめです。 1年契約だと割高になってしまうようです。   ライセンスのパッケージ だいたいStandard／Professional／Enterpriseと三段階用意されていることが多いです。 三段階に分かれていないサービスもあります。 主な違いは使える機能の種類です。 カスタムテーブルを作れる数の上限など、一部数量的な違いがあるサービスもあります。   オプションやアドオン データの暗号化とか生成AI機能とかはオプション購入する必要があります。 Professional以上じゃないと使えないオプションなどライセンスのパッケージと関係がある場合があります。 これが結構複雑なので、自分達のやりたいことがどのライセンスパッケージで使えるのか、 きちんと確認しましょう。   ITSMのユーザー課金の考え方 ITSMはユーザー課金です。 ServiceNowの考え方では、ユーザーは3種類います。 Fulfiller BusinessSteakHolder Requester 大事なことは、Requesterは無料で使えるということです。 ユーザー単位なので、ITを利用する社員数で考えてしまうかもしれませんが、 IT運用する人の数で考えるのが正解です。 BusinessSteakHolderライセンスもFulfillerに比べて価格が安いですが権限が限定されます。 明確に承認だけの人が確定しているならいいと思いますが、 要件を詰めていった結果Fulfillerが必要、となって予算オーバーとならないように概算のときなどは注意が必要です。   ITSMのライセンスのパッケージ ITSMは、ライセンスのランクによって使える機能が違います。 Standard Professional Enterprise ITサービスマネジメントの本当に基本的な機能だけで良いならStandard。 Professionalでは、ITサービスマネジメントの改善を進めるための情報分析機能が充実しています。 様々なオプションやアドオンもProfessional以上が条件となっていることが多いです。 データ分析、機械学習、チャットボット、生成AIなどを活用して高度な運用と改善を加速したい場合は、 Professional以上がいいでしょう。 Enterpriseは、Process MiningとWorkforce Optimizationがさらに追加されます。   ちなみに、CMDBは、プラットフォームで提供される機能なので、 ITSMに限らずServiceNowを契約すると利用できるものです。 構成情報の自動収集は、ITOMのDiscoveryの機能となりますので、 別の契約が必要ですが。   アドオン、オプションの種類 アドオンもたくさんあって書ききれないのですが、主要なものはこんな感じかと。 ITSM Professional Plus：Now Assist for ITSMという生成AIを使うためのライセンスです。Fulfiller単位課金です。 Platform Encryption：インスタンス全体の暗号化オプションです。 Impact：ServiceNow社のサポート契約で、ライセンスとは別に有料の契約が必要です。サポートのサービスレベルによってプランが複数用意されています。業務の重要性に応じて検討しましょう。専任のエンジニアがつく最高位のプランもあります。   あとは、様々な他社製品のデータをServiceNowで統合したい場合は、 Workflow Data Fabricという別のサービスの購入が必要です。   ITSM以外は、、、 ITSM以外は、もう少し詳しくなったら、また別の機会にしようと思います。 乞うご期待。   最後まで読んでいただき、ありがとうございました。

こんにちは SCSKの庄司です。 今回は基本的な機能ではありますが意外と知らない人も多い、レコードを一括更新する方法を紹介していきます。 本記事は執筆時点（2025年7月）の情報になります。最新の内容は製品ドキュメントを参考にしてください。 CtrlまたはShiftキーを使用したリストエディターの活用 まずは最も手軽な方法を紹介します。 手順： ①リスト画面を開き、CtrlキーもしくはShiftキーを押下しながら更新対象となるレコードの対象フィールドをクリックして選択します。 Ctrl：任意のレコードを個別に選択 Shift：隣接するレコードを範囲選択 青色に変更されたフィールドが、選択中のフィールドです。 CtrlとShiftの違いとしては、Ctrlは複数選択、Shiftは範囲選択であるという点です。 具体的には、Ctrlは飛ばし飛ばしで任意のレコードを個別に選択できます。 一方で、Shiftは隣接するレコード間を範囲選択します。 ExcelでのCtrlとShiftキーでのセル選択をイメージしていただければわかりやすいと思います。 ②選択中のフィールドの中の任意のレコードをダブルクリックします。 リストエディター画面に選択中のフィールドの数が表示されています。 ③更新内容を入力します 今回は、「アサイン先グループ」を「Hardware」に変更します。 ④保存を押下します 更新後、先ほど選択したすべてのレコードが更新されていることがわかります。     注意： この方法は最も簡単にレコードを一括更新できるものの以下のような制約があります。 ・一度に更新できるフィールドは一項目のみ ・リスト上に表示されているレコードの範囲までしか更新できない(最大100件)   「すべて更新」 「すべて更新」を使うと、一括でテーブル上のすべてのレコードを更新することもできます。 手順： ①コンテキストメニューを開き、「すべてを更新」を選択します。 ②更新対象のレコード数が表示されるので、よければOKを押下します。 この更新対象は現在のリスト上のすべてのレコードになりますので、フィルター条件を使用することで更新対象を変更することが出来ます。 今回は「アサイン先グループ」が「Hardware」のレコードを一括更新します。 ③フォーム画面が表示されるので、この画面で対象レコードに対して一括で更新したい内容を記載します。 今回は、「アサイン先グループ」を「Software」、「アサイン先」を「Beth Anglin」に変更します。 ④[更新]を押下すると、画面がリスト画面に遷移します。 「複数の更新が完了しました。合計レコードが更新されました：21」というメッセージが表示されています。 対象レコードが更新されたので「アサイン先グループ = Hardware」のレコードがなくなっています。 「アサイン先グループ = Software」かつ「アサイン先 = Beth Anglin」かつ「更新日時 = 今日」でフィルタリングすると、先ほどは「アサイン先グループ = Hardware」だったレコードたちが出てきました。 注意： この更新方法だと、上限なくレコードを一括更新ができます。 ただし、気を付けなければならないのはすべてのレコードを目視で確認することはできない点です。 フィルター条件を間違えてしまうと意図しないレコードまで更新することになってしまうので注意が必要です。   「プレビューですべて更新」 「プレビューですべて更新」は、より安全にレコードの一括更新をすることが出来ます。 手順： ①コンテキストメニューを開き、データ管理>プレビューですべてを更新を押下します。 ②データ管理更新ジョブレコードが作成され、表示されます。 以下、このレコードの要点となるフィールドについて説明します。 ・ 条件 ：一括更新対象とするレコードのフィルター条件 今回は「アサイン先グループ = Software」かつ「アサイン先 = Beth Anglin」かつ「更新日時 = 今日」でフィルタリングした状態からフィルタリングした状態から[プレビューですべてを更新]を選択したので最初から入力されていますが、データ管理更新ジョブレコード上からフィルタリング条件を変更することもできます。 条件を記入した後[プレビュー]を押下すると、その条件に応じたレコードの数を表示してくれます。 更新対象となるレコードに間違いがないように、「条件」にはよく注意しましょう。 ・ フィールドと値 ：更新対象レコードに対して更新をかけるフィールドとその値 今回は「アサイン先グループ」を「Hardware」に、「カテゴリ」を「ハードウェア」に変更します。    実行場所 ：レコード一括更新の実行日時を定義します。 手動で更新を実施するので、今回は空欄のままにします。 ③必要事項を記入した後、[保存]を押下します。 ④保存後、関連リンク[今すぐ実行]を押下します。 ⑤更新の実行前に警告が出てきますので、問題なければ[続行]を押下します。 以上の手順で更新が完了しました。 ではインシデントテーブルを見に行きます。 「アサイン先グループ = Hardware」かつ「カテゴリ = ハードウェア」かつ「更新日時 = 今日」をみると、先ほどまで「アサイン先グループ = Software」かつ「アサイン先 = Beth Anglin」かつ「更新日時 = 今日」だったレコードたちが表示されています。        「アサイン先グループ = Software」かつ「アサイン先 = Beth Anglin」かつ「更新日時 = 今日」を見に行くと、レコードがなくなっています。 以上が「プレビューですべて更新」です。 基本的には手順が少し変わるだけで、やっていることやできることは先ほど紹介した「すべて更新」と変わりません。 ただし、一点大きく異なる箇所があります。 それは、「ロールバック」ができる点です。 以下、ロールバックの手順を紹介します。 ロールバック手順： ①先ほどのレコード更新完了画面から、[実行結果を確認]を押下すると、データ管理更新ジョブレコードが開きます。 開いたデータ管理更新ジョブレコードを見ると、「状況」が「完了」、「実行場所」が実行した日時になっています。 そして、先ほどは[すぐに実行]が表示されていた関連リンクに[ロールバック]が表示されています。 ②関連リンク[ロールバック]を押下すると、本当にロールバックを実施するかというポップアップが出てきますので、問題なければ[ロールバック]を押下します。 ③ロールバックが完了しました。 データ管理更新ジョブレコードの「状況」が「ロールバック済み」に変更されています。 では、リストを見に行きます。 ロールバック前とは異なり、「アサイン先グループ = Hardware」かつ「カテゴリ = ハードウェア」かつ「更新日時 = 今日」でフィルタリングしてもレコードがありません。 逆に、「アサイン先グループ = Software」かつ「アサイン先 = Beth Anglin」かつ「更新日時 = 今日」をみると先ほどのレコードたちが表示されています。     これがロールバックになります。 更新対象を間違えて一括更新してしまった際などに、更新内容を取り消すことが出来る非常に便利な機能です。 注意： 「プレビューですべて更新」も「すべて更新」同様、対象レコードを目視で確認できないので対象が間違っていないかは要確認です。 フィルター条件を間違えてしまうと意図しないレコードまで更新することになってしまいます。 「プレビューですべて更新」ならロールバックで戻すことはできますが、安易な一括更新は避けて慎重に実行するようにしましょう。   「選択項目を更新」 「選択項目を更新」を使うと、「プレビューですべて更新」や「すべて更新」とは異なりフィルタリングしたレコードではなく、選択したレコードに対して一括更新することができます。 手順： ①インシデントテーブルで更新対象とするレコードを選択します。 今回は「アサイン先」が「ATF User」になっているレコードをの中から「カテゴリ」が「ハードウェア」になっているレコードを更新対象とします。   ②選択後、コンテキストメニューを開き、[選択項目を更新]を選択します。 ③フォーム画面のような画面が開きますので更新内容を入力します。 ここからは先ほど紹介した[すべてを更新]と同じです。 今回は、カテゴリをデータベースにしてみましょう。 ④入力後更新を押下します。 画面が遷移し先ほど選択したレコードの「カテゴリ」が「データベース」に更新されています。  注意： こちらの方法は対象レコードを選択する必要があるため、リスト上に表示されているレコードの範囲までしか更新できません(最大100件) また、一括選択する場合を除き、選択の手間もかかるため大量のレコードの一括更新にはお勧めできません。   まとめ 以上が、リスト画面からレコードを一括更新する方法です。 どれも簡単な作業ですが非常に有用な機能ですので、ぜひ使ってみてください。

こんにちは  SCSK 野口です。 前回の記事 『LifeKeeperの「Quorum/Witness」とは』 では、 Quorum/Witnessの種類とパラメータについてご紹介いたしました。 まだ、お読みでない方は上記リンクからご覧ください。 本記事では、 Quorum/Witness（Storage） を仮想マシン上のLinux環境に導入してみます。 今回、共有ストレージには「blockタイプ」を採用します。 おさらい 前回の記事でもお伝えしましたが、共有ストレージは各ノードからアクセス可能なストレージのことです。 Quorum/Witness機能専用で使用する共有ストレージは、LifeKeeperリソースとして保護することはできません。 あくまでもスプリットブレインを回避する機能のために使用します。 Storageモードでは、下記３つの共有ストレージの種類（タイプ）が選択できます。 ・block………共有ストレージに物理ストレージやRDM（物理互換）、iSCSI（VM 内イニシエーター）を使用する場合 ・file…………共有ストレージにNFS (または Amazon EFS) を使用する場合 ・aws_s3……共有ストレージに AmazonのS3 、または Amazon S3互換のオブジェクトストレージを使用する場合 ※ Windowsの場合は、blockタイプはありません。 ちなみに Storageモード は、 2ノード以上４ノード以下 から 利用可能よ！ でも、 クラスター内に  ” – ”  と  ” . ”  だけ異なるホスト名の ノードが存在する場合 は Storageモードが利用できないよ。 例えば、 クラスター内に 「  node-1  」 と 「  node.2   」 が存在する場合はホスト名を変更してね！ 導入 今回の構成について 今回の構成では Virtual Box（仮想VM）を使用し、2台のサーバ（ノード）構成にします。 また、共有ストレージについては VDI（Virtual Disck Image）を使用していきます。 そして、1QWKオブジェクトあたり必要な容量は  4096 バイト (4 KB ) となります。 「QWK_STORAGE_TYPE」を blockタイプにした場合、QWK オブジェクトの配置場所は以下となります。 今回は2台のサーバ（ノード）だから、 QWKオブジェクトに必要な容量は 8192バイト（8KB）だよ！ 2つのパーティションを用意する必要があるんだね！ 動作環境 今回の　Qurum/Witness（Storage構成） を導入した構成は以下となります。   一般的な  Active/Standby 構成ね 稼働系ノードの障害時に待機系ノードにサービスを引き継ぐんだよね！ 導入手順 1.サーバをセットアップし、他のサーバとネットワーク通信ができることを確認します。 ※ サーバセットアップの詳細は省かせていただきます。 サーバ間で通信できているか、お互いに pingコマンドで疎通確認してみます。 [root@rhel75n01 ~]# ping -c 3 rhel75n02 PING rhel75n02 (～.～.～.～) 56(84) bytes of data. 64 bytes from rhel75n02 (～.～.～.～): icmp_seq=1 ttl=64 time=1.68 ms 64 bytes from rhel75n02 (～.～.～.～): icmp_seq=2 ttl=64 time=0.943 ms 64 bytes from rhel75n02 (～.～.～.～): icmp_seq=3 ttl=64 time=0.960 ms — rhel75n02 ping statistics — 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 0.943/1.194/1.681/0.346 ms [root@rhel75n02 ~]# ping -c 3 rhel75n01 PING rhel75n01 (～.～.～.～) 56(84) bytes of data. 64 bytes from rhel75n01 (～.～.～.～): icmp_seq=1 ttl=64 time=1.49 ms 64 bytes from rhel75n01 (～.～.～.～): icmp_seq=2 ttl=64 time=0.913 ms 64 bytes from rhel75n01 (～.～.～.～): icmp_seq=3 ttl=64 time=0.909 ms — rhel75n01 ping statistics — 3 packets transmitted, 3 received, 0% packet loss, time 2004ms rtt min/avg/max/mdev = 0.909/1.106/1.496/0.275 ms 2.サーバに LifeKeeper をインストールします。 その際、「Use Quorum/Witness functions」を有効にし、Quorum/Wintness パッケージをインストールします。 3.全てのノード間でコミュニケーションパスを作成し、ALIVEであることを確認します。 今回は LKWMCなので、左タスクバーの「コミュニケーションパス」を選択します。 ※ コミュニケーションパス（ハートビート）が１つの場合、「リソースツリー」画面では警告が表示されます。 コミュニケーションパスのステータスが「ALIVE」であることを確認します。 4.すべてのノードで Quorum/Witness の設定を行います。(/etc/default/LifeKeeper) ※ パラメータについては、冒頭でお話しした記事を参照してください。 [root@rhel75n02 ~]# vi /etc/default/LifeKeeper QUORUM_MODE= storage             # デフォルト値は majority です                        # What style of quorum verification do we do in comm_up/down                        # and lcm_avail (maybe other) event handlers.                        # NOTE: This only matters of the quorum support is installed                        #            (the steeleye-lkQWK package).                        # The possible values are:                        #  – none/off: Do nothing, skip the check, assume all is well.                        #  – majority: Verify that this node and the nodes it can reach                        #                   have more tha half the cluster nodes.                        # – tcp_remote: Verify that this node can reach more than half                        #                      of the QUORUM_HOSTS via tcp/ip.                        # – storage: Verify by the QWK storage protocol (requires                        #                 additional configuration). WITNESS_MODE= storage              #デフォルト値は remote_verify です                        # This can be either off/none, remote_verify or storage.                        # In remote_verify mode, core event handlers (comm_down) will                        # double check the death of a system by seeing if other visible                        # nodes also think it’s dead.                        # In storage mode, core event handlers (comm_down) will check                        # the death of a system by the QWK storage protocol. なお、Storageモードを利用しているため、必要なパラメータは設定ファイルの末尾に追加します。 # Do NOT edit LK_DISTRIBUTION values – this may cause LifeKeeper to malfunction LK_DISTRIBUTION=redhat LK_DISTRIBUTION_VERSION=7.5-8.el7ON_VERSION=7.5-8.el QWK_STORAGE_TYPE=block                         #（必須）追記 QWK_STORAGE_HBEATTIME=6                     #（任意）追記しない場合はデフォルト値 (6)となる QWK_STORAGE_NUMHBEATS=4                    #（任意）追記しない場合はデフォルト値 (4)となる QWK_STORAGE_OBJECT_rhel75n01=/dev/sdc1     #（必須）追記 QWK_STORAGE_OBJECT_rhel75n02=/dev/sdc2     #（必須）追記 「QWK_STORAGE_OBJECT _ <ホスト名>」 のパラメーターは、 ホスト名に” – ”  と  ” . ”  を含む場合、 ” _ ” （アンダースコア）に置き換えてください！ 「  node-1  」と「  node-2  」や「  node.1  」と「  node.2 」の場合は、 「 node_1 」と「 node_2 」に置き換えて追記すればいいんだね！ 1号機（rhel75n01）からqwk_storage_init コマンドを実行します。 ※ 「QWKオブジェクトとして既に存在しますが上書きしますか?」 と問われるので ”y” を入力し、[Enter] を押します。 [root@rhel75n01 ~]# /opt/LifeKeeper/bin/qwk_storage_init ok: LifeKeeper is running. ok: The LifeKeeper license key is successfully installed. ok: QWK parameter is valid. QWK object of /dev/sdc1 is not yet avail. /dev/sdc1 already exsits as not QWK_STORAGE_OBJECT: overwrite? (y/N): y すると、全ノードで QWK オブジェクトの初期化が終わるまで待ち状態になります。 [root@rhel75n01 ~]# /opt/LifeKeeper/bin/qwk_storage_init ok: LifeKeeper is running. ok: The LifeKeeper license key is successfully installed. ok: QWK parameter is valid. QWK object of /dev/sdc1 is not yet avail. /dev/sdc1 already exsits as not QWK_STORAGE_OBJECT: overwrite? (y/N): y ok: The path of QWK object is valid. ok: down: /opt/LifeKeeper/etc/service/qwk-storage: 2764s ok: Initialization of QWK object of own node is completed. QWK object of /dev/sdc2 is not yet avail. QWK object of /dev/sdc2 is not yet avail. QWK object of /dev/sdc2 is not yet avail. 2号機（rhel75n02）からも qwk_storage_init コマンドを実行すると、 2号機（rhel75n02）1号機（rhel75n01）ともに 「 Successful. 」 と出力されます。 ※ 1号機（rhel75n01）と同様のことを問われるので ”y” を入力し、[Enter] を押します。 [root@rhel75n02 ~]# /opt/LifeKeeper/bin/qwk_storage_init ok: LifeKeeper is running. ok: The LifeKeeper license key is successfully installed. ok: QWK parameter is valid. QWK object of /dev/sdc2 is not yet avail. /dev/sdc2 already exsits as not QWK_STORAGE_OBJECT: overwrite? (y/N): y ok: The path of QWK object is valid. ok: down: /opt/LifeKeeper/etc/service/qwk-storage: 2788s ok: Initialization of QWK object of own node is completed. ok: quorum system is ready. ok: run: /opt/LifeKeeper/etc/service/qwk-storage: (pid 5152) 1s, normally down Successful. ちなみに初期化後のログを確認したところ、以下のようなメッセージが出力されます。 Jul 15 17:39:43 rhel75n01 runsv[4974]: INFO:runit:::013008:qwk-storage server is starting up Jul 15 17:39:43 rhel75n01 qwk_storage_server[4973]: INFO:qwk:::135805:starting qwk_storage_server Jul 15 17:39:43 rhel75n01 qwk_storage_server[4973]: INFO:qwk:::135848:[rhel75n01:/dev/sdc1] invalid qwk object was found. initializing to sequence 0. Jul 15 17:39:43 rhel75n01 qwk_storage_server[4973]: INFO:qwk:::135848:[rhel75n02:/dev/sdc2] invalid qwk object was found. initializing to sequence 0. Jul 15 17:39:43 rhel75n01 qwk_storage_server[4973]: INFO:qwk:::135923:[rhel75n01:/dev/sdc1] qwk object was restored. Jul 15 17:39:43 rhel75n01 qwk_storage_server[4973]: INFO:qwk:::135924:quorum state changed to AVAIL. Jul 15 17:39:55 rhel75n01 qwk_storage_server[4973]: INFO:qwk:::135923:[rhel75n02:/dev/sdc2] qwk object was restored.   この手順が完了すると、クラスターにおいて Quorum および Witnessの機能が有効化されるわ！ フェイルオーバーが実行される前に Quorumチェック と Witnessチェックが実施されるよ！！ ちなみに、 共有ストレージにアクセスできなくなるとリソースの起動に影響するよ。 だから、 すべてのノードから常時アクセス可能な共有ストレージが必要だよ！ 動作確認 QWKオブジェクトが指定された間隔で更新されているか、実際に確認してみます。 更新間隔は/etc/default/LifeKeeper に記載される  QWK_STORAGE_HBEATTIME（デフォルト6）で定義されます。 1号機（rhel75n01）から ddコマンドを 2回実行し、QWK オブジェクト1が更新されているか確認してみます。 ※ 2回目の ddコマンドを実行する際は、指定された時間と同じくらい間隔をあけてください。 [root@rhel75n01 ~]# dd if=/dev/sdc1 bs=4096 count=1 | strings 1+0 レコード入力 1+0 レコード出力 4096 バイト (4.1 kB) コピーされました、 0.0016561 秒、 2.5 MB/秒 signature=lifekeeper_qwk_object local_node=rhel75n01 time=Fri Jul 16 01:31:15 2025 sequence=8651 node=rhel75n02 commstat=UP checksum=9659698734818933381       [root@rhel75n01 ~]# dd if=/dev/sdc1 bs=4096 count=1 | strings 1+0 レコード入力 1+0 レコード出力 4096 バイト (4.1 kB) コピーされました、 0.00232737 秒、 1.8 MB/秒 signature=lifekeeper_qwk_object local_node=rhel75n01 time=Fri Jul 16 01:31:21 2025 sequence=8652 node=rhel75n02 commstat=UP checksum=9659699284571077253 1号機（rhel75n01）からQWK オブジェクト2（/dev/sdc2）も確認してみます。 ※ 2号機からの確認は省かせていただきます。 [root@rhel75n01 ~]# dd if=/dev/sdc2 bs=4096 count=1 | strings 1+0 レコード入力 1+0 レコード出力 4096 バイト (4.1 kB) コピーされました、 0.0110848 秒、 370 kB/秒 signature=lifekeeper_qwk_object local_node=rhel75n02 time=Fri Jul 16 01:50:10 2025 sequence=8833 node=rhel75n01 commstat=UP checksum=9643936960751614597       [root@rhel75n01 ~]# dd if=/dev/sdc2 bs=4096 count=1 | strings 1+0 レコード入力 1+0 レコード出力 4096 バイト (4.1 kB) コピーされました、 0.000993328 秒、 4.1 MB/秒 signature=lifekeeper_qwk_object local_node=rhel75n02 time=Fri Jul 16 01:50:16 2025 sequence=8834 node=rhel75n01 commstat=UP checksum=9643937510513719941 両ノード（ rhel75n01 と rhel75n02 ）のタイムスタンプは同じになるとは限らないわよ なお、 Quorum/Witness（Storage） を導入しているサーバでは、 OS起動後にログを確認すると以下のようなメッセージが出力されます。 Jul 1 6 10:13:05 rhel75n01 qwk_storage_server[2960]: INFO:qwk:::135857:[rhel75n02:/dev/sdc2] lcd sys state: UP (It looks the same from its own node and from the target node.) Jul 1 6 10:13:05 rhel75n01 qwk_storage_server[2960]: INFO:qwk:::135863:[rhel75n02:/dev/sdc2] remote node up (status=CR1) Jul 1 6 10:13:05 rhel75n01 qwk_storage_server[2960]: INFO:qwk:::135866:quorum_verify(LCM_AVAIL, ): AVAIL Jul 1 6 10:13:14 rhel75n01 qwk_storage_server[2960]: INFO:qwk:::135857:[rhel75n02:/dev/sdc2] lcd sys state: UP (It looks the same from its own node and from the target node.) Jul 1 6 10:13:14 rhel75n01 qwk_storage_server[2960]: INFO:qwk:::135863:[rhel75n02:/dev/sdc2] remote node up (status=CR1) Jul 1 6 10:13:14 rhel75n01 qwk_storage_server[2960]: INFO:qwk:::135866:quorum_verify(COMM_UP, rhel75n02): AVAIL Jul 1 6 10:13:14 rhel75n01 qwk_storage_server[2960]: INFO:qwk:::135868:witness_verify(COMM_UP, rhel75n01): UP Jul 1 6 10:13:14 rhel75n01 qwk_storage_server[2960]: INFO:qwk:::135868:witness_verify(COMM_UP, rhel75n02): UP まとめ 今回は Quorum/Witness を実際に導入してみましたがいかがでしたか。 導入する際は、以下の点に注意してください。 ・共有ストレージの種類は、3つから選択ができる。（Windowsの場合は2つから選択） ・導入する前に、ホスト名やノード数に細心の注意を払う。 ・導入する際は、コミュニケーションパスが Aliveであることを確認する。 ・動作確認では、指定された間隔で更新されているかタイムスタンプを確認する。   詳細情報をご希望の方は、以下のバナーからSCSK Lifekeeper公式サイトまで

Cato Networks社が今年（2025年）で3回目となるパートナーサミット「Japan Partner Summit Tokyo 2025」が、2025年7月15日（火）に開催されました。 SCSKは、 新規顧客の売り上げに最も貢献したパートナー として「 Japan Highest New Logo Revenue 2024 」と、 最も卓越したサポートを提供し、お客様の満足度向上に貢献したパートナー として「 Japan Best Technical Support Partner 2024 」の2つのアワードを受賞いたしました。 日本でパートナーサミットが2023年に開始されてから 3年連続のアワード受賞 となり、今年度はアワードの ダブル受賞 となりました。 2025年度 https://www.scsk.jp/news/2025/pdf/20250722i.pdf 2024年度 https://www.scsk.jp/news/2024/pdf/20240722i.pdf 2023年度 https://www.scsk.jp/news/2023/pdf/20230726i.pdf アワードが意味するところ 「 Japan Highest New Logo Revenue 2024 」アワードが示すように、これから新しくCatoクラウドのご検討を開始されるお客様は、まずはSCSKまでお問い合わせください。 正しいCatoクラウドのサービスのご紹介、ご理解の支援から、お客様の環境へCatoクラウドを適用する際の不安や懸念点、移行に関わる疑問点などを、多くの導入実績をもとにした最適な回答を行うことが可能です。 もちろん事前検証となるPoC（概念実証）のご支援も実施しております。 ご好評いただいているCatoクラウドの FAQサイト や、本 技術ブログ（TechHarmony） 記事など、いちいち当社へ問い合わせをすることなく、可能な限りお客様自身が自己解決を行うことができるように各種デジタルコンテンツを充実しておりますので、非常にタイムパフォーマンスが高いPoCを行うこと可能となっております。 Catoクラウドのサービスの紹介を受けたが、メリットがよく分からない。他のSASEソリューションとの違いがよく分からない。自社へ適用するにはどうすれば良いか分からない。などがあれば、ぜひ お問い合わせ ください。 次に「 Japan Best Technical Support Partner 2024 」のアワードが示すように、SCSKとご契約いただいたお客様には、日本語での技術問い合わせを始めとし、各種マネージドサービスをご提供しております。これらのサービスが卓越したサポートで、お客様の満足度向上に貢献したとの評価をいただきました。 PoCと同様ですが、FAQサイトや、技術ブログ記事など、各種デジタルコンテンツも充実させており、また、Catoクラウドのドキュメント（Knowledge）は殆どが英語となるため、独自のAIチャットボットもご提供しております。 AIチャットボットに、日本語での自然語検索を行い、Cato公式文書（英語）や、FAQサイト、技術ブログなどを一括検索し、検索結果を回答するとともに、その情報引用元もご提供します。 「SCSK Cato クラウド AI チャットボット」をリリースしました SCSKが開発した「Catoクラウド AIチャットボット」の機能・利便性・導入効果をご紹介します。 blog.usize-tech.com 2025.02.14 また、Cato社のサポート認定「 Cato Distinguished Support Providers（CDSP） 」認定も受けております。 CatoクラウドのCDSP（Cato Distinguished Support Providers）認定を取得 Catoクラウドの戦略的パートナーとしてのCDSP（Cato Distinguished Support Providers）認定取得と、お客様におけるメリットについて解説しています。 blog.usize-tech.com 2024.03.04 SCSKでは、Cato社の上級エンジニアに直接問い合わせが行えますので、当社へお問い合わせいただいた課題については、より早く、より質の高い回答が行うことが可能となっております。 Catoクラウドを現在ご利用中で、何かお困りごとがあるお客様が居れば、ぜひ一度SCSKまで お問い合わせ ください。 最近は、Catoクラウドのユーザーコミュニティ（ユーザ交流会、ユーザ会）である「 Cato Circle（ケイトサークル ）」を発足いたしました。 Catoクラウド ユーザーコミュニティ「Cato Circle」を発足しました！ Catoクラウド ユーザーコミュニティ「Cato Circle（ケイトサークル）」の発足についての記事となります。 blog.usize-tech.com 2025.07.02 Cato Circleは、ユーザーコミュニティなので、通常の企業セミナーのように、一方的に説明を行う「説明型」イベントではなく、利用者であるお客様が、Catoクラウドの自社での活用方法や、利用上の課題を発表し、利用者同士が情報を共有する「双方向型」のイベントを企画しております。 お客様同士の交流、ネットワーク構築から、情報交換のきっかけをご提供し、課題や悩みを共有し、解決するヒントを得ていただくことが Cato Circle の目的となっております。   まとめ 日本国内でも「SASE（Secure Access Service Edge、サッシー）」や、「Cato Networks（ケイトネットワークス）」、「Catoクラウド（正式名称 Cato SASE Cloud Platform）」の認知度は徐々に上がって来ておりますが、まだ低い状況です。 2023年、2024年と品川駅の自由通路にて屋外広告を出稿していましたが、2025年も6月と7月にそれぞれ1週間広告出稿しました。 SCSKでは、2021年からSASEの主要な４ソリューションを一同に紹介を行うオンラインセミナー「SCSK SASE Solution Summit（通称 S4 エスフォー）」を定期的に開催しております。これまで15回開催し、述べ2,000名以上の方にご参加いただいております。 また、Catoクラウドにおいても、デモセミナー（オンライン）、ハンズオンセミナー（オフライン）なども定期的に開催しておりますので、ご興味ある方は、ぜひご参加ください。 Catoクラウド イベント・セミナー情報 | よくあるご質問 | Cato Cloud ケイトクラウド - SCSK 定期的にCatoクラウドをご紹介するセミナーを開催しております。・2024年9月26日（木）Catoクラウド ハンズオンセミナー【札幌開催分】　～全国5都市開催（東京/大阪/名古屋/博多/札幌）～　... cato-scsk.dga.jp SASEセミナー、Catoクラウドセミナー以外に、Catoクラウドの お客様導入事例 の制作、 FAQサイト 運営、この TechHarmony（技術ブログ）で、Catoクラウドの日本語のお役立ちサイトを目指し、Catoクラウド、SASEの認知度向上と、皆様のお役に立てればと考えております。 Catoクラウドに少しでも興味をお持ちになられた方は、ぜひ当社まで お問い合わせ ください。 Catoクラウド エンジニアブログまとめ記事 Catoクラウドのエンジニアブログ（TechHarmony）でのまとめ記事となります。 blog.usize-tech.com 2024.02.27

Catoクラウドの3つのファイアウォール機能の一つ、「LAN Firewall」の設定方法の紹介記事です。 2025年7月の機能リニューアルに準拠した操作方法、注意事項を説明いたします。 はじめに：LAN Firewallとは？ Catoクラウドは、以下の通り3種類のファイアウォール機能を有しています。 名称 役割 Internet Firewall Catoのネットワークを経由してインターネットへ接続する際のアクセス制御 WAN Firewall Catoのネットワークを経由する、拠点内リソースへのアクセス制御 LAN Firewall Catoのネットワークを 経由しない 、Socket経由での拠点配下の通信の制御 上記の通り、LAN Firewallは「Catoのプライベートバックボーンを経由させない」 挙動をとることができるという特徴があります。 CatoのSocketはVLANの管理用機能も有しているため、 部門や機能ごとにセグメントを分けて、各セグメント間の通信は拒否させる サーバ用セグメントに存在する特定のサーバだけは接続可能とする といった、拠点内の通信制御としてよく見られる機能をCatoクラウドで完結させることが可能です。 LAN Firewall自体は従来からCatoの一機能として存在していましたが、 本機能は2025年7月に大規模なリニューアルが実施されました。 従来のLAN Firewallを設定していた場合、Catoによる設定の自動移行が実施されます 。 移行後は本記事の記載にあるような形で設定の確認・変更を行うことになるのでご注意ください。 LAN Firewallの設定 設定画面と2つの「Rule」 従来、LAN Firewallの設定は各Sitesの設定画面から個別に管理する必要がありました。 2025年7月のアップデートにより、LAN Firewallの設定は[Security] > [Firewall]配下に移動されました。 3種類のファイアウォールがメニュー上で並ぶようになり、直感的にわかりやすい配置となりました！ LAN Firewallには、異なる役割を持つ2つのルールが存在します。 それぞれの設定方法について、以降のセクションにて説明していきます。 名称 役割 Network Rule 「どの通信をLAN Firewallでの制御対象とするか」を設定するルールです。 このルールで定義されていない通信は、WAN Firewallの適用対象になります。 Security Rule 条件に応じて通信の許可/ブロックを指定するルールです。 一般的にイメージされるファイアウォールのルールがこちらです。 「Network Rule」の配下に配置され、 親にあたる「Network Rule」の条件を満たす通信にのみ適用 されます。   Network Ruleの作成 リニューアルされたLAN Firewallですが、従来通り「暗黙のWAN転送」の仕様が採用されています。 つまり、 「LAN経由」とルールで指定されていない通信は全てCato PoPへ転送され、他のSite宛の通信と同様にWAN Firewallを経由してから元のSiteへ再転送 という挙動をとることになります。 この、「どの通信はWANを経由させないか」を指定するルールが「Network Rule」です。 [Security] > [Firewall] > [LAN Firewall]にて、 [LAN Firewall]タブの「New > New LAN Network Rule」を選択すると新規作成が可能です。 項目名 役割 General ルールの名前や配置位置、適用する通信方向を定義します。 他のファイアウォールと同様のものです。 Site 適用対象とするSiteを指定します。デフォルトだと「Any」となっていますが、 デフォルトのままだと文字通り「全てのSite」に適用 されてしまいます。 例えば、VLAN IDを用いて通信を制御するルールを作成したとして、 同名のVLAN IDを使用するSiteすべてに適用されることになります。 適用したくない拠点にまで適用されるリスクがあるため、極力 対象を絞るほうが安全 でしょう。 Source 適用対象とする通信の「接続元」を指定します。 固定のIPアドレスやIPレンジ、VLAN、Network Interface等を指定可能です。 従来通りに個別のSiteで作成したVLAN/サブネットを対象とする場合は、 「Site Network Subnet」から選択することとなるでしょう。         Internet FirewallやWAN Firewallとは異なり、 ユーザ・ユーザグループでの指定はできない 点に注意が必要です。 Destination 適用対象とする通信の「接続先」を指定します。 指定方法は「Source」同様です。 Service/Port 対象とする通信を、HTTP等のプロトコル、または宛先ポートで絞ることが可能です。 後程作成する「LAN Firewall Rule」で指定する形としても問題ありません。 適用対象をより確実に絞り込みたい場合は、こちらで指定すると良いかもしれません。 NAT 行きの通信について、NATを適用して接続元IPアドレスを固定することが可能です。 Transport 適用対象を、LAN経由（PoPを通さない）またはWAN経由（PoPを通す）とするよう指定します。 基本的に、LAN Firewallを使う以上は「LAN」とすることが多いでしょう。 「WAN」を指定した場合、PoPを経由させることは継続しつつ WAN Firewallよりも優先度の高い制御としてLAN Firewallを適用することになります。 設定を作成し「Save」をクリックすれば、新しいNetwork Ruleが作成されたことを確認できます。 作成直後のPublishは厳禁 作成されたNetwork Ruleには、 デフォルトで「Block Any」が付与 されます。 つまり、Network Ruleを作成した直後にそのままPublishしてしまった場合、 条件を満たす経路の通信が全てBlockされる 事態が発生します。 必ず、次セクションの「Security Rule」を設定してからPublishしましょう。 Security Ruleの作成 Network Ruleで指定した対象の通信について、具体的な制御を行うのがSecurity Ruleです。 最低でも1つ「Allow」とするSecurity Ruleを設定しなければ、 Network Ruleで指定された対象の通信は 全て、暗黙のBlockの対象 とされてしまいます。 定義漏れが無いよう注意しましょう。 [Security] > [Firewall] > [LAN Firewall]にて、 [LAN Firewall]タブの「New > New LAN Firewall Rule」を選択すると新規作成が可能です。 項目名 役割 General ルールの名前や配置位置、適用する通信方向を定義します。 基本的に他のファイアウォールと同様ですが、 「どのNetwork Ruleに紐づけるか」を明示する必要がある という独自の特徴があります。 Source 適用対象とする通信の「接続元」を指定します。 固定のIPアドレスやIPレンジ、VLAN、Network Interface等を指定可能です。 従来通りに個別のSiteで作成したVLAN/サブネットを対象とする場合は、 「Site Network Subnet」から選択することとなるでしょう。         Internet FirewallやWAN Firewallとは異なり、 ユーザ・ユーザグループでの指定はできない 点に注意が必要です。 基本的にLAN Network Ruleの同名の項目とほぼ同じですが、 LAN Firewall Ruleの場合、ここでSiteを指定することも可能です。 Destination 適用対象とする通信の「接続先」を指定します。 指定方法は「Source」同様です。 App/Category 後述する「Layer 7設定」を有効化しているSiteに限り使用可能な項目 です。 ※有効化されていない状態で設定した場合、正常に動作しない場合があるとされています。         対象とするアプリケーションを指定できます。 例えば、「TeamViewerからのアクセスのみ許可」「Microsoft関連アプリの通信は許可」 といった従来のポート指定では困難であった設定が可能です。 Service/Port 対象とする通信を、HTTP等のプロトコル、または宛先ポートで絞ることが可能です。 例えば「HTTPアクセスは許可」「RDPやSSHは不許可」といったルールの作成に利用します。 Action 許可/不許可を設定します。 当該ルールにHitした場合の、イベント生成/メール通知の有無も指定可能です。 イベント生成については、トラブル時の確認のため原則有効とすることを推奨します。 設定を作成し「Save」をクリックすれば、新しいSecurity Ruleが作成されます。 Security Ruleは、対応するNetwork Ruleの配下に存在することが確認できるでしょう。 LAN Firewallは、以下の順序で動作します。 １．通信が、作成済の「LAN Network Rule」に該当するかどうかを上から順に確認 ２． 該当した場合のみ 、当該Network Ruleに紐づけられた「LAN Firewall Rule」を 上から順に確認。いずれにも該当しなければ「Block Any」を適用 ３．いずれの「LAN Network Rule」にも該当しなかった場合、 「Default send to cloud」が適用され、PoPへ転送。WAN Firewallを適用 このため、「LAN Firewall Rule」を本来と異なる「LAN Network Rule」へ 紐づけた場合、上記の「１．」の段階でスキップされてしまう可能性がございます。 適切な設定がなされたことを確認してから、右上の「Publish」を実行しましょう。 Layer 7機能の概要、有効化手順 今回のリニューアルにおいて「Next Gen LAN Firewall」として大きくアピールされているのが、 Layer 7に対応した制御機能です。 具体的には、従来の仕様と比べて下記のような違いがあります。 従来のLAN Firewall：IPアドレス、TCP/UDP、ポートで制御を行う Next Gen LAN Firewall：上記の制御に加え、 アプリケーション層の内容を参照した制御 も可能 例えば、SMBによるファイル共有を許可する上で、セキュリティに優れるSMBv3のみを許可する、 Windowsのアプリケーション全般を識別し、それだけを許可する、等の制御が可能となります。 本機能は、 デフォルトでは無効 となっています。有効にした場合にSocketで実施する処理が増え、 スループットが低下するリスクが存在するためです。 無効であっても、従来通りのLAN Firewallとしては正常に機能します。 有効化したい場合、[Security] > [Firewall] > [LAN Firewall]にて、 [LAN Firewall Settings]タブへ移動します。 上記画面で「New」を選択することで、Site単位での有効化設定が可能です。 通信量の多いSiteは対象外とする、テスト用の拠点でのみ有効にする、といった処置も行えます。   終わりに 従来よりInternet FirewallやWAN Firewallとは異なる操作方法であったLAN Firewallですが、 今回のリニューアルで大規模な変更が加えられました。 うまく使いこなせば、CatoのPoPへと向かう通信を減らし、 通信帯域を一定程度削減するといった効果を得られる場合もあります。 本記事も参考にしつつ、ぜひ活用を検討してください。

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

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

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

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

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

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

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