以前、Disaster Recovery 機能を用いたLifeKeeperの構築を行いました。 AWS環境でのLifeKeeperを用いた災害対策！Disaster Recovery Add-on 構築＆機能検証 災害対策サイトへのリアルタイムでのデータレプリケーションと、フェイルオーバーを可能にするDisastar Recovery Add-onの設定手順と機能検証を行いました。 blog.usize-tech.com 2025.02.05 検証環境を一から作成し、LifeKeeperのインストールを初めて行ったのですが、 その際に生じた躓いたところを、自分への備忘もかねて今回まとめました。 概要 AWS環境のRed Hat Enterprise Linux に LifeKeeperをインストール Disaster Recovery Add-onの初期設定及びリソース作成/拡張を実施 インストール時 まず初めにLifeKeeperをインストールの際のトラブルシューティングです。 事前に確認しておくべき項目を記載しておきます。 ライセンスが有効であるか 初歩的なことですが、一番大事な確認かもしれません。 ライセンスが有効になっているか、期限が切れていないかまずは確認しましょう。 SELinuxが無効化されているか SELinux が enforcing モードの場合 、LifeKeeper は動作しないため無効となっているか確認しましょう。 確認コマンド：sestatus 上記事項の確認を終えましたら、インストールに移っていきます。 インストールの手順としては、isoファイルを対象のノードにセットして、セットアップを実行していきます。 私が初めて実施した際は、まずその段階でエラー発生しました。 # ./setup LifeKeeper for Linux Setup Validating files........................................................................OK Collecting system information.....................................done. Preparing configuration information............done. Performing package installation and updating configuration information for LifeKeeper for Linux. Install LifeKeeper and dependent packages done. Setup failed. Fix the problem and try again. ---error message---   - Status code: 999 for https:/--- Error: Failed to --- # 上記表示のように、エラーメッセージやエラーコードが表示されました。 セットアップコマンドが失敗した際は、エラー原因を確認し該当の箇所をある程度は切り分けられることができますので、 対処をして再度チャレンジしていきましょう。 インストールが完了しましたら、LifeKeeperが起動しているか確認してみましょう。 確認方法としては、/opt/LifeKeeper/bin/lktest　を実行すると確認ができます。 # /opt/LifeKeeper/bin/lktest F   S UID      PID   PPID  C  CLS PRI  NI SZ    STIME    TIME   CMD  4 S root     23199 23134 0   TS   39 -20 4579  05:29  00:00:00 lcm  4 S root     23201 23140 0   TS   39 -20 5526  05:29  00:00:00 ttymonlcm  4 S root     23205 23133 0   TS   29 -10 6674  05:29  00:00:00 lcd # 上記コマンドを実行して出力がされていれば、無事LifeKeeperは起動されております。   リソース作成時 続いて、LifeKeeperのインストール完了後、リソースと呼ばれる、LifeKeeperにて保護するアプリケーションやファイルシステムを設定する中でのトラブルシューティングとなります。 今回はDisaster Recovery Add-onにおけるDRBDリソース作成および拡張時におきたトラブルシュートの例を記載いたします。 リソース不足 デフォルト値の設定にてリソース作成を試みたところ容量不足でエラーが発生しました。 1.0MBで容量が不足とのことなのでこちらの対処として、AWS EBS で10 GiBのサイズを対象 インスタンスへの割り当てを行い、こちらのエラーは解消となりました。   パーティション作成 続いて、DRBDリソース作成時に発生したエラーです。 このエラーは、パーティションの無いデバイスに対して操作を行うと生じるエラーとのことでした。 こちらは検証を行っていた段階では製品マニュアル等に記載が無い情報となりメーカーのサポート窓口と密にやり取りを行い解消できた事象となります。 対処として、マウント対象のデバイスに対してパーティションを作成し事象が解消となりました。 そのため、データレプリケーションリソース作成の際は、事前にデバイスの確認を行い、無いようであればディレクトリにパーティションの作成を行いましょう。   パーティションの作成方法としては以下となります。 fdiskを使用して新しいパーティションを作成または修正します。 ● sudo fdisk /dev/＜対象デバイス名＞ ● n を押して新しいパーティションを作成。 ● p を選んでプライマリパーティションを設定。 ● 必要に応じて値を設定し、最後にパーティション変更を保存するために w を押します。              　 DRBDリソース再作成時の注意点 一度リソースの作成ができず、再度リソースの作成を試みようとしたとき、 DRBD の設定が残っている可能性があり、その場合リソース作成でエラーが発生いたします。 その際は以下のコマンドを実行をして余分な情報を削除する必要があります。 rm /etc/drbd.d/*res* ※該当 ファイルの削除確認が表示されますので y で削除してください。 (何度もリソース作成をしていたので、何回も削除をして疲れた思い出があります。)   コミュニケーションパス作成時 リソース拡張前にコミュニケーションパスを作成する リソース拡張という操作をするのですが、そもそもリソース拡張とは、なんぞやというところですが リソース拡張とは1号機、2号機で作成したリソースを簡単に言うと紐づける動作となります。 その際の動作ですが、コミュニケーションパスで接続されているサーバーがないとそもそもLifeKeeper側で認識ができず、拡張ができないとのことです。 なので、先にコミュニケーションパスの作成をしましょうというお話です。 ちなみに、コミュニケーションパスの作成が完了し1号機、2号機が接続されている状態でリソース拡張先のサーバーでも該当のARL(今回の場合 DRBD ARK) やとLifeKeeperの設定をGUI上で行うLKWMC のインストールの準備が必要となります。こちらが行えていたら、リソース拡張操作で DRBD リソースの拡張が行えるようになります。   名前解決 コミュニケーションパスの作成時にも、もちろん(？)エラーが発生しました。 エラー原因は1号機、2号機間での名前解決が出来ていないからでした。 今回は、hostsファイルに対象のホスト名を明記し、解消しました。 vi /etc/hosts 192.168.xx.xx 10.142.xx.xx   対象ポートの許可  以下のTCPポートの許可設定が必要となります。 サービス ポート番号 コミュニケーションパス (TCP) 7365/tcp GUI サーバーとの通信 81/tcp、82/tcp GUI サーバーとクライアントとの RMI 通信 1024/tcp 以降の全ポート LKWMCの通信GUIサーバー 5110/tcp LKWMCのREST APIサーバー 5000/tcp   Disaster Recovery Add-on機能の確認時 無事DRBDリソース作成及び拡張ができ、設定が完了したかと思い、機能の確認をしたのですが想定通りの動作がせず困ったことに、、、 そこで有識者に確認をしてみたところQuorum/Witness の設定をしてみたらどうかとの見解を頂きました。 構成例 - LifeKeeper for Linux LIVE - 9.9.0 ここでは DRBD を用いた３ノードディザスターリカバリーの構成例を説明します。 概要 以下の AWS... docs.us.sios.com storage モード - LifeKeeper for Linux LIVE - 9.6.1 docs.us.sios.com Quorumパラメータ一覧 - LifeKeeper for Linux LIVE - 9.4.0 下記の表は、Quorumパラメーター名とその意味を説明しています。これらの値は /etc/default/LifeKeeper... docs.us.sios.com 上記3つの資料を参考にQuorum/Witnessの設定をしてみたのですが、/opt/LifeKeeper/bin/qwk_storage_initを実行でエラーが出てしまいました。 よくよく確認すると、AWS CLIの設定を修正(アクセスキー設定を統一)して再度実行したところ解消しました。 その後、東京リージョンのノードを落として、データレプリケーションが大阪ノードで行われるかの機能について確認したところ、 無事フェイルオーバーとデータレプリケーションを確認できました！復旧後の動作も問題なく確認できたため検証終了となりました。 参考設定値 ＃cat /etc/default/LifeKeeper NOBCASTPING=1  QUORUM_MODE=storage WITNESS_MODE=storage ～以下省略～ # Do NOT edit LK_DISTRIBUTION values – this may cause LifeKeeper to malfunction LK_DISTRIBUTION=redhat LK_DISTRIBUTION_VERSION=9.4-0.4.el9 QWK_STORAGE_TYPE=aws_s3 QWK_STORAGE_OBJECT_ip_10_142_xx_xx_compute_internal=s3://drbd/～ QWK_STORAGE_OBJECT_ip_10_142_xx_xx_compute_internal=s3://drbd/～ QWK_STORAGE_OBJECT_ip_192_168_xx_xx_compute_internal=s3://drbd/～   まとめ 今回の検証作業では、一歩進んでは躓き、そこからまた一歩進んだかと思えば違う壁にぶつかりと一進一退の作業でした。 今回行ったトラブルシューティングの対応を今後に活かしていき、スムーズなLifeKeeperの構築を目指していきたいです。 本記事についてより詳しい内容を知りたい方がいらっしゃいましたら 以下画像をクリックし、HPよりお気軽にお問い合わせください。  

本記事は 新人ブログマラソン2024 の記事です 。 皆さん、こんにちは！新米エンジニアの佐々木です。 前回は、Snowflakeの新機能コンピュートプールについて記事にまとめさせていただきました。多くの方々に読んでいただき、大変嬉しく思っています。 まだ読めていないという方は、以下の記事をまずは読んでいただけると幸いです！！ Snowflake の新機能！コンピュートプールについて調査してみた – TechHarmony さて今回は、前回の記事の続編ということで、実際に コンピュートプールを用いたSnowflakeの公式チュートリアル に挑戦してみました！ 今回は、そのチュートリアルを通して学んだことについて共有したいと思います。 チュートリアルの概要 今回は「 Snowpark Container Servicesサービスを作成する 」という題材のチュートリアルを実施しました。 チュートリアル1: Snowpark Container Servicesサービスを作成する | Snowflake Documentation docs.snowflake.com えっ、コンピュートプールのチュートリアルじゃないの？と思われた方もいるかと思います。 実は今回扱うSnowpark Container Servicesを理解するにはコンピュートプールへの理解が必要不可欠となります。そのため今回は上記のチュートリアルを実施することにしました！ Snowpark Container Servicesって何？ Snowpark Container Services（以下、SPCS）は、 Snowflakeの強力なデータプラットフォーム上で、コンテナ化されたアプリケーションを直接実行できる画期的なサービス です。Dockerコンテナを活用することで、機械学習モデルのデプロイ、APIの構築、ストリームデータ処理など、様々なワークロードをSnowflake内で実行できます。 これにより、 データとアプリケーションの近接性：  データ移動のコストを削減し、パフォーマンスを向上 Snowflakeのセキュリティとガバナンス：  Snowflakeの強固なセキュリティとガバナンスをそのまま利用可能 スケーラビリティ：  Snowflakeの柔軟なスケーラビリティを活用 といったメリットが生まれます。 コンピュートプールとは？ SPCSを理解する上で欠かせないのが コンピュートプール です。コンピュートプールは、Dockerコンテナを実行するための計算リソースの集合体であり、簡単に言うと「アプリケーションを動かすためのサーバーのグループ」のようなものです。 なぜコンピュートプールが必要なのか？ SPCSでは、Dockerイメージを元にコンテナを作成し、そのコンテナ内でアプリケーションを実行します。コンテナは、CPU、メモリ、ストレージなどのリソースを必要としますが、コンピュートプールは、これらのリソースをコンテナに提供する役割を担います。 つまり、 コンピュートプールがあるからこそ、SPCS上でアプリケーションを動かすことができる のです！ チュートリアルの流れ では上記を踏まえたうえで、実際にチュートリアルを進めた流れについて以下に示します。 環境構築: Snowflakeアカウントの準備、SPCSが利用可能なリージョンの確認、必要なロールの付与など、基本的な環境設定を行う イメージリポジトリ作成: SnowflakeにDockerイメージを保存するためのリポジトリを作成する。これが、コンテナ化されたアプリケーションの保管場所となる イメージプッシュ: ローカルでビルドしたDockerイメージを、先ほど作成したリポジトリにプッシュする。今回の例では、シンプルなHello Worldアプリケーションのイメージを使用する コンピュートプール作成: ここが重要なポイント！SPCSでコンテナを動かすためのリソースとなるコンピュートプールを作成する。CPU、メモリ、インスタンス数などを指定し、アプリケーションのニーズに合わせた構成を定義する サービス定義: コンテナサービスを定義する。どのイメージを使うのか、どのコンピュートプールで動かすのか、ポート設定などを指定する サービスデプロイ: 定義したサービスをデプロイする。Snowflakeが自動的にコンテナを起動し、サービスを稼働状態にする サービスエンドポイントアクセス: 外部からサービスにアクセスするためのエンドポイントを確認し、ブラウザなどでアクセスしてアプリケーションが正常に動作することを確認する この記事では大まかな流れについてしか触れませんが、より具体的なことを知りたい方は公式チュートリアルをご覧ください！ コンピュートプールの重要性 このチュートリアルを通して、特に重要だと感じたのが コンピュートプール の存在です。コンピュートプールは、SPCS でコンテナを実行するためのコンピューティングリソースの集合体であり、以下の役割を担っています。 リソースの管理: CPU、メモリ、GPU などのリソースをプールとして管理し、SPCS で実行されるコンテナに割り当てる スケーラビリティの実現: コンピュートプールのサイズを調整することで、アプリケーションの負荷に合わせて柔軟にスケーリングする 分離性の確保: 異なるワークロードに対してコンピュートプールを分けることで、リソースの競合を防ぎ、安定したパフォーマンスを維持する チュートリアルでは、 COMPUTE_POOL_INSTANCE_FAMILY に STANDARD_1（事前に定義された値） を指定してコンピュートプールを作成しました。この設定により、SPCS は各コンテナに適切な CPU とメモリを割り当て、アプリケーションがスムーズに動作することを保証します。 また、コンピュートプールのサイズを調整することで、アプリケーションの負荷変動に対応できる点も魅力的です。例えば、データ分析のピーク時にはコンピュートプールのサイズを大きくし、夜間などの負荷が低い時間帯にはサイズを小さくすることで、コストを最適化できます。 まとめ 今回のチュートリアルを通して、SPCS の基本的な使い方とコンピュートプールの重要性を学ぶことができました。具体的には以下のことに気づきました。 SPCS は、Snowflake のデータとコンピューティングリソースを組み合わせることで、高度なデータ処理や機械学習のワークロードを効率的に実行できる強力なツールである コンピュートプールは、SPCS のパフォーマンスとスケーラビリティを左右する重要な要素であり、ワークロードの特性に合わせて適切な設定を行う必要がある SPCS を活用することで、データエンジニアリングから機械学習まで、幅広いユースケースに対応できる可能性がある 今回のチュートリアルをもとに、今後はより複雑なアプリケーションのデプロイや、コンピュートプールの最適な設定方法について深く探求していきたいと思います！

こんにちは、佐藤です。 AWS のサービスやアーキテクチャ、全然覚えられないなんてことありませんか…？ 私も最初は「IAM って何？」「S3 って何？Storage Service…？」など、専門用語の洪水に溺れそうになりました… そんな悩みを解決してくれるのが AWS BuilderCards です。 今回は、このカードゲームのルールについて、初めての方でも理解できるように解説していきます。 1. AWS BuilderCards とは AWS BuilderCards は、AWS が提供するサービスやそれらを組み合わせたアーキテクチャを楽しく学ぶことができるカードゲームです。 各カードには QR コードがついており、スキャンするとそのカードが表すサービスやツールについて詳しく学べる仕組みになっています。 ゲームの基本情報         プレイ人数: 2〜4人 プレイ時間: 20〜30分 対象: AWS サービスに興味がある方、IT 専門家、クラウド技術を学習したい人 2. カードの種類と役割 AWS BuilderCards には主に 3 種類のカードがあります。 ① スターターカード（Starter Cards） スターターカードはプレイヤーごとに色分けされた 10 枚のセットで、オンプレミス環境を表します。右上隅にグレーの S-アイコン（Starter の「S」）がついており、ゲーム開始時に各プレイヤーの手札となります。 ちなみに第 2 版では、オンプレミスカードの名前が「より多様なオンプレミス IT 環境を反映するように」という変更がされ、Virtual Machine カードとの新しい組み合わせ効果も追加されています。 ② Well-Architected カード Well-Architected カードは、ゲームの獲得ポイントとなるカードです。1 ポイントと 3 ポイントの 2 種類があり、最終的にこのカードを集めることがゲームの勝利条件になります。 ちなみに、プレイヤー数によって使用するカード数が変わる点に注意が必要です。（右上の赤い□をチェック） 2 人プレイ：2 人用アイコンのカードのみ 3 人プレイ：2 人用・3 人用アイコンのカード 4 人プレイ：すべてのカード ③ ビルダーカード（Builder Cards） ビルダーカードは、AWS サービス、認証、ツール、フレームワークなどを表すカードです。これらはクラウド環境を表しており、アーキテクチャ構築の基本となります。 このカードには QR コードが記載されており、スキャンするとそのトピックについて詳しく学べます。ゲームをしながら AWS の知識を身につけられるのが大きな特徴です。 3. ゲームの準備 実際にゲームを始める準備をしていきましょう。 各プレイヤーは好きな色のスターターカード 10 枚を受け取ります（4 色あるので最大 4 人までプレイ可能） プレイヤー数に応じて Well-Architected カードを用意します（1 ポイントカードを 3 ポイントカードの上に置きます） ビルダーカードをコストなし（無料で取れるカード）とコストあり（クレジットが必要なカード）の 2 つの山札に分けます コンソール（取り札）を作ります： コストなしの山札から 4 枚 コストありの山札から 1 枚 同じカードが出たら重ねて、常に 5 種類のカードが並ぶようにします 各プレイヤーは自分のスターターカード 10 枚をシャッフルし、5 枚を手札に取ります ミッションカードを使う場合は、各プレイヤーがミッションカードを 1 枚引きます これで準備完了です！ 4. ターンの進め方 – 3 つのフェーズ 各ターンは 3 つのフェーズで構成されています。 フェーズ 1：ビルド このフェーズでは、手札からカードを出してアーキテクチャを構築していきます。 オンプレミスカードの処理 ： ターン開始時に、手札 5 枚のうちビルダーカードがオンプレミスカードより多い場合、オンプレミスカード 1 枚を捨てることができます。ただし、捨てる場合は、そのターン中に少なくとも 1 枚のカードをコンソール（取り札）から取る必要があります。 アーキテクチャの構築 ： 手札からカードを場に出してアーキテクチャを作ります。アーキテクチャは最低 2 枚のカードで構成されますが、単体カードの配置も可能です。 カードの効果 ・カードを引く効果 (🃏)：追加で手札からカードを引けます ・クレジット追加 (💰)：そのターンで使えるポイント（ビルダーカードの右上の数字）が増えます ・クラウド採用追加 (☁️)：コンソール(取り札)からカードを追加で取れます ・効果使用後に捨てる (🌇)：一度だけ効果を使えるカードです わかりづらい用語をまとめてみましたのでご参考までに！ ・クレジット(💰)：手札を増やすためのポイント。手札の合計値がポイントになり、コストありカードの購入に使います ・コストなし/ありカード：無料で取れるカードと、クレジットが必要なカード（右上に数字がある） ・クラウド採用(☁️)：コンソール（取り札）からカードを取得する行為。基本 1 ターン 1 回！ 特定のカードを組み合わせると追加効果が発生するコンボ効果もあります。ただし、そのターンで組み合わせたカードは取り消しできないので注意しましょう。 フェーズ 2：カード獲得 このフェーズでは、コンソールからカードを 1 枚採用します。 コストなしのビルダーカードを無料で獲得 または、クレジットを使ってコストありのカード（ビルダーカードまたは Well-Architected カード）を購入 使用できるクレジット数は、配置したカードの合計クレジット値です。各プレイヤーはターンごとに基本 1 回のカード取得が可能ですが、コンボ効果で複数枚取得することもできます。 採用したビルダーカードは捨て札に、Well-Architected カードはプレイヤーエリアに配置します。 コンソールに良いカードがなければ、運試しでコストなしの山札から直接 1 枚引くこともできますが、その場合は引いたカードを返すことはできません。 フェーズ 3：ターン終了 ターンの最後には： アーキテクチャと残りの手札をすべて捨て札に置きます リソース山札から新たに 5 枚のカードを引きます 山札がなくなったら捨て札をシャッフルして新しい山札にします 次のターンの計画を立てます これで 1 ターン完了です。次のプレイヤーに順番が回ります。 5. ゲームの終了と勝利条件 最後の Well-Architected カードが取られ、すべてなくなったらゲーム終了となります。 各プレイヤーは獲得した Well-Architected ポイントを合計し、最も多いプレイヤーが勝者です。同点の場合は、ビルダーカードの数が多いプレイヤーが勝ちます。 ゲームはだいたい 20〜30 分で終わるように設計されているので、ランチタイムや短い休憩時間でも十分プレイできます。 6. まとめ AWS BuilderCards 、カードゲームだからと言って侮れませんね… このゲームを通じてこんなことを学ぶことができます。 ・AWS サービスの基本概念が自然と身につく ：Lambda、S3、EC2 などのサービスの役割や関連性を理解できます ・アーキテクチャの設計思想を学べる ：どのサービスを組み合わせるとよいのか、実践的な知識が身につきます ・Well-Architected フレームワークへの理解が深まる ：AWS の設計原則やベストプラクティスを学べます 私自身、最初はルールが少し複雑に感じましたが、1〜2 回プレイすると以外にもすぐになれました！ ぜひ皆さんも、同僚や友人と AWS BuilderCards を楽しみながら、クラウドの知識を深めてみてください！ 参考： AWS BuilderCards – Cloud Computing for Video Games – AWS

こんにちは、SCSKでAWSの内製化支援『 テクニカルエスコートサービス 』を担当している貝塚です。 AWSの検証をしていて、AWS Transit Gatewayの先にDirect Connect GatewayとAWS Direct Connectがいて、その先にオンプレミスがつながっている構成の検証をしたいこと、ありますよね。 でもAWS Direct Connectが準備できず、AWS Site-to-Site VPNを張りたいけれど検証に使えるオンプレミス上のVPNルータも準備できず、AWS Transit Gatewayに直接つなげたVPCで代用も考えるけれど環境の再現度の問題からVPCで代用は避けたい。そういうこともよくありますよね。（※） ※VPCをTransit Gatewayに直接つなげて疑似オンプレミスとするとサブネットがどのAZにあるかによってTransit Gateway経由通信の挙動に違いが出てしまうのでDirect Connectの代替と見なし難い、など。 そんな時、AWS Site-to-Site VPNでVPC同士つなげればよいのでは？と考えつくわけです。実はAWSのオンラインセミナーにオンプレミスとのVPN接続を行うハンズオンがあり、疑似オンプレミス環境としてVPCを使うようになっています。 https://pages.awscloud.com/JAPAN-event-OE-Hands-on-for-Beginners-Network2-2022-reg-event.html?trk=aws_introduction_page これをそのまま真似ればよいのでは？と思うところですが、疑似オンプレミス環境ではマーケットプレイスのvyosテンプレートを使うようになっており、フリートライアルの後はvyosのライセンス料も発生します。（※） ※素直にvyosのライセンス料払え、という話はありますが… そこでとにかく簡単に・安価にSite-to-Site VPN環境を構築するということで、二つのVPCをAWS標準のAWS Site-to-Site VPN機能を使って接続してみます。（※） ※本稿は、正確には、Transit GatewayとVPCをAWS Site-to-Site VPNで接続する記事になっています。 なお、私の目指すところが、AWS Transit Gatewayの向こう側にあるVPC以外のネットワークと通信できること、であったため、VPNのパラメータや経路冗長化は考慮しておらず、ただ通信できることだけを目標とした記事構成になっています。 アーキテクチャ図 今回構築する構成は下図の通りです。 Site-to-Site VPN以外は構築済みという前提で進めます。 AWS Transit Gateway側VPN設定 管理コンソールより、「VPC」-「Transit Gatewayアタッチメント」から「Transit Gatewayアタッチメントを作成」をクリックし、以下の通り設定します。 アタッチメントタイプ「VPN」を選択します。 カスタマーゲートウェイは、VPNの相手側のグローバルIPです。現時点では決まっていないため、適当に1.1.1.1としておきます。 ルーティングはスタティックで構成するのでBGP ASNは適当で構いません。ルーティングオプションは静的を選択します。 トンネルのオプションは、指定しなければ自動生成されるので空欄のままとします。 作成後、管理コンソールより、「VPC」-「Site-to-Site VPN接続」に移動、VPN接続一覧に新しくVPN接続が作成されているので、そのVPN IDをクリックし、詳細を表示します。 トンネルの状態を確認し、Tunnel 1の外部IPアドレスと内部IPv4 CIDRをメモしておきます。 「設定をダウンロードする」をクリックし、相手側VPNルータのサンプルコンフィグをダウンロードします。必要なのは事前共有キーだけなので、ベンダー等は何を選んでも構いません。 私は以下のようにしました。 ダウンロードしたテキストファイルを開き、事前共有キーを発見してメモしておきます。 VPC(疑似オンプレミス)側VPN設定 管理コンソールより、「VPC」-「Site-to-Site VPN接続」から「VPN接続を作成する」をクリックし、以下の通り設定します。 ターゲットゲートウェイのタイプは「仮想プライベートゲートウェイ」を選択し、適切な仮想プライベートゲートウェイを選択します。 カスタマーゲートウェイは「新規」、IPアドレスに先ほどメモしたTunnel 1の外部IPアドレスを入力します。 ルーティングはスタティックで構成するのでBGP ASNは適当で構いません。ルーティングオプションは静的を選択します。 ローカル IPv4 ネットワーク CIDRに、Transit Gateway側ネットワークのCIDRを入力します。 トンネル 1 の内部 IPv4 CIDR、トンネル 1 の事前共有キーに先ほどメモした値を入力します。 VPN接続を作成したら、先ほどと同様、作成したVPN接続の詳細を確認し、Tunnel 1の外部IPアドレスをメモしておいてください。 AWS Transit Gateway側VPNの設定変更 続いて、VPC(疑似オンプレミス)側VPNの外部IPアドレス情報を反映するため、Transit Gateway側VPNの設定を変更していきます。 管理コンソールより、「VPC」-「カスタマーゲートウェイ」から「カスタマーゲートウェイを作成」をクリックします。 IPアドレスに疑似オンプレミス側VPC接続の作成時にメモしたTunnel 1の外部IPアドレスを入力し、カスタマーゲートウェイを作成します。 次に、Transit Gateway側VPN接続のカスタマーゲートウェイを今作成したものに置き換えます。管理コンソールより、「VPC」-「Site-to-Site VPN接続」からTransit Gateway側のVPN接続を選択し、「アクション」-「VPN接続を変更」をクリックします。 ターゲットカスタマーゲートウェイに今作成したカスタマーゲートウェイを指定して変更を保存をクリックします。 最後に、AWS Site-to-Site VPNはデフォルトではVPN接続を受け付ける側として動作するようになっており、このままでは接続が開始しないので、一方をVPNを開始する側として設定します。 管理コンソールより、「VPC」-「Site-to-Site VPN接続」からTransit Gateway側のVPN接続を選択し、「アクション」-「VPN トンネルオプションを変更」をクリックします。 VPN トンネル外部 IP アドレスのところでTransit Gateway側VPNのTunnel1側IPアドレスを選択すると、IPSecオプション設定が表示されるので、スタートアップアクションを開始に変更します。   トンネルステータスの確認 以上でトンネルがアップするはずですのでステータスを確認してみます。 Transit Gateway側Site-to-Site接続のトンネルの詳細をチェックし、Tunnel1のステータスがアップになっていればOKです。 経路設定～疎通確認 Transit GatewayおよびVPCサブネットのルートテーブルで、疑似オンプレミスへの経路が適切に設定されていることを確認します。また、疑似オンプレミスサブネットのルートテーブルで、Transit Gateway側への経路が適切に設定されていることを確認します。 以上で設定完了です。疎通確認を行い、疎通出来たら環境構築完了です！   まとめ オンプレミス想定のネットワークをAWS Transit GatewayやVPCに接続して検証したい、でもVPNルータやAWS Direct Connectを手配するほどでもない、しかしながらVPC Peeringなどで代用するのはオンプレミスの再現として適切か不安がある、というケースはどのくらいあるのでしょうね……私は頻繁にあるのでこのような記事を執筆するに至ったのですが、需要はあまりないのだろうか……と思いつつ、どなたかのお役に立てれば幸いです。

こんにちは、SCSKでAWSの内製化支援『 テクニカルエスコートサービス 』を担当している貝塚です。 AWS Client VPNの環境を構築する機会がありました。いろいろ試していてそんなに難しいところはないなと思ったのですが、ちょっと注意した方がよいなと感じたことが2点ほどありましたので、それを書き残しておきます。 クライアント証明書失効リスト(CRL)の有効期限が切れるとAWS Client VPNに接続できなくなる クライアント証明書を使用した相互認証を採用している場合に該当します。 証明書失効リスト(CRL)には、クライアント証明書等と同様に有効期限が設定されています。AWS Client VPNエンドポイントにインポートしたCRLの有効期限が切れると、クライアントVPNに一切接続できなくなります。 恥ずかしながら勉強不足でCRLに有効期限があることを意識できておらず、運用に入ってから冷や汗をかきました。実はAWSのドキュメントにも書いてありましたが、見出しと内容が一致していないのでやや見落としがちです……と言い訳。 Troubleshooting AWS Client VPN: Client software returns a TLS error when trying to connect to Client VPN - AWS Client VPN This information helps troubleshoot a Client VPN issue around a TLS error. docs.aws.amazon.com CloudWatchのメトリクスCrlDaysToExpiryでCRL有効期限までの日数を取得できるので、CloudWatchアラームで監視するようにしましょう。 Receive notification before the CRL for Client VPN expires I want to receive a notification that the CRL (Certificate Revocation List), that’s associated with the AWS Client VPN e... repost.aws ユーザー接続ごとの帯域制限は10Mbps……ではない 次は、ちゃんとトラブルシューティングのセクションも目を通さないとだめだな……と思って心を入れ替えてドキュメントを読んだが故のどっきりです。 Troubleshooting AWS Client VPN: Verify the bandwidth limit for a Client VPN endpoint - AWS Client VPN This information helps you check the bandwidth limit for a Client VPN endpoint. docs.aws.amazon.com 「ユーザー接続ごとに 10 Mbps の帯域幅制限があります。」と書かれており、やばっ、顧客の要件にあわないものを提案してしまったか！？と焦りました。 こちらは、ベストプラクティスの項に別の記述がありました。 Rules and best practices for using AWS Client VPN - AWS Client VPN Learn specific rules and best practices for using Client VPN. docs.aws.amazon.com 「ユーザー接続ごとに 10 Mbps の最小帯域幅がサポートされています。」 どちらが正しいのかiperf3を使って検証してみたところ200Mbpsほど出ており、これは私の使用していたインターネット環境の限界速度でしたので、1ユーザ接続だけであればこれ以上は出ると考えてよさそうです。 まとめ 以上、AWS Client VPNに関する小ネタ2点でした。 ドキュメントをちゃんと読むの、重要ですね。見落としなく読むのはなかなか大変ですが、ベストプラクティスやFAQについては一通り目を通すことを心掛けたいです。

こんにちは。SCSKのふくちーぬです。 DX(デジタルフォーメーション)が加速する現代のビジネス環境において、APIを公開しサービス連携を実現してAPIエコノミーを拡大していくことが重要となっています。これはUberやStripe、楽天等のパブリックAPIに限らずプライベート(社内)APIについても同様です。企業内に埋もれたデータ活用が叫ばれている中で、API の重要性はますます高まっています。プライベート API を組織内で効果的に運用するための実践的なアプローチとして、カスタムドメインの活用方法について解説します。 Amazon API Gatewayについて Amazon API Gatewayは、AWS が提供するフルマネージド型のAPI管理サービスです。REST、HTTP、および WebSocket の API を作成、公開、管理、保護するために使用されます。これによって、開発者はサーバレスアーキテクチャやマイクロサービスを構築する際に、スケーラブルで高可用な API を迅速にデプロイすることが可能です。 REST APIでは、HTTP API よりも柔軟かつ強力な認証・認可(IAM認証やLambda Authorizer、Amazon Cognitoと連携したOauth2.0認証)に始まり様々な機能を有しています。 高度な認証機能 API流量の制御 データ変換とバリデーション機能 バージョン管理、カスタムドメイン アクセスログ、実行ログのモニタリング AWS Lambdaを始めとしたマイクロサービスとの統合 本記事ではエンタープライズで頻繁に採用実績のある、REST型APIを取り上げています。 Amazon API Gateway（規模に応じた API の作成、維持、保護）| AWS Amazon API Gateway は、数回クリックするだけで、簡単に API の作成、配布、保守、監視、保護が行えるフルマネージドなサービスです。どのようなスケールにも対応するパフォーマンスを低コストでご利用いただけます。 aws.amazon.com デフォルトドメイン vs カスタムドメインの利用について 以下の観点でも解説していますが、エンタープライズの本番環境利用用途であればカスタムドメインを利用する方針がベストプラクティスです。パブリックAPIにおいても、同様です。デフォルトドメインだと、企業ブランドイメージや視認性が悪く使い勝手も良くはありません。 デフォルトドメイン curl https://<apiid>.execute-api.<awsリージョン>.amazonaws.com/<stage>/<resourcepath> カスタムドメイン curl https://fukuchiiinu.net/<stage>/<resourcepath> ガバナンスとコンプライアンス デフォルトドメインでは、迅速な導入による俊敏性は確保できるものの、ガバナンス管理が難しくなります。 カスタムドメインでは、ドメインの一貫性を保つことができ、社内ポリシーやセキュリティガイドラインに適した統制要件を満たすことができます。 運用ライフサイクル デフォルトドメインでは、ドメインについてはAWS管理されます。 そのため、API開発者者はPoC環境では迅速にプロトタイピング作成等に使用できます。一方、ドメインは一意のIDによって自動で割り当てられるためAPIを再作成した場合は、クライアントサイド開発者はURL等の変更を余儀なくされ運用負荷が高まります。 カスタムドメインでは、独自ドメインで用意できるため、APIの再作成や追加等があってもクライアントサイドは柔軟に対応することが可能です。ドメインについては、利用者側で管理するため社内発行CAを利用する場合は証明書の管理が必要になりますが、ACM発行証明書で代替できる場合は自動更新されます。 デフォルトドメイン利用時の構成 オンプレミス環境からから、RDSのデータベースに格納されている情報に安全にアクセスするシナリオを考えてみます。 オンプレミス業務アプリケーションがデータ取得のためのAPIリクエストを発行 Direct Connectを通じてた閉域網でアクセス VPCエンドポイントを経由してプライベート型のAPI Gatewayにリクエストが到達 バックエンドのVPC Lambdaを起動 Lambdaがプライベートサブネット内のRDSからデータ取得 取得したデータがオンプレミス環境のアプリケーションに返却 以下のように、デフォルトドメイン利用時は、VPCエンドポイント及びPrivate型のAPI Gatewayの構成で社内向けAPIやシステム間連携などで、安全な通信とアクセス制御を実現できます。 API Gatewayの各種APIエンドポイントを叩く用のVPCエンドポイントを作成する必要があります。  com.amazonaws.<リージョン>.execute-api VPCエンドポイントでのアクセス制御 本構成の場合、クライアントサイドからAWSへの玄関口はVPCエンドポイントとなります。そのため、VPCエンドポイントにアタッチされているセキュリティグループにてホワイトリスト形式でのアクセス制御をすることが重要です。 具体的には、クライアントサイド（オンプレミスのサーバやVPC内のEC2や、VPC Lambda等）のIPアドレスやセキュリティグループをホワイトリスト形式で登録することで、その他のクライアントからのアクセスをブロックすることができます。 Amazon API Gatewayでのアクセス制御 Amazon API Gatewayでは、リソースポリシーを利用して、特定のVPCエンドポイント経由でのみアクセスできるよう制御します。 許可ステートメントと拒否ステートメントを組み合わせることで、特定のVPCエンドポイントからのみAPIアクセスができるよう強固なセキュリティ制御をしています。 “*/*/*/*”のパターンについては、APIのID・ステージ・リソースパス・メソッドで制御することも可能です。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "execute-api:Invoke", "Resource": "arn:aws:execute-api:<awsリージョン>:<awsアカウントid>:*/*/*/*", "Condition": { "StringEquals": { "aws:SourceVpce": "<vpcエンドポイントid>" } } }, { "Effect": "Allow", "Action": "execute-api:Invoke", "Resource": "arn:aws:execute-api:<awsリージョン>:<awsアカウントid>:*/*/*/*", "Condition": { "StringNotEquals": { "aws:SourceVpce": "<vpcエンドポイントid>" } } } ] } TLS通信について 以下のプロセスで、デフォルトドメイン/カスタムドメインでAPIにアクセスする際のTLS通信が行われます。 DNS解決 クライアントがドメイン名の名前解決 オンプレミスのDNSサーバまたは、Amaozn Route53インバウンドエンドポイント経由でAmazon Route53 ResolverでIPアドレスに解決 TCP接続確立 3ウェイハンドシェイク TLSハンドシェイク ClientHello：クライアントサイドのブラウザまたは業務アプリケーションが対応しているTLSバージョンと暗号スイートのリストを提示 ServerHello：API GatewayがTLS1.2と特定の暗号スイートを選択 Certificate：API GatewayがAWS管理証明書またはACM証明書の情報を送信 KeyExchange：ECDHE鍵交換で共通の秘密鍵を安全に確立 Finished：双方が暗号化モードに切り替わり完了 証明書検証 クライアントサイドが証明書チェーンを検証 ドメイン名、有効期限、発行者を確認 データ交換 確立した暗号化通信にて、HTTPリクエスト/レスポンスを交換 接続終了 プライベート型のAPI Gatewayにおいては、TLSバージョンが強制されており、TLS1.2のみをサポートしています。（TLS1.3については、未サポート） 暗号スイートについては、下記表に記載されているように比較的近代的なものが利用できますが、こちらも制御はできません。 API Gateway で REST API カスタムドメインのセキュリティポリシーを選択する - Amazon API Gateway カスタムドメインのセキュリティポリシーを選択する方法について説明します。 docs.aws.amazon.com カスタムドメイン利用時の構成 プライベートAPIにおいて、カスタムドメインを使用する主要パターンを説明します。API Gatewayにおいて、カスタムドメインがサポートされていますので、ELB(ALB、NLB)のコストや管理負荷が不要であるパターン１が推奨構成です。 パターン１：VPCエンドポイント+Amazon API Gateway 本構成は、re:Invent2024で発表されたアップデートとなります。従来までは、Amazon API Gateway単体ではカスタムドメイン設定がネイティブにサポートしていませんでしたので、待望の機能拡張となります。 カスタムドメインを作成します ACM証明書をカスタムドメイン名と合わせて設定します ベースパスマッピングを行い、複数のプライベートAPIのステージをマッピングします カスタムドメイン名とVPCエンドポイント間で、ドメイン名アクセスを関連付けます Amazon API Gateway がプライベート REST API のカスタムドメイン名のサポートを開始 - AWS AWS の新機能についてさらに詳しく知るには、 Amazon API Gateway がプライベート REST API のカスタムドメイン名のサポートを開始 aws.amazon.com 本アップデートにより、証明書の管理をAmazon API Gatewayのみで完結することができ、TLS通信の一貫性を保ったエンドツーエンドの安全な通信が確立できるようになりました。 VPCエンドポイントでのアクセス制御 本構成の場合、デフォルトドメイン利用時と 同様 のアクセス制御します。クライアントサイドからAWSへの玄関口はVPCエンドポイントとなります。そのため、VPCエンドポイントにアタッチされているセキュリティグループにてホワイトリスト形式でのアクセス制御をすることが重要です。 Amazon API Gatewayでのアクセス制御 デフォルトドメイン利用時と 同様 のアクセス制御を実施します。Amazon API Gatewayでは、リソースポリシーを利用して、特定のVPCエンドポイント経由でのみアクセスできるよう制御します。 TLS通信について デフォルトドメイン利用時と 同様 のプロセスです。利用する証明書の管理が異なります。 パターン２：ALB＋VPCエンドポイント+Amazon API Gateway 本構成は、API Gateway単体ではカスタムドメイン設定がネイティブにサポートしていなかったため、Application Load Balancerを前段に挟む構成となっています。つまりALBは、リバースプロキシとして機能を提供します。そしてACM証明書は、ALBとAPI Gatewayで同一の証明書を関連付けます。 カスタムドメインを作成します ACM証明書をカスタムドメイン名と合わせて設定します ベースパスマッピングを行い、複数のプライベートAPIのステージをマッピングします リソースポリシーにてドメインに対するアクセス制御をします リスナーとしてHTTPS:443を持つALBを作成します。加えてALBとACM証明書を関連付けます。 ALBのターゲットグループとして、VPCエンドポイントを指定します 本構成は、ALBのDNSでAPIアクセスさせるため、DNS設定にCNAMEまたはALIASで登録をする必要があります。ALBのDNS名は複数の動的IPアドレスに変換される性質を持つつため、クライアントがhostsファイルでアクセスを想定している環境では、適さないことを理解してください。 ALBでのアクセス制御 本構成の場合、クライアントサイドからAWSへの玄関口はALBとなります。ALBにアタッチされているセキュリティグループにてホワイトリスト形式でのアクセス制御をしましょう。 VPCエンドポイントでのアクセス制御 VPCエンドポイントのセキュリティグループでは、ALBからのアクセスのみを受け付けることができるよう、ALBのセキュリティグループからのインバウンドアクセス許可をします。 API Gatewayでのアクセス制御 デフォルトドメイン利用時と 同様 のアクセス制御を実施します。 TLS通信について 本構成では、①クライアントサイド-ALB間の通信と②ALB-API Gateway間の通信でTLS終端されます。クライアントサイドでの証明書検証に加えて、API Gateway側でも正しく証明書検証を実施します。 パターン３：NLB＋VPCエンドポイント+Amazon API Gateway 本構成もパターン2と同様に、re:Invent2024以前でのカスタムドメインを利用する際の代替案の一つです。パターン2との違いとしては、Network Load Balancerに置き換わっています。 カスタムドメインを作成します ACM証明書をカスタムドメイン名と合わせて設定します ベースパスマッピングを行い、複数のプライベートAPIのステージをマッピングします リソースポリシーにてドメインに対するアクセス制御をします リスナーとしてTLS:443を持つALBを作成します。加えてNLBとACM証明書を関連付けます。 NLBのターゲットグループとして、VPCエンドポイントを指定します 本構成は、NLBの静的IPアドレスを利用することができます。オンプレミス内の複雑なネットワーク構成の場合、AWSへの通信時にもホワイトリスト形式で制御している環境もよく見かけますが、FW要件を満たすことができるのが特徴です。   NLBでのアクセス制御 本構成の場合、クライアントサイドからAWSへの玄関口はNLBとなります。2023/7までは、NLBにセキュリティグループをアタッチできなかったため、AWS Network FirewallやネットワークACLを利用する必要がありました。 セキュリティグループがアタッチできるタイプのNetwork Load Balancer（NLB）へ移行する手法[Elastic Load Balancing +Amazon Elastic Compute Cloud + AWS CloudFormation] セキュリティグループがアタッチされていないNetwork Load Balancer（NLB）をIPアドレスを保持したまま、セキュリティグループがアタッチできるNetwork Load Balancer（NLB）へ移行する手法をご紹介します。 blog.usize-tech.com 2024.02.13 現在はサポートされているため、NLBにセキュリティグループを必ずアタッチしてホワイトリスト形式でのアクセス制御をしましょう。 VPCエンドポイントでのアクセス制御 ALBの場合と同様です。 VPCエンドポイントのセキュリティグループでは、NLBからのアクセスのみを受け付けることができるよう、NLBのセキュリティグループからのインバウンドアクセス許可をします。 API Gatewayでのアクセス制御 デフォルトドメイン利用時と 同様 のアクセス制御を実施します。 TLS通信について 本構成では、①クライアントサイド-NLB間の通信と②NLB-API Gateway間の通信でTLS終端されます。しかし、NLBではTLSリスナーの場合、証明書の検証を実施しないという仕様があります。 ターゲットグループに TLS プロトコルが設定されている場合、ロードバランサーは、ターゲットにインストールした証明書を使用して、ターゲットと TLS 接続を確立します。ロードバランサーはこれらの証明書を検証しません。したがって、自己署名証明書または期限切れの証明書を使用できます。 Network Load Balancers のターゲットグループ - エラスティックロードバランシング Network Load Balancer のターゲットグループを設定する方法について説明します。 docs.aws.amazon.com そのため、通常通りクライアントサイドではNLBに関連付いた証明書の検証は実施します。NLBではSNI自体は転送しますが証明書を検証しないため、TLSパススルーで動くということになります。つまり、NLBでは正規の証明書を関連付けて、API Gateway側では異なる証明書（期限切れの証明書など）を関連付けていても通信が確立してしまいます。 NLBとAPI Gatewayで関連付けている証明書が異なる場合でも、APIリクエスト/レスポンスが成功してしまいますので注意する必要があります。 このようなリスクを最小限に抑えるために、証明書を不用意に変更されないような仕組みとして、予防的統制と発見的統制を取り入れた多層防御を導入することもできます。 　予防的統制 　AWSのIAMポリシーによる権限制御 　CloudFormationテンプレートによる一元的な管理 　発見的統制 　Config+Lambdaのカスタムルールによる継続的な監視 or EventBridge+CloudTrailによる変更検知 　証明書が不一致になった際の自動修復ルール 　アラーム通知 ログの取得 API Gatewayでは、アクセスログ及び実行ログをCloudWatchLogsへ出力できるので、どちらもONにします。 API Gatewayのアクセスログ アクセスログはセキュリティ監査とトラブルシューティングのために必須です。デフォルトのログ形式に加えて要件に併せて追加のパラメータを設定します。 { "requestId":"$context.requestId", "ip": "$context.identity.sourceIp", "caller":"$context.identity.caller", "user":"$context.identity.user","requestTime":"$context.requestTime", "httpMethod":"$context.httpMethod","resourcePath":"$context.resourcePath", "status":"$context.status","protocol":"$context.protocol", "responseLength":"$context.responseLength" } 例えばXrayによるAPIの可視性、WAFによるAPIのL7防御をしている際は、追加のパラメータを設定します。 API Gateway のアクセスのログ記録のための変数 - Amazon API Gateway 変数のアクセスのログ記録などのリファレンス。 docs.aws.amazon.com ALB/NLBのアクセスログ 加えて、ALB/NLBではアクセスログを取得できるため、アクセスログをS3に出力します。 Application Load Balancer のアクセスログ - エラスティックロードバランシング Elastic Load Balancing が提供するアクセスログを使用して Application Load Balancer を監視する方法について説明します。 docs.aws.amazon.com Network Load Balancer のアクセスログ - エラスティックロードバランシング Elastic Load Balancing が提供するアクセスログを使用して Network Load Balancer を監視する方法について説明します。 docs.aws.amazon.com ALB/NLBのアクセスログでは、API Gatewayのアクセスログ・実行ログでは取得できない下記の情報を取得することができます。 ・リクエストサイズ（received_bytes / received_bytes） ・レスポンスサイズ（sent_bytes / sent_bytes） ・TLSプロトコルバージョン（ssl_protocol / tls_protocol_version） ・暗号スイート（ssl_cipher / tls_cipher） リクエスト/レスポンスサイズを継続的にモニタリングしておくことで、バッファーオーバーフロー攻撃/データ流出/DDoS攻撃等の兆候を捉えることができます。これに加えてWAFのリクエストヘッダやボディ検査をすることで、異常なリクエストについてBlockすることが可能となります。 また暗号化プロトコルと暗号スイート情報を取得しておくことで、脆弱性のある暗号化設定がされていないか継続的に監視することができます。 API Gatewayの実行ログ 実行ログでは、リクエスト/レスポンスのパラメタータ・ボディの記録に加えてバックエンドのエラー情報も含まれるものになります。 エンタープライズ利用において、実行ログでは”データトレース”はオフに設定して、”エラーと情報ログ”のみ記録します。 OWASPのAPIセキュリティに関する文書や、AWS公式ドキュメントにおいても、 ログ内に機密情報（個人情報やデータペイロード）に記録されないように設定するように との記載があります。 Error messages include stack traces, or expose other sensitive information API8:2023 Security Misconfiguration - OWASP API Security Top 10 The Ten Most Critical API Security Risks owasp.org API Gateway での CloudWatch による REST API のログの設定 - Amazon API Gateway Amazon API Gateway で CloudWatch によるログを設定する方法について説明します。 docs.aws.amazon.com 最後に いかがだったでしょうか。 企業内のデータ分析やデータ連携をするニーズが増えている中、プライベート APIは安全かつ効率的な基盤となります。 本記事で紹介したベストプラクティスを活用して、エンタープライズ固有の要件に沿った最適なプライベートAPIを実装いただけますと幸いです。 本記事が皆様のお役にたてば幸いです。 ではサウナラ～🔥

こんにちは　ＳＣＳＫ　池田です。 前回は LifeKeeperのプロダクトサイクル（サポートフェーズ） について解説しましたが、そのサポート契約をするとどのように問い合わせすることができるのかを解説します。 サポートには「サイオスサポート」と「パートナーサポート」があります まず問い合わせの前に、サポートを契約する際に「サイオスサポート」か「パートナーサポート」かによって問い合わせ方法が異なります。 まずは以下の絵をご覧ください。 サイオスサポート は、 お客様から直接サイオステクノロジーのサポート窓口 に問い合わせしていただきます。 パートナーサポート は、 SCSKのようなSI&サポートパートナーが間に入り 、お問い合わせに対応します。SI&サポートパートナーで回答が難しい場合は、SI&サポートパートナーがサイオステクノロジーに問い合わせをエスカレーションします。 現在のご契約がどちらのサポートになっているかは、サポート証書の「５．サポート窓口」に書いてあります。 ※以下はサポート証書のイメージ図となります。 サイオスサポートかパートナーサポートかによって問い合わせ先が異なります サポート形態に、サイオスサポートとパートナーサポートという種類があることをご理解いただいたと思いますが、それぞれ問い合わせ先が異なります。 サイオスサポートの場合 上述した「５．サポート窓口」に記載のリンクからお問い合わせサイトに移動してください。 https://bccs.sios.jp/contact/ 　（2025/3/28 現在） ※24/365のサポートを提供する「Premiumサポート」や「拡張Premiumサポート」、「拡張Premium＋＋サポート」をご契約のお客様には、上記フォームとは別の連絡先が通知されますので、メーカーからの案内にご注意ください リンクをクリックすると以下のような画面が表示されますので、サインインIDをお持ちの方は赤枠の「お問い合わせフォームへ」をクリックしてください。 ※サインインIDをお持ちでない場合は、以下画面最下部の「サインインIDを登録する」からサインインID作成手続きに進んでください。 問い合わせしたい時に慌てないように予めサインインIDを作成しておくことをお勧めします。 すると以下のログイン画面が表示される為、メールアドレスとパスワードを入力し「サインイン」をクリックしてください。 ログインに成功すると「購入後のお問い合わせ」画面が表示される為、必要事項を記入の上、「送信」をクリックすることで問い合わせすることができます。 この際にサポート証書の右上に記載されている「PSC No.」を入力してください。これによりどの契約のお問い合わせかが紐づけられます。   パートナーサポートの場合 パートナーサポートの場合は、パートナー会社でそれぞれ異なりますが、ＳＣＳＫの場合は「LK@scsk.jp」宛にメールにてお問合せいただく形式になります。 お問い合わせいただく際のメール本文には、以下の内容を必ず書いていただくようお願いします。 ・PSC No.　※サポート証書に記載 ・お客様名　※サポート証書に記載 ・お問い合わせ内容   まとめ 今回は、LifeKeeper購入後の問い合わせ方法について、また問い合わせにはサイオスサポートとパートナーサポートがあり、それぞれ問い合わせ方法が異なるという点について解説させていただきました。 ・サポートには「サイオスサポート」と「パートナーサポート」がある ・サポート種類により問い合わせ方法が異なる ・サイオスサポートの場合は、予めサインインIDを作成しておくこと   詳しい内容をお知りになりたいかたは、以下のバナーからSCSK LifeKeeper公式サイトまで

みなさん、こんにちは。SCSKの津田です。 先日AWSクラウド環境にてLifeKeeperの構築を行っていたところ、Amazon Route 53のリソース作成ができない事象が発生しました。 当初は単なるエラー対応で解決するかと思っていましたが、要件定義レベルの見直しが必要になる事態に発展してしまいました… 今回はその体験記を共有いたします。 本記事がLifeKeeperでRoute 53リソースを作成予定の方、また同様の問題が発生して困っている方にとっての参考になれば幸いです。 前提(構成について) まず、前提としてLifeKeeperの構築を行っていた環境の構成をお話します。 第４回　【LifeKeeper】AWSでは仮想IPアドレスが使えない！？をこうして解決する！！ でもお伝えした通り、 AWS環境では仮想IPアドレスの機能が提供されていないため、今回の環境では、Amazon Route 53を利用した接続方式を採用しました。 そのためLifeKeeperでは「Recovery Kit for Route 53」でAmazon Route 53リソースを作成することにより、Amazon Route 53のホストゾーン上の一部レコードを管理し、VPC外のクライアントからクラスタへの接続を冗長化する構成で環境構築を進めていました。 <イメージ図＞ ■OS：Redhat Enterprise Linux release 8.6 ■LifeKeeper：LifeKeeper for Linux Version 9.8.0 Amazon Route 53リソースの作成ができない！ LifeKeeperGUI画面でAmazon Route 53リソースの作成を進めていたところ、 プライマリサーバでのリソース作成時に以下のような画面が表示され、先に進めなくなってしまいました。 メッセージによれば複数のゾーンが該当したとのこと… ＜GUI表示画面＞ ※上記画面はRoute 53リソースの作成でプライマリサーバのリソースタグ名を設定し、「Create」ボタンを押下した後に出力されました。 ※上記画面で「Cancel」を押すとRoute 53リソースの作成は終了し、入力していたRoute 53リソースの設定は初期化されてしまいます。 メッセージの原因 メッセージについてサイオステクノロジー社が公開するオンラインドキュメントを確認しましたが、 関連した記述が見当たらず対処できなかったため、サイオステクノロジー社のサポート窓口へ問い合わせを行いました。 その結果、 メッセージの原因は「同名のホストゾーンが存在している」ことであり、これによりRoute 53リソースが作成できないことが分かりました。 LifeKeeperでRoute53リソースを作成する際、対象のホストゾーン(ドメイン)を設定しますが、IDではなく名前で識別する仕様上、ホストゾーン名は一意である必要があるようです。 メッセージの通り、今回の環境ではパブリックホストゾーンとプライベートホストゾーンで同名のホストゾーンを2つ作成していました。 その後の対応 サポート窓口からは対応案として、重複しているホストゾーンのうちどちらか一方を削除または名前変更することを提案頂きました。 しかしこれらホストゾーンは既に稼働中の他システムでも使われており、名前の削除や変更、クラスタ用に別のホストゾーンを作成することは難しく、、、 様々な観点で検討した結果、今回の環境ではRoute53を用いた接続方式は利用せず、 第８回　AWS外からAWS内のHAクラスターシステムへどう接続する！？ ～ LifeKeeper ～ にてお伝えしたような、ルートテーブル+Transit Gateway経由を用いた接続を行う方針へ大きく変更となりました。 皆さまもご注意を！ 今回名前が重複していたホストゾーンは、それぞれパブリックホストゾーンとプライベートホストゾーンのtypeで作成しており、 ホストゾーンは同名ではあるものの異なる範囲で機能しています。 他の環境においても同様にホストゾーンを作成するケースは珍しくないかと思います。 しかし、 ホストゾーンの重複が解決できない場合、LifekeeperのRoute53リソースの作成ができなくなってしまうので、 要件定義段階からの注意 が必要です。 LifekeeperのRoute 53リソースの作成ができない場合、クライアントからサーバへのRoute 53を用いた接続を冗長化できず、構成の見直しが発生する恐れがあります！！ なお今回起きた問題については、サイオステクノロジー社と連携をとり、LifeKeeperのオンラインマニュアルに注意書きを載せて頂くことになりました。Recovery Kit for Route 53の要件に以下のように記載頂いています。 パブリックホストゾーンとプライベートホストゾーンで同名のホストゾーンが存在しないことを確認してください。同名のホストゾーンが存在するとRoute53リソースの作成に失敗します。 (上記は2025年3月時点での記載) ※LifeKeeper for LinuxではVersion 9.6.0以降のマニュアルに記載 ※LifeKeeper for WindowsではVersion 8.9.0以降のマニュアルに記載 また、現状LifeKeeperのRoute 53リソース作成ではホストゾーンを名前で指定しておりますが、 今後はIDで指定できるように検討頂くことを、 サイオステクノロジー社の開発部隊 へ依頼しました。 このようにSCSKのLifeKeeperチームではサイオステクノロジー社と連携をとりながらLifeKeeperの改良にも努めております。 まとめ 今回はLifeKeeperでRoute 53リソースの作成ができなかった事象を体験記としてお伝えしました。 クライアントとクラスタ間の接続方式で大幅な見直しが発生する事態にもなりかねませんので、 Route53の接続方式をとる場合は、要件定義段階から以下にご注意ください！ ・Amazon Route 53で同名のホストゾーンが複数存在する場合、LifekeeperでRoute 53リソースの作成ができない。  　(=クライアントからクラスタサーバへのRoute 53を用いた接続が冗長化できなくなる。)   詳しい内容をお知りになりたいかたは、以下のバナーからSCSK Lifekeeper公式サイトまで

皆さん、こんにちは！USiZEサービス部第一課の黄です。 これまでの記事では、Rubrikのランサムウェア対策や機密データ検知など、主要な機能についてご紹介してきました。 Rubrikは バックアップ&復元からバックアップデータの活用までデータ管理 に特化したIT企業です。 「まだ読んでいない！」という方は、ぜひ以下の記事もあわせてご覧ください。 Rubrikとは？クラウド＆オンプレにも対応する次世代バックアップ管理を紹介 – TechHarmony Rubrikのランサムウェア対策：仕組みとシミュレーションで確認 – TechHarmony Rubrik Sensitive Data Discoveryとは？機密データを簡単に管理・可視化する方法 – TechHarmony さて、今回は少し視点を変えて、「Rubrikとクラウドサービスの連携」にフォーカスしたいと思います。 Rubrikは複数のクラウドプラットフォーム（例：AWS、GCP、VMWare）との連携も対応していますが、 今回は特に利用者の多い「 AWSとの連携 」に絞ってご紹介します。 Rubrikをクラウド環境で活用したいと考えている方は、ぜひ最後までチェックしてみてください！ RubrikとAWS連携の概要 AWSでは、 EC2、S3やRDSなどの多様なリソースを RSC（Rubrik Security Cloud）上でまとめて保護・管理する ことが可能です。 RSC（Rubrik Security Cloud）は、Rubrikが提供するクラウドベースの統合管理プラットフォームです。 今回の記事では、 EC2インスタンスのバックアップ管理 を中心にご紹介していきます。 上図は、RSCを使ってAWSのEC2をバックアップ・管理する流れをまとめたものです。 大きく「一次バックアップ」と「二次バックアップ」の 2 段階に分かれます。 一次バックアップ段階 Rubrikは API経由で EC2インスタンスに対してバックアップデータを取得します。 EC2 の AMI（Amazon Machine Image）や EBS（Elastic Block Store） に保存されます。 ただし、AMI や EBS は ストレージコストが高め で、 長期保存には不向き というデメリットがあります。 二次バックアップ段階 Rubrik Exocompute（次の章で説明） により、取得したバックアップデータを S3バケットにアーカイブ することで、 コストを大幅に抑えながら長期保存 することが可能になります。  ※ S3 は「安くたくさん保存できる場所」とイメージしてもらえるとわかりやすいかもしれません。 RubrikとAWS連携の検証レポート 本章では、上の図にある 一次バックアップから二次バックアップまでの一連の流れ を、 実際の操作手順・設定画面のスクリーンショットとともに、わかりやすく紹介 していきます。 大きな流れとしては、以下の3ステップで構成されています： Rubrik と AWS アカウントの連携 一次バックアップの取得 二次バックアップの取得 この流れに沿って、それぞれのステップを以下で詳しくご紹介していきます。 1. Rubrik と AWS アカウントの連携 まずは、RSC上でAWSアカウントを登録します。 RSC の「 ワークロードの追加 」画面から AWS EC2 を選択すると、下図のように 2 種類の登録方法が表示されます。 CloudFormation テンプレート（CFT）を使用する方法 手動で IAM ロールなどを設定する方法 今回の検証では、より便利な CFT を使用する方法 を選択しました。 次に、RSC 上で登録したい AWS アカウント と リージョン（Region） を設定すると、Rubrik 側で CloudFormation テンプレート（CFT）が自動生成されます。 ここで設定が必要なのは以下の3項目です： アカウントID ：AWS側のIDで、RubrikとAWSを紐づけるために使用します。 アカウント名 ：AWS側とは無関係で、RSC上で識別しやすくするための任意の名前です。今回は「 test-kou 」です。 リージョン ：今回は「東京」を選択しました。 CloudFormation テンプレート（CFT）をダウンロードし、 AWSのCloudFormation にアップロードしてスタックを作成します。 上の図に示すように、Rubrikから作成してくれたCFTに三つの項目があります。 CrossAccountRole ：Rubrik が AWS リソースにアクセスするための IAM ロールです。 EC2ProtectionPolicy ：EC2 のバックアップを実行するために必要な権限を定義したポリシーです。 RubrikSecurityCloudNotifier ：AWS アカウントの連携情報を Rubrik 側に通知するための仕組みです。 スタックの作成が完了すると、Rubrik 側で連携が自動的に完了し、RSC 上にも登録済みとして反映されます。 2. 一次バックアップの取得 次は、 一次スナップショットの取得 についてご説明します。 前章の RubrikとAWS アカウントの連携 により、すでに AWS アカウントとの接続は完了しており、CloudFormation テンプレート（CFT）を通じてRSC側に EC2 操作の権限も付与されています。 この上で AWS 上に EC2 インスタンスを作成すると、 自動的に RSC に反映され 、管理対象として一覧に表示されます（下図参照）。 ※ kou-test-rubrikは事前にAWS側で作成されたEC2インスタンスです。 RSC の画面上からkou-test-rubrikをクリックして、「 オンデマンドスナップショット 」を実行するだけで、スナップショットの取得が可能です。 この操作により、 Rubrik が自動で EC2 の AMI および EBS のスナップショットを作成 してくれます。 API ベースで処理されるため、特別な手作業や設定は必要ありません。 少し時間が経つと、下図のように、 EC2のAMIやEBS スナップショット が AWS 上に作成されていることが確認できます。 同時に RSC上 にもバックアップデータとして反映されます。 3. 二次バックアップの取得 実際、 一次バックアップの取得だけでも、RSC 上でバックアップを扱うことは可能 です。 ただし、一次スナップショットでは EC2 の AMI や EBS をそのまま保持 するため、保存期間が長くなると コストが高くなる という課題があります。 この課題を解決するために用意されているのが、 二次バックアップ です。簡単に説明すれば、 取得したバックアップデータをS3などのストレージにアーカイブする ことで、コストを抑えながら長期保管を実現する仕組みです。 二次スナップショットを利用するには、Rubrik 側でいくつかの設定が必要です。主に以下の3点になります： Rubrik Exocompute の設定 アーカイブ先の設定 SLA ドメインの設定 Rubrik Exocompute の設定 Rubrik Exocompute とは、 RubrikがAWS側でEKS（Elastic Kubernetes Service）を使って一時的な処理用リソースを自動で立ち上げる仕組み です。 この機能を設定することで、バックアップデータの転送や整形といった処理を Rubrik が AWS 上で自動的に行えるようになります。 設定方法については、「 Rubrik と AWS アカウントの連携 」の章と同様に、RSC 側で CloudFormation テンプレート（CFT）を生成し、それを AWS 側で CloudFormation のスタックを更新することで完了します。 上図に示すように、先ほど連携した「 test-kou 」AWSアカウントについては、Exocomputeがまだ設定していません。 そのため、既に連携済みの AWS アカウントに対して、Exocomputeを操作するための権限を付与する必要があります（下図参照）。 権限の管理方法としては、以下の 2 つのオプションがあります： Rubrik Managed ：Rubrik が EKS を自動的に作成・管理します Custom Managed ：自分たちで用意した既存の EKS クラスタを使用します 今回は Rubrik Managed を選択しました。 次には、自動的に生成されたCFTにより、AWS 側で CloudFormation のスタックを更新します。 更新が完了すると、上図のように CFT によって 4 つの新しいリソースが自動で作成されます。 それぞれ Rubrik が一時的に処理用サーバー（EKS）を起動し、必要な操作を実行するために使われるものです。 AWS側での作成が完了すると、RSC 側にもExocomputeが自動的に反映されます。 ※ 上図のとおり、Exocompute の設定には VPC の情報も含まれています。設定時にどの VPC を使うかは任意で選べますが、今回は検証で一次バックアップの段階と同じVPCを指定しました。 アーカイブ先の設定 次に、 二次バックアップとしてバックアップデータをどこに保管するか を設定します。 保管先には、オンプレミスのストレージやクラウド上の S3 バケットなどを選択できますが、今回の検証では AWS S3 を指定しました。 具体的な操作は、大きく2つのステップに分かれます。 AWS アカウントに対して S3 関連の操作権限を付与します。 その後、RSC 上でアーカイブ先として S3 バケットを設定します。 ※ S3 バケットは Rubrik 側で自動的に AWS に作成されるため、ユーザーが手動で準備する必要はありません。 まず、既存の「 test-kou 」AWSアカウントに対して、S3 関連の操作権限を付与します。 今回の検証では S3 をアーカイブ先として選択するため、下図のように「クラウドネイティブロケーション」を選択します。 次に、生成された CFT を用いて CloudFormation のスタックを更新すると、下図のように新たな権限が 1 つ追加されていることが確認できます。 ※ 「CloudNativeArchivalLocationPolicy」と呼ばれますが、今回はアーカイブ先として S3 を選択しているため、実際には S3 の操作に関する権限です。 権限追加した後に、RSC側でアーカイブ先（S3 バケット）を設定します。 上図に示されている 「kou-test-s3」は、RSC 側で設定したアーカイブ先の名前 です。一方、 「rubrik-kou-test-location」は、AWS 側に自動作成されるS3バケットの名称 になります。 また、 S3バケットに保存されるオブジェクト （今回の場合はバックアップデータ）については、 6種類のストレージクラスから選択できます。 ただし、S3 のバックアップデータ以外の用途では、上位 4 種類のみが選択可能です。 なお、ストレージクラスは上にあるものほど高コストで、下に行くほど低コストになります。 設定が完了すると、AWS 側にも正しく反映されていることが、下図から確認できます。 現時点では Exocompute がまだ動作していないため、S3 バケットの中身は空のままです。Exocompute を動かすには、SLA ドメインの設定が必要です。 SLAドメインの設定 SLAドメインとは、「どのくらいの頻度でスナップショットを取得するか」「どこにアーカイブするか」「どのくらいの期間保存するか」など、バックアップに関するルールをまとめたポリシーのことです。 SLAドメインをEC2インスタンスに適用することで、Exocomputeが実際に動作し、バックアップデータのアーカイブ処理が実行されるようになります。 まずは、SLAドメインを新規作成します。 SLAドメインの設定対象として「 AWS EC2/EBS 」を選択します。 ※ 対象によって設定できる項目が異なるため、適切な対象を選ぶ必要があります。 次に、バックアップデータを取得する 頻度と、保持期間 を設定します。 ※ 保持期間は、一次バックアップ・二次バックアップに関係なく、バックアップデータ全体の保存期間を指します。 あらかじめ指定したバックアップ全体の保持期間は 7 日間のため、 ローカルストレージ（一次バックアップの保存先：AMI や EBS）での保持期間も 0～7 日の範囲で設定できます。 今回は「1日」を設定しました。 つまり、バックアップデータは取得後、1 日間 AMI や EBS に保存され、その後自動的に削除される形になります。 なお、今回は検証のため、 「インスタントアーカイブ」 をクリックしたため、バックアップデータ取得のタイミングで、すぐに二次バックアップ先（S3 バケット）にもアーカイブされます。 インスタントアーカイブを使用しない場合は、バックアップデータはまず一次バックアップ（AMI や EBS）として 1 日間保持され、その後、Exocompute の処理を通じて S3 バケットに転送され、残りの 6 日間保持される流れになります。 あわせて、先ほど作成したアーカイブ先「kou-test-s3」もここで指定します。 最後、SLAドメインの名前を設定します。 バックアップの結果確認 ここまでの設定で、一次バックアップから二次バックアップまでの準備がすべて完了しました。 あとは、 作成した SLA ドメインを対象の EC2 インスタンスに割り当てるだけで、Rubrik が自動的に一次バックアップ（AMI・EBS スナップショット）を取得します。さらに Exocompute を経由して、バックアップデータを指定した S3 バケットにアーカイブしてくれます。 まず、指定したEC2インスタンス「test-kou」に対して、SLAドメインを割り当てます。 SLAドメインを割り当てた後、しばらくすると画面上に反映されます。 AWS側の S3 バケットにバックアップデータのオブジェクトが作成されていることが確認できます。 設定した保存クラスについても、下図のように確認可能です。 RSC側でも下図通り、一次バックアップおよび二次バックアップの取得状況が反映されており、それぞれの処理が正しく実行されたことを確認できます。 「Location」が「Archived」と表示されているものが二次バックアップ、「Primary」と表示されているものが一次バックアップです。 まとめ 今回は、Rubrik と AWS の連携に関する検証内容を整理してご紹介しました。 少し内容が多く、読みづらく感じられた方もいらっしゃるかもしれませんが、最後までご覧いただきありがとうございました。 今回は EC2 インスタンスのバックアップデータ管理に絞ってご説明しましたが、実は S3 や RDS など他の AWS リソースについても、基本的な手順は大きく変わりません。 ご興味のある方は、ぜひ参考にしていただければと思います。

本記事は 新人ブログマラソン2024 の記事です 。 2024年度新人の野上です。 社内業務でQuickSightを初めて利用したのですが、思い通りにデータを扱えず苦戦しました。 QuickSightの分析の中で、計算式や関数を組み合わせて「計算フィールド」を作成できるのですが、エクセルの計算式と同じように使うことはできず、QuickSight独自のルールがありました。 私が苦戦したのは「集計関数」に関するルールです。 このルールを詳しく解説しているブログは少なかったため、同様の問題に直面した初心者方の力になればと思い記事にしました。 集計関数とは まず、「集計関数」とは何かを説明します。 集計関数 とは、複数の行から集計した値を返す関数のことを言います。これはデータ分析などで一般的に用いられる数学的計算です。 表を用いた例で説明すると、以下のようになります。 ここで平均単価＝avg(単価)という計算式で計算されていますが、複数行にわたる単価の値（ 青く囲んだ部分 ）の平均値を返しています。 また、1つの行レベルで計算が可能な関数は 非集計関数 と呼ばれます。 販売金額＝販売個数×単価という計算式で計算していますが、これは1つの行レベルで計算しています。（ 赤く囲んだ部分 ） 直面した集計関数の使用ルール 私が今回直面した集計関数のルールは以下です。 計算フィールドには、入れ子になった集計関数を含めることができません。 上記のルールは普段エクセルを利用している方が直面する問題だと思います。 [参考]: 集計関数 – Amazon QuickSight エラーの例 今回は、販売履歴を時系列で並べたデータセットを使用して、以下のような年度別累計販売金額を表示することを目的としていました。 ここでは、以下の手順で表示することを考えました。 「前年度販売金額」という計算フィールドを作成する 「販売金額」、「前年度販売金額」を使用して累計値を計算する「今年度累計販売金額」、「前年度累計販売金額」という計算フィールド作成 折れ線グラフを2本重ねて表示して、前年度と今年度を比較するグラフを作成する しかし、2.の「前年度累計販売金額」の計算フィールド作成で、以下のようなエラーが確認できました。   ここでは、SUM関数（集計関数）と前年度販売金額が入れ子になっていました。 上記では、集計関数をSUM関数のみしか使っていないように思えますが、計算フィールドである「前年度販売金額」に集計関数が含まれていることで、入れ子になっていると判定されました。「前年度販売金額」では集計関数としてmax関数が用いられていました。   集計関数を複数使用しなければ、目的のグラフを作成することができないため、QuickSight上でグラフが作成できませんでした。   実際に対処した方法 実際には違う対処方法があるかもしれませんが、初心者なりの対処方法ですのでご容赦ください。 エクセルファイルの加工 私は手動でアップロードしたエクセルファイルをデータセットに使用していたため、エクセルファイルを加工することで対処しました。 エクセルファイルにて、日付のセルから年度を切り出すセルを作成 年度ごとに累積値を表示するセルを作成 集計関数を入れ子にすることができないので、入れ子にならないようエクセルファイル上で集計関数を実装してしまうことで、Quicksight上では集計関数が入れ子にならないようにしました。 データセットの再アップロード 先ほど作成できなかった「前年度累計販売金額」の計算フィールドをエラーなく作成することができ、年度別累計販売金額を表示するグラフを作成することができました。 まとめ 今回は、Amazon QuickSightにおける「集計関数」のルールについて説明しました。 私が実際に試したように、BI製品の仕様や制約によっては、元となるデータの加工が必要になることがあります。 案件の中でも同じようなケースが往々にしてありそうだと感じました。 初めてのBI製品を使用する際には、公式のドキュメントなどを確認して仕様を十分に理解することをお勧めします。 この記事がQuickSightを初めて使う方の役に立てば嬉しいです。

こんにちは。SCSK株式会社の安藤です。 先日、AWS X-Rayを操作する機会がありましたので、Zabbixと比較してみたいと思います。監視ツール選定のご参考になれば幸いです。   ZabbixとAWS X-Rayの概要 まずは、ZabbixとAWS X-Ray、それぞれの概要を記載します。   Zabbixとは まずはZabbixの説明を簡単にさせていただきます。 Zabbixは、エンタープライズ対応のオープンソース統合監視ツールです。 サービスやそれを支える ITシステム(サーバ、ネットワーク機器等)の状態を把握し、障害の予兆やサービスへ影響を及ぼす事象が発生した際に、システム管理者やオペレータに通知を行うオープンソースの統合監視ソリューションです。 数万デバイス規模のエンタープライズ環境でも多数の稼動実績を誇っています。 Zabbixの詳細情報については、以下をご確認ください。 Zabbix :: The Enterprise-Class Open Source Network Monitoring Solution ZabbixはITインフラストラクチャ・コンポーネントの可用性やパフォーマンスを監視するためのエンタープライス向けソフトウェアです。Zabbixはオープンソース・ソフトウェアとして開発されており、無料でダウンロードいただくことが可能です。 www.zabbix.com   AWS X-Rayとは 次に、AWS X-Rayについて簡単に説明させていただきます。 X-Rayは、マイクロサービスアーキテクチャにおけるリクエストの流れを追跡し、各サービス間の通信を可視化します。これにより、サービス間の依存関係を視覚的に把握し、パフォーマンスのボトルネックを特定できます。AWSのサービスですので、他のAWSサービス（Lambda、EC2、ECSなど）とシームレスに統合できます。また、カスタムメタデータを追加して、詳細なトレース情報を収集できます。 X-Rayの詳細情報については、以下をご確認ください。 AWS X-Ray（分散アプリケーションの分析とデバッグ）| AWS AWS X-Ray では、リクエストのトレースによりマイクロサービスアプリケーションをデバッグおよび分析できるため、問題の根本原因とパフォーマンスのボトルネックを見つけることができます。 aws.amazon.com   ZabbixとX-Rayの比較 早速比較していきます。 簡単に一覧表にしてみました。 比較項目 Zabbix X-Ray 概要 オープンソースの監視ツール AWSマネージド監視サービス 難易度 Zabbixの知識が必要 AWSの知識があれば 比較的容易 デフォルト機能で有効化できないサービスの場合は 知識が必要 監視対象 クラウド・オンプレどちらも対応 AWSのサービス （Lambda、EC2、ECSなど） コスト ソフトウェア自体： 無料 AWS上に構築する場合：EC2料金 サポート入る場合：年間サポート料金 従量課金制 （監視項目数に応じた課金） 監視対象数 無制限（サーバのスペックに依存） 無制限 サポート Zabbix Enterpriseサポート AWSの公式サポートとコミュニティ   導入難易度 ZabbixはGUIで設定可能ですが、柔軟性が高い分、目的とする監視を設定するために、知識が必要です。 一方X-RayもGUIで設定可能です。AWSの操作に慣れていれば、比較的容易に設定可能と思います。ただし、一部サービスではデフォルト機能で有効化できないので、その場合には知識が必要です。   参考までに、設定方法を記載します。   Zabbix設定方法 サーバは構築済とします。新規導入の場合は、以下の手順をご参照ください。 LinuxサーバーへのZabbixインストール手順 オープンソースの統合監視ツールである「Zabbix」を、Linuxサーバーへインストールする手順を紹介します。 blog.usize-tech.com 2024.02.13 Zabbix 7.0 LTSをインストールしてみた 最新バージョンであるZabbix 7.0 LTSがリリースされましたので、AWS上にインストールしてみたいと思います。 また、インストールするために必要な手順を本記事にて記載いたします。 blog.usize-tech.com 2024.06.12   Web監視の設定例です。 ①監視対象ホストを登録します ②監視アイテムを追加します ③登録されたことを確認します ※上記は、Webページへのアクセスを確認するアイテムを作成しています。より詳細なステップを設定した監視をすることも可能です。   X-Ray設定方法 ①対象のマイクロサービスで、X-Rayトレースを有効化します API Gateway： ログ/トレース のセクションから、有効化します   Lambda：関数の設定から、 CloudWatch Application Signals and AWS X-Ray  セクションの アクティブトレース を有効化します   DynamoDB：デフォルト機能では有効化できません。ライブラリをインストールし、X-RayのSDKを使ってトラッキングの設定をします。   ② AWSマネジメントコンソールより、X-Rayへアクセスします   ③ トレースマップを表示します 左側のナビゲーションペインの  [X-Ray トレース]  セクションで  [トレースマップ]  を選択します。   ③確認したいサービスノードを選択します 直観的操作で、メトリクス、アラート、応答時間の分布など、追加情報を確認できます。ドリルダウンで詳細表示も可能です。   監視対象 監視対象は、Zabbixはクラウド・オンプレ環境両方のサービスを監視できます。管理画面を一元化することが可能です。一方X-Rayは、AWSのサービスとの親和性が高くなっています。   どちらを選ぶ？ 環境や目的に合わせて、最適なツールを選択してください。それぞれ、メリット・デメリット、強み・弱みがあります。 最後まで読んでいただき、ありがとうございました。   最後に 弊社ではZabbix関連サービスを展開しています。以下ページもご参照ください。 ★Zabbixの基礎をまとめたeBookを公開しております！★ FAQ・お問い合わせ｜SCSK Plus サポート for Zabbix 導入をご検討される際、よくあるご質問と回答についてまとめております。 www.scsk.jp   ★SCSK Plus サポート for Zabbix★ SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします www.scsk.jp   ★YouTubeに、SCSK Zabbixチャンネルを開設しました！★ SCSK Zabbixチャンネル 本チャンネルでは、SCSK株式会社でのZabbixに関するトレンド/事例紹介などを動画にまとめて取り上げております。最新のトピックについては、以下の弊社HPもしくはツイッターアカウントをぜひ参照ください。ツイッターアカウント： www.youtube.com   ★X（旧Twitter）に、SCSK Zabbixアカウントを開設しました！★ x.com x.com

こんにちは、SCSKの嶋谷です。 前回私の部署の先輩である谷さんがMackerelを使用してAWSのサーバレスサービスを監視する方法と結果についての記事を掲載しました。 ご覧になっていない方は是非ご覧ください。 Mackerel で AWS のサーバーレスサービスを監視してみた – TechHarmony 話は変わりますが、私が前回投稿した記事の中で紹介しているDify環境は複数のコンテナから構築されてます ( Mackerel で Docker を監視してみた – TechHarmony )。この環境全体の処理の流れや遅延原因を従来のサーバ監視で実現することは不可能です。近年では、このようなマイクロサービスを監視するためにオブザーバビリティフレームワークであるOpenTelemetryが注目を集めています。 OpenTelemetry を使用すればDify環境の詳細な処理の流れや遅延場所の特定ができると思い、検証したいと思いました！ Dify環境のデータをOpenTelemetryで収集するためには、OpenTelemetryの設定をDify環境のプログラムに書き加える必要があります。この処理を1から実装するのは大変だと思いました。そこで今回は、手始めに公開されているデモ環境でデータを収集して、Mackerelで可視化してみました。 OpenTelemetryとは OpenTelemetryとは、システムやサービスの状態を詳細に把握するために必要となるテレメトリーデータ(ログ・トレース・メトリクス)を生成・収集・送信するためのソフトウェアです。CNCF(Cloud Native Computing Foundation)のOpenTracingプロジェクトとOpenCensusプロジェクトが統合されて誕生したプロジェクトによって開発されたソフトウェアです。詳細は以下をご参照ください。 Cloud Native Computing Foundation 近年クラウドネイティブ等の普及により、アプリケーションをそれぞれ異なるコンテナやサーバで構築するシステムが一般的になっています(マイクロサービス)。その結果、情報が分散されシステム全体の状態を把握しづらくなり、迅速なトラブルシューティングが困難となっています。システム全体の状態を把握するためにはテレメトリーデータの収集が必要不可欠です。 旧来はテレメトリーデータは標準化されておらず、ベンダーによってフォーマットや取得方法などが異なっていました( ベンダー依存 )。近年、テレメトリーデータのフォーマット・取得方法などを標準化しようとする動きが活発化しています。OpenTelemetryでは、ベンダー依存することなくテレメトリーデータを収集することができます。さまざまなプログラミング言語に対応可能なAPIやSDKが公開されており、システム構築の際に使用する言語を気にする必要はありません。 詳細については、以下をご参照ください。 OpenTelemetry公式サイト MackerelとOpenTelemetryを連携している記事が数少ないため、実際に実装して記事を書いてみました。 今回の記事ではOpenTelemetryでデータを収集するための「デモ(マイクロサービス)環境の構築」と「Mackerelでデータの可視化」の 2部構成 になっています。 1.デモ(マイクロサービス)環境の構築 まずはデモ(マイクロサービス)環境の構築について説明します。 監視対象について OpenTelemetryの公式サイトにデモ環境が公開されているため、こちらを今回の監視対象としました。具体的には、模擬のECサイトでの操作(商品閲覧・購入・会計など)からテレメトリーデータを収集しています。デモ環境の詳細は以下をご参照ください。 デモ環境 今回はAWSのEC2上にデモ環境を構築しました。構成図は以下の通りです。   デモ環境の構築 Githubからデモ環境のレポジトリをクローン git clone https://github.com/open-telemetry/opentelemetry-demo.git レポジトリをクローンしたディレクトリに移動 cd opentelemetry-demo docker composeコマンドで環境を作成 docker compose up --force-recreate --remove-orphans --detach 起動確認 各サービスごとのコンテナが作成され、起動できていることを確認しました。 ECサイトへのアクセス 4の手順でコンテナが作成され起動できていることを確認したため、実際にアプリケーションが動作していることを確認します。ドキュメントでは、ECサイトに「http://localhost:8080」でアクセスすると記載されています。私はEC2上に環境を構築しているため、同じサブネットに配置した別のEC2からデモ環境が構築されているEC2のプライベートIPアドレスでアクセス(http://プライベートIP:8080)しました。 上記の図のように、初期画面から商品を選択して購入するなどの一般的なECサイトを模倣した操作を行うことが可能となっています。 2.Mackerelへのデータ送信・可視化 前章で構築したECサイトを操作することでテレメトリーデータが生成されます。生成されたテレメトリーデータをMackerelに送信して可視化してみます。今回はトレースデータの可視化について説明します。 トレースデータとは分散システムにおけるリクエストの処理経路を表すデータです。詳細については下記サイトが参考になります。 トレースデータとは何か – その重要性を理解する デモ環境での設定 OpenTelemetryで収集したデータをMackerelに送信するにはデモ環境の設定ファイルでデータの送信先(エンドポイント)にMackerelを設定する必要があります。手順は以下の通りです。 デモ環境のsrc/otel-collectorの設定ファイル(otelcol-config.yml)に以下を追記 exporters: #途中省略 otlphttp/vaxila: endpoint: "https://otlp-vaxila.mackerelio.com" headers: Accept: "*/*" "Mackerel-Api-Key": ${env:MACKEREL_APIKEY} デモ環境直下の設定ファイル(docker-compose.yml)に以下を追記 >otel-collector: #途中省略 enviroment: #途中省略 - MACKEREL_APIKEY=xxxxxxxxxxxxxxxxxxxxxxxxx この処理がとても重要です。 当初は手順1のMACKEREL_APIKEYに直接APIキーを入力していました。この設定時に、APIキーを正しく設定していたのですが、APIキーが無効であるエラーに直面しました。デモ環境はdocker上で動作しており、docker composeコマンドで起動しているため設定ファイル(docker-compose.yml)に環境変数(APIキー)を記述しないと正しく動作しません。私のdocker composeコマンドの理解不足でこの問題を解決するのにとても苦労しました。 環境を再作成 docker compose up --force-recreate --remove-orphans --detach Mackerel上でデータの閲覧 デモ環境での設定が完了すると、Mackerelの画面上でデータを可視化することができます。手順は以下の通りです。 Mackerelのサイドメニューのトレースをクリック クリックするとMackerelの画面がトレースを閲覧する画面に遷移します。 トレース閲覧 トレース閲覧画面では、アプリケーションのサービスごとにトレースを閲覧することができます。 トレース一覧で閲覧したいサービスを選択してデータを可視化します。今回はcheckout(会計)サービスのデータを可視化してみました。 上記の図のようにデータはレイテンシーの分布として表示されています。グラフは横軸が時間で縦軸がレイテンシーとなっており、トレースをヒートマップで表示しています。時間帯・レイテンシーにおけるトレースの総数を可視化することができました！ トレース詳細を閲覧 トレース閲覧画面の下部にはトレースの一覧が表示されています。閲覧したいトレースの行をクリックすることでトレースの詳細を閲覧することができます。 トレースデータはスパン(APIコールやストレージアクセスなどのさまざまなアクション)の集合体であるため　1つのトレースにさまざまな処理が含まれています。トレースの閲覧画面ではサービス毎にスパンが色分けされています。スパンの右端にはレイテンシが記載されており、どの処理に時間を要しているかを確認できます。1つのトレースデータを閲覧するだけでも各サービス間の連携や通信方法などさまざまな情報を理解することができます。 スパンの詳細を閲覧 トレースの詳細画面で1つのスパンをクリックすることでスパンの詳細を閲覧することができます。 スパンの詳細からトレース・スパンのID、開始・終了時刻、ホストOSの情報やサービスで使用されているプログラミング言語など多くの情報を知ることができます。今回はLinux環境でデモ環境を構築したため、OS情報はLinuxが表示されています。今後はWindowとLinuxで表示内容にどのような差があるのかも調査していきたいです。           トレース画面からサービスの処理数(トレース数)や流れ、各処理の詳細を知ることができるためシステム全体を理解することが容易になるのではないかと感じました。また今後は複数の監視サービスとの違いなども調査してみたいと思います。 おわりに OpenTelemetryで取得したデータをMackerelで可視化することができました。デモ環境の構築・Mackerelとの連携ともに詰まった点はありましたが、なんとか解決できたので自分自身の技術力が少し向上した気がしています。 1月~3月までMackerelに関するブログを投稿してきましたが、皆さんも少しMackerelに興味を持ったのではないでしょうか。2週間のトライアルなどもありますので、是非実際に触れてみてほしいと思います。 最後までお付き合いいただきありがとうございました。

こんにちは、SCSKの田中です。 今回は、Azure VM（AVD（Azure Virtual Desktop）ではありません）にOfficeを導入する際、Microsoft 365 E3ライセンスを紐づける際の注意点やつまづきそうなポイントをご紹介いたします。 前提 まずはじめに抑えておきたい前提として、 E3ライセンスは1ユーザーにつき、1ライセンス紐づけられるといったルールがあります 。 デバイスに対して割り当てるようなボリュームライセンス(買い切り)とは異なるものであることをご認識ください。 また E3ライセンスを割り当てることができるユーザーは、Entra ユーザーである ことも前提となります。 Microsoftドキュメントでは、 E3ライセンスを割り当てたEntraユーザーでAzure VMにサインインすることでライセンスをアクティベートすることができる と記されています。 Windows Enterprise は、たとえば、Microsoft 365 管理センターを使用してユーザーに割り当てられます。 ライセンスを持つユーザーが、Microsoft Entra資格情報を使用して要件を満たすデバイスにサインインすると、Windows は Pro エディションから Enterprise、または Pro Education から Education にステップアップします。 エディションがステップアップされると、Enterprise/Education 機能のロックが解除されます。 ユーザーのサブスクリプションの有効期限が切れたり、別のユーザーに転送されたりすると、現在のサブスクリプションの有効期限が切れると、デバイスはシームレスに Windows Pro または Windows Pro Education エディションに戻ります。 Windows サブスクリプション ライセンス認証 | Microsoft Learn   条件 最終的にAzure VMにE3ライセンスをアクティベーションする為に必要な条件を以下に記載いたします。 Azure VMのOSがProエディションであること(評価版でないこと) デバイスがMicrosoft Entra　参加済みであること   実際の手順 はじめに構築したAzure VMに対してMicrosoft Entraへ参加させていきます。 仮想マシン構築時に[管理]タブから[Azure AD資格情報を使用してログインする]を選択することで、Microsoft Entraに参加した状態で起動することができます。 もしチェックをせず構築した場合でもAzure CLIから拡張機能をインストールすることで参加させることができます。   Microsoft Entra ID を使用して Azure の Windows 仮想マシンにサインインする - Microsoft Entra ID Windows を実行している Azure VM に Microsoft Entra 認証を使用してサインインする方法について説明します。 learn.microsoft.com   無事Microsoft Entraに参加されると以下のようにデバイスに表示されます。   続いてE3ライセンスを割り当てたユーザでアクティベーションさせたいAzure VMにサインインします。 E3ライセンスを割り当てたユーザは以下のように製品名とアクティブ状態が表示されます。   アクティベーションが完了していない状態のAzure VMのライセンス認証画面は以下となります。 ライセンスを割り当てたユーザでサインインすることで以下のようにアクティベーション状態となります。   Azure VMへのE3ライセンスアクティベーション手順は以上になります。

はじめに 私はAWSでの構築やPythonプログラムの改修・開発などを行う業務を担当しています。私の開発チームでは開発手法が古く、小規模なチームではあるものの、高品質でスピード感のある開発ができていないという問題がありました。 そこでGitとCI/CDを利用した開発手法を取り入れて、開発チームが高品質でスピード感のある開発ができるような案を考案してみました。チームへの導入はまだ途中ですが、導入背景・課題から構成や具体的な設計方針・運用ルールまでを記載している記事は少ないかと思いますので、同じような問題を抱えている方のお役に少しでも立てればと思い、記事を書きました。 GitやCI/CDを初めて耳にするような方にも理解してもらえるように用語の説明も記載しています。 GitとCI/CD導入の背景・課題 開発は高品質でスピード感あることが理想ですが、私のチームはそんな理想的な開発ができずに困っていました。 そこでデジタル庁のレポート( CI/CDパイプラインにおけるセキュリティの留意点に関する技術レポート )にて定義されている、開発における一般的な業務プロセスごとに現行手法と、その手法によって発生している課題を整理しました。 開発における一般的な業務プロセス ソースコードや設定ファイルに対する作業 品質保証に関わる作業 実行環境への配送および実行 以下のように整理した結果、チームの現行開発手法が全体的に古く、それが原因となってこれら課題が発生していることが分かりました。そして、これら課題が品質・スピードを低下させ、理想的な開発ができていないと推測しました。 業務プロセス 現行手法 課題事例 ソースコードや 設定ファイルに対する作業 詳細設計書をエクセルで作成する 実機と差分が発生 プログラムをバージョン管理せず、 共有フォルダに保管して管理する 変更の追跡が困難 共同作業によりデグレ発生 品質保証に関わる作業 作業前後を見比べて、 作業箇所を発見し、レビューする 作業箇所の見落とし レビューする側の稼働状況により、リリース遅延 動作確認テストまたは、机上検証をする テスト、検証、稼働工数不足 実行環境への配送および実行 手作業で構築する 構築時の設定値誤り プログラムを実行環境へ手作業で配置する 実行環境へのプログラム配置忘れ   GitとCI/CD導入後の手法 現行手法にGit、CI/CDを取り入れて、先ほどの課題を改善し、高品質化、スピード向上を目指す場合、 下記の改善手法が最適と考えました。なお、AWS環境での開発を前提に検討しています。 業務プロセス 現行手法 検討した改善手法 ソースコードや 設定ファイルに対する作業 詳細設計書をエクセルで作成する 詳細設計書をCloudFormationで代替する プログラムをバージョン管理せず、 共有フォルダに保管して管理する プログラムをGitでバージョン管理する 品質保証に関わる作業 作業前後を見比べて、 作業箇所を発見し、レビューする 作業箇所をGitで自動的に表示し、レビューする 動作確認テストまたは、机上検証をする 自動動作確認テストまたは、AIによる机上検証する 実行環境への配送および実行 手作業で構築する CI/CDを利用して自動で構築する プログラムを実行環境へ手作業で配置する プログラムを実行環境にGitで半自動に配置する 補足：Gitとは Gitはファイルの変更履歴を記録・管理するアプリケーションです。 Git周りの用語も説明すると、Gitでは作業者はファイルやディレクトリに対する編集結果を自身の作業端末上の「ローカルリポジトリ」という保管場所に記録します。これを「コミット」と呼びます。 複数人で作業をする場合は、ローカルリポジトリにおける差分を関係者と同期するために、差分をソースコード管理システム上の「リモートリポジトリ(リポジトリ)」に送信します。これを「プッシュ」と呼びます。 他作業者への影響を最小限とするために、一般的に「ブランチ」を作成します。 元のブランチの内容に影響を与えることなく安全に変更を加え、そして変更が完了したら、メインの内容に統合します。これを「マージ」と呼びます。マージの承認依頼を「プルリクエスト」と呼びます。 補足：CI/CDとは CI(Continuous Integration)は継続的インテグレーションと呼ばれ、ソースコードから環境で実行できる成果物を生成(ビルド)し、動作確認テストをすることを意味します。 CD(Continuous Delivery)は継続的デリバリーと呼ばれ、成果物(ソースコード)を実行環境に自動的に配送することを意味します。 CI/CDパイプラインについて デジタル庁レポートを参考に、CI/CDパイプラインを用いた実行環境への配備までの各フェーズを説明します。 CI/CDパイプラインにおけるセキュリティの留意点に関する技術レポート ローカル作業フェーズ 先ほどの表における、業務プロセスの「ソースコードや設定ファイルに対する作業」に相当します。 主に作業者がソースコードや設定ファイルに対する作業と検証を行うフェーズとなります。 作業者は手元の端末や統合開発環境（IDE）で作業をし、その内容をGitでソースコード管理システムに送ります。 ビルドフェーズ 先ほどの表における、業務プロセスの「品質保証に関わる作業」に相当します。 最新のソースコードや設定ファイルを元とした成果物の生成、検証・テスト、保管を行うフェーズです。 CI/CD パイプラインの内、CIがこれに当たります。 デリバリフェーズ 先ほどの表における、業務プロセスの「実行環境への配送および実行」に相当します。 成果物の実行環境への配送と実行を行うフェーズです。CI/CD パイプラインの内、CDがこれに当たります。   GitとCI/CD導入後の構成 今回、改善を行うシステムはAWSを利用しており、開発環境と本番環境の2面構成です。また、業務用プログラムの実行環境として社内に2台のPCを設置しています。 体制は開発チームと運用チームの2チーム体制で、運用チームは監視結果のレポートの発行やお客様の新規追加・解約に合わせて、AWSの構成変更を行います。 こういった環境や体制にGitとCI/CDを導入すると、以下構成になると考えています。   次に、先ほどのデジタル庁レポートで用いられていた3つのフェーズに当てはめて、検証開始から本番環境や実行環境への配備までの作業の流れを説明します。なお、各フェーズを行ったり来たりしますのでご注意ください。 開発環境での作業の流れ 開発環境では、検証や検証完了リソースを本番環境にデプロイする前の動作確認が目的です。 ローカル作業フェーズ 開発者は機能開発や改修を契機に開発ブランチから機能検証ブランチを新たに作成して検証を開始します。 開発者は検証における作業結果を機能検証ブランチにプッシュします。 検証終了後、開発者は機能検証ブランチから開発ブランチへのプルリクエストを送信し、CodeGuruの指摘コメントを反映し、承認者へレビューを依頼します。 承認者はプルリクエストをレビューし、問題が無ければ承認の上、機能検証ブランチを開発ブランチへマージします。 ビルドフェーズ 開発者からのプルリクエストをトリガにコードチェック用のパイプラインが起動し、CodeGuruが作業結果をレビューし、指摘をプルリクエストのコメントに記載します。 （AWSデプロイを伴う時）マージをトリガにデプロイ用パイプラインがCloudFormation(CFn)テンプレートをCFnへ取り込める形式に変換して、S3に保管します。 デリバリフェーズ （AWSデプロイを伴う時）デプロイ用パイプラインが変換されたCFnテンプレートをCFnに取り込み、CFnがリソースを構築し、動作確認可能な状態とします。 （実行環境PC上のスクリプト更新を伴う時）開発者が実行環境PC上の開発ブランチでプルを実行。開発ブランチのスクリプトが実行環境PCに配置され、動作確認可能な状態とします。 本番環境での作業の流れ 本番環境では、本番稼働リソースを本番環境へ配備すること、実行環境へプログラムを配備することが目的です。 ローカル作業フェーズ 開発環境での動作確認終了後、開発者は開発ブランチから本番ブランチへのプルリクエストを送信し、CodeGuruの指摘コメントを反映し、承認者へレビューを依頼します。 承認者はプルリクエストをレビューし、問題が無ければ承認の上、開発ブランチを本番ブランチへマージします。 （顧客追加・解約時）運用者が開発ブランチにて顧客情報を記載したCFnテンプレートを配置します。 運用者は開発ブランチから本番ブランチへのプルリクエストを送信し、CodeGuruの指摘コメントを反映し、承認者へレビューを依頼します。 （顧客追加・解約時）承認者はプルリクエストをレビューし、問題が無ければ承認の上、開発ブランチを本番ブランチへマージします。 ビルドフェーズ プルリクエストをトリガにコードチェック用パイプラインが起動し、CodeGuruが作業結果をレビューし、指摘をプルリクエストのコメントに記載します。 （AWSデプロイを伴う時）マージをトリガにデプロイ用パイプラインがCFnテンプレートをCFnへ取り込める形式に変換して、S3に保管します。 デリバリフェーズ （AWSデプロイを伴う時）デプロイ用パイプラインが変換されたCFnテンプレートをCFnに取り込み、CFnがリソースを構築し、リリースされます。 （実行環境PC上のスクリプト更新を伴う時）開発者が実行環境PC上の本番ブランチでプルを実行。本番ブランチのスクリプトがPCに配置され、本番利用可能な状態となります。   改善手法を実現するための設計方針・運用ルール 改善手法を実現するための設計方針や運用ルールを記載します。これら設計方針や運用ルールはデジタル庁のレポート（ CI/CDパイプラインにおけるセキュリティの留意点に関する技術レポート ）を参考にしました。 CloudFormation、Gitについては導入済みで、実績のある設計方針や運用ルールもありますが、それ以外の技術は机上検証はしていますが、実績はありません。以下は参考程度に利用いただき、利用する際は十分に検証してから利用いただくことをお勧めいたします。   CloudFormationにおける運用ルール テンプレート作成に関するルール CloudFormationには機密情報を載せず、最悪ソースコードが流失しても問題ない状態とすること。 機密情報、個人情報を利用する場合はParameterStoreへ保管し、そこから取得すること。 取得した機密情報、個人情報は後続フェーズへ引き継がないこと。 テンプレートが詳細設計書としても機能するように、各設定値の真上にコメントでその設定値とした理由を記載すること。 ただし、JSONの場合は仕様によりコメントを記載できないためコメントは不要とする。 テンプレートは原則YAML とするが、プログラムで処理がしやすい場合はJSONを利用しても良い。 本番、開発環境で一貫して同じテンプレートを利用するため、アカウントIDや自リージョンなどは組み込み関数の変数(例えば、自リージョンは!Ref “AWS::Region”)を利用すること。 効率性、安全性を高めるため、原則、ネストテンプレート構成とする。 リソースの参照はリポジトリ内のリソースパスを参照パスとして利用すること。 CloudFormationへ取り込む前のルール テンプレートのアップロード前に”aws cloudformation validate-template”コマンドを使用して、テンプレートの構文に誤りが無いことを事前に検証すること リソースによっては設定変更時に一度削除して、構築される場合があるため、テンプレートのアップロード前に変更セットを作成し、意図しない作成、削除が発生しないことを確認してから、アップロードすること。 「aws cloudformation create-change-set」コマンドを使用して、変更セットを作成します。 変更セットを作成したら、「aws cloudformation describe-change-set」コマンドを使用してその内容を確認できます。 その他 AWSでの構築は原則、CloudFormationによる構築とし、マネジメントコンソールでの構築は禁止とする。 定期的にリソースを自動作成したい場合、定期実行EventBridgeでテンプレートを修正・追記する方針とする。 EventBridgeで直接リソースを作成し、コードで管理していないリソースを作り出さないため。   Gitにおける運用ルール 作業環境 開発ツール 開発者はVSCodeを統合開発環境とし、GitLens(無料版)という拡張機能を導入すること。 生成AIを利用し、CFnテンプレートやソースコードのたたき台を作成する時に活用すること。 認証情報を一度入力したら以降は毎回入力する必要が無いように、GitCredentialManagerを利用する。 開発ルール 誰が更新したのかが分かるようにGitコマンドにおけるUsernameは姓名(アルファベット)で設定し、Emailは会社アドレスを設定する。 Gitの作業履歴はコミットとして残す方針とし、Gitコマンドの強制プッシュを原則禁止とする。 生成AIは社内ガイドラインに沿って利用すること。必要に応じて情報をマスクして利用すること。 作業者毎にリポジトリアクセス用IAMユーザを発行し、開発者はフルアクセス権限、それ以外（実行環境PCや運用チーム)には読み取り権限を付与する。 フルアクセス権限はAWSCodeCommitPowerUserポリシーのみを、読み取り権限はAWSCodeCommitReadOnlyポリシーのみを付与する。 リポジトリアクセス用ユーザには利便性向上のため、Gitコマンド実行時のMFAを強制しない。 開発、本番ブランチの削除、直接のプッシュができない権限をリポジトリアクセス用ユーザ、マネコンユーザに付与する。 ただし、顧客追加/解約時に利用するため、運用チームはマネコンユーザで開発ブランチへファイルを配置できるようにする。 運用チームは原則、実行環境PC上のCFnテンプレートやプログラムの更新を行わないこと。ただし、ブランチにアップロードしていない実行環境PC固有のファイルであれば更新可能 実行環境PCではグローバルな.gitignoreファイルを作成すること。（git config –global core.excludesfile ~/.gitignore_global) 情報漏えいを防ぐため、個人所有のGit系SaaSの認証情報を作業者端末に設定しない。 ブランチ構成について CFnテンプレートを可能な限り検証から本番まで一貫して利用すること。バグの早期発見が目的。 開発、本番環境用にブランチを作成する。開発、本番ブランチは削除せずに永続的に残す。 開発環境での検証用に機能検証ブランチを複数作成・削除して良い。機能検証ブランチは機能開発やバグ改修のたびに開発ブランチから分岐して、機能検証ブランチを作成すること。 緊急改修が必要な時でも機能検証→開発→本番ブランチという順番で迅速に改修できるため、緊急改修ブランチは作成しない。 顧客追加/解約時、運用チームはマネコン経由で開発ブランチにCFnテンプレートをアップロードし、本番ブランチへのプルリクエストによって新規顧客に必要なリソースを構築/削除すること。 各ブランチの分岐元ブランチ、ブランチへのプッシュ可否、ブランチへマージできるブランチ、ブランチ削除可否は以下表を参照すること。 ブランチ名 概要 分岐元ブランチ ブランチへのプッシュ可否 このブランチへマージできるブランチ ブランチの削除可否 本番ブランチ 本番環境で稼働するリソースやソースコードが格納されるブランチ 無 不可 開発ブランチ 不可 開発ブランチ 開発環境で稼働するリソースやソースコードが格納されるブランチ 本番(初回だけ) 開発チーム：不可 運用チーム：可 機能検証 ブランチ 不可 機能検証 ブランチ 機能開発や改修を頻繁に行うブランチ 開発 可 無し 可 各ブランチの分岐、マージのイメージを以下に図示する。 プッシュ、プル、プルリクエストについて プッシュ時、レビューする人が修正内容を判断しやすくするために、担当した修正タスク名、要件、設計方針のいずれかをプッシュ時のコミットにコメントすること。プッシュが大量に実施される場合は任意のコメントで良い。 デバッグにより同じ修正タスクに対して、複数回プッシュする必要がある場合、修正タスク名と回数をコメントに記載するなど適当なコメントでも良い。 強制プッシュ（例えば、”git push origin main –force”,”git push origin main -f”）を禁止とする。ただし、リモートリポジトリへの影響がないローカル環境での強制力のある操作は許可する。 特にVSCodeのエラーウィンドウが出現した際は、強制力のある操作がされることがあるため、forceやf、上書きといった言葉が使われているエラーメッセージの場合は翻訳して意味を理解したうえでOKボタンを押す。 プッシュしたコミットを取り消す場合、”git revert”を利用し、コミットの取り消しを行う。コミットを取り消した状態のコミットでプッシュしてリモートリポジトリに反映すること。（取り消し履歴を残すことが目的） プルリクエスト時、レビューする人が修正内容を判断しやすくするために、プルリクエストのタイトル欄に担当した修正タスク名、説明欄に要件、設計方針、修正したことのいずれかを記載すること。 コミットしていない変更がある状態でブランチ移動などをしたい場合、”stash”を利用して変更を一時保存する。（コミットしていない変更が存在する場合はブランチ移動などの一部操作が不可のため） プッシュ、プルリクエストでコンフリクトが発生した場合、コンフリクト行を影響が無いように修正したうえで再度プッシュ、プルリクエストを送信すること。 影響が発生する場合は、必要に応じてGitLensで該当行のコミッターを特定し、そのコミッターと相談してコンフリクトを解消すること。 フォルダ構成について 顧客新規追加/解約時はマネコン経由で開発ブランチにCFnテンプレートをアップロードし、本番用ブランチにプルリクする。 リポジトリルートに.gitignoreファイルを配置して、.conf、.log、.xls、.jsonなどログや認証情報は除外する レビューについて レビューイ（レビューしてもらう側） 分岐したブランチから本番または、開発用のブランチにプルリクエストをする。 Amazon CodeGuruがプルリクエストの更新分に対して自動的にレビューし、指摘をコメントする。 CodeGuruからの指摘コメントがある場合は指摘反映後、そのプルリクエストを閉じて、再度プルリクエストする。指摘コメントがなくなるまで繰り返す。 CodeGuruからの指摘コメントが無い場合、レビュアーにプルリクエストのレビューを依頼する。 CodeGuruのレビューコメントが間違っている、意図的にベストプラクティスに沿わないコードとする場合はコメントに対してその理由をコメントし、その指摘を無視する。 レビュアー（レビューする側） プルリクエストのマージ先ブランチが正しいことを確認する。 意図しないリソースの置き換えが発生していないかを確認する。 過去にCodeGuruから指摘があったどうかを確認し、CodeGuruからの指摘を反映できているか確認する。 ファイル内の特定行に対して指摘があれば、その行にコメントをする。 ファイルに全体的な指摘があれば、ファイルに対してコメントをする。 レビュー合格であれば、プルリクエストを承認して、マージする。 マージ時はソースブランチを削除する。   CI/CDにおける設計方針、運用ルール CodePipeline ステージ共通 パイプラインの構成もCFnテンプレートで管理する。パイプライン用CFnテンプレートをCFnへ手動で取り込んで構築する。 パイプラインやCloudFormationが利用するIAMロールには基本的にAWS管理ポリシーを付与せず、必要最低限のポリシーを付与すること。 開発環境にコードチェック用、AWSデプロイ用のパイプラインを構築し、本番環境にはAWSデプロイ用のパイプラインを構築する。 検証ではパイプラインを利用しないため、コードチェック用のパイプラインで実行されるコマンドをローカル環境で実行しておくこと。 ソースステージ ソースリポジトリはCodeCommitを指定すること。 ブランチは本番環境では本番ブランチを、開発環境では開発ブランチまたは、機能検証ブランチを紐づける。機能検証ブランチは複数作成されるため、機能検証ブランチごとにパイプラインを作成すること。 検出はEventBridgeを利用してソースの変更を検知する。ソース変更のポーリングは開発、検証環境は自動ポーリングを有効としても良いが、本番は手動ポーリングとする。 ビルドステージ ビルド端末内ではソースステージからのアーティファクトを解凍し、ビルドステージの端末内で展開する。 パッケージ化を行うアクショングループでは、リソースへの参照パスはそのままではCloudFormationへ取り込めないことからS3 URLパスに変更するために親テンプレートをビルド端末内で「aws cloudformation package」コマンドでパッケージ化する。 保存先バケットのオブジェクト名にはコミットIDを含める。 既に構築されているリソースへの更新、削除はスタックを設定し、ドリフト検出する。 ビルド端末内で変更セットを作成させ、置き換え、削除、更新が発生する場合、ビルド端末からプルリクエストにコメントを追記すること。コメント追記後に変更セットを削除する。 ビルド時のログは全てCloudWatchLogsへ保管すること。 コードチェック用パイプライン向け CodeGuru Securityへパッケージテンプレートを送信する。 AWSデプロイ用パイプライン向け ビルド端末内でパッケージ化したテンプレートをアーティファクトとしてデプロイステージへ引き渡す。 デプロイステージでアーティファクトの改ざん検証に利用するため、テンプレートのハッシュ値を取得し、パイプラインの変数にハッシュ値を格納する。 デプロイステージ（AWSデプロイ用パイプライン向け） アーティファクトが改ざんされていないか検証するため、S3から取得したテンプレートのハッシュ値とパイプラインの変数に格納したハッシュ値を比較し、検証する。 デプロイステージであるが、CodeBuildを利用して上記を実現する。 ビルドステージから引き渡されたアーティファクトに対して、パッケージ化されたファイルをデプロイするように設定する。 S3 バケットはAWS管理のキーで暗号化し、公開設定としないこと。 バケットはバージョニングを有効化すること。 バケットポリシーで同環境のコードパイプラインとAdministratorのIAMユーザ以外のアクセスを拒否する。 ParameterStore 機密情報、個人情報は全てパラメータストアに保管すること。 IAM、EventBridge 以下クロスアカウントアクセス用のIAMロールを開発環境に作成する 本番環境のIAMロールが本ロールを引き受けられる(AssumeRoleされる)こと 本番環境のCodePipelineが開発環境のCodeCommitにアクセスできること CodeCommit上のソースコードを本番におけるCodePipelineのアーティファクトバケットに格納できること 以下クロスアカウントアクセス用のIAMロールを本番環境に作成する 上記開発環境のIAMロールを引き受ける(AssumeRoleする)こと CodeCommitの変更イベントを本番環境に通知するEventbridgeを開発環境に作成し、通知をトリガーにパイプラインを起動するEventbridgeを本番環境に作成する ※IAM、EventBridgeは以下記事を参考にさせていただきました。 https://qiita.com/ozzy3/items/079f82b6123ec57f3c91

SCSKの畑です。 これまでのエントリで説明してきた Redshift テーブルデータのメンテナンスアプリケーションにテーブルデータの差分比較機能を実装しているのですが、バックエンド側についてどのように実装したのかを記載してみます。 アーキテクチャ図 性懲りもなく今回も。今回はバックエンド側の処理として実装しているため、以下図では AppSync から呼び出される Lambda が対象となります。ただ、Lambda ならではの話みたいなものは今回は正直ないです・・   背景 テーブルデータの差分比較機能については、元々お客さんと詰めた 機能要件の一つ にありましたので実装は規定路線でしたが、フロントエンド/バックエンドのどちらで実装するかというのがちょっとした考えどころでした。本アプリケーションにおけるテーブルデータの差分比較機能は、 アプリケーション上でユーザが編集したデータと編集前のデータを比較 異なるバージョン間のテーブルデータを比較 の2パターンで使用されますが、前者の方が使用頻度は高いと思われること、及び（当然ながら）ユーザはアプリケーション上でテーブルデータを編集することの2点より、当初はフロントエンド側で実装する方針としました。しかし、具体的にどのようなアプローチで実装するのかなかなか定まりませんでした。 まず、 少し前のエントリ で紹介した Tablator 上で編集した項目（セル）の情報を保持できるためそれをそのまま使用しようかと考えていましたが、ライブラリの仕様上 削除した行データ＆外部ファイルからインポートしたデータ の場合は対象とならないことが分かりました。また、異なるバージョン間のテーブルデータを比較する場合は実質的に S3 上のテーブルデータ同士を比較する処理となり、Tablator の機能は使用できないため見送ることに。 Tabulator - Editing Data Use built in cell editors to allow users to edit table data, or build out your own for fully customizable table input tabulator.info よって、真っ当に2つのテーブルデータを比較するような処理をフロントエンドでどう実装するかを考えたのですが、Javascript（Typescript）でその手の処理を実装したことがなかったため、ライブラリや比較手法の調査でこれという正解が見つかりませんでした。元々 Python の pandas ライブラリについては過去案件などで使い慣れていたため、pandas ライクに使用できるライブラリが良さそうということで調べたところ danfo.js なるものを見つけました。 Danfo.js Documentation | Danfo.js Danfo.js is an open-source, JavaScript library providing high-performance, intuitive, and easy-to-use data structures fo... danfo.jsdata.org 使い勝手も良さそうだったのですが、実はこの調査の過程で pandas であれば簡単に差分比較できる方法を見つけてしまっており・・残念ながらその方法が使えなさそうだったため、その分のロジックについて自前で実装することを考慮するとバックエンド側で Python/pandas を使用して実装してしまう方がトータルで効率良いのではないかということで、バックエンド側で実装する方針に変更しました。また、差分比較処理自体は相応に重い処理であるため、フロントエンド（クライアント）側で実装した場合の影響を憂慮したことも理由の一つです。バックエンド側で実装する分には、（極論） Lambda に頑張ってもらえれば良いだけなので・・ なお、バックエンド側で差分比較を実装するにあたり、フロントエンド側で編集したテーブルデータをバックエンド側に持ってくる処理が追加で必要となりましたが、ちょうど編集中のデータを S3 上に一時保存するような機能を実装したところだったため、同機能と合わせて差分比較を実施するようにすることで問題なく実装できました。異なるバージョン間のテーブルデータ比較については先述した通りS3 上のテーブルデータ同士を比較する処理であり、Lambda 上から直接処理できたため問題ありませんでした。   pandas を使用した実装方法 ということで本題なのですが、pandas.DataFrame.merge の indicator 引数を使用することでテーブルデータの差分比較を容易に実現することができました。 pandas.DataFrame.merge — pandas 2.2.3 documentation pandas.pydata.org 例として以下のような2つのテーブル間での差分比較を考えてみます。table_1 を編集前のデータ、table_2 を編集後のデータと想定し、同テーブルにおける PK 列を「pk」列とします。 [table_1] pk col_1 col_2 col_3 row_0 1 2 3 4 row_1 11 12 13 14 row_2 101 102 103 104 [table_2] pk col_1 col_2 col_3 row_0 2 3 4 5 row_1 11 12 13 14 row_2 101 102 1030 1040 よって、差分比較の結果としては、 table_1 の 1行目：table_1 にのみ存在するデータ（＝編集で削除された行データ） table_2 の 1行目：table_2 にのみ存在するデータ（＝編集で追加された行データ） table_1/table2 の 3行目：table_1 の 3行目の「col2」「col3」列の値が変更されたデータ のように差分が検出されることを期待しています。 具体的な実装例は以下の通りです。df_table_1 及び df_table_2 にそれぞれのテーブルに対応した DataFrame が定義されている前提として、DataFrame.merge で差分比較を実施しています。この関数自体は2つのテーブルを結合（マージ）する関数であり、結合条件は on 引数で、結合方法は how 引数で示されます。よって、以下の実装例は 全ての列を結合条件とした外部結合処理 となります。 純粋にテーブル間での差分比較を実施するために全ての列を結合条件としています。別の言い方をすると、結合条件に指定する列のみが差分比較の対象となり、それ以外の列における差異は無視されます。よって、ユースケースにより差分を検出したい列のみを結合条件に指定すると良いでしょう。 import pandas as pd df_table_1 = pd.DataFrame( [[1, 2, 3, 4], [11, 12, 13, 14], [101, 102, 103, 104]], columns=['pk', 'col_1', 'col_2', 'col_3'], index=['row_0', 'row_1', 'row_2'] ) df_table_2 = pd.DataFrame( [[2, 3, 4, 5], [11, 12, 13, 14], [101, 102, 1030, 1040]], columns=['pk', 'col_1', 'col_2', 'col_3'], index=['row_0', 'row_1', 'row_2'] ) df_compared = pd.merge(df_table_1, df_table_2, on=['pk', 'col_1', 'col_2', 'col_3'], how='outer', indicator=True) すると、実行結果として以下のような DataFrame が得られます。この _merge 列の内容が実質的に差分比較結果を示しており、それぞれ以下のような意味となります。つまり、both 以外の行については何らかの差分があるということになります。 both：両方のテーブルに存在している行データが一致している行 left_only：左側のテーブルにのみ存在している行 本実装例では table_1 が該当 right_only：右側のテーブルにのみ存在している行 本実装例では table_2 が該当 pk col_1 col_2 col_3 _merge 0 1 2 3 4 left_only 1 2 3 4 5 right_only 2 11 12 13 14 both 3 101 102 103 104 left_only 4 101 102 1030 1040 right_only 実行結果を見ますと、想定される差分比較結果の項目で示した内、1. と 2. の項目については想定通りに検出されていることが確認できます。一方で 3. の項目については left_only と right_only の両方が出力されています。 これは先述した外部結合のロジックを踏まえると自明なのですが、全列のデータを比較している以上 table_1 と table_2 で異なる行データとして出力されることから、即ち left_only と right_only の両方が出力されている行はデータの一部が変更されていることが分かります。ただ、この実行結果自体からはプログラム上でそれを簡単に判断することができません。よって、行データを一意に区別するための情報である PK 列で実行結果を GROUP BY することにより、各行ごとの差分比較結果を得ることができます。以下変更後のコードとなります。 本実装のロジック上、PK 列のみの行データ更新は実質的に行削除/行追加のセットとして認識されます。先述した通り、PK 列が行データを一意に区別するための情報であるためですが、これは一般的な RDBMS や KVS でもオペレーション上はそのような制約がある（PK列のみの変更はできず、行削除/行追加が必要）ことがあるため、差分比較のロジックとしても特に問題はないと判断しています。お客さんにも業務上そのようなオペレーションが基本的に発生せず、発生した場合は行削除/行追加のセットとして差分認識されても問題ないことを確認しています。 import pandas as pd df_table_1 = pd.DataFrame( [[1, 2, 3, 4], [11, 12, 13, 14], [101, 102, 103, 104]], columns=['pk', 'col_1', 'col_2', 'col_3'], index=['row_0', 'row_1', 'row_2'] ) df_table_2 = pd.DataFrame( [[2, 3, 4, 5], [11, 12, 13, 14], [101, 102, 1030, 1040]], columns=['pk', 'col_1', 'col_2', 'col_3'], index=['row_0', 'row_1', 'row_2'] ) df_compared = pd.merge(df_table_1, df_table_2, on=['pk', 'col_1', 'col_2', 'col_3'], how='outer', indicator=True).query(f'_merge != "both"').groupby(['pk']) for pk_cols, group in df_compared: print(f'pk_cols: {pk_cols}') print(group) その結果、以下のように PK の値ごとに差異のある行データがそれぞれ取得できていることが分かります。 pk_cols: (1,) pk col_1 col_2 col_3 _merge 0 1 2 3 4 left_only pk_cols: (2,) pk col_1 col_2 col_3 _merge 1 2 3 4 5 right_only pk_cols: (101,) pk col_1 col_2 col_3 _merge 3 101 102 103 104 left_only 4 101 102 1030 1040 right_only もちろんこのままでは3.のパターンについてどの列のデータに差異があるのか分からないため、Lambda 上では差異検出用のロジックを組んだ上で追加された行・削除された行・変更された行の3パターンに分けて最終的に JSON 形式で情報を出力するようにしていますが、そのあたりの実装は本情報を扱うアプリケーション/処理によって適宜変更されるものと思います。 なお、本実装の制約事項として、ロジック上テーブル定義（列定義）の異なる2つのデータを比較した場合はエラーが出力されてしまい比較できません。本アプリケーションにおいて列定義の変更はスコープ外としておりその観点では考慮の必要がありませんでしたが、アプリケーション外での列定義変更についてはユースケース上あり得るため、Lambda 上の実装では DataFrame.merge の実行前に列定義が同一であることを確認するようにしています。 そのような背景もあって、 テーブルデータのメンテナンス機能について補足したエントリ に記載している通り、テーブルの列定義はファイル単位で保持した上で、ファイルのハッシュ値のみで同一性を比較できるようにしています。   まとめ 本案件事例ではアプリケーション内の一機能として実装していますが、例えばデータベースの移行時や ETL/ELT 関連処理時においてデータベース外でテーブルデータの差分比較を実施したいケース自体はこれまでも度々あったため、備忘も兼ねてまとめてみた次第です。もちろん、データベース内で比較してしまうのが、処理速度やリソース面の観点も含めて一番手っ取り早い方法かと思いますが、ファイルベースで比較したいという機会も意外と多かったりするので・・ 本記事がどなたかの役に゙立てば幸いです。

1. はじめに こんにちは。SCSK志村です。 Azureの仮想ネットワークサービスにおける「ネットワークセキュリティグループ(以下NSG)」と「ルートテーブル」の既定値および実機挙動の確認方法についてまとめました。 2.NSGの既定値について NSGは作成時にAzure によって既定の規則が作成されます。 既定の規則の詳細は公式ドキュメントの以下に記述があります。 Azure ネットワーク セキュリティ グループの概要 | Microsoft Learn 受信規則の一つを例にとって確認してみます。 Priority source 送信元ポート 宛先 送信先ポート Protocol アクセス 65000 VirtualNetwork 0-65535 VirtualNetwork 0-65535 Any Allow source/宛先が「VirtualNetwork」に対するすべての通信が許可されていることが確認できます。 この「VirtualNetwork」は「サービスタグ」と呼ばれる、Azureで定義されたIPアドレスプレフィックスのグループを表します。 Azure サービス タグの概要 | Microsoft Learn 例えば、「VirtualNetwork」は仮想ネットワークアドレス空間をグルーピングしたものであることがわかります。 仮想ネットワーク アドレス空間 (仮想ネットワークに対して定義されているすべての IP アドレスの範囲)、すべての接続されたオンプレミスのアドレス空間、 ピアリング された仮想ネットワーク、 仮想ネットワーク ゲートウェイ に接続された仮想ネットワーク、 ホストの仮想 IP アドレス 、および ユーザーが定義したルート で使用されるアドレス プレフィックス。 このタグには、既定のルートも含まれる場合もあります。 上記の受信規則が実際の環境でどのような許可をしているのかを実機で調査してみました。 3.NSGの実機挙動の確認方法 Azure上で以下の環境を作成しました。 サービス IPアドレスプレフィックス/IPアドレス VNet 10.0.0.0/16 Subnet 10.0.0.0/24 VM 10.0.0.4 サブネットに既定の設定で作成したNSGを紐づけています。 公式ドキュメントの記載通り、「VirtualNetwork」からの通信が許可されています。 この「VirtualNetwork」が指す具体的なIPアドレスプレフィックスは、「有効なセキュリティルール」の機能で確認することができます。 ネットワークセキュリティグループの画面から　「ヘルプ」>「有効なセキュリティルール」を表示します。 対象サブネットに存在する「仮想マシン」・「NIC」を選択すると対象のNICで有効となっているルールが表示されます。 ここでサービスタグ「仮想ネットワーク※」を選択します。 ※表示により「VirtualNetwork」と「仮想ネットワーク」の翻訳の表記ゆれが発生するのでご注意ください。 アドレスプレフィックスとしてソース、宛先に「10.0.0.0/16」「168.63.129.16/32」と表示されました。 「10.0.0.0/16」：このSubnetが存在するVNetのIPアドレスプレフィックス 「168.63.129.16/32」：Azureプラットフォームリソースへの通信で利用するIPアドレス(ホストノードの仮想 IP) IP アドレス 168.63.129.16 とは | Microsoft Learn この2つのIPアドレスプレフィックスが「VirtualNetwork」タグとしてグルーピングされていることを確認することができました。 受信規則も送信規則も許可されているので同一VNet内の通信は既定の設定で許可されていることがわかります。 4.ルートテーブルの既定値について 次にルートテーブルの既定値を確認します。 既定のルートの詳細は公式ドキュメントの以下に記述があります。 Azure 仮想ネットワーク トラフィックのルーティング | Microsoft Learn Azure 仮想ネットワークのサブネットごとにルート テーブルが自動的に作成され、既定のシステム ルートがテーブルに追加されます。  と記述があるため、このシステムルートの一つを例にとって確認してみます。 ソース アドレス プレフィックス 次ホップの種類 Default 仮想ネットワークに固有 仮想ネットワーク 仮想ネットワーク(VNet)のIPアドレスプレフィックスの次ホップが仮想ネットワークとなっています。 仮想ネットワーク内のルーティングはシステムルートで定義されていることが確認できます。 上記のシステムルートが実際の環境でどのような許可をしているのかを実機で調査してみました。 ５.ルートテーブルの実機挙動の確認方法 既定の設定でルートテーブルを作成し、サブネットにアタッチします。 システムルートが存在するはずですが、表示上はルートが存在しないことが確認できます。 実際にルートは存在しないのか、どのようなルートが有効になっているのかは「有効なルート」の機能で確認することができます。 ルートテーブルの画面から　「ヘルプ」>「有効なルート」　を開き、「仮想マシン」・「NIC」を選択します。 すると、対象のNICで有効となっているルートが表示されます。 ルートテーブル上には何も表示されませんでしたが、有効となっているルートが存在することを確認できます。 VnetのIPアドレスプレフィックス「10.0.0.0/16」のネクストホップが仮想ネットワークとなっており、先のシステムルートの記述の通りとなっていることがわかります。 表示上ルートは存在しませんがルートテーブルの確認時は「システムルート」が有効化されていることに注意が必要です。 6.まとめ NSG、ルートテーブルの既定値と実機挙動の確認方法をまとめてみました。 既定で一定の通信が許可されるのはユーザフレンドリーではありますが、想定しない通信許可にもつながります。 設計通りの通信許可となっているか実機で確認をしておくと安心と考えます。 この記事がAzureにおけるネットワーク設計の一助になれば幸いです。

この記事はCatoクラウドをご利用中の方に向けた重要なお知らせです。 2024年11月に Cato Networksより、Catoクラウドのルート証明書が更新される旨の下記アナウンスがありました。 FAQ for the New Default Cato Certificate for TLS Inspection 現在のルート証明書は、有効期限が2025年10月29日までとなっています。この期限前までに各Catoクラウド環境にて新しいルート証明書への切り替え作業が必要です。 SCSKのご契約者様向けFAQサイトにも詳細を掲載しておりますが、本件に関するお問い合わせを多数いただいていることから、この記事でも対応方法、よくあるご質問等をご説明します。 この記事の要約 現在、Catoクラウドのルート証明書は、有効期限が2025年10月29日までのもの(旧証明書)と、2034年3月3日までもの(新証明書)の2種類が存在します。 2024年11月以前は旧証明書のみが配布されていたため、ご利用の多くのお客様は、新証明書への切り替えを行う必要があります。 ルート証明書は、端末側では新旧の両方をインストール可能です。しかしながら、Catoクラウド側で利用されるルート証明書は1つのみのため、すべての端末で新証明書のインストールが完了した後に、Cato管理画面から証明書の切り替えを行います。この作業は、旧証明書の有効期限である2025年10月29日までに完了する必要があります。 WindowsでCatoクライアントをご利用の場合は新旧証明書が自動でインストールされますが、macOS、Linux、iOS(iPhone/iPad)、Androidについては、新証明書を手動でインストールする必要があります(※macOSは例外があるため記事内容をご参照ください)。また、Catoクライアントをインストールしていない端末は、どのOSであっても新証明書の手動インストールが必要です。 ただし、Catoのルート証明書を利用せず、お客様独自のルート証明書を利用されている場合は、本対応の対象外となります。 前提情報 Catoクラウドのルート証明書とは? Catoクラウドには、TLS Inspectionという機能があります。これは、暗号化されたHTTPSトラフィックをCato PoP上で検査する仕組みで、セキュリティ上重要な機能です。TLS Inspectionが有効な環境では、端末がHTTPS接続を行う際にCatoクラウドのルート証明書が使用されます。そのため、Catoクラウドを経由して通信するすべての端末に、このルート証明書のインストールが必要となります。 また、ルート証明書はTLS Inspectionの他に、Firewall等での通信Block/Warning時の警告画面を表示するときにも使用されています。このため、TLS Inspectionを利用していない場合であっても、端末にルート証明書のインストールが必要です。 証明書の有効期限切れとは? すべての電子証明書には有効期限があり、期限を過ぎると使えなくなってしまいます。 Catoクラウドの既存のルート証明書は10年の有効期限で発行されており、2025年10月29日に期限切れとなります。これ以降は使用することができないため、 もし新しいルート証明書に切り替えをしなかった場合、HTTPSのWebページが表示できなくなる等の影響があります。 本記事では、以降の項目にて新しいルート証明書への切り替え方法をご案内していきます。 対応フローチャート まず、対応の流れは以下となります。 作業Step0: 対応が必要かどうか確認 ご利用の環境で対応が必要かどうかは、CMA(Cato管理画面)から確認可能です。Security > Certificate Management から、現在有効となっているルート証明書がどれなのかをご確認ください。 「2015～」と「2024～」の行があり、 2015のほうが「Active」になっている場合 👉️対応が必要です。「2024～」への切り替えを行う必要があります。 Step1へ進んでください。 「2024～」の1行のみがあり「Active」になっている場合 👉️ 対応は不要 です。2024年11月以降で開設されたアカウントのため、すでに新しい証明書が適用されています。 「2015～」と「2024～」の行があり、2024のほうが「Active」になっている場合 👉️ 対応は不要 です。すでに切り替えが完了しています。 「Custom Certificate」が「Active」になっている場合 👉️ 対応は不要 です。Catoのルート証明書ではない独自証明書を利用されています。証明書期限はご自身で管理をお願いいたします。 作業Step1: 各端末へ新しいルート証明書をインストール Catoクラウドを使用するすべての端末に、新しいルート証明書をインストールし、新旧両方の証明書が入っている状態にします。 OSや利用状況ごとに必要な対応が異なる点にご注意ください。 Windowsで、Catoクライアントをインストールしている端末 Catoクライアントがアップグレードされる際に、新証明書が自動でインストールされます。クライアントがバージョン5.11以上であれば新証明書もインストール済みです。もしそれ以下の場合には最新バージョンにアップグレードしてください。 macOSで、Catoクライアントをインストールしている端末 クライアントバージョン5.7以上を新規にインストールした場合は、新証明書・旧証明書の両方が自動でインストールされますので、対応不要です。 5.6以下をご利用中の場合、または 5.6以下から5.7以上へアップグレードした場合には、新証明書が自動でインストールされません。 新証明書の配布・インストールが必要です。 また、いずれの場合も、キーチェーンアクセスからCatoのルート証明書を信頼設定してください。 Linux、iOS、Androidで、Catoクライアントをインストールしている端末 新証明書が自動でインストールされません。新証明書の配布・インストールが必要です。 なお、Linux・Androidは TLS Inspectionの対象外ですが、ルート証明書はFirewall等の警告画面の表示にも使用されているため、インストールが必要です。 OSを問わず、Catoクライアント未導入で、Catoのネットワーク内にある端末 拠点内の据え置きPCなど、Catoクライアントをインストールしていない、Catoのルート証明書のみを導入している端末では、 新証明書が自動でインストールされません。新証明書の配布・インストールが必要です。 各OSの証明書導入手順 新しいルート証明書は、 Catoダウンロードサイト より入手可能です。 また、各OSへの導入手順は、以下のCato KnowledgeBase をご参照ください。 Windows Installing the Cato Certificate on Windows Devices macOS Installing the Cato Certificate on macOS Devices iOS Installing the Cato Certificate on iOS Devices Android Installing the Cato Certificate on Android Devices Linux 環境ごとに異なるため、OSのドキュメント等をご確認ください なお、各端末への新証明書の配布・インストールは、手動での対応の他、ご利用のActive DirectoryやMDM・端末管理システムから配布する方法もあります。 作業Step2: CMAからルート証明書を切り替え 以降の作業は、全ての端末に新証明書を導入した後に実施してください。切り替え作業後は、新証明書が入っていない端末は通信不可となります。 Cato側で利用する証明書を、新証明書に切り替えます。 CMAで Security > Certificate Management を開きます。「2024～」の行の右端「…」から「Activate」をクリックします。 切り替えの確認画面が表示されます。「OK」をクリックします。 切り替えすると以下のように「2024～」のほうが「Active」となります。 以上で、ルート証明書の切り替え作業は完了です。 よくあるご質問 ルート証明書の切り替えに関し、これまでにいただいているご質問をご紹介します。 端末に新・旧両方の証明書をインストールして問題ないのか はい。両方の証明書が入っていても、OSやCatoクライアントの動作には問題ありません。 旧証明書を入手したいときはどうしたらよいか Catoダウンロードサイト から入手できる証明書は、すでに新証明書となっています。旧証明書が必要な際は、CMAにログインし Security > Certificate Management を表示、「2015～」行の右端「…」をクリックしダウンロードしてください。 TLS Inspectionを利用していないが、証明書更新は必要なのか 必要です。ルート証明書はTLS Inspectionの他に、Firewall等の警告画面を表示するときにも使用されているためです。 なお、Catoクラウドの機能を有効活用いただくため、TLS InspectionはONとすることを強くおすすめしております。 端末側で旧証明書・新証明書を見分けるにはどうしたらいいか 証明書のCommon Name(CN)が異なりますので、表示される名前で判別可能です。 旧証明書(2015) ⇒ Cato Networks CA 新証明書(2024) ⇒ Cato Networks Root CA もちろん有効期限で見分けることも可能です。 新証明書へ切り替え後、一部の端末のみWebサイトが正しく表示できない 当該端末に新証明書がインストールされていない可能性があります。端末側を確認してください。 新証明書へ切り替え後、特定のアプリケーションやブラウザのみ利用不可となった アプリケーションやブラウザによっては、OSの証明書を参照しないものがあります。 その場合、当該アプリケーションへ個別に新証明書を設定する必要があります。 例) JavaSE、Git、IntelliJ、Firefox Developer Edition、Waterfox等 新証明書に切り替えしたが、旧証明書を使うよう戻したい 「2015」のほうの証明書をActivateすることで戻せます。切り替え・切り戻しに回数等の制限は無く、何度でも可能です。 切り替え完了後、旧証明書はどうしたらよいか 端末側の旧証明書はそのままで差し支えありませんが、削除しても問題ありません。CMA側は、現時点ではそのまま表示され続けます。今後削除されるかどうかは未定です。 今後もこのような証明書更新が発生するのか 新証明書の期限が2034年のため、2033年に同様の更新が必要となる予定です。 最後に 以上、ルート証明書更新についてのご案内でした。期限は2025年10月29日ですが、早めの対応をお願いいたします。 ご不明な点がありましたら、SCSKをはじめ、Catoクラウドのライセンス提供元へお問い合わせください。

SCSKの畑です。 今回は完全に Nuxt3 に閉じた話題ですが、アプリケーションのルーティングパス設計を当初の意図通りのものにするのにちょっと苦労したので、その経緯と解決策もといちょっとした Tips について紹介してみます。タイトルの通り完全に小ネタです。。。   本題 これまでのエントリで取り上げてきた Redshift テーブルデータのメンテナンスアプリケーションにおいては、テーブルの主な編集状態（ステータス）が以下3種類定義されており、設計上それぞれで画面（URL パス）を分けています。 normal：通常状態 editing_content：テーブルデータの編集中 awaiting_approval：編集後のテーブルデータ更新承認待ち 以前のエントリ で記載したような更新承認用の簡易ワークフローに対応 上記の各画面に対応した機能が各テーブルで共通であることから、実装及びメンテナンスコストを抑えるために各テーブルごとにページ/コンポーネントは作成せず、共通化する方針としていました。よって、テーブル名については URL パスからパラメータとしてページ/コンポーネントに渡してあげるような形で、以下のような URL パス設計を考えていました。対象テーブルのステータスが normal であればテーブル名のみ、そうでなければ対象のステータスがその後ろの URL で指定されるような形式です。 <ルートURL>/mastertable/<テーブル名>：通常状態の画面 <ルートURL>/mastertable/<テーブル名>/editing_content：テーブルデータの編集中画面 <ルートURL>/mastertable/<テーブル名>/awaiting_approval：テーブルデータ更新承認待ち画面 Nuxt3 の場合はデフォルトでファイルシステムベースのルーティングが使われており、pages ディレクトリ配下のファイル/ディレクトリ配置に応じてルーティングが定義されます。また、パスの一部をパラメータとしてページ/コンポーネントに渡すような動的ルーティングも可能となっており、ファイル/ディレクトリ名の一部を [] で囲むと、その部分がパラメータとして解釈されます。先述の通り、今回の場合はテーブル名を [table_name] としてパラメータとして渡すことを考えて、ファイル/ディレクトリ構造を以下のようにしていました。 pages/mastertable ├ [table_name].vue：通常状態の画面 └ [table_name] ├ editing_content.vue：テーブルデータの編集中画面 └ awaiting_approval.vue：テーブルデータ更新承認待ち画面 ところが、この方法だと上手くいきませんでした。[table_name] の定義が同じディレクトリ階層で重複してしまったことが原因と考えられますが、ちょっと調べた限りでは他の方法が見当たらず。 後から調べたところ Nested Routes というルーティング（というよりはファイル/ディレクトリ構造によりページ/コンポーネントをネストする仕組み？）に該当していたようなのですが、どちらにせよ本来の目的外でした。。 pages · Nuxt Directory Structure Nuxt provides file-based routing to create routes within your web application. nuxt.com この時点では各機能の開発中であったため以下のような仮のルーティングに変更して作業を進めていたのですが、URL パスの末尾にテーブル名が来てしまい当初の設計通りになっていない上、各画面の Vue ファイル名が同一になってしまう分かりづらさなども相まって、事あるごとに何とかならないかとモヤモヤすることに。 pages/mastertable ├ [table_name].vue：通常状態の画面 ├ editing_content └ [table_name].vue：テーブルデータの編集中画面 └ awaiting_approval └ [table_name].vue：テーブルデータ更新承認待ち画面 その後開発が進み、テーブルデータのバージョン管理（参照）機能を追加したのですが、バージョン情報を URL パスとしてどう取り扱うかを検討する必要がありました。同機能においても画面としては通常状態のものを共用する想定であり、バージョン情報を URL パスとして渡すかどうかで画面上に表示するデータの種類（最新データ or 指定バージョンのデータ）を切り替えるようなイメージで考えていました。 それと合わせて先述したルーティングの課題についても検討すべく色々調べた結果どうにか解決策に辿り着き、最終的には以下のようなディレクトリ構成となりました。 pages/mastertable └ [table_name] ├ [[version_index]].vue：通常状態（最新データ）の画面 兼 特定のバージョンデータ参照画面 ├ editing_content.vue：テーブルデータの編集中画面 └ awaiting_approval.vue：テーブルデータ更新承認待ち画面  version_index というバージョン情報を表すルートパラメータを [[]] で囲んでいますが、この記法が解決策のキモでして、オプショナル（省略可能）なルートパラメータという意味合いとなります。 pages · Nuxt Directory Structure Nuxt provides file-based routing to create routes within your web application. nuxt.com 即ち、URL パスに version_index ルートパラメータを含むか否かで画面に表示するデータの種類の出し分けを行うロジックを実装できる上、URL パスとしても <ルートURL>/mastertable/<テーブル名>：通常状態（最新データ）の画面 <ルートURL>/mastertable/<テーブル名>/<バージョン情報>：特定のバージョンデータ参照画面 <ルートURL>/mastertable/<テーブル名>/editing_content：テーブルデータの編集中画面 <ルートURL>/mastertable/<テーブル名>/awaiting_approval：テーブルデータ更新承認待ち画面 のように、通常状態（最新データ）に対応する URL パスはバージョン番号が省略された結果テーブル名のみの形式となり、編集中/承認待ちの場合はテーブル名の後ろに対応するステータス名が指定される形式となります。よって、バージョン情報の取り込みと共に当初の設計通りの URL パスを指定することができ、無事にモヤモヤ感も解消することができました。。 なお、本解決策は以下の Nuxt3 解説書を読んでいて見つけたものだったのですが、公式 URL をよくよく見るとちゃんと書いてありました。あまりにシレっと書いてあるので、このエントリを書くにあたって改めて見返すまで気づきませんでしたが・・ Nuxt 3 フロントエンド開発の教科書 本書は，最近需要が急増しているSSR（Server Side Rendering）によるSPA開発に適したWebアプリケーションフレームワーク「Nuxt 3」の解説書です。Nuxtは，最新のバージョン3でVue 3に完全対応したことで，Co... gihyo.jp ちなみに、Nuxt3 ではカスタムルーティングを実装することも可能ですが、本案件事例ではそこまでの必要性がなかったため本記事では触れません。そのあたりも含めたルーティング設定の詳細については以下のサイト様がよくまとまっているかと思いました。 Nuxt 3 × Vue Router の主要な機能をまとめてみた zenn.dev   まとめ Nuxt3 における動的ルーティングについては色々な情報があるのですが、オプショナルなパラメータの使用例も含めた情報はそれほど多くないように思えたため、備忘がてら書いてみた次第です。 本記事がどなたかの役に立てば幸いです。

本記事は 新人ブログマラソン2024 の記事です 。 皆さん、こんにちは！新米エンジニアの佐々木です。 今日は、企業のデータ活用をグッと加速させる、ビッグなお知らせがあります！ 企業のデータ活用を強力に後押しするため、 SCSKはSnowflake Inc.と販売代理店契約を結びました！ これにより、 SCSKからSnowflakeを販売できるようになりましたが、それだけではなく、Snowflakeの導入から運用・保守に至るまでの技術支援、また、 最短5日でSnowflake環境を用意することができるサービス など、魅力的なサービスラインナップを用意しました！ なぜ、このサービスが必要なのか？ 多くの企業がDX（デジタルトランスフォーメーション）やAI（人工知能）の活用に大きな期待を寄せていますが、実際にはデータが社内のあちこちに散らばっていて、なかなか有効活用できていないのが現状です。特に大企業では、組織の壁がデータの一元管理を阻み、本格的なデータ活用が進んでいないという課題があります。 そこでSCSKは、このデータ管理の課題を解決して企業がもっと手軽に、そして効果的にデータを使えるように、Snowflakeと連携したサービスを提供開始しました！ Snowflakeとは？ Snowflakeとは、シンプルで効率的、そして信頼性の高いAI活用を実現するためのデータプラットフォームです。 世界中の1万社以上もの企業が、このSnowflakeのAIデータクラウドを活用し、データ共有、AI/機械学習アプリケーションの開発、そしてAIによるビジネスの強化に取り組んでいます。 Snowflakeのここがすごい！ マルチクラウド対応:  Amazon Web Services、Microsoft Azure、Google Cloudといった主要なクラウドプラットフォームで利用可能。 データ共有とエコシステム:  データ共有やマーケットプレイスを通じて、安全かつ柔軟なデータコラボレーションが実現。 高パフォーマンス & メンテナンスフリー:  コンピューティング層とストレージ層が分離されているため、高いパフォーマンスを維持しながら、運用にかかる負担を大幅に軽減。 Snowflakeについてもっと詳しく知りたい方はこちらへ！ Snowflake AIデータクラウド | Snowflake Japan Snowflakeデータクラウドにぜひご参加ください。このグローバルネットワークでは、何千もの組織がコラボレーション、多様なワークロードの強化、データアプリケーションの構築を行っています。 www.snowflake.com SCSKのSnowflake活用サービス：3つのポイント SCSKは、Snowflakeを活用してお客様のデータ活用を強力にサポートします。主なサービスは以下の3つです。 クラウドデータ活用基盤クイックスタートパック： データ分析に必要なシステム環境を、Snowflakeを含めて 最短5日 で構築できるテンプレートをご提供。すぐにデータ活用を始められます。 Snowflakeテクニカルエスコートサービス： データ戦略の企画から、基盤構築、運用、活用まで、Snowflakeのエキスパートがお客様に寄り添い、データ活用を内製化できるようサポートします。 「ナレコレBI」のSnowflake対応： SCSKのデータ分析ツール「ナレコレBI」がSnowflakeに対応。Snowflakeのスモールスタートの強みを活かし、「ナレコレBI」を導入することで、より迅速にデータ分析を始めることが可能です。 各サービスについては近日中にそれぞれ別ブログとして発信しようと思っているので、乞うご期待下さい！ 今後の展開 SCSKは、今回発表した「クラウドデータ活用基盤クイックスタートパック」を、 2025年度に10社、2027年度までに累計30社 のお客様にご導入いただくことを目標としています！ さらに、Snowflake関連サービスを拡充するとともに、これまで培ってきた基幹・サプライチェーン領域のソリューションとの連携も視野に入れ、データ活用の可能性を広げる新たなサービスを開発していきます！ 皆さんも、SCSKの今後のデータ活用に関する取り組みに、ぜひご期待ください！ 最後に 最後に、本件に関する内容は社外向け発信文書としても公開しておりますので、是非以下もご覧ください！ https://www.scsk.jp/news/2025/pdf/20250311i.pdf

SASE。ゼロトラスト。 「近年バズワードとして注目されていることは知っているが、調べてみてもよく分からない。」 「ネットワークやセキュリティのソリューションなのは理解できたが、自分の言葉で説明できない。」 私は2024年12月から新たにSASEを担当することになりましたが、最初に感じた壁が上記でした。 今回は私のような「これを機にSASEを理解したい」という方に向けて、超初心者向けの「SASEとは？」を説明していきます。   SASEの概要 まずはSASEについて、その概要をご説明します。 表面だけでなく、自分の中に落とし込んで理解することが大事だと思いますので、本記事を見て腑に落ちない部分があれば、ぜひ他の記事などで深掘りしてみてください。 SASEを一言で言うと SASEを一言で言うと「“ネットワーク”と“ネットワークセキュリティ”をクラウドベースで統合したもの」 です。 ※SASEとは、 S ecure A ccess S ervice E dgeの略 となります。 “ネットワーク”とは・・・ 光ファイバーや専用線などで行うような通信の提供と、その通信を制御・管理する仕組みのことを指します。 具体的には、SD-WAN、MPLS、Ethernet、VPN、AWSのDirect Connect、AzureのExpressRouteなどです。 “ネットワークセキュリティ”とは・・・ ネットワークの利用に関わるあらゆる脅威を防御する仕組みを指します。 具体的には、ファイアウォール、セキュアゲートウェイ(SGW)、CASB、DLPなどです。 上記を一体化しクラウドサービスで提供する製品(もしくはそのような概念)を、SASEと呼びます。 ちなみに、ここから“Access(ネットワーク)”を抜いた、SSE(Secure Service Edge)という概念・製品もあります。 詳細を知りたい方は、以下を参照ください。 SSEとSASEどちらを選べばよいのか？ SSE（Security Service Edge）とSASE（Secure Access Service Edge）どちらを選択すれば良いのかについて解説を行っています。 blog.usize-tech.com 2023.11.27 なお、SASEとゼロトラストの違い・関係についてイマイチ理解できない、という方もいるかもしれません(私もそうでした)。 これらの関係性をイメージするために、次はゼロトラストについて説明します。 ゼロトラストの考え方と、SASEとの関係性 ゼロトラストとは、サイバーセキュリティにおける概念(考え方) です。 どんな概念かというと、 「すべて信用しない(Zero Trust) という前提に立ち、適切な認証を受けたユーザーと端末だけが、許可されたアプリケーションやデータにアクセスできるようにする」 というものになります。 これは、従来の 境界型セキュリティの考え方、 「外部(インターネット)と内部(社内LAN)を境界で分け、内部は信用できるという前提のもと、内部を外部攻撃から防御する」 とは全く異なる考え方 となります。 IaaS(AWSなど)やSaaSの普及、リモートワークの増加、サイバー攻撃の巧妙化に伴い、徐々にゼロトラストが重要視され始めました。 ゼロトラストアーキテクチャ（ゼロトラストを実現するための7つの要素） は、以下のように定義されています。  これら各要素のサービスを提供する会社が、それぞれ“ゼロトラスト”を謳っているため、世の中には様々な“ゼロトラストソリューション”が存在します。(会社によっては、MFAも“ゼロトラストソリューション”と呼ばれ、CASBも“ゼロトラストソリューション”と呼ばれます。) いろいろな製品が“ゼロトラストソリューション”と呼ばれると分かり辛いのですが、 SASEに関しては、ゼロトラストアーキテクチャ上で、主に“ネットワークセキュリティ”の要素/機能を提供するソリューション です。 つまり、SASEはゼロトラストを実現する要素の1つ、と言うことです。 繰り返しになりますが、 SASE自体は“ネットワーク”と“ネットワークセキュリティ”のクラウドソリューションである 、とご理解ください。 SASEを構成する機能 SASEが持つべき機能は何なのか？　を具体的に以下に羅列します。 ※こちらは、私がGartner(最初にSASEを提唱した会社)のレポートから、分かりやすさ/耳なじみの良さを重視して再整理したものです。 ＜ネットワーク機能＞ ・プライベートバックボーン(専用の回線)、SD-WAN、Proxy、WAN最適化、QoS、ネットワークアプライアンス(NW機器)　他 ＜ネットワークセキュリティ機能＞ ・ファイヤーウォール(FW)、SWG、ZTNA、CASB、RBI　他 ※出典：Magic Quadrant for Single-Vendor SASE, Published 3 July 2024 また、これら全てはクラウドベースで提供されることが大前提となります。 なお、 世の中にSASEを呼称するソリューションは沢山ありますが、その中には、上記全ての機能が含まれていない製品も数多くあります。 （例えば、ネットワークセキュリティ機能はあるがSD-WAN、Proxyの機能はない・・・など） SASEを検討される際には、「自社に必要な機能は何なのか？」、「その機能が検討しているSASEに含まれているのか？」について、ぜひ整理していただければと思います。 ※弊社にご相談いただければ、お客様の要件と最適なSASEについて、ご一緒に整理させていただきます。   SASE導入のメリット 「SASEが一体何なのか？」、少しでも理解が深まりましたでしょうか？ 概要が理解できれば、次のステップとして 「SASEは私達にどんな価値をもたらすのか？」 が気になるところです。 SASEは、 境界型(従来型)のネットワーク/セキュリティを利用している方にとって多大なメリット がありますが、複合的で一言では表現し辛いため、自分なりの分類で説明してみます。 ＜SASE導入のメリット＞ No 特徴(利点) 価値をもたらす領域 ① ネットワーク構成がシンプルになる 運用面、コスト面、セキュリティ面 ② 全ての通信をリアルタイムに一元管理できる (ネットワークの)品質面、運用面 ③ 境界だけではなく、拠点/端末間の通信も全てセキュアに管理できる セキュリティ面 ④ すぐに利用できる・スモールスタートできる デリバリー面、コスト面 ①ネットワーク構成がシンプルになる これが、 SASEの最大の特徴であり、かつ最大のメリット だと思います。 従来型のネットワークは、複数キャリアを使い分け・管理していたり、セキュリティ機器がバラバラであったりと、シンプルな構成ではないことがほとんどです。 近年ではリモートワーク環境、SaaS・IaaSの導入が急激に進んだことで、継ぎ接ぎの対応による更なる複雑化が進んでしまっています。 SASEでは、 ネットワークとネットワークセキュリティの機能が全てクラウドサービスで提供 されるため、 これまで多種多様な機器・サービスで対応していたネットワーク領域を集約化 できます。 ネットワーク領域の集約化によって、 運用負荷は大きく軽減 されます。（キャリア/機器ごとの細かな管理・調整は必要なくなります。） コスト面では、 通信キャリアのサービスや各種機器にかかる費用は不要と なります。 もちろんSASE分のコストは新たに発生しますが、ネットワーク全体のコストで見ると、環境次第で大幅な削減が可能となります。 また、集約化により企業の セキュリティポリシーも統一化され、一元管理が可能 となるため、企業のセキュリティレベルを向上させます。 ②全ての通信をリアルタイムに一元管理できる 従来のネットワーク(インターネット・専用線)では、専用の分析ツール・サービスなどを利用しない限り、通信量や通信内容を可視化することができません。 つまり 「誰が」、「いつ」、「どこに」、「どれくらい」通信したかが、分からない状況 です。 この状態には、様々な問題があります。 まず、通信帯域がひっ迫している場合に、その原因特定・対処が出来ません。 そうすると、品質が悪いという結果論で、本当は必要ない回線増強(コスト増)を行ってしまう可能性があります。 ※具体的に例えると、通信がひっ迫している原因が実は「多くの社員が業務内にYoutubeを見ているから」だと特定できれば、 回線増強をしなくても、社員へのYoutubeアクセスを制限するだけで問題は解決するかもしれません。 同様に、ネットワーク障害やセキュリティインシデントが発生した場合にも、その原因特定・対処が困難となります。 (対応できる場合もありますが、可視化している場合と比べて格段に時間を要します。) SASEでは、 全ての通信量・通信内容をリアルタイムに可視化・一元管理でき、上記のような問題を解消 します。 ③境界だけではなく、拠点/端末間の通信も全てセキュアに管理できる サイバー攻撃はどんどん巧妙化しており、もはや従来の境界型セキュリティでは対応しきれなくなっています。 例えば、直近の脆弱性を突いた「ゼロデイ攻撃」、セキュリティの弱い子会社・関連会社・地方/海外拠点からターゲットの企業に侵入する「サプライチェーン攻撃」などが有名です。 また、「フィッシング(メールを通じた偽URLへの誘導など)」もかなり巧妙化しており、馬鹿にできません。 境界型セキュリティ(内部は安全)のネットワークでは、外部からの攻撃は想定(対策)していても、社内通信を利用した内部からの攻撃は想定(対策)していません。 つまり、高度な攻撃で一度社内に侵入されると、全てのシステムに自由にアクセスされてしまいます。 毎年、こういった方法で多くの企業がランサムウェアや情報漏洩の被害に遭っています。 この問題を解消するために注目されているのが「ゼロトラスト」であり、SASEはその実現を手助けします。 先述の通り、 SASEは クラウドで“ネットワーク”と“ネットワークセキュリティ”を提供 する製品 です。 それは、 外部だけでなく、内部(拠点/端末間の通信)も全てセキュアに管理できる ということであり、拠点を経由しターゲット侵入する　「サプライチェーン攻撃」への防御を可能とします。 また、 クラウドサービスのため自社で管理するセキュリティ機器は無くなり 、「ゼロデイ攻撃」など脆弱性を狙った攻撃も回避できます。 ※各種機器の脆弱性対応（パッチ適応・バージョンアップ作業）は、SASEベンダー側で厳格に管理・実行されます。 巧妙化するサイバー攻撃への対策には、SASEの導入が大きな効果を発揮します。 ④すぐに利用できる・スモールスタートできる これはクラウドサービスの一般的なメリットですが、もちろんSASEでも同様です。 従来、新たな回線を手配する場合には、開通まで数か月程度のリードタイムが発生します。(増速する場合にも、同様に数か月必要です。) セキュリティ機器に関しても、モノにもよりますが少なからず納期の影響を受けます。 クラウドサービスである SASEでは、インターネット回線さえあれば、新規回線の手配や増速にリードタイムを必要としません。 （既存ネットワークやSASEの設定・構築期間は必要となります。） 所定の手続きの経てライセンスが発行されれば、即利用可能となります。 すぐに利用可能なため、SASEはスモールスタートしやすいソリューションでもあります。 クラウドサービスの特性を活かして、小規模から始められる価格形態のSASEも多数あります。 最小構成から始め、後から必要に応じて拠点/帯域/セキュリティ機能などを追加する 、 という柔軟な導入を行える事が、SASEの強みの１つとなります。   おわりに SASEを学び始めて3ヶ月の私の言葉で、できるだけ詳しくない方にも伝わるように解説してみました。 「SASEとは何？」「何が魅力なの？」について、理解が深まりましたでしょうか？ 何か知識を身に着けるうえで「しっかり理解すること(=自分の中に落とし込み、嚙み砕き、自分の言葉で説明できるようになること)」は　とても大事ですが、解説サイトや説明資料を見ても表面上・文字面でしか理解できない、という悩みは良くあると思います。 特にSASEは、ネットワークやセキュリティ関連の経験があれば別ですが、初心者の方にとっては「しっかり理解すること」が難しい領域だと感じています。 私も3ヶ月前までそういった経験がなく、とても苦労しました。 この記事が、皆さんのSASEに対する理解を深める一助となれば、嬉しく思います。 最近は、 生成AIを活用するとより具体的で分かり易く解説してくれたりもする ので、ピンとこなかった説明は、ぜひご自身でも深掘りしてみてください。