こんにちは、広野です。 RAG をつくるにはチャンキング戦略が大事！と当社若手エンジニアの野口さんに熱く語られまして。 ニーズが多いであろう、CSV データからの検索精度向上を目指してみました。本記事はアーキテクチャ編で、続編記事で実装編の公開を予定しています。 やりたいこと (前置き) 以下のような架空のヘルプデスク問い合わせ履歴データ (CSV) を用意しました。 ヘルプデスク担当者が、新たな問い合わせを受けたときに似たような過去の対応を引き当てられるようにしたい、というのが目的です。   参考記事 当社エンジニア野口さんの記事。本件の実現にあたり、相談させて頂きました。ありがとう！ （シリーズ1：RAGの基本情報 / 第2回）チャンキング（チャンク化）とは：戦略の全体像、サイズ/オーバーラップ設計、失敗パターンと検証デモ RAGで「検索は当たるのに回答が噛み合わない」原因はチャンキング設計にあることが多い。本記事ではchunk size/overlapの勘所、代表6戦略＋発展2、LangChain×Vertex AI（Gemini Embedding）デモで検証方法まで整理。 blog.usize-tech.com 2026.02.09   以前、私が公開した Amazon Bedrock Knowledge Bases や Amazon S3 Vectors を使用した RAG 基盤の記事。今回はこの基盤のチャンキング戦略をカスタマイズして臨みました。 React で Amazon Bedrock Knowledge Bases ベースの簡易 RAG チャットボットをつくる [2026年1月版] アーキテクチャ概要編 AWS re:Invent 2025 で、Amazon S3 Vectors が GA されました。それを受けて、以前作成した RAG チャットボットをアレンジしてみました。 blog.usize-tech.com 2026.01.06   本記事の言及範囲 RAG そのものや、RAG 基盤については本記事では語りません。 以下のアーキテクチャ図の中の、赤枠の部分に着目します。ベクトルデータを格納するまでの、データソースのチャンキングをどう設計、実装するかです。   やりたいこと (再掲) 以下の CSV データを読み込ませて、似たような対応を引き当てたいと前置きで申し上げました。 もう少しやりたいことをブレークダウンします。 LLM に、今届いた新しい問い合わせに対する回答案を提案させたい。 回答案を生成するために、自然言語で書かれた問い合わせ内容と回答内容から、意味的に近いデータを引き当てたい。 カテゴリで検索対象をフィルタしたい。その方が精度が上がるケースがあると考えられる。 LLM が回答案を提案するときには、参考にした過去対応履歴がどの問合せ番号のものか、提示させたい。その問合せ番号をキーに、生の対応履歴データを参照できるようにしたい。 以下の前提があります。 データソースとなる CSV ファイルは 1つのみ。過去の対応履歴は 1 つの CSV ファイルに収まっているということ。 つまり、データの1行が1件の問い合わせであり、その項目間には意味的なつながりがある。 まあ、ごくごく一般的なニーズではないかと思います。 アーキテクチャ 実現するために、どんなアーキテクチャにするべきか。 1行の中にある各項目は意味的なつながりがあり、これらをチャンク分けしてしまうと意味的な関連性が切れてしまいます。そのため、 1行1チャンク にするのが適切だと考えられます。 チャンクを引き当てた後は、それに紐づく各データを参照したいので、メタデータを定義することが必要です。それがあれば、参考データとしてメタデータを持ってくることができます。また、メタデータを定義した項目については、その項目でフィルタすることができます。 なるべく安くてマネージドなサービスを使用したく、冒頭で紹介したアーキテクチャ図にあるように、Amazon Bedrock Knowledge Bases と Amazon S3 Vectors を使用します。  ここで課題が。 Amazon Bedrock Knowledge Bases のチャンキング戦略は組み込みでいくつか用意されているのですが、構造化データの「1行1チャンク」というパターンは存在しないのです。 ナレッジベースのコンテンツのチャンキングの仕組み - Amazon Bedrock Amazon Bedrock では、データを取り込むとき、データ検索を効率化するため、まずドキュメントやコンテンツを管理しやすいかたまり (チャンク) に分割します。それらのチャンクは埋め込みに変換され、分割前のドキュメントへのマッピングを... docs.aws.amazon.com   そのため、カスタムのチャンキング戦略を作成するしかなく、手段として AWS Lambda 関数で実装する機能が用意されています。 カスタム変換 Lambda 関数を使用してデータの取り込み方法を定義する - Amazon Bedrock カスタム変換の Lambda 関数を定義して、ナレッジベースの取り込みプロセスに独自のロジックを挿入できます。 docs.aws.amazon.com   実際その仕組みを作ってみて理解したのですが、以下のようなアーキテクチャになります。 図中の丸数字の説明で流れはだいたいご理解いただけると思うのですが、一応説明します。前提として、ドキュメント用 S3 バケットに CSV データが入っています。 Amazon Bedrock ナレッジベースの同期ボタンを押します。 ナレッジベースは、ドキュメント用 S3 バケットにある CSV データを取得します。 CSV データを、所定のフォーマットの JSON にして、中間成果物用 S3 バケットに保存します。JSON フォーマットは決まっていて、そこに取得した CSV データのテキストをそのまま格納する感じです。Amazon Bedrock ナレッジベースとしてのチャンク戦略は「なし」にする必要があります。チャンク分割せずデータまるごと、後続の Lambda 関数でチャンク分割する設計です。仕様ですが、中間成果物用 S3 バケットはドキュメント用 S3 バケットとは別にする必要があります。 Bedrock ナレッジベースは、保存した JSON データ (と言っても実質 CSV データ部分しか使用されない) を処理するため、チャンク分割用カスタム Lambda 関数を呼び出します。 Lambda 関数は、Bedrock ナレッジベースから渡された JSON データのバケットやキーを元に CSV 部分のデータを取得し、1行単位で1チャンクにし、さらにメタデータを付加した JSON データに加工して中間成果物用 S3 バケットに書き戻します。 Bedrock ナレッジベースが、Lambda 関数が作成してくれた加工後 JSON データをもとにベクトル化し、S3 Vectors に書き込みます。 チャンク分割された後のデータ構造 Lambda 関数がチャンク分割した後のデータ構造 (上のアーキテクチャ図では 5番の処理によって作成されるもの) は、以下のようにします。 { "fileContents": [ { "contentBody": "問合せ番号: AB01234569\n商品番号: SH001-01BL\n\n問合せ内容:\n[問合せ内容の文章]\n\n回答内容:\n[回答内容の文章]", "contentType": "TEXT", "contentMetadata": { "問合せ番号": "AB01234569", "販売形態": "代理店", "受付日時": "2026/2/23 12:59", "完了日時": "2026/2/23 13:39", "商品番号": "SH001-01BL", "カテゴリ": "家庭用収納棚", "ステータス": "完了" } }, { "contentBody": "問合せ番号: AB01234573\n商品番号: TB19541\n\n問合せ内容:\n[問合せ内容の文章]\n\n回答内容:\n[回答内容の文章]", "contentType": "TEXT", "contentMetadata": { "問合せ番号": "AB01234573", "販売形態": "直販", "受付日時": "2026/2/24 9:15", "完了日時": "2026/2/24 14:30", "商品番号": "TB19541", "カテゴリ": "家庭用テーブル", "ステータス": "完了" } } ] } fileContents 配列の各要素が 1 チャンク（CSV の 1 行に相当） contentBody がベクトル化・検索対象にできるテキスト contentMetadata が引用表示やフィルタリングに使用されるメタデータ ※contentBody ももちろん引用可能 contentBody、contentMetadata にどの項目を含めるかはデータや設計次第で変わりますが、データソースの CSV データをこのフォーマットに落とし込めれば勝ちです。 以降は、実装編の記事で詳細を説明いたします。   続編記事 続編記事を公開でき次第、こちらに掲載します。   まとめ いかがでしたでしょうか。 本記事が皆様のお役に立てれば幸いです。

SCSKの畑です。 先般のエントリ で予告していた通り、なぜ以下のような MySQL レプリケーション構成を取っているのかについて、幾つかの観点から説明していきたいと思います。   補足その1：レプリケーションフィルタ仕様の差異 まず真っ先に疑問として浮かぶであろう点は、何故 Aurora と RDS の間にわざわざ中継用レプリカとして EC2 上の MySQL を挟んでいるのかだと思います。以下のように直接 Aurora と RDS の間でレプリケーションを構成してしまえば 1 台インスタンスを減らせますし、レプリケーション構成としても AWS マネージドにできます。そして何より、先般のエントリで取り上げたような EC2 の AZ 障害を考慮する必要がなくなります。 正直メリットしかない、というか当初は私自身もこの構成にできないかを考えていたくらいなのですが、それができない理由が冒頭の構成図でも言及している「レプリケーションフィルタ」機能にあります。その名の通りレプリケーション対象のオブジェクトをフィルタリングするための機能で、以下の通りAWS のドキュメントに記載のある通り RDS や Aurora においても使用することができます。本構成ではテーブル単位のレプリケーションフィルタ（下記ドキュメントだと replicate-do-table に該当）を使用しています。 MySQL でのレプリケーションフィルターの設定 - Amazon Relational Database Service レプリケーションフィルターを使用して、リードレプリカでレプリケートするデータベースとテーブルを指定します。 docs.aws.amazon.com では何が問題なのかと言うと、MySQL オリジナルのバイナリと RDS/Aurora 間に、 レプリケーションフィルタのパラメータの文字数制限（仕様）の差異があること です。具体的には以下の通り、RDS/Aurora には MySQL オリジナルのバイナリにはない制限があります。そして、現行環境におけるレプリケーションフィルタの文字数が 2000 文字を超えている ため、上記構成を取ることはできませんでした。 MySQL オリジナルのバイナリ：明確な制限なし（よって MySQL 側の内部仕様に準ずる） 現行環境では 2000 文字以上のフィルタ設定が動作している状況 RDS/Aurora： 2000文字 もちろん、以下のような構成上の代替案はいくつか考えられるのですが、いずれもそれぞれ不可能な理由が明確であったため、最終的には EC2 上で MySQL オリジナルのバイナリを中継用レプリカとして立てる構成に決定しました。 EC2 の可用性 (99.9%) と RDS/Aurora の可用性 (99.95%/マルチ AZ 構成前提) の差異を許容できるかどうかや、EC2 の AZ 障害が発生した場合の復旧に期間・工数を要するという観点もありましたが、それらのリスクを許容できる前提で今回の構成を選定しています。本格的な見直しは今後のモダナイゼーション（AWS へのシフト）で、ということですね。 RDS/Aurora の文字数制限に収まるようにフィルタリング要件を見直す 本案件における移行要件（非互換を極力排除して AWS に移行（リフト）すること）に適合しないため NG アプリケーション側の大幅な改修が必要でありそもそも現実的ではない レプリケーションフィルタを使用せず、全てのテーブルをレプリケーションするように変更 本案件における移行要件（非互換を極力排除して AWS に移行（リフト）すること）に適合しないため NG 論理的には可能だがレプリケーション遅延など性能への影響が大きい上、バイナリログの転送量が増えることでレプリケーション先データベースのストレージ使用量も合わせて増えてしまう データベース単位のレプリケーションフィルタ（replicate-do-db）とテーブル単位のレプリケーションフィルタを併用することで、後者の文字数を減らして制限に収まるようにする データベース単位のレプリケーションフィルタを使用できる対象がないため NG 正規表現が使用できるレプリケーションフィルタ（replicate-wild-do-table）を使用することで文字数制限に収まるようにする 実装自体は可能なものの、ルールがかなり複雑になってしまい運用上の支障が大きいため NG EC2 の代わりに RDS/Aurora を複数インスタンス立てた上で、それぞれのインスタンスごとにレプリケーションフィルタ設定を分割することで文字数を減らして制限に収まるようにする NG、理由は次項にて説明するので割愛 なお、他のソリューションとして DMS の採用についても一応検討されましたが、DMS の主用途はあくまでもデータベース移行であるため、今回のような純粋なデータレプリケーション目的に使用するには適さないという結論になりました。DMS にも各種制約・条件がある以上、基本的にはデータベースのレプリケーション機能を使用することをまず検討すべきです。   補足その2：大元のソースが同じ DB のマルチソースレプリケーション構成における弊害 さて、前項目でもったいぶって割愛した構成案ですが、図にすると以下の通りとなります。言葉で説明するとややこしいのですが、要はRDS/Aurora を複数台立ててレプリケーションフィルタ対象のテーブルをそれぞれ分割することで、RDS/Aurora のレプリケーションフィルタの文字数制限に収まるようにするのが狙いです。（図では RDS ですがこの構成であれば Aurora でもいけるはず） 現行のレプリケーションフィルタ設定を維持しつつ、中継用レプリカに RDS/Aurora を採用できる現実的な構成案としてはおそらく唯一です。RDS が 2 台構成となることに伴うコストの増大や、2 台が直列構成となる以上稼働率への影響は避けられませんが、EC2 の AZ 障害を考慮する必要がなくなるメリット自体も大きいと考え手元で検証していました。その結果、運用管理上問題になるであろう挙動が判明したためお蔵入りになってしまいました。 具体的には、上流の Aurora で一部の DDL（CREATE DATABASE 文など）を実行した際に、 上記構成図の 中継用レプリカ_1 と 中継用レプリカ_2 両方から同一の DDL 文が下流の RDS に同期されてしまい、更新の競合が発生することで片側のレプリケーションが停止してしまう という挙動です。手元での検証結果となりますが、対象となる DDL 文は以下の通りです。 CREATE/ALTER/DROP DATABASE 文 CREATE/ALTER/DROP EVENT 文 CREATE/ALTER/DROP FUNCTION 文 CREATE/ALTER/DROP PROCEDURE 文 上記 4 つの内、CREATE DATABASE 文以外の 3 つについてはスキーマ（MySQL においてはデータベースと同義）にオブジェクトが紐つくため、上記構成図における レプリケーションフィルタ_1 と レプリケーションフィルタ_2 の対象スキーマが異なる場合、本事象は発生しません。しかし、残念ながら本構成においては単一スキーマにおけるレプリケーション対象のテーブルだけで文字数制限（2000 文字）を超過してしまうため対象となります。そして、CREATE DATABASE 文はサーバレベルのオペレーションとなるため問答無用で競合してしまいます。 EVENT/FUNCTION/PROCEDURE の 3 つについては、CREATE 文に IF NOT EXIST 句、DROP 文に IF EXIST 句を付けて実行することで競合を回避できます。対象オブジェクトが存在しない（存在する）場合にのみ作成（削除）されるような挙動となるためです。その上で ALTER 文は使用せず、変更が必要な時は再作成（DROP ⇒ CREATE）するようにすれば、一応運用で本事象を回避することは可能です。 ただ、実運用においてこの回避策を間違えずに実施できるか（間違えると即本番障害）のハードルが高い上、 DATABASE については明確な回避策がないため（実質的に DATABASE 関連の DDL 文を実行しない以外の選択肢がない）さすがに運用上厳しいという結論になりました。 なお、本事象はテーブル単位のレプリケーションフィルタ（replicate-do-db）を使用している環境で発生します。他のレプリケーションフィルタ（replicate-do-db）の場合だと挙動が異なりますが、詳細は割愛します。。   補足その3：Aurora MySQL と RDS for MySQL のレプリケーション機能差異 ということで EC2 周りの構成についての言及は一段落なのですが、下流の RDS についても疑問を持たれるケースもあるかと思います。上流は Aurora にしているのになぜ？という疑問ですね。 この疑問に対する回答はシンプルで、 Aurora はマルチソースレプリケーションをサポートしていない からです。具体的には以下のように、他のデータベースとのレプリケーションも構成しているため必然的に RDS を選択する必要があるということです。逆に言うと、もし Aurora がマルチソースレプリケーションをサポートしていた場合は、下流でもそのまま Aurora を使用していたと思います。 補足その2の構成案において先にしれっとマルチソースレプリケーション構成を示しちゃってましたが、もちろんこのパターンでも下流の RDS を Aurora に変更することはできません。 なお、AWS のドキュメントをざっと見る限りは明記されてはいないのですができるとも書いていない上、現時点では RDS でマルチソースレプリケーションを構成する際に使用するプロシージャが Aurora では提供されていないので確かだと思います。どっかに書いてあった気がするんですけども・・ Amazon RDS for MySQL のマルチソースレプリケーションの設定 - Amazon Relational Database Service RDS for MySQL でマルチソースレプリケーションを設定および管理する方法について説明します。 docs.aws.amazon.com   まとめ レプリケーションフィルタの仕様差異については最初知らなかったのですが、正直この差異によりある意味冗長な構成を組まないといけないというのはちょっとモヤモヤしてしまうところはあります。Aurora MySQL ならまだ分かるのですが、RDS for MySQL は Aurora との相対的なサービスの位置付けを考えると、MySQL オリジナルとより互換性のある仕様であって欲しかったところです。 当初は小ネタのつもりでしたが当時あれこれ検討していたためか筆が乗ってしまい思ったより長くなってしまいました。次回のデータベース関連のトピックこそ、ちゃんと小ネタになると思います。。 本記事がどなたかの役に立てば幸いです。

こんにちは、青木です。 今回はお客様とGoogle CloudでGeminiを利用したアプリ開発を経験したので、その感想を書いていこうと思います。 難しいことは行っていないですが、コーディングの知識がない自分でもAIを用いることでアプリ開発が思ったよりも簡単にできたので興味がある方はぜひご一読ください。   勉強会の内容 今回の勉強会ですが、1日目にGoogle Cloudのハンズオン、2日目、3日目で既存のアプリを改善する課題、成果発表を行う流れでした。 ハンズオンの内容をもとに課題を実施しているため、今回はハンズオンの内容は省略します。 勉強会の課題 今回の課題は「会議情報から会議調整AIアプリ」を作成するという課題でした。 （他のチームは「スキルマップ作成AIアプリ」が課題となっていました） 課題となっているアプリは以下になります。 （運営の方が課題で作ったアプリもGeminiで作成したよとのことでした） ■課題のアプリ ■アプリの動き Cloud Storageにカレンダーアプリからエクスポートしたcsvやicsファイルを格納し、内容を読み取ってGeminiが考えて空き時間を返す ■システム構成 実際の開発 「実装したい内容、改善したい内容の整理→Gemini CLIにプロンプトを投げる→Geminiがhtmlやpythonのファイルを書き換える」サイクルを行うことで結果としてアジャイル開発っぽく機能を追加、改善していきました。 また、エラーが発生してもGeminiに聞けばGeminiに自身が修正をしてくれるので、エラー対応も時間がかからず楽にすることができました。 ■Gemini CLI ■変更後のアプリ Geminiにお願いして、ファイルアップロード、アップロードしたファイルの削除、 検索期間を追加してもらいました。   開発を通して気づいたこと 今回はGeminiに任せっきりで開発をしてみて簡単にアプリ開発ができることはわかりましたが、以下のことにも気づきました。 空き時間をGeminiに検索をしてもらっていたが、検索に時間がかかっていたため、Pythonでロジックを組んで検索した方が効率的ではと疑問が残った。 Geminiにコーディングしてもらっていたので、実際にどんな処理を変更したのか、どんな処理がされているのかわからない状態で開発を進めていた。 ⇒ コーディングの知識がないと、ベストな選択肢、実際のコードの内容がわからないため、 　AIにコーディングは任せても最低限のコーディングの知識を持っていないと業務に活用できない 要件整理をして、その結果をGeminiにプロンプトとして投げることで開発が行われる ⇒ 要件整理と開発工程の境目が曖昧になり、ウォーターフォールの気持ちで実施はしているがアジャイル開発っぽくなる   感想 今回は最終発表を含め2日間という限られた時間でしたが、Geminiの力を借りることで、自力でコーディングするよりも遥かに多くの機能を実装できることを経験できました。 ただ、開発を進める中で、AIの提案を鵜呑みにすることの危うさを感じました。コーディングの知識が不十分だと、AIが生成したコードの中身が理解できないまま修正を繰り返してしまい、気づけば自分のコントロールを離れたプログラムが出来上がってしまいます。 ツールに「流される」のではなく、AIが提示したコードを自ら解釈し、良し悪しを判断できる基礎知識が不可欠だと強く学びました。 皆様もAIを活用する際は、その便利さに身を任せきりにせず、「なぜこのコードが動くのか」を自問自答しながら、自分の頭で理解することを忘れないでください。 最後までよんでいただきありがとうございます。 おまけ 今回の課題でほかに実装したかった機能や改善点を紹介します。 プロンプト指示内容を英語化することでプロンプトの精度を向上 →空き時間の検索が日本語だったため、英語にすることで精度が向上できたのかなーと考えてます 予定が更新された場合のリアルタイム同期（ファイルアップロードを使用しないインプット方法） →実際の現場ではわざわざファイルをエクスポートすることはないので、直接GoogleカレンダーやOutlookと連携できたらなーと考えています 作業などの打合せ以外の予定を内容を見て判定（件名に【調整可】の記載がある） →人によっては自分のタスクや調整可能な予定が入っていることもあるので、その時間の調整も提案してくれたらいいなーと考えています

SCSKの伊吹です。 今回はServiceNowの変更管理の違いについて触れてみたいと思います。 ServiceNow上での変更管理の種類 ServiceNowではITILの考えに沿って「通常変更（Normal Change）」、「緊急変更（Emergency Change）」、「標準的な変更（Standard Change）」の3種類の変更管理が定義されています。 それぞれの特徴については下記の通りです。 1. 通常変更 内容：リスクや影響を評価し、承認プロセスを経て実施される一般的な変更。 事例：ソフトウェアのアップグレード、新機能の追加など。 承認関連：変更依頼ごとに評価・承認が必要。CAB（Change Advisory Board）による承認が行われることがある。 2. 緊急変更 内容：ビジネス上重大な障害やセキュリティ問題等、迅速な対応が求められる変更。 事例：本番環境の障害対応、セキュリティパッチ適用など。 承認関連：通常の承認プロセスを簡略化し、Emergency CAB（ECAB）などによる承認が迅速に行われる。 3. 標準的な変更 内容：リスクが低く、頻繁に発生し、手順が明確で事前承認済みの変更。 事例：ユーザーアカウントの作成、デバイスのリセットなど。 承認関連：事前に認められた手順があるため、都度の承認は不要。 ServiceNow上でのステータスの遷移 変更管理レコードを作成したあとは運用に沿ってステータスが遷移していきます。 表は変更管理のステータスなどの情報をまとめたものになります。 表の右側を見て頂くと変更の種類によってステータスの遷移の流れが違うことがわかります。 これはそれぞれの変更管理の緊急性や事前承認によるものです。 ・通常変更の場合は、新規から完了(もしくはキャンセル)まで番号順にステータスが遷移します。 ・緊急変更の場合は、急いで復旧対応などを行うため「評価」ステータスを飛ばします。 ・標準的な変更の場合は、手順が明確で事前承認済みのため「評価」「許可」ステータスを飛ばします。   まとめ 変更管理の違いについて紹介しました。 ServiceNowには3種類の変更管理が定義されており、内容に応じてステータスの遷移も変わります。 用途・要件に合わせて適切なものを利用して下さい。

渾身の提案資料をメールで送った後、返信を待ちながら「本当に読まれているのかな？」と不安になったことはありませんか？ 従来のPDF添付による営業では、開封されたか、どのページに興味を持たれたかは神のみぞ知る「ブラックボックス」でした。 本記事でご紹介するDropboxの「DocSend」は、そんな資料送付を「運任せ」から「データ駆動型」へとアップデートするツールです。相手の関心を可視化し、無駄を減らして成約率を最大化する――。 本稿では、閲覧状況のリアルタイム把握から、データに基づいたフォローアップのタイミングまで、明日から現場で使える「戦略的活用法」を具体的に紹介します。 ※操作方法の基本については こちらの記事 をご覧ください。本記事では一歩踏み込んだ「実践的な使いこなし術」をお届けします。 DocSendが営業プロセスをどう変えるのか？（主な機能） • 閲覧データの可視化 誰が、いつ、どのページを何秒見たかまで把握可能です。（特定のページで離脱していれば、そこがボトルネック） DocSend にはダッシュボード（下図）が用意されており、直近のアクセス状況を一目で把握することができます。     さらにダッシュボードの各項目から詳細な分析へ遷移して確認することが可能です。 下図のように、デバイスの種類や、どこからアクセスしてきたのか、そして各ページに留まっていた時間が分かります。   • リア ルタイム通知 顧客が資料を開いた瞬間に営業担当者に通知を届けることが可能です。 • 状況に応じたアクセス権設定 不特定多数に送りたい情報、特定の人にだけ共有したい情報、特定の企業内なら共有可にしたい情報など柔軟に設定が可能です。　 • 最新版への資料アップデート 送信済みのURLはそのままで、中身の資料だけを最新版に差し替えすることが可能です。   【実践】データから読み解く「次の一手」の打ち方 • ケースA：熱度の高い顧客を見極める 複数回閲覧している、または社内で転送されている形跡（視聴デバイス増）があれば、決裁ルートに乗っている可能性も考えられます。 即座に電話や追加提案をしましょう。 • ケースB：関心が薄い箇所を特定する 特定の導入事例ページが読み飛ばされているなら、その事例は顧客に刺さっていないのかも。 該当ページのコンテンツを見直しましょう。 • ケースC：離脱ポイントを改善する 「費用」のページで全員が離脱しているなら、価格設定や説明の順序に課題がある可能性があります。 再検討しましょう。   セキュリティと管理：営業効率を落とさないガバナンス • パスワード保護と閲覧制限 – 不特定多数の人に見ていただきたいチラシ – A社向けの提案資料 – 個人との契約情報 など、情報を共有したい相手に応じて柔軟なアクセス権設定が可能です。 不特定多数に配布した場合も、閲覧時のメールアドレス入力/確認を有効化することで、誰が閲覧したかが判別できますので、その人にコンタクトをとることも可能になります。 また、必要に応じてパスワード設定を有効化することで、リンク情報が分かっていてもパスワードを知らないと閲覧ができないようにすることも可能です。 • NDA締結との連携 – A社に提案依頼をする前に機密保持契約を締結したい – 情報開示するにあたり、機密保持契約を締結したい など、情報共有したい相手に事前に機密保持契約（NDA）を求めることが可能です。 • 「バーチャルデータルーム」 – 取引先ごとにまとめたい共有資料 – 製品・サービスごとにまとめたい資料 – カテゴリー単位にまとめたい資料 など、まとめたい単位で「バーチャルデータルーム」を作成し、ひとまとめにした共有リンクを作成することも可能です。 ファイルを追加、更新しても共有リンクはそのまま利用可能ですので、取引先にURLを再送付することも不要です。   クラウドストレージサービスとの連携 DocSendは、「共有」に特化したサービスとなっています。共有する元ファイルはPCやクラウドストレージなどから集めてきて（DocSendにコピーするイメージ）、それを共有するものになります。 共有するリンクを生成することができるクラウドストレージサービスであれば、ファイルの実態をDocSend側にコピーせずにリンクを使った共有設定も可能となります。（この場合は、リンクのURLをアクセス時にクラウドストレージ側で設定されているアクセス権が適用されます。DocSendで設定したアクセス権+クラウドストレージでのアクセス権） 以下のクラウドストレージサービスと連携する（直接ファイルを取り込む）ことが可能です。 ・Dropbox ・Google Drive ・Box ・OneDrive ・SharePoint また、Dropboxであれば、共有したファイルをDropbox側で更新すると、その変更を自動同期してDocSend上のコピーに反映することも可能です。 営業DXの第一歩：明日から実践する「DocSend 3ステップ導入術」 「DX（デジタルトランスフォーメーション）」と聞くと難しく感じますが、まずは「メールの添付ファイルをURLに変えるだけ」からスタートしましょう。 STEP 1： 「鉄板の営業資料」を1つだけ選んでアップロードする まずは全ての資料をデジタル化しようとせず、最も頻繁に使う「会社紹介資料」 や 「最新の事例集」を1つだけDocSendにアップロードしてください。 ポイント： PDFとして送っていたものを、DocSendのリンク（URL）に置き換える準備をするだけです。これだけで「資料を見ていただけたのだろうか？」の心配がなくなります。また、「最新版への差し替え」がいつでも可能になります。 STEP 2： 特定の顧客専用の「パーソナライズド・リンク」を発行する 明日送る予定のメールで、早速実践します。汎用的なリンクではなく、「特定の顧客専用リンク」を作成して送りましょう。 DocSendでは、一つのコンテンツに対して複数の共有リンクを生成できます。「A社様リンク」を作成しておけばA社の方がアクセスされたことが簡単に識別できます。 なぜやるか： 誰が資料を開いたかが特定できるため、後でデータを見た時に「A社の担当者様が、今まさに3回目を見ている！」という確信を持てるようになります。 STEP 3： 「通知が来た瞬間」に、次のアクションを決める 資料がクリックされると、手元にリアルタイムで通知が届きます。ここからがデータ駆動型営業の本番です。 即フォロー： 通知が届いて閲覧が終わった直後に、「資料の内容でご不明な点はございませんでしたか？」と連絡を入れてみてください。顧客の記憶が最も鮮明なタイミングでのアプローチは、驚くほど会話が弾みます。 中身の分析： 「料金ページで3分止まっていた」なら、予算の懸念があるはず。「導入事例をじっくり見ていた」なら、信頼性を求めているはず。次回の商談の「最初の1分」で話すべき内容が、データによって明確になります。 まとめ 「DocSend」は、単なるクラウドストレージでも、ファイル共有ツールでもありません。売上を作るための攻めのツールです。有効な潜在顧客の発掘から、顧客とのリレーションシップ強化に至るまで様々な場面で安全に、効率的に情報共有を実現できます。 「DocSend」で営業DXの一歩を踏み出してみませんか？ ご説明やデモのご依頼は下記のお問合せ先まで。   お問合せ： Dropbox-sale@scsk.jp SCSKのDropbox紹介サイト： https://www.scsk.jp/product/common/dropbox/index.html SCSKのDocSend紹介サイト： https://www.scsk.jp/product/common/dropbox/docsend.html

前回の記事「 Dropbox APIでデータ移行ツールを作ってみた (前編) 」では、データ移行で使用するDropbox APIエンドポイントとサンプルコードを紹介しました。弊社が開発したデータ移行ツールでは、upload_session系のエンドポイントを使ってファイルデータのアップロードを並列で処理するようにしています。 今回は、 実際 並列でファイルデータをアップロードするようにしたら、どれだけ効果があるのかを実際に開発したツールを使って検証しようと思います。また、並列化以外に工夫したポイントなども紹介したいと思います。 データ移行検証1 まずは、ファイルアップロードの並列度を変えると、移行時間がどれだけ短縮できるのか？という観点で検証してみましょう！ 検証方法と環境 ネットワーク回線速度 (ネットワーク回線速度計測サイトを使って計測): アップロード 130Mbps ダウンロード 150Mbps ファイルサイズ： 2 MiB /ファイル 転送ファイル数：10ファイル (合計 20MiBの転送) 検証パターン： 並列度：1, 2, 4, 10 (データアップロード・ワーカープロセス数) コミット(※)：並列度と同じに固定 ※ コミットとは、finish_batchでのメタデータ書込み対象ファイル数のことです 　 並列度1 のときは、メタデータも 1ファイルずつ書き込むという感じで。 検証組み合わせ： 並列度1 x コミット数1 並列度2 x コミット数2 並列度4 x コミット数4 並列度10 x コミット数10 検証1の結果と考察 表1：並列度の違いと移行速度 並列度1の場合、upload_session/start & append で1ファイル分のデータをアップロードし、その後 upload_session/finish_batch で 1ファイル分のメタデータの書込むというのを、10ファイル分繰り返しています。 一方、並列度10の場合、10ファイル分のデータを並列にアップロードし、1回で10ファイル分のメタデータを書き込みます。 表1を見ると、並列度1 から並列度2にすると、全体のアップロード時間が約 60% に短縮されています。 2並列でファイルをアップロードするからといって、アップロード時間が半分にはなりませんでした。 並列度を「4」にした場合、アップロード時間が 約50%になっています。並列度2の場合時間を40%削減できましたが、並列度4では並列化の効果は少なくなっています。並列度を「10」にした場合、全体のアップロード時間は並列度4とほぼ同じくらいで、並列度をぐんと上げた効果は余り出ていないような感じです。 表1の「1ファイルの平均移行速度」を見てください。並列度を上げると反比例して、1ファイルの平均移行速度が遅くなっていることがわかりますね。並列化は、データ送信処理を行うプロセスを複数作成し、各プロセスが同時並行でファイルアップロードを行うように実装されていますが、プロセス数がPCに搭載されているCPUのコア数以上に なると、各プロセスが本当の意味での同時進行ではなくなってしまいます。検証に利用したPCのコア数は 8 だったため、並列度10だとコア数を超過しており、処理速度の短縮にはならなかった可能性があります。他にも、ネットワークの帯域など外部要因の影響もあるでしょう。 この結果から、並列度を上げれば単純に比例してデータ移行時間が短くなるわけではないことがわかります。実際にデータ移行を行う際は、利用するPCやネットワーク環境などの影響を考慮し、事前検証して最適な並列度を調べる必要があります。弊社がお客様のデータ移行を行う際に必ずお客様環境での事前検証作業を行うのは、このためです。 参考記事: Dropboxへのデータ移行ってどうやるの？ データ移行検証2 次の検証では、もう少しデータ移行規模を大きくしてみたいと思います。検証1と同じファイルを利用しますが、ファイル数を増やして 合計 1GiB のデータ移行を実施したいと思います。 検証方法と環境 ネットワーク回線速度 (検証1と同じ): アップロード 130Mbps ダウンロード 150Mbps ファイルサイズ： 2MiB/ファイル (検証1と同じ) 転送ファイル数： 500 ファイル (合計 1 GiBの転送) 検証パターン： 並列度：1, 4, 10, 15 コミット数：50 (データ移行ツールのデフォルト値) 検証2の結果と考察 表2 検証2の結果 表2のとおり、1GiBのデータ移行時間は、並列度1の場合は約13分 (783秒)、並列度4の場合は 約4.4分、並列度10だと約3分となりました。 10ファイル(20MiB)の場合よりも移行したデータ量(ファイル数)が大きいので、並列度による移行時間の違いがはっきりでています。並列度10だと 並列度1と比較して 約4.5倍速くなっています。   一方、並列度10と並列度15では、並列度15の方が遅くなっています。これは、並列度15の場合Dropboxへのデータアップロード処理で一時的なエラーが発生したことが影響していると思われます。データ移行ツールでは、一時的なエラーが発生すると少し時間を空けてから再アップロードするように実装しているため、全体的な処理時間が伸びてしまったようです。   最も速度が早かった、並列度10の結果を元に１TBのデータを移行するのみかかる時間や1ヶ月で移行可能なデータ量を計算してみると…. 　1TBのデータなら 50時間 ( 1GB 約3分 = 3 x 1,000 = 3,000分 = 50時間) 　1ヶ月で 約 14 TB　( 50時間/TB なので 30日 x 24時間 ÷ 50時間/TB ≒ 14.4 TB)   ネットワーク帯域に余裕があるなら、PC台数を増やし、それぞれ別フォルダを移行するようにすることで、1ヶ月で移行できるデータ量を増やすことも可能です。 アップロード時のエラーについて 並列度15の場合に、データアップロード時に発生したエラーは、「429 – Too many requests」というものです。Dropbox APIリファレンス・マニュアルによると、「このエラーは過去数分間に送信したリクエスト数が多すぎる」ことで発生するようです。これは、Dropbox社がDropboxを利用している全ユーザに平等にサービスを提供するという観点から、特定ユーザのリクエストばかり処理することを制限しているために発生するエラーです。エラーになる条件、閾値は非公開のため、アプリ側でこのエラーが発生しないように制御することは難しく、エラー発生時の処理をしっかり作っておく必要があります。   リファレンス・マニュアルには「Too many requests」のエラーが発生した場合は、エラーレスポンスに含まれる「Retry-Later」で指定されている秒数間待ったあと、リクエストを再送するようにと書かれています。弊社のデータ移行ツールでは、「Too many requests」エラーのエラーエスポンスを解析し、Retry-Laterで指定された秒数間、sleepし、再アップロードを試みるように設計しています。このようにすれば、データ移行の確実性はアップしますが、sleep時間が発生することで全体の処理時間は延びてしまいます。移行処理時間を単純に短くするだけなら、エラー時はそのファイルの移行を諦め、次に処理を進めるという方法もアリですね。   並列度を高くした結果、Too many requests エラーが多発するような状況になると、待機時間が増え、移行時間がどんどん延びてしまいます。Too many requestsエラーが発生したことを、他のプロセスに知らせるような作りにはなっていないため、最悪すべてのプロセスがToo many requestsエラーになってしまい、全体のアップロードがしばらく進まなくなる可能性もあります。したがって、このエラーが発生しない程度の並列度を探るというのが、重要となってきます。   今回の検証では、やや大きめのファイルサイズとなる 2MiB のものを使っていましたが、テキストファイルやMicrosoft Officeのファイルなど小さなファイルが中心の場合は、1ファイルの送信時間が短くなる分、リクエスト数が増えちゃいますので、Too many requestsエラーの確率が高くなることが予想されます。その場合は、並列度を下げるなどの工夫が必要かもしれません。移行データの平均ファイルサイズも、並列度を決めるパラメータになりそうですね。   移行ファイルサイズが大きい　=>　並列度 高 移行ファイルサイズが小さい　=>　並列度 低   データ移行ツールの開発秘話 「開発秘話」なんておおげさな見出しにしちゃいましたが、ここでは開発時に工夫したこととか、まだやりきれていないことととかをご紹介したいと思います。 差分移行機能とミラー機能 データ移行ツールの開発は、お客様のデータ移行を実施するためにツールが必要というのが出発点でした。   ファイルサーバからクラウドへのデータ移行は、ファイルサーバ間移行のような速度を出せないため、データ移行期間中もお客様にはファイルサーバのデータを使って通常業務を継続して頂く必要があります。このため、通常業務で発生したファイルの追加、更新、 削除を、移行先であるDropboxに反映する必要があります。この更新分を反映するために実施する再アップロード作業を「差分移行」と呼んでいます。   差分移行では、ファイルサーバとDropboxにアップロードし終わっているデータの「突き合せ」を行い、差分移行すべきファイル(下記の①～③)を検出するわけです。   ① ファイルサーバに新しく追加されたファイル ② ファイルサーバで更新されたファイル ③ ファイルサーバで削除されたファイル   ①の検出は、Dropboxに存在しないファイルを見つければOKです。初回移行で移行できなかったファイルも①としてアップロード対象になりますので、エラーリカバリもできて一石二鳥です。 ③の検出は、Dropboxだけに存在するファイルを見つけます。見つけたあと、Dropboxのファイルを削除すべきかどうかは、お客様データですので消す消さないは選択できたほうが良さそうです。 ②の更新されたファイルの検出は、いくつかのパターンが考えられます。 A. ファイルサイズが一致しない (ファイルを書換えたら、サイズが変わる) B. ファイル更新時間が異なる　(ファイルを書換えたら、更新時間が新しくなる) C. ファイルの中身が一致しない (ハッシュ値を計算し、比較する。Dropboxはファイル情報としてハッシュ値を持つ)   A.は、テキストファイルとかだと、一文字だけの書き換えではファイルサイズが変わらないこともあります。このため、ファイルサイズが同じだからといって移行対象外にするのは、ちょっとリスクが高そうです。   B.は、逆にファイルの中身は変わっていないのに、更新時間だけ新しくなるという可能性があります。差分移行は、できだけアップロードすべきデータ量を少なくし、短時間で終わらせたいので、ファイルデータが異なるものだけをアップロードするようにしたいですね。   と考えると、アップロード対象のファイルの検出は、ハッシュ値を比較するのが確実そうです。 Dropboxの場合、保存されているファイル一覧データを取得すると、その中に「content_hash」という計算されたハッシュ値が含まれます。また、このハッシュ値を計算する方法も公開されていますので、ファイルサーバ側のファイルデータのハッシュ値を計算し、content_hashの値と比較することでファイルの中身が一致するか、一致しないかを判断できます。弊社のデータ移行ツールでは、標準ではハッシュ値比較を行い、差分移行対象のファイルを決定するようにしています。   ただ、ハッシュ値を計算するには、一度ローカルファイルを読み込む時間が必要になるため、パフォーマンスはよくありません。なので、ファイル更新時間だけ見るオプションも用意しています。   そして、先程の③。Dropboxにしか存在しない　というのは実は、ふたつの可能性があります。 A. 初回移行後、ファイルサーバ側でファイルを削除したため、アップロード済みのファイルがDropboxに残ってる B. Dropboxに直接ファイルを作ってしまった (もともとファイルサーバには存在しないファイル)   A. なら機械的に削除しても問題なさそうですが、B. のファイルを削除しては問題となってしまう可能性があるため、機械的に「削除」するわけにもいきません。そこで、弊社のデータ移行ツールでは、標準では③の場合、ログに記録を残すだけでDropbox側のファイルは削除しません。オプションで、移行元と移行先が完全に一致する状態にする「ミラーモード」を用意し、ミラーモードを選択すると、Dropboxにしか存在しないファイルを「削除」するようにしています。   Pythonのマルチプロセス構成と移行ログ データ移行ツールでは、ファイルアップロード処理を並列化するために図1のように少し複雑なプロセス構成となっています。 図1　データ移行ツールのプロセス構成 メインプロセスが、移行元フォルダに保存されているファイルリストを読み出し、各ファイルアップロードプロセスに割り当てていきます。ミラーモードで移行している場合、Dropboxのみに存在するフォルダ/ファイルを削除する処理も並列化されています。他にファイルアップロードの結果をまとめ、指定されたコミット数分まとめてファイルメタデータをDropboxに書き込む処理も独立したプロセスとなっています。   複数プロセスで構成されているため、致命的エラーやユーザによる処理中止時など、動いているプロセスをきれいに終了するようにしています。   また、移行できたのか、できていないのかを確認できるようにするため、すべてのデータ移行結果をログファイルに記録する必要がありますが、複数プロセスから1つのログ・ファイルに書き込むことはできません。このため、各プロセスではログメッセージなどファイルに記録したいメッセージをメッセージキューを介して、ログ書込み専用プロセスに受け渡し、ログ書込み専用プロセスが順番にファイルに書き込むという仕組みを採用しています (図２)。 図2　ログメッセージの出力 ファイルアップロードプロセスはバイナリデータのアップロードが完了すると、アップロードしたデータのファイル情報をメッセージキューを介して、finish_batchプロセスに渡します。finish_batchプロセスは、キューから受け取ったファイル情報が指定された数分溜まると upload_session/finish_batchエンドポイントを使ってメタデータの書込みを行います。   ファイル名に利用できない文字が含まれたり、指定されたパスが正しくないなど、メタデータの書込み時にエラーとなる場合もあります。このため、finish_batchエンドポイントのレスポンスを確認し、成功、失敗をきちんとログに書き込むことが重要なポイントとなっています。 図3　メタデータの書込み おわりに 前回、今回とDropbox APIを駆使して開発したデータ移行ツールの仕組みなどを紹介しました。興味をもって読んで頂けたでしょうか？　今後もDropbox APIやDropboxのちょっとDeepな記事をご紹介していきたいと思います！   SCSKでは、お客様のご要件に合わせたDropbox APIツールの開発も行っております。Dropbox運用の効率化や棚卸しなどでツールがほしい！といったご要望があれば、是非 SCSKまでご遠絡頂けたらと思います   問合せ先: dropbox-sales@scsk.jp 弊社Dropbox紹介ページ: https://www.scsk.jp/product/common/dropbox/index.html

こんにちは、SCSKの坂木です。 ZabbixとPagerDutyを連携させると、障害発生時に電話で通知を受け取れるようになり非常に便利です。しかし、設定を間違えると「深夜にアラートが連発して、電話が鳴り止まない」という大変な事態になります。 今回は、 Zabbixから短期間に同じような障害通知が連続して発生した場合でも、PagerDuty側でそれらを「1つのインシデント」としてまとめ、電話通知を「1回」に抑える方法を解説・検証 します。   検証構成 今回の構成は以下の通りです。 [Zabbix] —-(Webhook)—-> [PagerDuty] —-(電話通知)—-> [運用担当者] ZabbixとPagerDutyの基本的な連携（Integration Keyの設定など）は完了している前提で進めます。 ZabbixとPagerDutyの基本的な連携は こちら に記載してますので、未設定の方は参考にしてください。   電話通知の設定 PagerDuty側で電話番号を登録します。 1. PagerDuty画面右上のアイコンから [My Profile] を選択。 2. [Contact Information] に電話番号を登録します。   3.  [Notification Rules] タブで以下のように、緊急度の高いインシデントのみ電話通知するよう設定します。 High Urgency（緊急度：高）: Email と 電話 Low Urgency（緊急度：低） : Emailのみ（電話は設定しない）   Service Orchestrationの設定 Zabbixから送られてきた全ての障害通知に対して電話通知すると、電話が鳴りやまないという状況になります。そのため、送られてくる障害情報に応じて緊急度を振り分け、電話通知するかしないかを判断する必要があります。 今回は 特定のホストからの通知であれば高い緊急度にして電話通知されるように設定 します。（前章で出てきた、High Urgencyに振り分けられるようにします） 1. 対象の Service を選択し、[Settings] タブを開きます。 2. [Service Orchestrations] セクションを探し、ルールを新規作成（New Rule）します。 ルールの設定内容 条件（Condition)     : event.source matches part ‘<対象のホスト名>’ 　 （今回は testhost でフィルタリング） アクション (Actions):　Set severity to error / critical  今回条件は1つですが、電話通知させたい条件を追加する場合は下の [＋] を押して複数の条件を設定できます。   それ以外（Fallback Behavior）の設定 「上記のルールに当てはまらないもの（＝重要じゃないホスト）」のアクションを以下のように設定します。 Alert Behavior: Set alert severity to warning / info   Assign and Notifyの設定 ここで対象Serviceの [Settings] タブにある [Assign and Notify] セクションを確認してください。 この設定により、ルールで判定された Severity: Critical/Error が High Urgency（電話通知） に 、 Severity: Warning/Info が Low Urgency（メール通知） に自動的に変換されます。   これで、 testhostからの障害通知は High Urgency 　 それ以外は Low Urgency 　という自動振り分けの仕組みが完成しました。   Alert Groupingの設定（Service Settings） 重要サーバの障害であっても、1分間に10回も電話がかかってきては対応できません。 そこで、 Zabbixから送られてくるアラートについて関連するものはまとめる設定 に変更します。 1. Zabbixを連携させている Service を開き、[Settings] タブをクリック。 2. [Reduce Noise] セクションにある [Automatically group alerts by similarities in alert summaries, historic alert patterns and 　　past merged alerts.] を選択し、後続の類似アラートを同一インシデントとしてまとめる期間を指定します。 (今回の検証では5分として設定しました。)   検証その１ それでは、実際に障害を発生させて挙動を確認します。 Zabbixサーバから、特定ホストの障害アラートを短期間で十数件送信します。   実行結果 ① スマホへの着信確認 携帯電話には、 1回だけ 自動音声の電話がかかってきました 。   ② PagerDuty上の表示確認 PagerDutyのインシデント一覧を確認すると、 作成されたインシデントは 1件だけ でした。   Zabbixから送った複数の障害通知をPagerDuty側でひとつに集約でき、電話回数も集約した1回のみ になることを確認しました。   Service Orchestrationの応用：アラートの「数」で緊急度を動的に変える ここでは、さらに一歩進んだ設定を行います。 特定のサーバ（testhost）からの通知は、普段はメールだけでいいけれど、短期間に大量のエラーを吐いた時だけは電話を鳴らしてほしい  という、「量」に応じた動的な通知コントロールを実現します。 これを実現するために、PagerDutyの Service Orchestration Rules を使用します。   手順①：対象ホストのSeverityを下げる（親ルール） 先ほど設定した特定のホスト（今回は testhost）からの通知を、Warning（電話を鳴らさない）設定にします。 条件（Condition)     : event.source matches part ‘<対象のホスト名>’ アクション (Actions): Set Severity to warning これで、testhost からのアラートは、通常時に「Low Urgency」として扱われ、メールのみ（電話なし）となります。   手順②：閾値を超えたらSeverityを上げる（子ルール） 次に、この親ルールの隣にある [+] ボタンを押し、子ルールを追加します。ここで「数」をカウントします。 今回は1分間で100件以上の通知があった場合に、critical（電話あり）となる設定とします。 条件（Condition)     : trigger_count over 1 minutes > 100 アクション (Actions): Set Severity to critical この設定により、 testhostからの通知であり（親ルール）、かつ、短時間で大量のアラートが来ている（子ルール）  場合のみ、強制的に緊急度が高（Critical）になり、電話が鳴るようになります。   検証その２ 実際に testhost からアラートを飛ばして挙動を確認します。   検証パターンA：電話なし まずは、testhost から障害通知を数十件送信します。 【結果】 PagerDutyの判定: Low 通知　　　　　　: メール通知のみ届きました 期待通りです。単発的なエラーや一時的な揺らぎであれば、担当者を叩き起こすことはありません。   検証パターンB：電話あり 次に、testhost から1分間以内に100件以上の障害通知を送信します。 【結果】 PagerDutyの判定: High 通知　　　　　　: 電話とメールの両方から通知が届きました   まとめ 今回の検証で、ZabbixとPagerDutyを組み合わせることで、大量のアラート通知を適切に制御できることが確認できました。 重要なポイントは以下の3点です。 Service Orchestration: ホスト名や発生頻度に応じて、電話通知の要否を自動で判断する。 Alert Grouping:  短期間に連続するアラートを1つのインシデントに集約し、電話通知回数を最小限に抑える。 Assign and Notify: SeverityとUrgencyを正しく連動させる設定を有効にする。 Zabbix側で複雑な通知条件を作り込むよりも、PagerDuty側で集約ルールを管理する方が、柔軟でメンテナンスも容易です。 担当者の負荷を軽減しつつ、重要な障害検知を確実に行う運用フローとして、ぜひ活用してみてください。   ▼ Zabbixに関するおすすめ記事 【Zabbix】UserParameterでスクリプト実行結果を監視する方法 ZabbixのUserParameter設定ガイド。独自の監視項目を追加する方法、引数を使ったコマンドの使い回し、system.runとの違いを具体例で紹介。監視業務を効率化したい方はぜひ。 blog.usize-tech.com 2025.11.06 【Zabbix】system.runでスクリプト実行結果を監視する方法 Zabbixのsystem.run設定方法をステップバイステップで解説。標準アイテムにないカスタム監視を実現するため、zabbix_agentd.confの修正、安全なAllowKeyの使い方、スクリプトの権限設定までを網羅。初心者でも安心のガイドです。 blog.usize-tech.com 2025.11.04   弊社ではZabbix関連サービスを展開しています。以下ページもご参照ください。 ★Zabbixの基礎をまとめたeBookを公開しております！★ Zabbix資料ダウンロード｜SCSK Plus サポート for Zabbix Zabbix監視構築に必要な知識と最新機能についての資料をダウンロードできるページです。世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします。 www.scsk.jp   ★SCSK Plus サポート for Zabbix★ SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします。 www.scsk.jp   ★SCSK Zabbixチャンネル★ SCSK Zabbixチャンネル SCSK Zabbixチャンネルでは、最新のZabbixトレンドや実際の導入事例を動画で解説。明日から使える実践的なノウハウを提供します。 今すぐチャンネル登録して、最新情報を受け取ろう！ www.youtube.com   ★X（旧Twitter）に、SCSK Zabbixアカウントを開設しました！★ https://x.com/SCSK_Zabbix x.com

TechHarmonyエンジニアブログでは、 AWS・Oracle Cloud・Azure・Google Cloud 各分野の受賞者 にフォーカスし、インタビューを通してこれまでの経歴や他の受賞者に聞いてみたいことをつないでいく「 リレーインタビュー 」をお届けしています。 第3弾は、「2025 Japan AWS Top Engineers」 を受賞された 寺内 康之（てらうち やすゆき）さん。 Japan AWS Top Engineers は、特定の AWS 認定資格を持ち、AWS ビジネス拡大につながる技術力を発揮した活動を行っている方、または技術力を発揮した重要な活動や成果がある方が選出されるプログラムです。 日々どのようにAWSと向き合い、どんな経験を積み重ねてきたのか。 そして、受賞に至るまでの背景には、どのようなキャリアストーリーがあったのでしょうか。 本インタビューでは、寺内さんのこれまでの経歴やAWSへの向き合い方、さらに「次の受賞者へ聞いてみたいこと」まで、じっくりとお話を伺いました。 プロフィール 2025 Japan AWS Top Engineers   所属： ITインフラサービス事業グループ クラウドサービス事業本部 クラウドサービス第二部 氏名： 寺内　康之   【自己紹介】 2024年、2025年と続けてJapan AWS Top Engineers (Service) に選出されました。今現在は、AWSの内製化を目指すお客様に対し、技術支援サービス「 テクニカルエスコート 」を提供するチームのリーダを担っています。 私は、小学生の頃にパソコン(PC-8001)に出会い、その後パソコン通信にハマり、大学ではUNIXの洗礼を受けました。 ネットワークエンジニアとして就職。その後サーバエンジニアとしても業務を行い、様々なお客様のシステム構築と運用を行いました。また自社で構築したサービス運用も経験するなど、いろいろな部署を渡り歩き、嬉しいこと辛いことの経験を積みました。 そんな中AWSと出会い、衝撃を受けることになります。AWSを中心にビジネスをしている現在の部署に異動し「テクニカルエスコート」を立ち上げました。 本編  AWSエンジニアになった背景を教えてください。 2007年にEC2が発表されAWSを知ったときの衝撃は忘れられません。サーバを作ることがソフトウェアのようにすぐに実現するという即時性と利便性は信じがたいものでした。 その 驚き が 魅力 に変わり、AWSのサービスに魅了されていきました。 その後のAWSのサービス拡充の勢いはすごいもので、新サービスのたびに感嘆したものです。従来の ITの概念を塗り替える 、その センス・オブ・ワンダー を皆さんにも感じてほしく、AWSを使った仕事をしたいと考えました。 基盤エンジニアであった私は、趣味でプログラミングをする程度ではあったものの、AWSが打ち出す開発者向けサービスとその思想に共感し、徐々に上位レイヤーへの進出も測っております。ITやクラウドは遷り変わりの早い世界であり、日々勉強を続けております。 エンジニアとして大切にしている価値観や信条はありますか？ 「使える」「作れる」というシステムの表面的な挙動だけではなく、その 裏にある技術的理論 をしっかり勉強することです。クラウドサービスは、コンピュータおよび通信の原理原則の上に、基礎技術が構築されており、それを組合せ抽象化したものです。その原理原則をしっかり学び理解した上で、システムを作っていきたいと考えています。 学ぶことは試行錯誤の連続であり、多くの エラーの先に成功 があります。それは自分だけでなく、誰でも同じだと思っています。業務の上でも、技術支援サービスは新しい体験が数多くあり、新しい試みは常に失敗と隣り合わせです。そのため 他者の失敗を許容する文化醸成を心がけています この度は受賞おめでとうございます！ 受賞に至るまで特に重点を置いて取り組んできたこと・乗り越えたチャレンジを教えてください。 まずは足場固めとして、AWSをSCSK社内で使ってもらうにはどうしたらいいかを考えました。 クラウドという概念は知っていても、いざお客様に提案しようとすると躊躇してしまう。なぜなら良くわからないから。だから経験をすることができない。こうした負の連鎖を断ち切りたいと考えました。そこで 社内 に対しても 社外 に対しても 実施する技術支援サービスを立ち上げ ました。 長く続いた オンプレシステム と、 クラウドサービス上で作るシステム とでは、システム設計の考え方が大きく 違い ます。このことを多くのエンジニアに 理解してもらう取り組みを続けています。 受賞がご自身のキャリアやチームに与えた影響はありますか？ 個人的には大きな 自信 につながりました。お客様と話す際も堂々と話せるようになったと思います。 チームとしては、メンバーの目標の一つにもなっていると思い、その結果 メンバーのスキル向上の啓蒙 になっていると思います。 またビジネスとしては お客様から の 信頼 される 効果が大きいです。特に技術支援という、技術力が重視され る ビジネス においては アピール として 箔 が付いた ことが何より有り難いです。 今後、個人として、挑戦してみたい新しい技術・分野や、目指している目標について教えてください。 IT技術進歩の歴史の中では、大きなブレイクポイントが度々ありました。インターネットの商業利用開始、スマートフォンの発明、クラウドサービスの開始、 ディープラーニング の 実用化 。こうしたブレイクポイントが起こると、そこには大きなビジネスチャンスが産み出されます。それを逃さず習得し、 新たなビジネス/サービス を創出 していきたいと考えています。LLMの成功から、機械学習・人工知能が大きな潮流となっておりますので、それは確実にキャッチアップしていきます。その 次は 、 量子コンピューティング だと思っています。 我々のチームは、基盤技術者が多いためアプリケーション開発に関する 技術の経 験 を積む ことが目標です。また DevOpsやAI-DLCなどの新たな開発体制・手法についての支援力をより拡充していきます。 前回のリレーインタビュー での佐藤 優音さんから 寺内さんへのご質問です。ご回答をお願いいたします。 寺内さんは、クラウド 黎明期 から 新しいサービスに関する知識 を積極的に 収集 されてきたと思いますが、常に最新技術をキャッチアップするための ポイントを教えて ください！ 一番の情報収集元はSNSです。自分の興味ある話題を発信することで 、SNSプラットフォーム が私の興味領域を学習し、 近しい話題を優先的に表示 してくれます。 発信 の増加が 入力 の増加につながる好循環を生み出すことがSNS活用のコツだと思います。 他にも、AWSやIT技術の アンテナの高い社内の人との対話 が非常に有用ですね。 次のインタビューは AWS Top Engineers の「畑 健治」さんです！畑さんにお聞きしたいことはありますか？ 畑さんはDBからアプリケーションまで 幅広いIT技術 を 習得 されていますが、コンピュータに触れていて 一番楽しいと思う点 はどんなところにありますか。 寺内さん、ありがとうございました！ 最後に、読者の方へメッセージをお願いいたします！ ITの原理原則は科学技術で成り立っています。 物理 や 数学 を疎かにせず勉強していきたいです。そして現実はSFビジョンに近づいてきました。正しく技術を理解し、 次の新たな未来をSF的思考をする こと、それが新たなエネルギーになると信じ、想像の翼を広げていきましょう   次回インタビューは、2025 Japan AWS Top Engineers を受賞された 畑 健治 （はた けんじ）さんです。 次回の記事もお楽しみにお待ちください！        

SCSKの畑です。 今回は実案件における Redis から Elasticashe（Redis OSS）への移行において直面したいくつかの仕様差異について、どのような対策を取ったのかも合わせて紹介したいと思います。ちなみに移行に関する初回のエントリは以下となります。 Amazon Elasticache 移行方式のまとめ とある案件において 他クラウド IaaS 上の Redis から Elasticache（Redis OSS）へのデータ移行要件があったため、移行方式についてどの方式を採用したのかを含めてまとめてみました。 blog.usize-tech.com 2026.02.12   差異その1：Elasticache は停止ができない まずはベーシックな内容から。 よく知られていることだと思うのですが、Redis と異なり Elasticache は停止ができません。メモリ上にデータを保持する以上、インスタンスを停止するとデータが失われてしまうが故の仕様かと類推するのですが、停止できないということは一度インスタンスを立ち上げた後は常時課金が発生してしまうことになります。特に性能試験用の環境のように、使用中は本番環境と同様の大きいインスタンスを必要とする環境ではその弊害もより大きくなってしまいます。 Redis も停止すればデータは失われる以上、（データを保持したままの）停止ができないというのは同様と言えるかもしれません。ただ、Redis の場合はデフォルトで起動時にバックアップ（dump.rdb ファイルなど）からのデータロードが可能なため、起動停止を前提とした運用は Elasticache より実施しやすいと言えると思います。 そこで、大きなインスタンスサイズを必要とする環境については、環境を使用していない時間帯はインスタンスサイズを縮小することで課金額を低減しようと考えていたのですが・・ふと、縮小先のメモリサイズより大きなデータが Elasticache 上に存在したらどういう挙動になるんだろう？という疑問が。実運用時においても同じような状況になることが予想できたため事前に検証しておくことにしました。 試しに 10 GB のキャッシュデータを cache.r7g.xlarge のインスタンスにロードした後、t3.micro にサイズを変更してみたところ・・ Failed to scale down to cache node type Replication Group redis-downsize-test because the node has insufficient memory. Please select a different node type or reduce current memory usage and retry のようなエラーが出力されてしまったため、（ある意味予想通りでしたが）縮小できませんでした。よって、Elasticache の（再）作成・削除により起動・停止を代替する方法が唯一の回避策という結論となりました。削除時にデータをバックアップとして残しておいて、それを（再）作成時に使用するような流れです。先述した Redis の挙動を Elasticache で実現しようとするとこうなります、とも言えますね。 直近にリリースした Elasticache で早速この対応が必要となったため、 一旦は AWS CLI で実装することで解決しました 。 ただし、この手法だと各環境ごとに Elasticache の（再）作成コマンドが必要になってしまうためあまり効率が良いとは言えません。本案件における AWS リソース/サービスのデプロイには CloudFormation を使用しているため、将来的にはそちらに移行したいところです。DeletionPolicy あたりを使用すればできるのかしら・・？   差異その2：一括移行の場合 Elasticache をバックアップから新規作成する必要がある 続いてはこちらのテーマ。上記内容（差異その1）とも関連する内容でもあります。 先般のエントリ でも言及していた通り、本案件における Elasticache のデータ移行は一括移行で実施する旨決定したのですが、一括移行において現行環境で取得したバックアップを新環境に移行する際において、そのタイミングでバックアップから Elasticache を新規作成する必要があります。言い換えると、作成済みの Elasticache に対して特定のバックアップをリストアするというオペレーションが行えません。 よって、一括移行のタイミングまで新環境（Elasticache）のエンドポイントが不明な状態になってしまうという懸念点がありました。当日移行（切替）のタイミングでアプリケーション側の各種設定を変更する必要がある訳ですが、その直前まで新環境（Elasticache）のエンドポイントが分からないというのは作業への影響が大きいと考えたためです。 当初この仕様にものすごく違和感があったのですが、Redis の場合も起動時にバックアップ（dump.rdb ファイルなど）のデータを読み込む挙動をしており、実のところ同じ仕様でした。。ただ、仮に同様のシナリオで別の IaaS 上の Redis に移行するケースを考えてみると、移行先サーバへの接続情報（IPアドレス/FQDN）は Redis 移行前に分かっていることになるので、その点においては差異があると思います。 一方で、過去の経験や上記（差異その1）の対応において Elasticache を同じ設定で再作成した場合、再作成前後で必ず同じエンドポイント名となったことから、裏取りも兼ねてエンドポイントの命名規則が分かれば（少なくとも現在の仕様において）事前に新環境でのエンドポイント名を導出することができると考えました。 AWS のドキュメントには該当するような内容がなさそうだったので、大人しく AWS サポートに確認しました。その結果、命名規則に関する公開情報はないという前提において現在の仕様を確認頂くことができたので、以下に共有します。クラスターモードや転送中の暗号化の差異によりエンドポイントの FQDN が異なるというのは正直気付かなかったところです・・ ◆クラスターモード無効・転送中の暗号化が有効 ・プライマリエンドポイント master.<クラスター名>.<6文字のランダム文字列(※).<リージョン名>.cache.amazonaws.com ・リーダーエンドポイント replica.<クラスター名>.<6文字のランダム文字列(※).<リージョン名>.cache.amazonaws.com ・ノードエンドポイント <ノード名>.<クラスター名>.<6文字のランダム文字列(※)>.<リージョン名>.cache.amazonaws.com ◆クラスターモード無効・転送中の暗号化が無効 ・プライマリエンドポイント <クラスター名>.<6文字のランダム文字列(※)>.ng.0001.<リージョン名>.cache.amazonaws.com ・リーダーエンドポイント <クラスター名>-ro.<6文字のランダム文字列(※)>.ng.0001.<リージョン名>.cache.amazonaws.com ・ノードエンドポイント <ノード名>.<クラスター名>.<6文字のランダム文字列(※)>.0001.<リージョン名>.cache.amazonaws.com ◆クラスターモード有効・転送中の暗号化が有効 ・設定エンドポイント clustercfg.<クラスター名>.<6文字のランダム文字列(※)>.<リージョン名>.cache.amazonaws.com ・ノードエンドポイント <ノード名>.<クラスター名>.<6文字のランダム文字列(※)>.<リージョン名>.cache.amazonaws.com ◆クラスターモード有効・転送中の暗号化が無効 ・設定エンドポイント <クラスター名>.<6文字のランダム文字列(※)>.clustercfg.<リージョン名>.cache.amazonaws.com ・ノードエンドポイント <ノード名>.<6文字のランダム文字列(※)>.0001.<リージョン名>.cache.amazonaws.com (※) 「6文字のランダム文字列」は、同一アカウント・同一リージョンであれば同じ値となる 今回使用するのは 「クラスターモード無効・転送中の暗号化が無効」 のパターンに該当するので、こちらの命名規則を連携して一旦解決となりました。   差異その3：通信暗号化方式と認証方式の組み合わせにおける制約がある さて、ある意味本題というか、相対的に影響が大きかったトピックがこちらとなります。 現行の Redis では 通信暗号化方式：暗号化なし 認証方式：AUTH 認証 という設定だったため Elasticache でも踏襲しようとしたところ、なんと Elasticache の仕様として設定できない ことがわかりました。設定可能な組み合わせは 通信暗号化方式：暗号化あり、認証方式：AUTH 認証 通信暗号化方式：暗号化あり、認証方式：認証なし 通信暗号化方式：暗号化なし、認証方式：認証なし のどちらかに限定されており、どれを選択した場合においても現行 Redis との非互換が発生してしまいます。また、現行 Redis との互換性を考えると、上記 3 つの組み合わせの内、2 についてはどちらの項目も現行 Redis からの変更になるため採用するメリットがないと判断し、それ以外の方式（1 or 3）のメリット・デメリットを整理した上でどちらの組み合わせを採用するかお客さんも交えて検討しました。 Elasticache における方式の組み合わせが限定されている理由として考えられるのは、「通信暗号化なしの場合は認証情報も平文で通信路を流れてしまうため、認証を設ける意味がない」というところだと思います。その意図は理解できるのですが、サービスレベルで組み合わせを限定するほどの意義があるのかというと・・正直ないのでは？というのが個人的な感想です。 ざっくりメリット・デメリットをまとめると以下の通りです。平たく言うと、現行環境と同一にする（ことで影響を抑えたい）項目としてどちらを取るかというような内容ですね。 通信暗号化方式：暗号化あり、認証方式：AUTH 認証 メリット：AUTH 認証に関連するアプリケーションコードの変更が不要 通信暗号化に関連するアプリケーションコードの変更は必要 デメリット：Elasticache への移行により、通信暗号化に伴う性能への影響が生じる可能性あり 通信暗号化方式：暗号化なし、認証方式：認証なし メリット：Elasticache への移行により性能への影響が生じる可能性を相対的に抑えられる（通信暗号化しないため） デメリット：AUTH 認証に関連するアプリケーションコードの変更が必要 結論から言いますと、本案件では性能への影響を重視して 「通信暗号化方式：暗号化なし、認証方式：認証なし」 の組み合わせを選択するになりました。また、現在 AWS へのマイグレーションを先行して実施している別の案件でも同一方式が選択されていたことも理由の一つとなりました。   補足：今回のケースにおける、上記変更に伴うアプリケーションへの影響について 上記にまとめた通り、通信暗号化を有効にする場合・AUTH 認証を無効にする場合どちらもアプリケーションコードの変更はいずれにせよ必要になりますが、実際にどのような変更が必要かはアプリケーション側の実装に依存します。 今回のケースの場合、通信暗号化関連についてはいわゆるアプリケーションのコンフィグ変更が必要でしたが、いずれにせよ移行（切替）時に接続先を Elasticache のエンドポイントに変更する必要があることも鑑みると、影響はほぼなしという判断になりました。 対して、AUTH 認証の無効化については一部のライブラリを使用しているアプリケーションコードにおいて影響がありました。例えば、phpredis ライブラリを使用した以下のような php のコードで AUTH 認証なしのElasticache (Redis) に対して接続しようとすると $redis = new Redis(); $redis->connect($host, $port, $timeout); $authenticated = $redis->auth($password); 以下のように、3行目の $redis->auth($password) 実行部分においてエラーが出力されてしまいます。AUTH 認証が無効であるにも関わらず AUTH コマンドが実行されているという内容ですね。よって、このようなコードについて、対象処理の削除、Elasticache (Redis) に接続できた時点で各種操作ができるようなロジックへの変更などの修正が必要となりました。 PHP Fatal error:  Uncaught RedisException: ERR AUTH <password> called without any password configured for the default user. Are you sure your configuration is correct? in /home/ec2-user/redis_test.php:14 ちなみに、AUTH 認証無効の Elasticache (Redis) に接続した状態でこの処理を実行したとしても、もしライブラリ側でエラーを返さないような実装になっていればコード変更が不要になった可能性もあります。そのあたりは使用しているライブラリに依存するところですが、上記については redis-cli のような公式ツールでも同じ挙動になったので、（言い方が適切がどうかはさておき）この実装自体は正しいのかなと思います。   まとめ 1点目・2点目については仕様だけ見てこういうものなのね、と一旦流していたのですが、よくよくユースケースを考えると困るみたいな内容でした。幸いどちらも事前に気づけてひとまず対策できたので良かったです。 トータルで一番影響が大きかったのはやはり3点目です。パラメータレベルでの互換性は事前にチェックしていたのですが、Elasticache においてはパラメータで設定できない内容だったことに加えて、個々の設定（通信暗号化/ユーザ認証）としては可能だけど組み合わせパターンに制約がある、という非互換性はちょっと予見できておらず面食らいました。先述の通りその意図は理解できなくはないんですけど、Redis との互換性を考えるとできるようにしておいても損しないんじゃないかと思うんですけどどうなんでしょうか。Elasticashe（Redis OSS）を選択する以上は、Redis との互換性を最優先するという意図があるでしょうし。 本記事がどなたかの役に立てば幸いです。

こんにちは、SCSKの伊藤です。 LifeKeeperは特長である『直観的なUI』に加え、利便性の高いCLIも備えています。 本記事では、LifeKeeper for LinuxをCLIのみで構築する流れをご紹介します。   CLIで構築する際の注意点 本手順で使用するLKCLIは、v9.5.0から実装された機能でありバージョンによって対応しているARKが異なりますので、バージョンに合わせたドキュメントを参照しておく必要があります。 ■LKCLIガイド(v10.0) https://docs.us.sios.com/spslinux/10.0/ja/topic/lkcli-guide docs.us.sios.com   v10.0については、LifeKeeper for Linuxインストレーションガイドの 『Linuxの依存関係』 に記載のある「一般的なパッケージの依存関係」のパッケージをインストールしていれば、LinuxOS上のデスクトップ環境のパッケージ導入は必須ではありません。 その他のバージョンについては、デスクトップ環境のパッケージ導入は必須になる場合もありますので、事前にサポートに確認するようにしてください。   LifeKeeper for LinuxをCLIだけで構築してみた。 さっそく、LifeKeeper for Linuxの構築をCLIだけで実施していきます。 ターミナルの背景について、LifeKeeperセットアップ画面を除き 赤はアクティブサーバ 、 青はスタンバイサーバ になります。 実施環境は以下の通り。 ■環境情報 ホスト名 アクティブサーバ　＝　rhel01 スタンバイサーバ　＝　rhel02 OS Red Hat Enterprise Linux release 8.6 (Ootpa) 導入するLifeKeeper製品 LifeKeeper for Linux v10.0 ■コミュニケーションパス 優先度1 192.168.10.101/192.168.10.102 優先度2 192.168.11.101/192.168.11.102 ■作成するリソース階層 /kdump ファイルシステムリソース 　datarep-/kdump データレプリケーションリソース 　　ip-192.168.11.200 IPアドレスリソース ■ファイルパス インストールイメージ /work/LifeKeeper_linux_10-0-0.img ライセンスファイル /tmp/lk.lic   １．アクティブサーバでインストールイメージを確認します。 [root@rhel01 ~]# ls -l /work/LifeKeeper_linux_10-0-0.img -rw-r–r–. 1 root root 431099904 12月 18 16:20 /work/LifeKeeper_linux_10-0-0.img   ２．インストールイメージをマウントします。 [root@rhel01 ~]# mount /work/LifeKeeper_linux_10-0-0.img /media -t iso9660 -o loop mount: /media: 警告: デバイスは書き込み禁止です、読み込み専用でマウントします.   ３．マウント先のディレクトリに移動し、セットアップを実行します。 [root@rhel01 ~]# cd /media [root@rhel01 media]# ./setup   ４．非同期ミラーリング構成が未サポートである旨の警告が表示されますので、[< Continue >]を選択します。   ５．[Recovery Kit Selection Menu]を選び、[<Select>]を選択して先に進めます。   ６．[Storage  —>]を選び、[<Select>]を選択して先に進めます。   ７．[DataKeeper for Linux]にチェックを入れ、[< Done >]を選択して前の画面に戻ります。   ８．そのまま[< Done >]を選択して前の画面に戻ります。   ９．そのまま[< Done >]を選択してインストール構成を確定します。   １０．インストールの確認画面が表示されるので、[< Yes >]を選択してインストールを開始します。   １１．セットアップが完了することを確認します。 Configure LifeKeeper management group Setup complete.   １２．インストールイメージをアンマウントします。 [root@rhel01 media]# cd / [root@rhel01 /]# umount /media   １３．ライセンスファイルを読み込みライセンスキーを登録します。 [root@rhel01 media]# /opt/LifeKeeper/bin/lkkeyins /tmp/lk.lic LifeKeeper license key installation was successful!   １４．LifeKeeperを起動します。 [root@rhel01 media]# /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 for Linuxをインストールしていきます。 　　　アクティブサーバでインストールイメージを確認します。 [root@rhel02 ~]# ls -l /work/LifeKeeper_linux_10-0-0.img -rw-r–r–. 1 root root 431099904 12月 18 16:20 /work/LifeKeeper_linux_10-0-0.img   １６．インストールイメージをマウントします。 [root@rhel02 ~]# mount /work/LifeKeeper_linux_10-0-0.img /media -t iso9660 -o loop mount: /media: 警告: デバイスは書き込み禁止です、読み込み専用でマウントします.   １７．マウント先のディレクトリに移動し、セットアップを実行します。 [root@rhel02 ~]# cd /media [root@rhel02 media]# ./setup   １８．非同期ミラーリング構成が未サポートである旨の警告が表示されますので、[< Continue >]を選択します。   １９．[Recovery Kit Selection Menu]を選び、[<Select>]を選択して先に進めます。   ２０．[Storage  —>]を選び、[<Select>]を選択して先に進めます。   ２１．[DaataKeeper for Linux]にチェックを入れ、[< Done >]を選択して前の画面に戻ります。   ２２．そのまま[< Done >]を選択して前の画面に戻ります。   ２３．そのまま[< Done >]を選択してインストール構成を確定します。   ２４．インストールの確認画面が表示されるので、[< Yes >]を選択してインストールを開始します。   ２５．セットアップが完了することを確認します。 Configure LifeKeeper management group Setup complete.   ２６．インストールイメージをアンマウントします。 [root@rhel02 media]# cd / [root@rhel02 /]# umount /media   ２７．ライセンスファイルを読み込みライセンスキーを登録します。 [root@rhel02 media]# /opt/LifeKeeper/bin/lkkeyins /tmp/lk.lic LifeKeeper license key installation was successful!   ２８．LifeKeeperを起動します。 [root@rhel02 media]# /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.   ２９．それぞれのサーバでlcdstatusが表示できることを確認します。 [root@rhel01 /]# /opt/LifeKeeper/bin/lcdstatus -e BACKUP TAG ID STATE PRIO PRIMARY [root@rhel02 /]# /opt/LifeKeeper/bin/lcdstatus -e BACKUP TAG ID STATE PRIO PRIMARY   ３０． アクティブサーバで1本目のコミュニケーションパスを登録します。 [root@rhel01 ~]# /opt/LifeKeeper/bin/lkcli commpath create –laddr 192.168.10.101 –raddr 192.168.10.102 –dest rhel02 Performing commpath ‘rhel02:192.168.10.101/192.168.10.102’ create… Commpath ‘rhel02:192.168.10.101/192.168.10.102’ created successful.   ３１．続けて2本目のコミュニケーションパスを登録します。 [root@rhel01 ~]# /opt/LifeKeeper/bin/lkcli commpath create –laddr 192.168.11.101 –raddr 192.168.11.102 –dest rhel02 Performing commpath ‘rhel02:192.168.11.101/192.168.11.102’ create… Commpath ‘rhel02:192.168.11.101/192.168.11.102’ created successful.   ３２．コミュニケーションパスが登録されたことを確認します。 ※このタイミングではSTATEがDEAD状態になります※ [root@rhel01 ~]# /opt/LifeKeeper/bin/lcdstatus -e BACKUP TAG ID STATE PRIO PRIMARY  MACHINE NETWORK ADDRESSES/DEVICE STATE PRIO rhel02 TCP 192.168.10.101/192.168.10.102 DEAD 1 rhel02 TCP 192.168.11.101/192.168.11.102 DEAD 2   ３３．スタンバイサーバで1本目のコミュニケーションパスを登録します。 [root@rhel02 ~]# /opt/LifeKeeper/bin/lkcli commpath create –laddr 192.168.10.102 –raddr 192.168.10.101 –dest rhel01 Performing commpath ‘rhel01:192.168.10.102/192.168.10.101’ create… Commpath ‘rhel01:192.168.10.102/192.168.10.101’ created successful.   ３４．続けて2本目のコミュニケーションパスを登録します。 [root@rhel02 ~]# /opt/LifeKeeper/bin/lkcli commpath create –laddr 192.168.11.102 –raddr 192.168.11.101 –dest rhel01 Performing commpath ‘rhel01:192.168.11.102/192.168.11.101’ create… Commpath ‘rhel01:192.168.11.102/192.168.11.101’ created successful.   ３５．コミュニケーションパスが登録されたことを確認します。 ※このタイミングでSTATEがALIVE状態になります※ [root@rhel02 ~]# /opt/LifeKeeper/bin/lcdstatus -e BACKUP TAG ID STATE PRIO PRIMARY MACHINE NETWORK ADDRESSES/DEVICE STATE PRIO rhel01 TCP 192.168.10.102/192.168.10.101 ALIVE 1 rhel01 TCP 192.168.11.102/192.168.11.101 ALIVE 2 [root@rhel01 ~]# /opt/LifeKeeper/bin/lcdstatus -e BACKUP TAG ID STATE PRIO PRIMARY MACHINE NETWORK ADDRESSES/DEVICE STATE PRIO rhel02 TCP 192.168.10.101/192.168.10.102 ALIVE 1 rhel02 TCP 192.168.11.101/192.168.11.102 ALIVE 2   ３６．アクティブサーバでLifeKeeper設定ファイルを置換してブロードキャストPINGモードを無効化します。 [root@rhel01 ~]# vi /etc/default/LifeKeeper :%s/NOBCASTPING=0/NOBCASTPING=1/g :wq!   ３７．設定値が「NOBCASTPING=1」になっていることを確認します。 [root@rhel01 ~]# cat /etc/default/LifeKeeper | grep NOBCASTPING= NOBCASTPING=1 # Can be used to disable the broadcast ping mechanism   ３８．スタンバイサーバでLifeKeeper設定ファイルを置換してブロードキャストPINGモードを無効化します。 [root@rhel02 ~]# vi /etc/default/LifeKeeper :%s/NOBCASTPING=0/NOBCASTPING=1/g :wq!   ３９．設定値が「NOBCASTPING=1」になっていることを確認します。 [root@rhel02 ~]# cat /etc/default/LifeKeeper | grep NOBCASTPING= NOBCASTPING=1 # Can be used to disable the broadcast ping mechanism   ４０．アクティブサーバでIPアドレスリソースを作成します。 [root@rhel01 ~]# /opt/LifeKeeper/bin/lkcli resource create ip –tag ip-192.168.11.200 –ipaddr 192.168.11.200 BEGIN create of “ip-192.168.11.200” LifeKeeper application=comm on rhel01. LifeKeeper communications resource type= ip on rhel01. Creating resource instance with id IP-192.168.11.200 on machine rhel01 Resource successfully created on rhel01 BEGIN restore of “ip-192.168.11.200” END successful restore of “ip-192.168.11.200” END successful create of “ip-192.168.11.200”.   ４１．作成したIPアドレスリソースのPINGリストを登録します。 [root@rhel01 ~]# /opt/LifeKeeper/bin/lkcli resource config ip –tag ip-192.168.11.200 –pinglist 192.168.11.1 Saving new ping list for subnet 192.168.11.0:   ４２．PINGリストに登録されたことを確認します。 [root@rhel01 ~]# cat /opt/LifeKeeper/subsys/comm/resources/ip/pinglist.192.168.11.0 192.168.11.1   ４３．アクティブサーバにてリソースのステータスを確認します [root@rhel01 ~]# /opt/LifeKeeper/bin/lcdstatus -e BACKUP TAG ID STATE PRIO PRIMARY ——  ip-192.168.11.200 IP-192.168.11.200 OSF 1 rhel01 MACHINE NETWORK ADDRESSES/DEVICE STATE PRIO rhel02 TCP 192.168.10.101/192.168.10.102 ALIVE 1 rhel02 TCP 192.168.11.101/192.168.11.102 ALIVE 2 ※この時点でIPアドレスリソースのSTATEが OSF になっている場合は、下記のコマンドでリソース起動を実施します。 [root@rhel01 ~]# /opt/LifeKeeper/bin/perform_action -t ip-192.168.11.200 -a restore BEGIN restore of “ip-192.168.11.200” END successful restore of “ip-192.168.11.200”   ４４．アクティブサーバからスタンバイサーバにIPアドレスリソースを拡張します。 [root@rhel01 ~]# /opt/LifeKeeper/bin/lkcli resource extend ip –tag ip-192.168.11.200 –dest rhel02 –ipaddr 192.168.11.200 Building independent resource list  Checking quorum status  Quorum does not seem to be installed on this server, continuing  Checking existence of extend and canextend scripts  Checking extendability for ip-192.168.11.200  Pre Extend checks were successful Extending resource instances for ip-192.168.11.200  Creating dependencies  Setting switchback type for hierarchy  Creating equivalencies  LifeKeeper Admin Lock (ip-192.168.11.200) Released  Hierarchy successfully extended   ４５．アクティブサーバからスタンバイサーバにPINGリストを拡張します。 [root@rhel01 ~]# /opt/LifeKeeper/bin/lkcli resource config ip –tag ip-192.168.11.200 –pinglist 192.168.11.1 –remote rhel02 Saving new ping list for subnet 192.168.11.0:   ４６．スタンバイサーバにIPアドレスリソースが反映されていることを確認します。 [root@rhel02 ~]# /opt/LifeKeeper/bin/lcdstatus -e BACKUP TAG ID STATE PRIO PRIMARY ——  ip-192.168.11.200 IP-192.168.11.200 OSU 10 rhel01 MACHINE NETWORK ADDRESSES/DEVICE STATE PRIO rhel01 TCP 192.168.10.102/192.168.10.101 ALIVE 1 rhel01 TCP 192.168.11.102/192.168.11.101 ALIVE 2   ４７．スタンバイサーバにPINGリストが反映されていることを確認します。 [root@rhel02 ~]# cat /opt/LifeKeeper/subsys/comm/resources/ip/pinglist.192.168.11.0 192.168.11.1   ４８．続けて、データレプリケーションリソースを作成していきます。 　　　アクティブサーバでレプリケーション対象がマウントされていることを確認します。 [root@rhel01 ~]# mount | grep /kdump /dev/sdb1 on /kdump type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota)   ４９．スタンバイサーバでレプリケーション対象がマウントされていないことを確認します。 [root@rhel02 ~]# mount | grep /kdump [root@rhel02 ~]# fdisk -l /dev/sdb1 ディスク /dev/sdb1: 99 MiB, 103809024 バイト, 202752 セクタ 単位: セクタ (1 * 512 = 512 バイト) セクタサイズ (論理 / 物理): 512 バイト / 512 バイト I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト   ５０．アクティブサーバでデータレプリケーションリソースを作成します。 [root@rhel01 ~]# /opt/LifeKeeper/bin/lkcli resource create dk –tag datarep-/kdump –mode synchronous –bitmap /opt/LifeKeeper/bitmap__kdump –hierarchy existing –mount_point /kdump –fstag /kdump BEGIN create of “datarep-/kdump” /dev/sdb1 is configured to be mirrored using /dev/md0 END successful create of “datarep-/kdump” mount -t xfs -orw,seclabel,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota /dev/md0 /kdump devicehier: Using /opt/LifeKeeper/lkadm/subsys/scsi/netraid/bin/devicehier to construct the hierarchy   ５１．アクティブサーバでデータレプリケーションリソースが作成されていることを確認します。 [root@rhel01 ~]# /opt/LifeKeeper/bin/lcdstatus -e BACKUP TAG ID STATE PRIO PRIMARY rhel02  ip-192.168.11.200 IP-192.168.11.200 ISP 1 rhel01 rhel02  /kdump /kdump ISP 1 rhel01 rhel02  datarep-/kdump 1ATA_VBOX_HARDDISK_VBe0725981-3d008a14-1 ISP 1 rhel01 MACHINE NETWORK ADDRESSES/DEVICE STATE PRIO rhel02 TCP 192.168.10.101/192.168.10.102 ALIVE 1 rhel02 TCP 192.168.11.101/192.168.11.102 ALIVE 2   ５２．アクティブサーバからスタンバイサーバにデータレプリケーションリソースを拡張します。 [root@rhel01 ~]# /opt/LifeKeeper/bin/lkcli resource extend dk –tag datarep-/kdump –dest rhel02 –mode synchronous –bitmap /opt/LifeKeeper/bitmap__kdump –fstag /kdump –device /dev/sdb1 –laddr 192.168.10.101 –raddr 192.168.10.102 Building independent resource list  Checking quorum status  Quorum does not seem to be installed on this server, continuing  Checking existence of extend and canextend scripts  Checking extendability for datarep-/kdump  Checking extendability for /kdump  Pre Extend checks were successful Extending resource instances for datarep-/kdump  extend datarep-/kdump/rhel01 -> datarep-/kdump/rhel02  Creating dependencies  Setting switchback type for hierarchy  Creating equivalencies  LifeKeeper Admin Lock (/kdump) Released  Hierarchy successfully extended Extending resource instances for /kdump  Creating dependencies  Setting switchback type for hierarchy  Creating equivalencies  LifeKeeper Admin Lock (/kdump) Released  Hierarchy successfully extended   ５３．スタンバイサーバにデータレプリケーションリソースが反映されていることを確認します。 [root@rhel02 ~]# /opt/LifeKeeper/bin/lcdstatus -e BACKUP TAG ID STATE PRIO PRIMARY ——  ip-192.168.11.200 IP-192.168.11.200 OSU 10 rhel01 ——  /kdump /kdump OSU 10 rhel01 ——  datarep-/kdump 1ATA_VBOX_HARDDISK_VB05620f4b-02891c76-1 OSU 10 rhel01 MACHINE NETWORK ADDRESSES/DEVICE STATE PRIO rhel01 TCP 192.168.10.102/192.168.10.101 ALIVE 1 rhel01 TCP 192.168.11.102/192.168.11.101 ALIVE 2   ５４．アクティブサーバからリソース階層を作成します。 　　　リソース「datarep-/kdump」の下位にリソース「ip-192.168.11.200」を指定します。 [root@rhel01 ~]# /opt/LifeKeeper/bin/lkcli dependency create –parent datarep-/kdump –child ip-192.168.11.200 Creating the dependency on the server rhel01 Creating the dependency on the server rhel02 The dependency creation was successful   ５５．リソース階層が作成できたことを確認します。 [root@rhel01 ~]# /opt/LifeKeeper/bin/lcdstatus -e BACKUP TAG ID STATE PRIO PRIMARY rhel02  /kdump /kdump ISP 1 rhel01 rhel02    datarep-/kdump 1ATA_VBOX_HARDDISK_VBe0725981-3d008a14-1 ISP 1 rhel01 rhel02      ip-192.168.11.200 IP-192.168.11.200 ISP 1 rhel01 MACHINE NETWORK ADDRESSES/DEVICE STATE PRIO rhel02 TCP 192.168.10.101/192.168.10.102 ALIVE 1 rhel02 TCP 192.168.11.101/192.168.11.102 ALIVE 2 [root@rhel02 ~]# /opt/LifeKeeper/bin/lcdstatus -e BACKUP TAG ID STATE PRIO PRIMARY ——  /kdump /kdump OSU 10 rhel01 ——    datarep-/kdump 1ATA_VBOX_HARDDISK_VB05620f4b-02891c76-1 OSU 10 rhel01 ——      ip-192.168.11.200 IP-192.168.11.200 OSU 10 rhel01 MACHINE NETWORK ADDRESSES/DEVICE STATE PRIO rhel01 TCP 192.168.10.102/192.168.10.101 ALIVE 1 rhel01 TCP 192.168.11.102/192.168.11.101 ALIVE 2   ５６．念のため、スタンバイサーバにスイッチオーバーを実施してみます。 [root@rhel02 ~]# /opt/LifeKeeper/bin/perform_action -t /kdump -a restore BEGIN restore of “ip-192.168.11.200” END successful restore of “ip-192.168.11.200” BEGIN restore of “datarep-/kdump” /dev/sdb1 is configured to be mirrored using /dev/md0 Resource “/kdump” is “OSU”. The mirror “datarep-/kdump” will wait to replicate data until all resources in the hierarchy of type “filesys” are in-service. To replicate data immediately run: “/opt/LifeKeeper/bin/mirror_action datarep-/kdump resume” on “rhel02” (see “LKDR_WAIT_TO_RESYNC” in /etc/default/LifeKeeper). END successful restore of “datarep-/kdump” BEGIN restore of /kdump mounting file system /kdump mount -txfs -orw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota /dev/md0 /kdump File system /kdump has been successfully mounted. END successful restore of /kdump   ５７．問題なくスイッチオーバーできることが確認できました。 [root@rhel02 ~]# /opt/LifeKeeper/bin/lcdstatus -e BACKUP TAG ID STATE PRIO PRIMARY ——  /kdump /kdump ISP 10 rhel01 ——    datarep-/kdump 1ATA_VBOX_HARDDISK_VB05620f4b-02891c76-1 ISP 10 rhel01 ——      ip-192.168.11.200 IP-192.168.11.200 ISP 10 rhel01 MACHINE NETWORK ADDRESSES/DEVICE STATE PRIO rhel01 TCP 192.168.10.102/192.168.10.101 ALIVE 1 rhel01 TCP 192.168.11.102/192.168.11.101 ALIVE 2 [root@rhel01 ~]# /opt/LifeKeeper/bin/lcdstatus -e BACKUP TAG ID STATE PRIO PRIMARY rhel02  /kdump /kdump OSU 1 rhel01 rhel02    datarep-/kdump 1ATA_VBOX_HARDDISK_VBe0725981-3d008a14-1 OSU 1 rhel01 rhel02      ip-192.168.11.200 IP-192.168.11.200 OSU 1 rhel01 MACHINE NETWORK ADDRESSES/DEVICE STATE PRIO rhel02 TCP 192.168.10.101/192.168.10.102 ALIVE 1 rhel02 TCP 192.168.11.101/192.168.11.102 ALIVE 2   さいごに クラウド環境では、構築担当にGUIログインをさせたくない等の要望があるケースも少なくありません。 GUI接続がネックでLifeKeeper for Linuxの導入を躊躇していたユーザーの助けになれば幸いです。   詳しい内容をお知りになりたいかたは、以下のバナーからSCSKLifekeeper公式サイトまで

Azureを使ったハンズオンやワークショップを開催する際、参加者のユーザーや参加者毎の専用リソースグループを用意し、それぞれに適切な権限を設定したいことがあると思います。 本記事では、Terraformのfor eachを使用してこれらの準備を効率的に行う方法について解説します。 for eachとは Terraformのfor eachは、リソースを複数回繰り返し作成するための機能です。 通常、複数のリソースを作成する際はそれぞれ個別にresourceブロックを記述必要がありますが、この機能を使用すると複数のリソースを1つのresourceブロックで定義することができます。 メリット 1. 効率性の向上 for eachを使用しない場合、コンソールで作成またはresourceブロックを記述する作業をリソースの数だけ繰り返すことになります。 for eachを使用すれば、リストとresourceブロックをそれぞれ1つ記述するだけで作成できます。 2. パラメーターの設定ミスの低減 「同じパラメーターでリソース名だけが違う」というように、一部のパラメーターだけが異なるリソースを複数作成するケースがあると思います。 for eachを使用せずに個別に作成すると、作業ミスで一部のリソースだけ異なる設定にしてしまうことがあるかもしれません。 しかし、for eachを使用すれば、変えたいパラメーター（リソース名等）だけをリストに記述し、他のパラメーターは全く同じリソースを安全に作成することができます。 使い方 まずは、リストを記述します。 locals { names = ["group_a", "group_b", "group_c"] } for eachにこのリストを指定し、{パラメーター名} = each.key と記述すると、そのパラメーターの値がリストの各要素の値となったリソースが作成されます。 下記のコードの場合、リソース名がgroup_a、group_b、group_cのリソースグループ3つが作成されます。 resource "azurerm_resource_group" "example_groups" { for_each = toset(local.names) name = each.key ・・・ } また、for eachを使用して作成されたリソースはマップ型になっているため、それらのパラメーターはeach.value.{パラメーター名}で参照できます。 下記のコードの場合、リソース名がexample_vmの仮想マシンがgroup_a、group_b、group_cに作成されます。 resource "azurerm_windows_virtual_machine" "example_VMs" { for_each = azurerm_resource_group.example_groups name = "example_vm" resource_group_name = each.value.name ・・・ } 想定ユースケース ここからはfor eachを活用した実践的な例として、Azureのワークショップやハンズオンの環境準備を想定したTerraformコードについて解説します。 想定するユースケースは以下の通りです。 参加者にはそれぞれユーザーを発行する 参加者毎に専用のリソースグループを作成し、自分のリソースグループでのみリソースの作成/閲覧/更新/削除ができるようにする 参加者全員が参照する共通のリソースは閲覧のみ可能にする 構成イメージ Terraformコード 最終的なコードは以下の通りです。以降の章で各部の解説を行います。 # ユーザー名のリスト variable "user_names" { default = ["user1", "user2", "user3"] } # ユーザーIDと専用リソースグループの名前のリスト locals { user_ids = [for user_name in var.user_names: "${user_name}_workshop@xxxxx.onmicrosoft.com"] resource_groups = [for user_name in var.user_names: "${user_name}_workshop_group"] } # ユーザーを作成 resource "azuread_user" "workshop_users" { for_each = toset(local.user_ids) user_principal_name = each.key display_name = each.key password = "xxxxx" } # グループを作成 resource "azuread_group" "workshop_group" { display_name = "workshop" security_enabled = true } # ユーザーをグループに追加 resource "azuread_group_member" "workshop_members" { for_each = azuread_user.workshop_users group_object_id = azuread_group.workshop_group.object_id member_object_id = each.value.object_id } # 共通リソースグループを作成 resource "azurerm_resource_group" "shared_rg" { name = "shared_workshop_group" location = "japaneast" } # 専用リソースグループを作成 resource "azurerm_resource_group" "user_rg" { for_each = toset(local.resource_groups) name = each.key location = "japaneast" } # 共通リソースグループに対する権限を定義 resource "azurerm_role_definition" "shared_rg_read" { name = "SharedRGRead" scope = azurerm_resource_group.shared_rg.id description = "全員共通RGの閲覧権限" permissions { actions = [ "Microsoft.Resources/subscriptions/resourceGroups/read", "Microsoft.Resources/subscriptions/resourceGroups/resources/read" ] not_actions = [] } assignable_scopes = [azurerm_resource_group.shared_rg.id] } # 共通リソースグループに権限を付与 resource "azurerm_role_assignment" "group_shared_rg_read_assign" { scope = azurerm_resource_group.shared_rg.id role_definition_id = azurerm_role_definition.shared_rg_read.role_definition_resource_id principal_id = azuread_group.workshop_group.object_id } # 専用リソースグループへの権限を定義 resource "azurerm_role_definition" "user_rg_crud" { for_each = azurerm_resource_group.user_rg name = "UserRGCRUD_${each.key}" scope = each.value.id description = "${each.key}専用RG用のCRUD権限" permissions { actions = [ "Microsoft.Resources/subscriptions/resourceGroups/read", "Microsoft.Resources/subscriptions/resourceGroups/write", "Microsoft.Resources/subscriptions/resourceGroups/delete", "Microsoft.Resources/*/read", "Microsoft.Resources/*/write", "Microsoft.Resources/*/delete", "Microsoft.Resources/deployments/*" ] not_actions = [] } assignable_scopes = [each.value.id] } # 専用リソースグループに権限を付与 resource "azurerm_role_assignment" "user_rg_crud_assign" { for_each = { for idx, rg_name in local.resource_groups : rg_name => local.user_ids[idx] } scope = azurerm_resource_group.user_rg[each.key].id role_definition_id = azurerm_role_definition.user_rg_crud[each.key].role_definition_resource_id principal_id = azuread_user.workshop_users[each.value].object_id } 1. ユーザー名のリストを作成 ユーザー名のリストを作成しています。 # ユーザー名のリスト variable "user_names" { default = ["user1", "user2", "user3"] } 2. ユーザーIDと専用リソースグループの名前のリストを作成 1のリストを使用して、ユーザーIDと専用リソースグループの名前のリストを作成します。 # ユーザーIDと専用リソースグループの名前のリスト locals { user_ids = [for user_name in var.user_names: "${user_name}_workshop@xxxxx.onmicrosoft.com"] resource_groups = [for user_name in var.user_names: "${user_name}_workshop_group"] } 3. ユーザーを作成 2のユーザーIDのリストを使用して、ユーザーを作成します。 ※ 手順の簡略化のため、ユーザーの表示名はユーザーIDと同じ値にしています。 # ユーザーを作成 resource "azuread_user" "workshop_users" { for_each = toset(local.user_ids) user_principal_name = each.key display_name = each.key password = "xxxxx" } 4. グループを作成 & ユーザーを追加 グループを作成し、3のユーザーをグループに追加します。 # グループを作成 resource "azuread_group" "workshop_group" { display_name = "workshop" security_enabled = true } # ユーザーをグループに追加 resource "azuread_group_member" "workshop_members" { for_each = azuread_user.workshop_users group_object_id = azuread_group.workshop_group.object_id member_object_id = each.value.object_id } 5. 共通リソースグループを作成 共通リソースグループを作成します。 # 共通リソースグループを作成 resource "azurerm_resource_group" "shared_rg" { name = "shared_workshop_group" location = "japaneast" } 6. 各ユーザーの専用リソースグループを作成 2の専用リソースグループの名前のリストを使用して、専用リソースグループを作成します。 # 専用リソースグループを作成 resource "azurerm_resource_group" "user_rg" { for_each = toset(local.resource_groups) name = each.key location = "japaneast" } 7. 共通リソースグループへのRead権限を定義 ＆ グループに権限を付与 5の共通リソースグループへのRead権限を定義し、4のグループに付与します。 # 共通リソースグループに対する権限を定義 resource "azurerm_role_definition" "shared_rg_read" { name = "SharedRGRead" scope = azurerm_resource_group.shared_rg.id description = "全員共通RGの閲覧権限" permissions { actions = [ "Microsoft.Resources/subscriptions/resourceGroups/read", "Microsoft.Resources/subscriptions/resourceGroups/resources/read" ] not_actions = [] } assignable_scopes = [azurerm_resource_group.shared_rg.id] } # 共通リソースグループに権限を付与 resource "azurerm_role_assignment" "group_shared_rg_read_assign" { scope = azurerm_resource_group.shared_rg.id role_definition_id = azurerm_role_definition.shared_rg_read.role_definition_resource_id principal_id = azuread_group.workshop_group.object_id } 8. 専用リソースグループへのCRUD権限を定義 ＆ 各ユーザーに権限を付与 6の専用リソースグループへのCRUD権限を定義し、各ユーザーに付与します。 Microsoft.Resources/*/read, write, delete の、「*」の部分にサービス名を記述することで、特定のサービスに限定した権限を付与することもできます。 # 専用リソースグループへの権限を定義 resource "azurerm_role_definition" "user_rg_crud" { for_each = azurerm_resource_group.user_rg name = "UserRGCRUD_${each.key}" scope = each.value.id description = "${each.key}専用RG用のCRUD権限" permissions { actions = [ "Microsoft.Resources/subscriptions/resourceGroups/read", "Microsoft.Resources/subscriptions/resourceGroups/write", "Microsoft.Resources/subscriptions/resourceGroups/delete", "Microsoft.Resources/*/read", "Microsoft.Resources/*/write", "Microsoft.Resources/*/delete", "Microsoft.Resources/deployments/*" ] not_actions = [] } assignable_scopes = [each.value.id] } # 専用リソースグループに権限を付与 resource "azurerm_role_assignment" "user_rg_crud_assign" { for_each = { for idx, rg_name in local.resource_groups : rg_name => local.user_ids[idx] } scope = azurerm_resource_group.user_rg[each.key].id role_definition_id = azurerm_role_definition.user_rg_crud[each.key].role_definition_resource_id principal_id = azuread_user.workshop_users[each.value].object_id } 確認 terraform applyを実行してAzure環境にコードで記述した内容を反映した後、管理者権限を持つユーザーでログインすると、以下のようにグループにユーザーが3つ追加されていることがわかります。 また、リソースグループも共通1つと専用3つの計4つが作成されていることが確認できます。 続いて、参加者用ユーザーでログインします。（下の画像はuser1_workshop@xxxxx.onmicrosoft.comでログイン） リソースグループを見に行くと、共通リソースグループと自分の専用リソースグループしか表示されないことが確認できます。 まとめ 以上の手順で効率的にユーザー/グループ/リソースグループの作成と権限の付与ができます。 TerraformをはじめとするIaCツールを使用せずに手作業で上記の環境準備を実施する場合、特に各自の専用リソースグループに対する権限付与の部分で多くの手間がかかってしまいます。 本記事で紹介したケースに限らず、for_eachを使用することで効率的にインフラ構築ができますの皆様もぜひお試しください！

本記事ではDropboxの共同編集について紹介したいと思います。 はじめに Dropbox では、他のユーザーと共有するファイルを共同編集できます。共同編集する作業は、利用するツール（Webブラウザ、デスクトップアプリ、モバイルデバイス）やファイルの種類によって方法が異なります。 前回、Windows PC上のWebブラウザを使った Dropbox での Microsoft Office ファイル の共同編集について紹介しました。今回は、Windows PC上の Dropboxデスクトップアプリで同期した Microsoft Office ファイル の共同編集 について記載します。 作業開始前の確認 共同編集を行うにあたっての前提条件と制限事項は、前回確認しました。 また、共同編集を行うには、まず対象のユーザーに「編集権限」を付与したフォルダを共有する必要がある点も前回のWindows PC上のWebブラウザを使った共同編集と同じです。詳細は前回の投稿を確認ください。   Windows PCでMicrosoft Office ファイルの共同編集を利用する -1 では、Dropboxデスクトップアプリで同期した Microsoft Office ファイルの共同編集を利用する手順を確認します。 Microsoft Office ファイルの共同編集を利用する 必要な設定 Windows PC上の Dropboxデスクトップアプリで同期した Microsoft Office ファイル の共同編集を利用する場合、次の設定を行います。 「Microsoft Office への保存場所」の設定　 ※必須 Windows の保護されたビュー　※任意 １.「Microsoft Office への保存場所」の設定 Dropboxデスクトップアプリで同期した Microsoft Office ファイル の共同編集を利用するには、Microsoft Officeアプリ側に保存場所としてDropboxを登録する必要があります。 管理者による設定 管理コンソールから共同作業を有効にする チームによるアプリのリンクをブロックしている場合は、Microsoft Office 365 と Dropbox のリンクを許可し、共同作業を有効にします。 これはチーム管理者が設定する内容なので、先ずはDropboxの管理者にMicrosoft Office 365 と Dropbox のリンクが許可されているか確認ください。   ［ 管理コンソール ］画面にて 製品 ＞ Dropbox の［ 設定 ］メニューから［ インテグレーション ］タブをクリックします。画面下部のアプリのリストにある　 Microsoft Office 365 が許可されていることを確認します。 ユーザーによる設定 Dropbox を保存場所として追加する ユーザー側では、 Dropboxデスクトップアプリ と Microsoft Office アプリ の両方で、Dropboxを保存場所として有効にする必要があります。 Dropbox デスクトップ アプリ Dropbox デスクトップ アプリの [基本設定] > [全般] タブを開き 、［ Dropbox をMicrosoft Office での保存先として 表示する ］の横にあるトグルをオンにします。                                   [基本設定]>[全般]タブ［Dropbox をMicrosoft Office での保存先として 表示する］ Microsoft Officeアプリ 各ユーザーはMicrosoft Officeアプリ側でDropbox を保存場所に追加します。 Dropbox での Microsoft Office の共同編集 – Dropbox ヘルプ 実施手順は、Microsoft Office で利用を開始する方法　＞　Microsoft デスクトップアプリの場合　を参照ください。 Excel の［ ファイル ］メニューから［ 開く ］をクリック、［ 場所の追加 ］をクリックした場合は、 画面右の一覧から［ Dropbox for Teams ］をクリックします。   Dropbox の認証情報画面が表示されたら、画面をスクロールし、メールアドレスを入力してDropboxにログインします。   Dropboxの認証が成功すると、保存する場所として Dropbox が追加されました。 2. Windows の保護されたビュー ファイルを開いて共同作業を開始した際にインターネットからのファイルにウイルスが含まれている可能性があることを警告するバナーが画面上部に表示される場合があります。この場合、Windowsが自動的に読み取り専用権限モードでファイルが開くので、ドキュメントの編集を開始するには、［ 編集を有効にする ］をクリックします。     この手順をスキップするには、Dropbox を信頼済みサイトに設定します。 ［ コントロール パネル ］を開きます。 ［ インターネット オプション ］をクリックします。 ［ セキュリティ ］タブを選択します。 ［ 信頼済みサイト ］を選択します。 ［ サイト ］をクリックします。 ［ このウェブサイトをゾーンに追加 ］にウェブ アドレス「 https://wopi.dropbox.com 」を入力し［ 追加 ］をクリックします。 以上にて、事前に必要な設定が完了しました。続いて、Dropboxデスクトップアプリで同期した Microsoft Office ファイル の共同編集 を開始しましょう。 Microsoft Office ファイルの共同編集を開始する Dropboxデスクトップアプリで同期した Microsoft Office ファイル（Word、PowerPoint、または Excel ）を開いた後、ファイルの左上にある［自動保存］をオンに切り替えます。 ※［自動保存］がオフになっている場合、共同作業は機能しません。                     自動保存をオン                                他のユーザーと同時に編集作業を行っているファイル上で、誰が何処を編集しているのか、また編集内容をリアルタイムで確認できます。 共同編集を行っているユーザーのアイコンが表示されます。                                    共同編集時には相手側で選択されたセルが色付きの太線で囲まれます                                     Dropboxを保存場所として追加すると、アクセス権のある Dropboxファイルの共同編集を次の 2 つの方法で開始することができます。 エクスプローラー（Windows）から直接開く。ファイルをダブルクリックすると、共同作業セッションが開始されます。  Microsoft Office アプリからファイルを開く。ファイルを開くと共同作業セッションが開始されます。 手順は以下のとおりです。 Microsoft Office アプリ（Word、PowerPoint、または Excel ）を起動します。 左側のサイドバーで［ 開く ］をクリックします。 ［ Dropbox for Teams ］をクリックします。 開きたいファイルを選択します。 補足 Dropbox バッジは表示されなくなります 共同作業を有効にすると、 Dropbox バッジは表示されなくなります。 Dropbox バッジは表示されなくなりますが、他のユーザーと共同作業しながら変更内容をリアルタイムで確認することで、全員が最新バージョンで共同作業を行えます。これにより、編集ファイルのコピー競合を防ぐことができ、ファイルの管理がより簡単になります。 Microsoft Officeアプリの保存場所からDropbox を削除する Microsoft Officeアプリの「名前を付けて保存」や「開く」の画面に表示される「Dropbox for Teams」を削除するには、 「接続済みサービス」から削除 します。 Microsoft Officeアプリ [ファイル] メニュー [アカウント] を選択すると、画面右側に「接続済みサービス」が表示されます。 一覧にある 「Dropbox for Teams」 の横に表示されている [削除] をクリックします。 確認メッセージが表示されたら、[はい] をクリックします。 設定を反映させるには、一旦 Microsoft Officeアプリを終了ください。 まとめ 1. 共同編集は Web ブラウザとデスクトップアプリで利用可能 2. 各利用方法に前提条件と制限事項がある 3. 共同編集には共有ファイルを「 編集可能 」で共有する必要がある 4. デスクトップで利用するには追加設定が必要 5. 共同編集中は競合防止やリアルタイム編集が可能   本投稿に関するお問合せ先     ：　 Dropbox-sales@scsk.jp SCSKのDropbox取り組み紹介：    https://www.scsk.jp/product/common/dropbox/index.html 参照情報 Dropbox 内で共同作業を有効にする方法 https://help.dropbox.com/ja-jp/view-edit/admin-guide-co-authoring Dropbox での Microsoft Office の共同編集 https://help.dropbox.com/ja-jp/view-edit/collaborate-on-microsoft-office Microsoft Office 365 で Dropbox を場所として追加する方法 https://help.dropbox.com/ja-jp/integrations/adding-place-microsoft-office Dropbox 向け Microsoft Office に関するよくある質問 https://help.dropbox.com/ja-jp/integrations/microsoft-office-faq

企業ネットワーク環境では、セキュリティや管理の観点から、ソフトウェアを複数のパソコンに一括で自動インストールしたいケースがあるかと思います。 一般的にはIT資産管理ソフトを利用することが多いですが、Active Directoryのグループポリシー（GPO）でもMSI形式のインストーラーを使った手軽な自動インストール機能が提供されています。 今回はCatoクライアントのMSIインストーラーとGPOを利用して自動インストールする手順をご紹介します。 前提条件 今回、グループポリシーでCatoクライアントを自動インストールする際に使用した構成・環境は以下の通りです。 構成 Catoネットワーク環境 Active Directoryドメインコントローラー Windows PC 環境 Windows PCがActive Directoryドメインに参加済み Active Directoryドメイン上に、インストール対象となるWindows PC用のOU（組織単位）が存在する Windows PCから読み取り可能なWindows共有フォルダー Active Directoryや共有フォルダーを操作できるドメイン管理者権限のユーザー 全体の流れ CatoクライアントのMSIインストーラーファイルをWindows共有フォルダーへ配置する ドメインコントローラー上でGPOを作成する GPOが適用されたWindows PCにユーザーの操作なしで自動インストールが行われる 詳細手順 1. CatoクライアントのMSIインストーラーファイルを準備して配置する 1-1. MSIインストーラーファイルの入手 Cato管理画面（CMA）にログインし、 [Access] → [Client Rollout] → Windows Clientの[Download Client] → [Download MSI] からMSI形式のインストーラーをダウンロードしてください。   1-2. Windows共有フォルダーへの配置 ダウンロードしたMSIインストーラーファイルを、Windows PCから接続可能な共有フォルダーへ配置してください。 配置したファイルのUNCパスをメモしておきましょう。 （例：UNCパス \\ad\share\setup.msi）   2. ドメインコントローラー上でGPOを作成する 2-1. グループポリシー管理ツールの起動 ドメインコントローラーにサインインし、管理ツールから［グループポリシーの管理］を起動します。   2-2. GPOの作成および適用先のOU指定 インストール先となるオブジェクトが所属するOUに、新規GPOを作成してください。既存のGPOが用途に合う場合はそちらを使用しても構いません。 ここではMEMBERコンピューターオブジェクトが所属している[catoscsk.local/Cato/PC/Mobile/]OUを対象とします。   2-3. グループポリシーの編集 作成したGPOを右クリックし［編集］をクリックしてください。 「グループ ポリシー管理エディター」が起動したら [コンピューターの構成] → [ポリシー] → [ソフトウェアの設定] → [ソフトウェア インストール] とツリーを展開してください。   2-4. パッケージの追加 ［ソフトウェア インストール］を右クリックし、［新規作成］→［パッケージ］とクリックしてください。   2-5. インストーラーファイルの指定 ［開く］ダイアログボックスが表示されるので、パスの箇所に共有フォルダーのUNCパス（例：\\ad\share\）を入力し、対象ファイル（例：setup.msi）を選択し［開く］をクリックしてください。   2-6. パッケージの割り当て 表示されるウィンドウで［割り当て済み］を選択し、［OK］をクリックしてください。 ※この操作が完了すると、次回Windows PC起動時にパッケージがインストールされるので、タイミング等は考慮してください。 パッケージが右ペインに表示されれば設定完了です。 このGPOが適用された後、起動したWindows PCで自動インストールが行われます。   3. GPOの適用と自動インストール GPOを適用したWindows PCを再起動してください。 グループポリシーの変更が反映された後、PCの起動時にCatoクライアントが自動インストールされ、スタートメニューやデスクトップに[Cato Client]アイコンが作成されます。   まとめ MSI形式のCatoクライアントのインストーラーを利用し、Active Directoryのグループポリシーの機能を使って自動インストールできることを確認しました。 企業環境でのクライアント展開の一例として、参考になれば幸いです。

ビジネスのデジタル化が進む中、もはや「ただのオンラインストレージ」の枠を超え、チームの共同作業プラットフォームとして欠かせない存在になった Dropbox。 しかし、いざ導入や見直しを検討すると「Standard、Advanced、Enterprise……結局、自社にはどれが最適なの？」という壁にぶつかりがちです。プランを間違えると、コストが無駄になったり、逆にセキュリティ要件を満たせなかったりすることも。 今回は、企業向けDropboxの3プランの決定的な違いと、迷わず選ぶための「簡単選択ガイド」をお届けします。 特に、次のようなお悩みをお持ちの方は必見です。 「プランが多すぎて、どこから比較すべきか分からない」 「急増するデータの容量不足や、情報漏洩対策に頭を悩ませている」 「ファイルサーバーからの移行、業務を止めずにできるか不安……」 この記事を読めば、自社に最適なプランと、スムーズな導入の進め方が見えてきます。 企業向けDropbox 3プランの比較表 まずは、主要な機能を横並びで比較してみましょう。                機能・項目 Standard Advanced Enterprise 主な対象 小規模なチーム 中堅〜大規模組織 主に大規模企業 高度な管理・制限が必要な組織 ストレージ容量 合計5TB（チーム全体） 15TB〜（5TB xユーザ数） 必要なだけ ファイル単位のアクセス履歴 なし ✓ ✓ SSO連携 なし ✓ ✓ ランサムウェアの検知と復元 なし ✓ ✓ 不審なアクティビティのアラート なし ✓ ✓ エンタープライズモビリティ管理連携 （モバイルデバイスの制限） なし なし ✓ データ保持/復元 180日間 365日間 365日間   ズバリ、自社にはどれ？「簡単選択ガイド」 「機能一覧を見てもピンとこない」という方のために、判断基準をシンプルにまとめました。 【Standard】を選ぶべきケース 利用人数が10名以下で、扱うデータがテキストや一般的なOffice文書中心（合計5TBで足りる）。 まずは手軽に、場所を選ばない働き方を実現したい。 【Advanced】を選ぶべきケース 「容量不足を気にしたくない」 。動画やCADデータなど重いファイルを頻繁に扱う。 「誰が、いつ、何をしたか」 を詳細なログで追跡する必要がある。 シングルサインオン（SSO）を導入して、ID管理を一元化したい。 【Enterprise】を選ぶべきケース 数千名規模のユーザを管理する必要がある。 高度なガバナンス （モバイルデバイスの利用制限、社内での個人アカウントの利用制限など）が必須。 ストレージ容量が1PBを超えてくる可能性がある。   「ライセンスを買って終わり」にしない。SCSKが選ばれる理由 Dropboxは非常に使いやすいツールですが、企業導入において最大のハードルとなるのが「既存環境からの移行」 と 「運用ルールの徹底」です。 SCSKでは、単なるライセンス販売にとどまらず、お客様の「困った」を解決する以下のメニューを揃えています。 ① 移行の不安を解消する「データ移行支援」 セルフデータ移行ツールの提供 「自分たちで安価に、でも確実に移行したい」という方向けに、SCSK独自の移行支援ツールを提供しています。 関連記事： 【決定版】Dropboxへのデータ移行を自力で効率化！SCSK「セルフデータ移行ツール」忖度なしレビュー – TechHarmony 移行作業の請負（大規模案件向け） 「ファイルサーバーに数テラバイトのデータがあり、業務を止めずに移行するのは無理……」という場合は、SCSKのプロフェッショナルが移行計画の策定から実作業までを代行します。 100TBを超えるような超大規模の移行実績 もございますので、安心してお任せください。            関連記事： 東急建設株式会社 様｜お客様事例｜SCSK株式会社 ② 「使いこなし」を加速するトレーニング 導入しても使われなければ意味がありません。 管理者が安心して運用するための 管理者向けトレーニング ユーザーが迷わず使いこなすための 利用者向けトレーニング これらをセットで実施し、スムーズな定着を支援します。 ③ 安全性を高める「認証システム連携」 Microsoft Entra ID（旧 Azure AD）やIDaaSとの連携設定も、技術的な知見を持つSCSKにお任せください。セキュアで利便性の高いSSO環境を構築します。   まとめ Dropboxのプラン選びは、現在の人数だけでなく、「将来のデータ量」 と 「必要なガバナンスレベル」を見極めるのがコツです。 「自社の要件だと、Advancedで足りるかな？」「移行のコスト感を知りたい」といった具体的なご相談があれば、ぜひお気軽にお問い合わせください。日本初のDropbox認定サービスパートナーとして培ったノウハウで、最適な環境づくりをお手伝いします。 本投稿に関するお問合せ先：　 Dropbox-sales@scsk.jp SCSKのDropbox取り組み紹介： https://www.scsk.jp/product/common/dropbox/index.html

こんにちは、Catoクラウド担当SEの中川です！ 今回の記事では、SocketのBypass機能の強化についてご紹介します。 ようやくBypassしたい通信先の指定にFQDNが使えるようになりましたので、その点を中心に設定方法を交えながらご紹介します。 Bypass機能ってそもそもなんだっけ？、という方は下記の記事をご参考いただければと思います。 【Catoクラウド】アプリケーション指定で通信をバイパスする – TechHarmony 本記事は下記のリリースノートの内容に従って記述しています。 Socket-Version-25-0-Release-Notes 2026年2月時点でEarly Availabilityとして提供されています。正式リリース時には機能が変更となる可能性がありますので、ご留意ください。 はじめに まず前提として、Catoではすべてのトラフィックを Cato Cloudに集約しセキュリティチェックすることが推奨されています。Bypass機能を利用するとセキュリティチェックが行われませんので、この点はご承知おきください。 ただその一方で、セキュリティレベルが担保されている特定の通信について、 Socket から直接インターネットへブレイクアウトさせたい という要件も少なくありません。 特にブレイクアウトさせたいと要望いただいていたのが Windows Update です。Windows UpdateがMicrosoftから配信されると、一斉にPCがアップデートを始めてしまい帯域を一気に消費してしまいやすいからです。 これまでは、QoSで優先度を下げることで、他の通信に影響を与えないよう回避していただくことを推奨していました。 ただ回避策があったとはいえ、そもそもCatoを経由させずに帯域を一切使わせないようにしたいという要望が多くありました。 そのご要望をかなえる機能がようやく追加されたということです！ アップデート概要 今回のBypass機能強化について、大きく3つのポイントに分けてご説明します！ 通信先指定がより柔軟に これまでも特定の通信をBypassさせることは可能でしたが、かなり限定的でした。具体的には IP アドレス指定  もしくは 以下の アプリケーションのみ に限定されていました。 Zoom Google Apps Microsoft SharePoint Online および OneDrive Microsoft Teams Microsoft Exchange (Outlook) Microsoft Defender そのため例えばIPアドレスが公開されているSaaSサービスをBypassさせることは可能でしたが、IPアドレスの追加があったりするとCMA上でわざわざ登録する必要があり運用に負担がありました。 今回のアップデートでは、下画像のように選択肢が増え、FQDNのほか、Custom Applicationやサブネットでも指定可能になりました。 Applicationは従来の宛先に加えて、Windows Updateのほか、NetflixやAmazon Prime Videoなどの動画配信サービスも指定可能になっています。 また、プロトコルでの指定も可能になりました。Simple Serviceを選べば下記のいずれかで簡単に指定できるほか、Custom Serviceを選べばポート番号を記載する形で指定もできます。 管理が簡単に 設定箇所がこれまでSiteごとのConfigurationでしたが、 CMAのNetwork ＞ Bypassに移動しています。 Siteごとに個別に設定運用する必要がなくなり、SiteをAnyと指定すれば一括で設定が適用できるようになり、また各Siteに設定値を見に行かなくても1ページで設定値が可視化できるようになったこともメリットと言えます。   イベントログが残るように 特にCatoのアップデート情報では言及されていませんが、従来のBypass機能ではイベントログは残せなかったところ、今回のアップデートでイベントログに記録されるようになりました。 Bypass機能を利用し始めたときに、きちんと想定通りBypassされているのか、反対に余計な通信もBypassされてしまっていないか確認するのに有用と思います。 下画像が実際のイベントログで、Sub-Type：Socket Bypass、Rule：Bypassのルール名で記録されることがわかりました。 具体的な設定方法を解説 それでは早速、具体的な設定方法を解説していきます。   最初に 先述の通り、設定箇所はNetwork ＞ Bypassです。初めてBypass機能を利用される場合は、右上のBypass rules Enabledのトグルをオンにする必要があります。 拠点と送信元の指定（SiteとSource） Firewallのルールなどと少し違うのは、Sourceとは別でSiteの設定があることです。 下画像の通り、Siteを指定したあと、SourceとしてIPアドレスレンジやVLAN IDなどで送信元を限定することができます。 今回はSiteのみ指定し、SourceはAnyとします。 送信先（Destination） Destinationは先の通り、FQDNやCustom Application選べるようになりました。 Custom Applicationでは、複数のFQDNやIPアドレスをまとめてグルーピングしておき、各ルールの編集を行わなくともグループで追加すればすべてのルールに適用できる点が小さなメリットです。 今回のルールは、ApplicationでWindows Updateを選択します。 ポート選択とイベント記録（Actions） Actionsでは、Socketのポート選択と、イベントに残すかが選択できます。 ポート選択では、もし特定のポートからトラフィックを強制的にブレイクアウトさせたい場合には、WANポートを指定できます。 例えばインターネット回線が複数あって、Bypassさせる通信は特定のインターネット回線を使わせるようにしたい、といった細かな要件がある場合に使用します。 ※AutomaticのままにするとSocketで最適選択されます。 今回はAutomaticで、イベントログはオンにしました。 最終的には下画像のような見栄えになり、Firewallなどと同様Hit Count(イベント数)も見ることができます。 想定ユースケース Catoのリリースノートでは、以下のようなユースケースが例示されていました。 Windows Update クラウドバックアップ ゲスト Wi-Fi Windows Updateのほか、既定のバックアップデータ保管先としてのクラウドサービスや、ゲストWi-Fiを拠点内で提供している場合に送信元指定して、Catoを経由させないといったこともBypassの利用シーンとして想定されています。 その他としては、Applicationで元々選択できたWeb会議系、今回追加された動画配信サイト系などのリアルタイムの通信性能が求められるような通信先があげられるかと思います。 ※FirewallやCASBなどで、例えばTeamsやNetflixに通信制御をかけている場合は、Bypassしてしまうと制御が効かなくなりますので注意が必要です。 まとめ 今回のアップデートにより、Socket の Bypass 機能が大きく強化されました。 これまで特に要望の多かったWindows Updateについて、ようやく現実的な形でBypassできるようになった点は大きなポイントです。 また、テナント全体での一元管理やイベントログの記録に対応したことで、運用面でも扱いやすくなったと言えます。 一方で、Bypassされた通信にはセキュリティチェックが適用されないため、対象とする通信の選定には注意が必要です。 本機能の特性を理解したうえで、適切なユースケースに限定して活用していただければと思います。

Microsoft ESI について調べても公式情報が見つからず、ブログ記事もほぼ存在しません。 私自身まだ使いこなせてはいませんが、本記事では実際に触れた内容を追記しながら、ESI の情報を共有します。   Microsoft ESIとは Microsoft ESI(Enterprise Skills Initiative) は、企業向けに提供されるクラウドやAIの学習プログラムです。 割引込みの資格の申し込みや、トレーニングコースの受講などが用意されてます。   コンテンツ Enterprise Skills Initiative esi.microsoft.com ESIポータルには8つのコンテンツがあります 1.Copilot for Microsoft 365 Training 2.Course Videos 3.Microsoft Learn for Organizations 4.Instructor-Led Courses 5.Microsoft Credentials 6.Microsoft Virtual Training Days 7.Training Services Partners 8.Games この中でも5. Microsoft Credentials は認定試験を50%オフで申し込めます。 正直、SCSK社員の多くはこれしか使ってない気がしてます。 私自身も今までは「ESI＝資格申し込み」というイメージが強かったですが、最近4. Instructor-Led Courses を利用しました。 Instructor-Led Coursesはマイクロソフト専門家によるオンライン講座を受講できるサービスです。   Instructor-Led Courses体験記 試しにCopilotの講座を受けてみました。 講座名は「AI-3025 Work smarter with AI」で、3時間のTeamsを利用したオンライン授業でした。 内容としてはCopilot の概要説明から始まり、PowerPointでのCopilot使用方法、効果的なプロンプトの作り方まで実務で即実践できる構成になってました。 特に印象的だったのは ラボ環境 が用意されていた点です。職場でMicrosoft 365 Copilotが使えない人にも環境が用意されていて親切でした。 講座の最後にはアンケートを記入して終了という流れです。 今度Microsoft Foundryの講座受けてきます。 AIエージェントを作成することがあまりないので楽しみです。   さいごに Microsoft ESIは、資格申し込みだけでなく多様なコンテンツが揃っており、使い倒すほど面白さが見えてくるサービスだと感じています。 今後は利用したコンテンツの体験をもとに記事を更新していきます。

SCSKの畑です。 先般のエントリ の内容は MySQL における特定障害シナリオからの復旧手順の検証に関連するものでしたが、引き続き今回はその障害シナリオや復旧手順について説明したいと思います。また、その復旧手順に関連する内容として RDS/Aurora (MySQL) におけるバイナリログの確認・取得方法についても合わせて紹介します。   データベースの構成について まず、本エントリで言及していくデータベース環境の構成について説明します。 具体的には、以下の通り Aurora ⇒ EC2 上の MySQL ⇒ RDS という流れで、ログポジションベースのレプリケーションが構成されている環境となります。また、Aurora ⇒ EC2 上の MySQL 間ではレプリケーションフィルタを使用しており、特定のテーブルに対する更新のみをレプリケーションしています。よって、必然的に EC2 上の MySQL ⇒ RDS 間においても同じテーブルに対する更新のみがレプリケーションされます。 また、Aurora 及び RDS はそれぞれ別の目的で複数のアプリケーションから使用されており、両方のデータベースを使用しているアプリケーションも存在します。 ちなみに、実環境の構成はこの数倍以上複雑で、データベース（インスタンス）の個数もはるかに多いです。今回はあくまで検証用に実環境のサブセットを構成しているとお考えください。 また、どうしてこのようなデータベース（レプリケーション）の構成にしているんだろう？という疑問をお持ちの方もいるかもしれませんが、そのあたりの理由は別エントリにて小ネタ的に触れたいと思います。ちゃんと理由がありますので・・ また、MySQL データベースにおけるレプリケーションの概要については、概要を同じ課の野上さんが昨年度まとめてくれていたので、そちらも合わせてご覧いただければと思います。 MySQL レプリケーションの方式をまとめてみた 初心者ながらレプリケーションの方式をまとめて記事にしました。 blog.usize-tech.com 2024.12.24   検証対象の障害シナリオ及び復旧手順について 検証対象の障害シナリオ EC2 の AZ 障害 が対象のシナリオとなります。 本案件における Aurora や RDS はマルチ AZ 構成とするため、単一 AZ 障害が発生した場合でもクラスタ or インスタンスがフェイルオーバすることで継続稼働できます。対して EC2 の場合は単一 AZ 上にのみ構成されるため、同 AZ で障害が発生した場合は継続稼働できません。EC2 の復旧手順自体は発生した AZ 障害の内容によりケースバイケースで変わってくると思われますが、どちらにせよ EC2 上で稼働していた MySQL のデータが障害発生直前の状態で復旧できる可能性は低いと考えるべきです。 よって、 EC2 の復旧後に MySQL のデータを復旧し、上流の Aurora 及び下流の RDS 間とレプリケーションを再開するための手順について検討する必要がありました。 復旧手順 こちらは先般のエントリでも触れていた通り、「 MySQL のデータをマネージド PITR で特定時刻のデータ断面にリカバリした後、その時刻以降のトランザクションログを対象としてレプリケーションすることで復旧する 」流れとなります。具体的には以下の通りです。 文章として冗長になってしまうので、以下では「EC2 上の MySQL」を便宜的に「EC2」と呼称します。 EC2 インスタンスを AMI から再作成 AZ 障害により AMI より EC2 インスタンスの再作成が必要という前提のため Aurora のマネージド PITR 機能を使用して、（できる限り最新の）特定時刻のデータ断面にリカバリした Aurora を作成 AMI に含まれる EC2 上 MySQL のデータの一貫性/整合性が保証されていない前提のため 指定した「特定時刻」以降のバイナリログが Aurora 上に全て保持されていること 1.で作成した Aurora から、EC2 及び RDS にレプリケーションしている対象のテーブルデータをエクスポートし、EC2 及び RDS にインポート 1.で指定した「特定時刻」に該当するバイナリログ（トランザクションログ）のログポジションを、Aurora 上に保持しているバイナリログから特定し、EC2 のレプリケーション開始ポジションに設定 EC2 上のバイナリログの現在のログポジションを確認し、RDS のレプリケーション開始ポジションに設定 EC2 及び RDS でレプリケーションを再開 今回はレプリケーション中継用の EC2 で障害が発生していますので、EC2 だけではなくその下流の RDS についてもレプリケーションの対象テーブルデータを特定時刻のデータ断面にリカバリする必要があります。この部分が手順 2-3 ですね。その上で、特定時刻以降のトランザクションログを対象としてレプリケーションを再開する部分が手順 4-6 にあたるのですが、ここが少々難解です。 まず、レプリケーションの設定は、レプリケーションのターゲットとなる MySQL で行う必要があります。つまり、Aurora ⇒ EC2 のレプリケーションについては EC2 上で、EC2 ⇒ RDS のレプリケーションについては RDS 上で設定します。そして先述の通りログポジションベースのレプリケーションを使用しているため、レプリケーション再開（再構成）にはレプリケーションのソースとなる MySQL のバイナリログポジションを指定する必要があります。つまり、RDS では EC2 のバイナリログポジション、EC2 では Aurora のバイナリログポジションをそれぞれ指定することになります。 この内、EC2 についてはレプリケーション中継用であり、元々 Aurora からのレプリケーションによる更新以外は発生しません。よって、手順 3 の完了後は 手順 6 によるレプリケーション再開までデータベースに更新が発生せず静止点が保たれるため、RDS のレプリケーション再開時に指定するログポジションは EC2 上のバイナリログの現在のポジションをそのまま使用すれば OK です。 一方で、EC2 の AZ 障害が発生しても Aurora は先述の通り継続稼働できるため、データの静止点は確保できないことから、EC2 と同じような方法ではバイナリログポジションの確認ができません。よって、代わりに Aurora 上のバイナリログの内容を確認して、手順 1 で指定した特定時刻に該当するログポジションを特定する必要があるということになります。つまり手順 4 ですね。 そして、この「Aurora 上のバイナリログの内容確認」手順が未検証であったため、やってみたところ意外と手間取ったというのが次セクションの話になります。 なお、AMI に含まれる EC2 上 MySQL のデータの一貫性/整合性が保証されており、かつそのデータ断面の時刻以降のバイナリログが Aurora 上に全て保持されている前提であれば手順 2 は不要です。この場合、手順 3 では EC2 上 MySQL のデータを RDS にエクスポート/インポートすることになります。 ただし、この方式では定期的に MySQL 及び EC2 を停止して AMI を取得する必要があるため、その間は Aurora ⇒ RDS 間のレプリケーションが実質的に停止してしまいます。その時間を許容できるかどうかが採用可否に直結しますが、本案件では NG だったため採用に至りませんでした。 また、AMI の取得間隔によって RTO が増大してしまうというのも考慮すべきポイントです。例えば 1 日間隔で AMI を取得していた場合は、障害発生のタイミング次第で最大 1 日程度のバイナリログを Aurora ⇒ EC2 ⇒ RDS と再度レプリケートする必要があるため、最終的な復旧までより多くの時間を要してしまう可能性があるためです。上記手順の場合は手順 2 においてできる限り最新の特定時刻を指定するようにしているため、レプリケート対象のバイナリログの量はより小さくなります。 Aurora 及び RDS の両方を使用しているアプリケーションの場合、Aurora への一部更新が RDS にレプリケーションされなくなることで継続稼働できなくなる可能性もあります。もし全てのアプリケーションがそのような構成だった場合は、逆に全てのアプリケーションを停止することで Aurora のデータ静止点を確保できることになるため、理論上は以下のように多少シンプルな手順とすることも可能です。 EC2 インスタンスを AMI から再作成 Aurora から、EC2 及び RDS にレプリケーションしている対象のテーブルデータをエクスポートし、EC2 及び RDS にインポート Aurora 上のバイナリログの現在のログポジションを確認し、EC2 のレプリケーション開始ポジションに設定 EC2 上のバイナリログの現在のログポジションを確認し、RDS のレプリケーション開始ポジションに設定 EC2 及び RDS でレプリケーションを再開 本案件の場合は、Aurora を使用しているアプリケーションは継続稼働可能 or 一部機能を縮退して継続稼働可能な構成であり、本障害からの復旧において Aurora 及びアプリケーションが継続稼働している前提で手順を確立する必要があったため、このような手順が必要となりました。   補足：MySQL のレプリケーション構成方式について さて、ここまで読んでお気づきの方もいると思うのですが、本構成で使用している ログポジションベースのレプリケーション構成方式 が、実のところ上記のように複雑な手順を必要とした理由となっています。 MySQL のレプリケーション構成方式というと、非同期・準同期レプリケーションのようにデータ同期のタイミングのことを指すとも捉えられますが、他に適当な言葉が思いつかなかったのでご了承ください。あえて言うなら「更新データのレプリケーション開始時点（どのバイナリログ/どのポジションから）を指定する方式」みたいな言い回しになってしまいますが、冗長もいいところなので・・ MySQL のレプリケーション構成方式は以下2種類があり、新しいのは GTID を使用した方式です。（と言っても初出は MySQL 5.6 なのでかれこれ 10 年以上前のことになりますが、、初めて案件で触ったのも 2013 年でした） GTID（Global Transaction ID）を使用したレプリケーション構成 バイナリログポジションを直接使用した使用したレプリケーション構成 GTID の説明は先般紹介した野上さんのエントリから引用させて頂きますが、以下の通りです。 GTID とは・・・ 発生元のサーバー (ソース) でコミットされた各トランザクションに関連付けられる一意の識別子です。 この識別子は、レプリケーション構成内のすべてのサーバーで一意です。 GTIDを使用することで、どのサーバにどのトランザクションまで実行してあるのかがわかるため、レプリケーション設定時に レプリケーションを始める トランザクションを自動で設定 してくれます。 よって、もし GTID を使用してレプリケーションを構成していた場合は、さきほど説明した一連の手順のようにバイナリログポジションを手動で導出及び再設定する必要がなくなるため、以下のように手順が大幅に簡略化されます。 EC2 インスタンスを AMI から再作成 Aurora のマネージド PITR 機能を使用して、特定時刻のデータ断面にリカバリした Aurora を作成 1.で作成した Aurora から、EC2 にレプリケーションしている対象のテーブルデータをエクスポートし、EC2 にインポート EC2 及び RDS でレプリケーションを再開 ちなみに、実環境の構成上は RDS へのデータインポートが不要になるメリットが大きいです。実環境では、RDS をソースとする下流のレプリケーション構成も複数存在するため、レプリケーション先のデータベースについても同様に対応する必要があるためです。RDS とのレプリケーション構成は維持されているので、RDS へのデータインポートを下流のレプリケーション先データベースにそのまま同期させる方式が一番シンプルではありますが、いずれにせよ時間はかかってしまいます。。 ここ最近は MySQL のレプリケーションの構成方式は基本的に GTID ベースが使用されることが多いため、本案件でも変更可否を打診してみたのですが、以下 URL のような GTID の制約に抵触していないかの影響調査、及び抵触している場合のアプリケーション改修が AWS への移行期間（カットオーバー）に合わなかったため、本障害時の想定復旧時間を許容頂く前提で最終的に見送りとなりました。 fw_error_www dev.mysql.com   バイナリログの確認自体はできるけど・・ さて、話が少々脇道に逸れてしまったので本題に戻りますが、「Aurora 上のバイナリログの内容確認」手順を検証すべく、マネジメントコンソールから Aurora のログセクションを確認してみたのですがバイナリログは見当たらず。ドキュメントも確認してみたのですが同様でした。いわゆる通常のログファイルとは扱いが異なるので、同じセクションにないこと自体は腑に落ちました。 RDS for MySQL データベースログの概要 - Amazon Relational Database Service RDS for MySQL データベースでモニタリングできるデータベースログについて説明します。 docs.aws.amazon.com 改めて調べてみると、 Aurora (RDS) からのバイナリログの取得（ダウンロード）については mysqlbinlog ユーティリティを使用する必要がある ことが分かりました。正直ちょっと驚きではありましたが、どちらにせよバイナリログの内容確認（＝PITR 対象の特定時刻に対応するログポジションの導出）にはこのユーティリティが必要なので、手順上は特に問題ありません。 MySQL バイナリログにアクセスする - Amazon Relational Database Service mysqlbinlog ユーティリティを使用して、RDS for MySQL DB インスタンスからバイナリログをダウンロードまたはストリーミングできます。バイナリログはローカルコンピュータにダウンロードされ、mysql ユーティリティを使... docs.aws.amazon.com ということで、後は Aurora (MySQL) 上からバイナリログ情報を確認して、ダウンロード＆内容確認する必要のあるバイナリログを特定できれば一通り手順を確立できると考えました。先述の通り、PITR 対象の特定時刻における更新が含まれているバイナリログが取得できれば良いので、バイナリログの最終更新日時だけでも分かれば対象が特定できると思い、Aurora (MySQL) 上からバイナリログ情報を確認してみたところ、、 mysql> show binary logs; +----------------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +----------------------------+-----------+-----------+ | mysql-bin-changelog.000009 | 743393 | No | | mysql-bin-changelog.000010 | 214 | No | | mysql-bin-changelog.000011 | 214 | No | | mysql-bin-changelog.000012 | 157 | No | +----------------------------+-----------+-----------+ 4 rows in set (0.01 sec) なんと、 バイナリログファイルの最終更新日時は MySQL 上の情報に含まれない んですね。そこで、どうやってバイナリログの最終更新日時を確認していたかを MySQL を良く触っていた当時の案件資料などから確認したところ、、 OS のファイルシステム上から最終更新日時を確認する手順となっていました。 もちろん当然ながら、Aurora/RDS 上ではこの方法は使えません。 さて困ったということで本腰を入れて色々調べてみたのですが、結論から言うと筋の良い方法がなかったため、最終的な手順としては以下の通り、ある意味繰り返し実行を前提とするようなあまりスマートではないものになってしまいました。。 show binary logs 文でバイナリログの一覧を取得 mysqlbinlog で最新のバイナリログ（原則ファイル名における通し番号が最も大きいもの）を取得し、そのバイナリログ内に PITR 対象とする特定時刻が含まれているかを確認 PITR 対象とする特定時刻が含まれていれば、そのログポジションを取得 PITR 対象とする特定時刻が含まれていなければ、次に新しいバイナリログを取得し同じ確認を繰り返す 先述の復旧手順の通り「できる限り最新の特定時刻に PITR する」ことで、より最新のバイナリログにその特定時刻に対応するログポジションが含まれている可能性が高まるため、上記の手順 2 における試行回数自体は低減できると思います。 ちなみに、show binlog event 文を使用すると、mysqlbinlog ユーティリティを使用することなくバイナリログ内のイベント（実際に実行された SQL 文など）やその時のログポジションを取得できますが、残念ながら時刻情報は取得できないので、今回のケースでは同ユーティリティを使用するしかありません。また、取得元サーバへの負荷も考慮すると、試行錯誤する前提ではバイナリログをダウンロードしてから中身を確認する方が無難かと思います。 もう一つ余談ですが、Oracle など他のデータベースの場合はトランザクションログに含まれる最初/最終の更新時刻がデータベース上から分かったりします。このあたりは RDBMS の種類（製品）によって機能差異が割とある印象です。   mysqlbinlog を使用した Aurora/RDS 上のバイナリログの取得・内容確認手順 ということで、最後に上記手順における mysqlbinlog のコマンド例についてまとめて本エントリを終わりたいと思います。なお、使用できるオプションについては以下の MySQL 公式マニュアルなども合わせてご参照ください。 fw_error_www dev.mysql.com   Aurora/RDS から対象のバイナリログをダウンロード こちらは特に難しくないですが、一応ポイントだけ書いておきます。 $ mysqlbinlog --host=<Aurora/RDSのエンドポイント名> --port=<Aurora/RDSのポート番号> --user=<ユーザ名> --password --read-from-remote-server --raw --verbose --result-file=<バイナリログの保存先> <ダウンロードするバイナリログ名> Enter password: <使用するユーザのパスワードを入力> –read-from-remote-server オプションにより、リモートサーバ（Aurora/RDS）からバイナリログを取得 データベース接続に使用するユーザには REPLICATION SLAVE 権限が必要 –raw オプション及び –verbose オプションは基本付けておくと良さそう（今回の用途だと –verbose は不要かも）   ダウンロードしたバイナリログ内における特定時刻以降のログポジションを取得 こちらの取得（導出）方法は複数あるとは思いますが、一例として記載します。 $ mysqlbinlog --start-datetime="<開始時刻（特定時刻）>" <バイナリログファイルパス> | head -n 20 このコマンドを実行すると以下のような出力結果が得られます。以下実行例では指定したバイナリログにおける 2026-01-21 14:05:32 以降の内容を取得しています。 $ mysqlbinlog --start-datetime="2026-01-21 14:05:32" binlog/mysql-bin-changelog.000004 | head -n 20 # The proper term is pseudo_replica_mode, but we use this compatibility alias # to make the statement usable on server versions 8.0.24 and older. /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/; /*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/; DELIMITER /*!*/; # at 4 #260119 2:34:34 server id 1770264728 end_log_pos 126 CRC32 0x46d7316f Start: binlog v 4, server v 8.0.42 created 260119 2:34:34 at startup ROLLBACK/*!*/; BINLOG ' OphtaQ+YGIRpegAAAH4AAAAAAAQAOC4wLjQyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA6mG1pEwANAAgAAAAABAAEAAAAYgAEGggAAAAICAgCAAAACgoKKioAEjQA CigAAW8x10Y= '/*!*/; # at 1450948 #260121 14:05:32 server id 1770264728 end_log_pos 1451027 CRC32 0x5369edb0 Anonymous_GTID last_committed=4592 sequence_number=4593 rbr_only=yes original_committed_timestamp=1769004332197054 immediate_commit_timestamp=1769004332197054 transaction_length=311 /*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/; # original_commit_timestamp=1769004332197054 (2026-01-21 14:05:32.197054 UTC) # immediate_commit_timestamp=1769004332197054 (2026-01-21 14:05:32.197054 UTC) /*!80001 SET @@session.original_commit_timestamp=1769004332197054*//*!*/; /*!80014 SET @@session.original_server_version=80042*//*!*/; あまり可読性は高くないのですが、上記出力結果における 「# at」に続く数値がログポジション、その次の行の「#」に続くタイムスタンプがそのポジションに対応する時刻 をそれぞれ示しています。また、mysqlbinlog ユーティリティの仕様として「# at 4」から始まるバイナリログ内の最初のログエントリ（7-14 行目）が必ず含まれています。–start-datetime で指定した時刻以降のログエントリが対象のバイナリログ内に含まれている場合は、その直後（15行目）以降に出力されます。上記実行例の場合は指定した時刻（2026-01-21 14:05:32）の更新が記録されていることが 16 行目から分かります。 よって、先述した復旧手順において確認すべきポイントは次の 2 つとなります。 最初のログエントリにおけるタイムスタンプが、PITR 対象の特定時刻より前の時刻であること –start-datetime で指定する時刻以降のログエントリが含まれていること –start-datetime で指定する時刻以降のログエントリが含まれていない場合、最初のログエントリのみが表示される よって、仮に先述した一連の復旧手順において、上記時刻を指定して PITR したデータを EC2 上の MySQL にインポートした場合、EC2 上でレプリケーション再開のために指定すべきバイナリログファイルは「mysql-bin-changelog.000004」、ポジションは「1450948」となります。 なお、先述の復旧手順において重要なのは上記の通りログポジションとそれに対応するタイムスタンプなので、grep コマンドなどを使用して出力内容を絞った方が見やすいかもしれません。例えばこんな感じです。 $ mysqlbinlog --start-datetime="2026-01-21 14:05:32" binlog/mysql-bin-changelog.000004 | egrep -A 1 "^# at" | head -n 20 # at 4 #260119 2:34:34 server id 1770264728 end_log_pos 126 CRC32 0x46d7316f Start: binlog v 4, server v 8.0.42 created 260119 2:34:34 at startup -- # at 1450948 #260121 14:05:32 server id 1770264728 end_log_pos 1451027 CRC32 0x5369edb0 Anonymous_GTID last_committed=4592 sequence_number=4593 rbr_only=yes original_committed_timestamp=1769004332197054 immediate_commit_timestamp=1769004332197054 transaction_length=311 -- # at 1451027 #260121 14:05:32 server id 1770264728 end_log_pos 1451119 CRC32 0xb1f278f0 Query thread_id=28836 exec_time=0 error_code=0 -- # at 1451119 #260121 14:05:32 server id 1770264728 end_log_pos 1451184 CRC32 0x4c427a20 Table_map: `repl_test`.`record_table` mapped to number 122 -- # at 1451184 #260121 14:05:32 server id 1770264728 end_log_pos 1451228 CRC32 0x3e65d56d Write_rows: table id 122 flags: STMT_END_F -- # at 1451228 #260121 14:05:32 server id 1770264728 end_log_pos 1451259 CRC32 0xf59a6d5b Xid = 1459644 -- # at 1451259 #260121 14:05:32 server id 1770264728 end_log_pos 1451338 CRC32 0xc31d6b97 Anonymous_GTID last_committed=4593 sequence_number=4594 rbr_only=yes original_committed_timestamp=1769004332431555 immediate_commit_timestamp=1769004332431555 transaction_length=311   まとめ ちょっと想定以上に長くなってしまったこともあり、2本構成のエントリの前半を構成説明～復旧手順まで、後半を Aurora/RDS 特有のトピックとしてまとめる方が収まりが良かった気がします、、が、先般のエントリではマネージド PITR の挙動にフォーカスして説明したかったこともありご容赦ください。個人的にあの挙動は結構衝撃的だったので。。 また、mysqlbinlog 自体は MySQL を触っていれば多少なりとも馴染みのあるユーティリティではあるのですが、RDS/Aurora のバイナリログを取得するために使用することになるとは思いませんでした。マネジメントコンソールから取得できるようになっていると便利だなと思いつつ、必要となるケースは少ないから仕方ないかなとも思います。 ただ、バイナリログの一覧や更新日時については、マネジメントコンソールなり AWS CLI なり、別の手段で確認できるようにしておいて欲しいところです。MySQL 側から確認の術がないという仕様も同じくらいどうかとは思うんですけど、結果的にこの点を確認するためにやや非効率な手順が必要となってしまっているのは否めず。サーバレスアーキテクチャが当たり前になりつつ昨今、マネージドサービスの制約である「OS レイヤーを直接触れない」ことの弊害を久々に感じた出来事でした。 本記事がどなたかの役に立てば幸いです。

TechHarmonyエンジニアブログでは、 AWS・Oracle Cloud・Azure・Google Cloud 各分野の受賞者 にフォーカスし、インタビューを通してこれまでの経歴や他の受賞者に聞いてみたいことをつないでいく「 リレーインタビュー 」をお届けしています。 第二弾は、「2025 Japan AWS Jr. Champions」 を受賞された 佐藤 優音（さとう ゆうと）さん。 Japan AWS Jr. Champions は、AWSを積極的に学び、自らアクションを起こし、その取り組みが周囲にも良い影響を与えている若手エンジニアが選出されるプログラムです。 日々どのようにAWSと向き合い、どんな経験を積み重ねてきたのか。 そして、受賞に至るまでの背景には、どのようなキャリアストーリーがあったのでしょうか。 本インタビューでは、佐藤さんのこれまでの経歴やAWSへの向き合い方、さらに「次の受賞者へ聞いてみたいこと」まで、じっくりとお話を伺いました。 プロフィール 2025 Japan AWS Jr. Champions 所属： 製造事業グループソリューション第一事業本部コンサルティング第三部 氏名： 佐藤　優音 【自己紹介】 製造事業グループソリューション第一事業本部コンサルティング第三部に所属をしている佐藤優音と申します。普段は   OracleのSaaS型 ERPパッケージの導入、リフトを担当 しております。AWSは業務では未経験で、自己研鑽（趣味）の範囲内で構築や勉強会の登壇などを行い、2025 Japan AWS Jr. Champions に選出いただきました。   本編  AWSエンジニアになった背景を教えてください。 学生時代、SaaSのスタートアップでインターンをしていた頃は、正直AWSって自分には関係ないものだと思っていました。ITのスペシャリストだけが触れる特別な技術というか、そんなイメージでした。当時は技術そのものより、IT技術を使ってお客さんの課題をどう解決するかという方に興味があったと思います。 AWSに興味を持ったきっかけは資格取得だったんですが、そこから実際にハンズオンをやってみたら 「こんなに簡単にシステムが作れるの？」 って驚いて。自分の思い描いたものを形にする楽しさにすっかりハマってしまいました。案件ではAWSを触る機会がなかったのですが、勉強会で登壇して自分の発表にフィードバックをもらえるのがすごく楽しくて。他の人の発表を聞くたびにモチベーションも上がりましたし、 勉強会に参加することが とても大きな経験 だったと思います。今は登壇やブログ、勉強会の開催に力を入れて 、 もっと多くの人が 気軽にAWSを始められる 環境を作っていきたいな と思っています。 エンジニアとして大切にしている価値観や信条はありますか？ 一番大事 にしているのは、 技術の裏側をちゃんと理解 すること です 。なんとなくの理解でも作業は進められるますが、どういうロジックでどんな処理がされているのかを正しく理解しておくと、後々の作業効率が全然違うんです。メンバーに引き継ぐときも、 説明がスムーズになりますね。 そして技術を理解するだけじゃなくて、それを分かりやすく伝える力も大事だと思っています。案件だとメンバーに自分の考えを伝えたり、お客さんの意見を聞いたりする場面が多いのですが、自分一人が理解していてもプロジェクトはうまく回らないと感じています。だからこそ 技術力を高める のはもちろん、 それを 正しく伝える 力 も磨いていきたい なと。 あとは務理解と技術理解の両輪をしっかり回すことですね。このバランスが崩れると、実現できない提案をしちゃったり、開発者目線だけのシステムになったりするので、 業務を正しく 回すために技術をどう活かすか 、それを常に考えながら仕事をしています。 この度は受賞おめでとうございます！ 受賞に至るまで特に重点を置いて取り組んできたこと・乗り越えたチャレンジを教えてください。 月1〜2回くらいのペースで勉強会に登壇したり、ブログを書いたりしていました。特に勉強会では、ちょっとユニークなテーマでハンズオンをやったり、技術的な部分もなるべく分かりやすく説明したり、初めてAWSに触れる人でもとっつきやすい発表を心がけていました。 また AWS BuilderCardsを使ったイベント運営 にも力を入れて、 初心者の方とベテランの方をつなぐ場づくり をしてきました。 案件とは全く別の領域を学び続けるのはかなり大変でした 。でも 「 AWSとOracleの両方 を極めたら どんな世界 が見えるんだろう 」 という 好奇心 のおかげで 広く学ぶ楽しみ みたいなもの を 実感 できた気がしています。 受賞がご自身のキャリアやチームに与えた影響はありますか？ Jr. Championsに選んでいただいてから、 AWSの活動がすごくやりやすくなったと実感しています。社内外問わず「Jr. Championsだから」っていうことで声をかけてもらえることが増えて、関われるイベントの幅も広がりました。それに、自分よりもっとアウトプットしているすごいメンバーと交流できるようになって、 毎日とても いい 刺激 を受けています。 業務では直接的に活きることは少ないですが、コミュニティでの関わり方とか自己研鑽のモチベーションが上がったりとか、間接的にいい影響はあるなと感じています。 今後はもっと周囲に影響を与えてみたいです。具体的には自分みたいに業務でAWSを使わない初心者の方でも始めやすい環境づくりに力を入れていきたいです。 自分でサーバーを買わなくても 従量課金で 手軽にハンズオンができるというクラウドの魅力 を活かして、 「 AWSに 興味 はあるけど 一歩踏み出せない 」 といった方の 背中を押せたら いい な と思っています 。 今後、個人として、挑戦してみたい新しい技術・分野や、目指している目標について教えてください。 今後はAWSの案件にも携わってみたい です。ERPの知識とAWSの知識を掛け合わせられたら、それが自分の強みになると思っているので、広い視野を持ってAWSに関わっていきたいです。   コミュニティ活動では、もっと運営力を磨いて、 自分がいなくても自立して回っていくようなコミュニティを作りたい なと思っています。最初の旗振りはもちろん大事なんですけど、やっぱり旗振りする人がいなくても自律的に成長していけるコミュニティが一番強いと思うんです。だから今関わっているコミュニティがもっと活性化するように、しっかり携わっていきたいです。   個人としては、 もっと AWSの 技術力を上げて いきたい です。趣味で触っているとどうしても業務的なシステムに関わる機会が少なくて、課金の都合もあって大規模なシステム構築も難しいのが正直なところでして… 。 苦手な分野をなくして 、 いろんなサービスに 知見を 持てるように 成長していきたい と思っています。 前回のリレーインタビュー での間世田 秀さんから 佐藤さんへのご質問です。ご回答をお願いいたします。 佐藤さんは、業務ではOracleを扱っているとお聞きしました。 AWS と Oracle 並行して、 学び続ける秘訣 を教えてください！ 「やはり自分の好奇心を信じて進めていくことかなと思います。AWSを学んでOracleの知識が生きること、Oracleを学んでAWSの 知識が生きることが 学習していると 必ず見つかる ので、それらに対して楽しさを見出すことでこれまで二刀流を続けることができていると思っています。自分の 得意を複数領域をかけ算して作り出す ことで、唯一無二の存在になれると信じて日々学習しています！」 次のインタビューは AWS Top Engineers の「寺内 康之 」さんです！寺内さんにお聞きしたいことはありますか？ 寺内さんは、クラウド 黎明期 から 新しいサービスに関する知識 を積極的に 収集 されてきたと思いますが、常に最新技術をキャッチアップするための ポイントを教えて ください！ 佐藤 優音さん、ありがとうございました！ 最後に、読者の方へメッセージをお願いいたします！ 私はAWSを業務で扱っていないのに表彰を受けるというややレアケースではありますが、こういう人間がJr. Championsとして選出されることで、 興味とやる気さえあれば不可能なことはない ということを少しは体現できたかなと思っています。これからも自分の好奇心に身を任せて 守備範囲の広いエンジニアとして精進してまいります！   次回インタビューは、2025 Japan AWS Top Engineers を受賞された 寺内 康之（てらうち やすゆき）さんです。 次回の記事もお楽しみにお待ちください！

こんにちは、クラウドサービス関連の業務をしている藪内です。 本記事は、 「AWSパラメータシート自動生成ツール」 についてのブログリレーの最終回（5本目）です！🎉 前回は、フロントエンド技術について解説しました。概要や要件定義、機能については過去回の記事をご参照ください。 今回は本ツールをユーザーとして利用し、使用感や手作業との比較結果について紹介します。 AWSのパラメータシート作成自動化ツールの取り組みについて ~概要編~ – TechHarmony AWSパラメータシート自動生成ツールの要件定義編 – TechHarmony Python × AWS CLIで「AWSパラメーターシート自動生成ツール」を作ってみた – TechHarmony AWSパラメータシート自動生成ツール ~フロントエンド編~ – TechHarmony 検証概要 ユーザー視点でのツール利用体験と所感 手作業と自動生成ツールにおける作業時間の比較 ユーザー視点でのツール利用体験と所感 本ツールは現在38種類のAWSリソースに対応しています。 その中から、「Amazon VPC」を例に取り、パラメータシート自動生成を検証しました。 また、複数のリソースのパラメータをまとめて出力できることを検証するために「Amazon S3バケット」のパラメータも出力しました。 主なユースケースとしては、構築したAWSリソースの詳細なパラメータを体系的かつ整形されたドキュメント（いわゆるパラメータシート）として出力・管理する場面を想定しています。 実際にツールを起動し、 数ステップで完成度の高いパラメータシートを作成できました！ 以下に、初期画面からパラメータシート作成までの各画面構成と、それぞれの所感や利点を整理しています。 ページ遷移その1 ページ遷移その2 ページ番号 概要 感想/利点 ① リソースのタイプの種類選択 種類ごとにリソースがまとめられており、選択しやすい！アイコンや略称、その説明があってわかりやすい。AWSらしいカラーの画面です。 ② リソースのタイプの選択 選択したリソースタイプがオレンジ色に変化します。 ③ ツールがパラメータを取得するために実行するコマンドの確認 出力されるパラメータの正当性が確認できます！ ④ パラメータを出力する対象のリソースの検索 検索でリソースを限定できます ⑤ リソースの選択 選択するとチェックマークの表示がされ、色も変化して見やすいです。 ⑥ 確認 一度確認画面があると誤った作成が減ります。 ⑦ リソースの追加 一度に複数のリソースのパラメータを出力できます。 ⑧ パラメータシートの作成 自動で非常に整ったシートを作成してくれます！！表紙も付いています！（パラメータ値は非表示加工済み） パラメータシート自動生成ツールがなければ、APIを手動で実行しながらエクセルに一つずつ入力し、確認までする必要がありましたが、数ステップで作成可能なのは感動です…！ 手作業と自動生成ツールにおける作業時間の比較 従来の手作業による作成と本ツールを用いた自動生成の所要 時間を比較しました。 対象とした作業は、特定のVPCについてのパラメータシート作成です。 手法 作業時間 作業範囲 手作業 6分10秒 VPCコンソールを表示してからパラメータシートの値入力まで 自動生成ツール 2分04秒 アプリを起動してからパラメータシート表示まで この結果、 約4分 の作業時間短縮につながりました！個人の操作スピードによる差はありますが、自動生成ツールを利用することで、個々の作業速度依存を低減でき、リソース件数が増えるほど工数削減効果が顕著になると考えられます。 また、手作業では入力ミス防止のための再確認が不可欠なのに対し、自動生成ツールは正しいコマンド実行による取得値を活用するため、ヒューマンエラー低減にも大きく寄与します。 また、パラメータ値の表記（例えば、Boolean値をTrueと記載するか、trueと記載するかなど）を統一できる点や、パラメータの詳細な知識なしでもシートが作成できる点も魅力に感じました！ まとめ 以上、AWSパラメータシート自動生成ツールの使用体験と、手作業との比較について解説しました。 手作業によるパラメータシートの作成は、パラメータ値の確認とエクセルへの転記を中心として数時間を要する作業です。加えて、記入内容の誤りを防ぐために確認を繰り返したり、パラメータ値の変更を反映するために作り直したりすると、細かな作業の連続で非常に神経をすり減らします。自動生成ツールはこれらの問題を解決し、利用者間で形式が統一されたパラメータシートの作成を可能にしてくれます。また、短縮して空いた時間を設計や実装、管理など異なる作業に使うことができ、プロジェクトの工数を削減できます。 機会があれば、実業務でも積極的に活用したいと考えています。 最後までご覧いただきありがとうございました。

初めまして。 AWS上で大規模な会員向けアプリケーションの構築・運用に携わっています。 本記事では、 OpenSearchとSageMakerを組み合わせたセマンティック検索基盤の構築事例 を紹介します。 既存のOpenSearchにカスタムAIモデルを連携する構成について、検討の過程と構成例を整理しています。 また、当初のデプロイ時に直面した課題や、最終的にSageMakerを採用するに至った技術選定の背景についても触れています。 2. 現状の検索構成 先日、アプリケーション開発チームより、次のような相談を受けました。 「クーポン検索機能を高度化するカスタムAIモデル（DistilUSE）を作ったので、こちらをAWS上にデプロイして既存のOpenSearchと連携してほしい」 現状の検索機能は、 OpenSearchを中心とした比較的シンプルな構成 になっていました。 アプリケーションユーザーからのクーポン検索リクエストは、まず ECS上で稼働しているアプリケーション（コンテンツ取得API） に送信されます。このAPIが検索条件を受け取り、 OpenSearch Serviceの検索APIを呼び出すことで検索処理を実行 します。 OpenSearch側ではクーポン情報をインデックスとして保持しており、検索処理は主に キーワード検索（完全一致・部分一致） によって行われていました。検索結果はAPIを経由してアプリケーションに返却され、最終的にユーザー画面へ表示されます。 また、OpenSearch ServiceおよびECSは同一VPC内に配置されており、通信はALBを介して行われる構成です。 この構成では、検索処理の責務はすべてOpenSearchが担っており、 検索クエリの解釈や意味的な理解といった処理は行っていない状態 でした。 図1：ECS上のAPIからOpenSearchを直接呼び出し、検索結果を返す構成 3.構成検討の過程 アプリケーションチームから依頼を受け、まずは 既存の構成を大きく変えずにカスタムAIモデルを組み込めないか を検討しました。 その選択肢の一つとして、OpenSearchが提供する ML Commons 機能の利用を検討しました。 ML Commonsでは、S3に配置したモデルをOpenSearch側でロードし、検索処理の中で推論を実行する仕組みが提供されています。 この仕組みを利用すれば、推論用のサーバーを新たに用意する必要がなく、アーキテクチャを比較的シンプルに保てると考えました。 そこで、アプリケーション開発チームから受領した カスタムAIモデル（DistilUSE / tar.gz） をS3に配置し、OpenSearch Serviceからモデルのロードを試みました。 しかし、結果としてこの構成は実現できませんでした。 今回受領したカスタムモデルは、 OpenSearch Service（マネージド環境）におけるML Commonsの制約により、そのまま有効化することができない仕様だったからです。 このため、 OpenSearch内部でモデルを実行する構成は断念 し、別のアーキテクチャを検討することにしました。 図2：S3に配置したモデルをOpenSearch内部で実行する構成（検討時） ML Commons を利用できなかった理由 ML Commons の利用を見送った理由は、主に 実行環境とマネージドサービスとしての制約 にあります。 受領したカスタムAIモデルは Python（PyTorch）ベース で構築されていましたが、OpenSearch Service の ML Commons は Javaベースの実行環境 を前提としています。そのため、モデルをそのまま実行することが難しく、形式変換などの追加対応が必要となりました。 これらの対応は工数や運用面の負荷が大きく、今回は現実的ではないと判断しました。 また、OpenSearch Service はマネージドサービスであるため、外部から持ち込んだカスタムモデルを柔軟に実行すること自体に制約があります。 以上の検討を通じて、 検索エンジンに計算処理を持たせる構成は適切ではない と判断し、計算処理は専用の実行基盤に切り出す方針としました。 次章では、この方針を踏まえて採用した SageMakerを用いた構成 について説明します。 4.最終アーキテクチャ 検討の結果、 計算処理は計算専用のリソースに切り出すべき と判断し、カスタムAIモデルの実行基盤として Amazon SageMaker を採用しました。 最終的なアーキテクチャを図3に示します。 本構成では、検索機能そのものは引き続きOpenSearchが担い、検索クエリやドキュメントのベクトル化といった 計算負荷の高い処理をSageMakerの推論エンドポイントに委譲 しています。 これにより、OpenSearchに過度な処理を持たせることなく、役割を明確に分離した構成とすることができました。 図3：SageMaker推論エンドポイントと連携した最終構成 5. SageMaker採用の背景 ここは今回の構築において、最も検討に時間を要したポイントです。 「Amazon Bedrock（サーバーレス）を利用すれば、より簡単に実装できたのではないか」 という選択肢もありましたが、最終的には SageMakerを用いた自前構築が最適 と判断しました。 理由は大きく2点あります。 理由1：カスタムモデルの利用要件 Amazon Bedrockは、あらかじめ用意された基盤モデルをAPI経由で利用できるサービスです。 一方で、利用できるモデルはBedrock側で提供されているものに限定されます。今回のケースでは、アプリケーション開発チームより 特定のカスタムモデル（DistilUSE）を利用したい という明確な要件がありました。 この要件を満たすには、モデルや実行環境を自由に構成できるSageMakerを採用する必要がありました。 理由2：スケールとコストの観点 今回対象としたシステムは、 全国規模のECサイト であり、検索リクエストが高頻度かつ継続的に発生することが想定されます。 BedrockのようなAPIベースのサービスは従量課金であるため、 リクエスト数の増加に伴うコストの増大 レート制限（スロットリング）による影響 といった点が懸念されました。 一方、SageMakerの推論エンドポイントは、 インスタンスをプロビジョニングすることで、一定のコストで安定した処理能力を確保 できます。大規模なトラフィックを前提とした場合、コストの見通しやすさと安定性の面でSageMakerの方が適していると判断しました。 6. 構築時のポイント 構築にあたっては、以下の点を重視しました。 役割の分離 検索処理はOpenSearch、ベクトル化などの計算処理はSageMakerとし、各コンポーネントの責務を明確に分離しました。 閉域網でのセキュリティ確保 SageMakerの推論エンドポイントはVPC内に配置し、OpenSearchとはVPCエンドポイント経由で通信させています。 データがインターネットを経由しない構成としました。 アプリケーションへの透過性 OpenSearchのIngestionパイプラインを活用することで、アプリケーション（ECS）側は裏でSageMakerが動作していることを意識せず、従来通り検索リクエストを送信するだけで利用可能としています。 なお、AIモデルのデプロイには AWS公式のDeep Learning Container を使用し、アプリケーションチームから受領した model.tar.gz （モデル本体・設定・辞書）をそのまま推論環境として利用しています。 7. まとめ 本構成により、コストや運用リスクを抑えつつ、柔軟な検索機能を実現できるアーキテクチャを構築することができました。 また、補足として、S3に配置したシノニム辞書をOpenSearchと連携させることで、検索精度の底上げも行っています。 今回の取り組みを通じて、AI機能の実装においては 用途や規模に応じたサービスの使い分けが重要 であると改めて感じました。 Amazon Bedrock 手軽に始めたい場合や、小〜中規模でモデルに強い制約がないケース Amazon SageMaker 特定のモデルを利用したい場合や、大規模アクセスを前提とするケース 単に動作する仕組みを作るだけでなく、将来的なスケールや運用まで見据えた設計を行うことの重要性を学ぶ良い機会となりました。