こんにちは、SCSK松岡です。 本記事では、クラウドデータプラットフォームであるSnowflakeが提供する数多くの機能のうち、データの共有/複製に焦点を当ててご紹介します。 データ分析・活用基盤の構築において、データの共有や複製は、システムの柔軟性や拡張性を高め、また管理を容易にするためのとても重要な機能です。 Snowflakeにおける代表的な共有/複製機能を特徴から分類し、それぞれのユースケースを記載しました。実現したい目的に応じてご参考いただければ幸いです。 Snowflakeとは Snowflake (Snowflake Cloud Data Platform)は、Snowflake社が提供するSaaS型のクラウドデータプラットフォームです。 データ管理、セキュリティ、ガバナンス、可用性、データレジリエンスをサポートしたフルマネージド型のサービスであり、ウェアハウスのスケーリング/ポリシー制御/データ共有の柔軟性などから、デジタルデータの一元管理に優れたプラットフォームとして注目を集めています。 プラットフォームの概要 Snowflakeのクラウドデータプラットフォームが世界的に、あらゆる規模、あらゆる業界において、をほぼ無制限の同時実行ワークロードで強化した方法をご紹介します。 www.snowflake.com   Snowflakeの共有/複製機能の分類 Snowflakeの主な共有/複製機能は、大きく以下の2観点で分けることができます。 「アカウントをまたいでデータ共有・複製するか」 「物理的にデータをコピーして共有・複製するか」 こちらの観点に基づき、Snowflakeの機能を4タイプに分類してみました Snowflakeにおける「アカウント」とは、ユーザーやリソースを管理するための単位です。 通常、部門やプロジェクトごとにアカウントを分割して管理します。 それぞれの機能についてご紹介します。   ゼロコピークローン ゼロコピークローン は、データの物理的なコピーを行わずにクローンを即座に作成できる機能です。 アカウント内のデータベース、スキーマ、テーブルをそれぞれの単位で自由にクローンすることができます。 概要を図で表すと以下のようになります。 メタデータ層は、データオブジェクト（テーブル、ビュー、インデックスなど）に関する構造的な情報を管理します。 ストレージ層は、Snowflakeで管理されるデータの物理的な保管場所です。 ストレージのコストを抑えながら(※)、スナップショットを容易に作成できることから、テスト環境を準備するようなユースケースで役立ちます。 ※クローン時点で追加のストレージコストは発生しませんが、 クローンしたデータを変更した場合は、それに応じてストレージの料金が発生します。 また、定義された期間の任意の時点にアクセスできるタイムトラベル機能を利用し、過去の履歴データを対象にクローンすることで、オブジェクトをリカバリするような使い方も可能です。 クローニングに関する考慮事項 | Snowflake Documentation docs.snowflake.com   データシェアリング Snowflakeでは、 データシェアリング の機能を活用することで、異なるアカウント間であっても柔軟にデータの共有が可能です。 データシェアリングでは、データのコピーは行わずに、データの共有先アカウント(コンシューマー)に読み取り専用の権限を付与します。 迅速かつ簡単に共有できることから、最新のデータに基づく分析を、異なる部門・組織間で行いたいようなユースケースで役立ちます。 Secure Data Sharingの紹介 | Snowflake Documentation docs.snowflake.com   アンロード (エクスポート) ゼロコピークローンがデータコピーを行わずにオブジェクトを複製する一方で、バックアップや他システムとの連携など、外部にデータをコピーしたいケースもあるかと思います。 Snowflakeでは、データを外部のクラウドストレージに アンロード(エクスポート) する機能も用意されています。 アンロードする際の対象データは、SQLクエリを用いて柔軟に指定することが可能です データのアンロードの概要 | Snowflake Documentation docs.snowflake.com   データベースレプリケーション/ アカウントレプリケーション 災害時の備えとして リージョン間の冗長性を持たせたい場合のように、異なるアカウント間でデータのコピーを行いたいケースもあるかと思います。 Snowflakeの データベースレプリケーション の機能では、複製スケジュールを設定した上で、 柔軟にアカウント間のデータを同期させることが可能です。 アカウントがBusiness Critical以上のプランであれば、上位の機能として、 ウェアハウス、ユーザー、ロール等も含めて同期させることができる アカウントレプリケーション が利用できます。 複数のアカウント間にわたるデータベースとアカウントオブジェクトの複製 | Snowflake Documentation docs.snowflake.com   最後に 「共有」「複製」といっても、Snowflakeでは様々な機能やオプションが提供されています。 目的に合ったものを見つけるためには、いったん立ち止まって「どこ・誰との共有か」「何のための複製か」を明確にすることが重要だなと今回整理して再認識しました。 公式サイトでは、各機能のより詳細な仕組みや考慮事項の説明があるので、そちらも合わせてご参考ください。

Cato クラウドの XDR Cato クラウドでは、ネットワークのトラフィックやエンドポイントの振る舞いなどの各種ログを Cato 独自の AI や機械学習アルゴリズムによって分析し、セキュリティ上の攻撃や脅威を自動的に検知する機能が提供されています。 この機能は XDR (Extended Detection and Response) と呼ばれており、問題を早期に発見・対処することを目的として、検知された問題を確認するダッシュボードやそれを分析するための一連のツールが用意されています。 この機能は情報セキュリティにおけるインシデントレスポンスを行う上で非常に有益なものであるのですが、活用するにはハードルが高いものであるとも感じています。そこで本記事では、そのギャップを埋めてお客様に XDR 機能を活用していただくために、XDR 機能を用いた運用例について説明します。 なお、Cato クラウドの XDR の紹介や基本的な利用シナリオについては次の記事にも記載しておりますので、そちらを先にご覧ください。（翻訳記事のため読みにくい部分がありますが、ご容赦ください。） CatoクラウドのEPPとXDRについて Catoクラウドで新たにリリースされたEndpoint Protection（EPP）とExtended Detection and Response（XDR）についての解説をしています。 blog.usize-tech.com 2024.02.14 世界初SASEベースのXDRについて Catoクラウドの世界初のSASEベースのXDRについて、とあるセキュリティアナリストの一日に焦点を当てた記事になります。 blog.usize-tech.com 2024.02.07 XDR 機能を用いたセキュリティ運用例 Cato クラウドの XDR 機能では、検知したセキュリティを脅かすインシデントのことを「ストーリー」と呼んでいます。1つのストーリーは基本的に異なるセキュリティ上の問題を示していますので、ストーリー単位で運用を行っていきます。 XDR 機能を用いたセキュリティ運用としては、次のように実施していくのが良いと考えています。 1. 新しいストーリーが作成されたことを認識する まずは、ストーリー・ダッシュボード画面やストーリー・ワークベンチ画面を定期的に確認し、新しくストーリーが作成されていないか確認しましょう。各画面は、CMA の [Monitoring] > [Stories Dashboard] や [Stories Workbench] から見れます。画面の詳細な見方については、先述の「 世界初SASEベースのXDRについて 」の記事を参照ください。 また、定期的に確認する運用では新しいストーリーに気付くのが遅れる可能性がありますので、後述のようにメール通知などによって気付けるようにすると良いです。 2. ストーリー一覧を確認する 新しいストーリーが作成されていれば、ストーリー・ワークベンチ画面で現在オープン中のストーリーの一覧を確認しましょう。 一覧画面で注目すべき項目は次の3か所です。 注目べき項目 内容 Criticality 重要度を表す 1 (低) ～ 10 (高) の値 Cato クラウド独自のアルゴリズムで算出される Indicator ストーリーの内容を簡潔に表す識別名 Producer ストーリーのタイプ 2024年4月時点では、Producer として次の5種類が定義されています。 (参考) Producer 内容 Threat Prevention IPS 機能で攻撃の振る舞いを検知した Threat Hunting イベント情報やより多くのトラフィックデータをもとに、広い範囲の攻撃の振る舞いが見つかった Usage Anomaly アプリケーションで通常とは異なる使用状況の兆候が見つかった (アップストリーム通信の帯域幅が通常と異なるなど) Events Anomaly 通常とは異なる量のセキュリティイベントを発生させているモノの兆候を検知した Network XDR ネットワークに関する劣化 (Socket ダウンやリンクダウン) が発生した Cato クラウドの Threat Prevention (旧 IPS) オプションを契約のお客様の環境では、「Threat Prevention」と「Network XDR」の2種類がストーリーとして検知されます。全ての種類を検知させるには、XDR Security Pro オプションの契約が必要となります。 また、「Network XDR」タイプは Socket の障害や拠点のインターネット回線の障害などによって発生しますが、障害が回復するとストーリーも自動でクローズされます。そのため、ストーリーに対して具体的に何らかの運用が必要になるというわけではありません。 以下では、「Threat Prevention」タイプに絞って、詳細の確認方法や対処方法について説明します。 3. ストーリーを分析する ストーリー・ワークベンチ画面でストーリーを選択すると、ストーリーの詳細を確認できます。ストーリーの詳細を確認する目的は、該当のストーリーがセキュリティ上問題があるものなのかどうか分析し、必要なら何かしら対処することにあります。 詳細画面には多くの情報が掲載されていますが、特に注目すべき項目は次の箇所です。 注目すべき項目 内容 Description (Details の中) Indicator (識別名) を詳しく表現した説明 Direction (Details の中) 関連する通信の向き (Inbound, Outbound, WANbound, All の4種類) Mitre Tags (Details の中) 該当する MITRE ATT&CK の種類 どのようなセキュリティ上の問題の可能性が検知されたか Target Actions 関連する通信が Cato クラウドのセキュリティ機能 (IPS, DNS Protection, Suspicious Activity など) でどう扱われたか Targets 関連する通信の相手に関する情報 Target (ホスト名・IPアドレス) や Registant Country (国名) が特に重要 Attack Related Events 関連する通信のイベント情報 Target (ホスト名・IPアドレス) や Destination Port (宛先ポート番号) が特に重要 これら情報をもとに、検知されたストーリーがセキュリティ上問題のあるものなのかどうか分析して判断しましょう。基本的には通信相手のホスト名や宛先ポート番号を見ればどういった通信か推測できることが多いと思います。単一の通信だけでなく、似た通信や異なる時間帯の通信も1つのストーリーに纏めて関連付けられていますので、分析しやすくなっています。それ以外にも、対象の通信の前後の時間帯で他にどのような通信が行われていたか、イベントログを確認すると分析の役に立ちます。 通信を行ったクライアントの情報も画面上で確認できますので、問題のあるものか判断しにくい場合はユーザにヒアリングしてみるのも良いですね。ただし、ユーザが認識していない通信 (例えば、アクセスした Web サイトに表示されている悪意ある広告など) の場合もあるという点に留意する必要があります。 実際は XDR 機能を利用する上でこの分析作業が最も難しく、機械的に行えるものでもないため、経験を積んで知見を蓄積していくしかない部分でもあります…。 4. ストーリーに対処する ストーリーを分析した結果、それがセキュリティ上問題があるものだった場合、そのような通信がブロックされるように Internet Firewall や WAN Firewall 機能に設定を追加しましょう。IPS などのセキュリティ機能でブロックされていたとしても、将来の通信がセキュリティ機能をすり抜ける可能性や Cato クラウド側のアルゴリズム変更でブロックされなくなる可能性がありますので、Firewall 機能でブロックするのが確実です。 その後、ストーリー詳細画面の右上にある三点アイコンの Story Actions メニューから、ストーリーのステータスをクローズ (Closed) に変更しましょう。 その際、「Analyst Verdict」という入力欄では、どのように分析したか次の4つから選択する必要があります。 Malicious (悪意ある) Suspicious (疑わしい) Informational (情報) Benign (無害) 選択した項目に応じてタイプや分類など詳細を任意で選択することもでき、入力しておけば将来的な分析にも役立てられるかと思います。 問題あるものか無害なものか判断できない場合は、ステータスを保留 (Pending Analysis または Pending More Info) に変更しておき、状況が変化したときにまた判断を行うというのでも良いです。 また、ストーリーがセキュリティ上問題のない無害なものだった場合、同様のストーリーが今後作成されないようにミュート (抑制) しましょう。この操作は Story Actions メニューにある「Add to new Muted Stories rule」というリンクから行えます。CMA の [Security] > [Detection & Response] > [Mute Stories] 画面からミュートを設定することもできますが、条件を手動で入力する必要があり、入力を間違えると問題あるストーリーまでミュートしてしまう可能性がありますので、ストーリーのステータスを変える際に合わせてミュートすることを推奨します。( 参考 ) その他：ストーリーの作成・更新通知を設定する CMA の [Security] > [Detection & Response] > [Reponse Policy] 画面から、ストーリーが作成・更新されたときにメール通知や Webhook 送信などを行うことができます。( 参考 ) CMA のストーリー・ダッシュボード画面やワークベンチ画面を定期的に確認する運用では新しいストーリーに気付くのが遅れてしまう可能性があるため、確実に気付けるよう通知設定を行うようにしましょう。ストーリーのタイプや重要度などの特定の条件に当てはまるものだけ通知することもできますが、まずは無条件で全て通知するようにしておき、通知量が多くなってきたら条件を付けて調整するのが良いと思います。 所感・課題点 本記事では XDR 機能を用いた基本的なセキュリティ運用の例を説明しましたが、実際に運用しようとすると超えるべきハードルや悩ましい点が多いというのが実情です。 まず、利用上の問題やセキュリティ上の実害が起きない限り、セキュリティ運用を実施する動機も沸かないのではないでしょうか。私自身としても、Cato クラウドが良きに働いてセキュリティ面で守ってくれるよう完全にお任せしてしまいたいと思っています。しかし、Cato クラウドで検知されたストーリーの内容を把握するようにすれば、企業システムの Cato クラウド以外の部分で発生した根本的な問題に気付けるというメリットもあります。例えば、PCがマルウェアに感染して不正な通信を行っているような場合、Cato クラウドの機能でそのことに気付くことができれば、素早く適切な対応を行えます。そのため、Cato クラウドに任せっきりにせずに、セキュリティ運用はしっかりと実施していかないといけません。 次に、やはり検知されたストーリーの内容の把握・分析・判断は難しく、なんとなく理解して推測できるものの確信を持てないことが多いです。ストーリーに該当する通信をブロックしてしまうとどこかで業務上の影響が発生してしまう可能性もあるため、セキュリティ上の問題の有無を判断するための基準や指針が必要となってきます。気軽に通信をブロックし、業務上の影響が発生したら元に戻せば良いという運用で良いのであれば気楽ではあるのですが、お客様の会社の規模によってはそういうわけにいかないこともあるかと思います。 そして、Cato クラウドがストーリーとして検知する際のアルゴリズムが非公開でよくわからないという点も悩ましいです。インターネット上で観測される様々な攻撃パターンや Cato の多数の顧客のトラフィック情報などをもとにアルゴリズムは日々改良されているものと推測されますが、どの程度の精度でストーリーが検知されているのかイマイチよくわかりません。また、故意に検知される方法もわからないため、運用テストも行えないのが困ります…。 とはいえ、いろいろ課題はあるものの XDR 機能は有益であることは間違いありませんので、より活用しやすくなる方法について今後も検討を続けていきます！

こんにちは。SCSKの山口です。 皆さん、誰しも一度は「過去に戻ってやり直したい」と思ったことがあるはずです。（唐突） 学校の花瓶を割ってしまったときや、大事なプレゼンで盛大に噛んでしまったとき、そして、 BigQuery テーブルの大事なデータを消してしまったとき。 大丈夫、 ３つ目は救えます 。 今回はそんなブログです。   BigQueryのタイムトラベル機能 BigQueryには、過去データへアクセスできる「タイムトラベル機能」という大変便利な機能が備わっています。 この機能を活用することで、以下のことが可能です。 特定の時点のデータをクエリで取得 特定の時点のテーブルを復元 ただし、タイムトラベル機能を使用できる期間は 7日間（デフォルト） となっています。 タイムトラベル期間の長さは 2~7日の範囲 で、 データセットレベル で設定することができます。 救えます。と堂々と前述しましたが、7日というタイムリミットはあります。人生そこまで甘くはありませんね。   過去のデータを一定期間保持しているとなると、気になるのが 課金 です。 デフォルトでは7日間のデータを保持していますが、必要に応じてタイムトラベル期間を短くすることで、物理ストレージの課金モデルを採用している場合に限り、「ストレージ費用」を節約できます。 論理ストレージの課金モデルを使用する場合は例外となるので、ご注意ください。（詳細は参考資料をご参照ください。） 過去のデータへのアクセス： https://cloud.google.com/bigquery/docs/time-travel?hl=ja タイムトラベルとフェイルセーフによるデータの保持： https://cloud.google.com/bigquery/docs/access-historical-data?hl=ja ストレージの課金モデル： https://cloud.google.com/bigquery/docs/datasets-intro?hl=ja#dataset_storage_billing_models ストレージの課金モデル更新： https://cloud.google.com/bigquery/docs/updating-datasets?hl=ja#update_storage_billing_models   実践①：特定の時点のデータをクエリで取得 ここから実践です。 まずは特定の時点のデータをクエリで取得してみます。 準備：テーブル 下記テーブルをテスト用として準備します 「INSERT_TIME」カラムには、データを入れた日時を入れています。 クエリ実行 では、準備したテーブルの【—- Check Point —-】の時点のデータを取ってみましょう。 過去のデータへのアクセス  |  BigQuery  |  Google Cloud に記載のあるSQLを参考に、日時を指定してデータを取得します。 実行SQL 実行結果 SELECT   * FROM   `evocative-entry-277709.yamaguchi_test.TIMETRAVEL_TEST`   FOR SYSTEM_TIME AS OF "2024-04-17 15:41:00+09:00" ※実行SQLでは、【—- Check Point —-】も含めるために敢えて15:41を指定しています。 結果として、【—- Check Point —-】より後のデータが入っていない状態に戻りました。大成功です。 （トリミングでギリギリを攻め過ぎましたが、ほんとに戻りました。）   実践②：特定の時点のデータをクエリで復元 今度は、一度削除してしまったデータを復元してみます。 準備：データを一部削除 実践①で使用したデータの【—- Check Point —-】以前に投入されたデータを一度削除します。 削除前 削除後 データの順序が前後していてかなりわかりづらいですが、【—- Check Point —-】以前に挿入されたCLM1が日本語のデータが消えている状態です。 この状態から、削除されたデータを復元します。 クエリ実行 実行SQL 実行結果 INSERT INTO   `evocative-entry-277709.yamaguchi_test.TIMETRAVEL_TEST` SELECT   * FROM   `evocative-entry-277709.yamaguchi_test.TIMETRAVEL_TEST`   FOR SYSTEM_TIME AS OF "2024-04-17 15:39:00+09:00" エラー： Table ‘evocative-entry-277709.yamaguchi_test.TIMETRAVEL_TEST’ is referenced with multiple snapshot read timestamps. For example, if ‘FOR SYSTEM_TIME AS OF’ expressions are used on the table, they should use the same TIMESTAMP value. Using the table as DML destination table references the table at query start time. エラーを吐かれました。 どうやら、復元先と復元元に同じテーブルを指定することはできないようです。 一度別名のテーブルにデータを復元し、その後元のテーブルに挿入する 方法をやってみます。   実行SQL① 実行結果 INSERT INTO   `evocative-entry-277709.yamaguchi_test. tmp_TIMETRAVEL_TEST ` SELECT   * FROM   `evocative-entry-277709.yamaguchi_test.TIMETRAVEL_TEST`   FOR SYSTEM_TIME AS OF "2024-04-17 15:39:00+09:00" ※一時テーブルを別途作成する必要があります   実行SQL②   INSERT INTO   `evocative-entry-277709.yamaguchi_test.TIMETRAVEL_TEST` SELECT   * FROM   `evocative-entry-277709.yamaguchi_test. tmp_TIMETRAVEL_TEST ` データの順序が逆転していますが、一度削除されたデータを復元し、テーブルを初期状態に戻すことができました。大成功です。 あとは元テーブル（TIMETRAVEL_TEST）を削除して、ALTER文でリネームとかしてあげると完全に元の状態に戻りますね。 （テーブルの名前を変更する： https://cloud.google.com/bigquery/docs/managing-tables?hl=ja#renaming-table ）   実践③：削除されたテーブルを復元 今度は、一度削除されてしまったテーブルを復元します。 実践①,②で使用したテーブルを削除します。 過去のデータへのアクセス  |  BigQuery  |  Google Cloud に記載のある方法で復元してみます。 コマンド bq cp [データセット名].[テーブル名1]@ XXXXXXX [データセット名].[テーブル名2] 「 XXXXXXX 」部分には、「 相対オフセット 」もしくは「 Unixエポック時刻 」を指定します。 相対オフセット：現在の時刻からの相対時間（ミリ秒単位） Unixエポック時刻：Unix エポック時刻からの経過時間（ミリ秒単位） Unixエポック秒は下記で取得可能です。 実行SQL 実行結果 SELECT   UNIX_MILLIS(TIMESTAMP(‘2024-04-17 18:00:00’,”Asia/Tokyo”))   下記コマンドを実行し、テーブルを別名の一時テーブルへ復元します。 実行コマンド 実行結果  bq cp yamaguchi_test.TIMETRAVEL_TEST@ -3600000   yamaguchi_test.tmp_TIMETRAVEL_TEST ※3600000 ms前（＝1時間前）を指定 bq cp yamaguchi_test.TIMETRAVEL_TEST@ 1713344400000  yamaguchi_test.tmp_TIMETRAVEL_TEST どちらのコマンドでも削除されたテーブルを復元できました。大成功です。   まとめ 今回はBigQuery のタイムトラベル機能を使って、特定時間のデータの取得、削除されたデータやテーブルの復元をやってみました。 私は、今回実践したSQLをプロジェクトクエリに保存しており、いつでも使えるようにしています。 大変便利な機能ですので、皆さんも是非ご活用ください。

こんにちは。SCSKの山口です。 今回は、BigQueryのドライランを実際にやってみたブログです。 業務で非常にお世話になり、便利すぎて感動したのでブログ化しちゃいました。皆さんも是非ご活用ください。   BigQueryドライラン概要 ドライランとは、クエリの検証、料金/データ見積もりを ”クエリを実際に実行することなく” 把握する事ができるモードです。 クエリを実際に実行しない（クエリスロットを使用しない）ため、課金なしで実行できるという何ともありがたい機能になっています。 公式のドキュメントには以下の通り記載されています。 BigQueryのドライランモードでは、次の情報が提供されます。 ・オンデマンドモードでの料金見積もり ・クエリの検証 ・キャパシティモードでのクエリのおおよそのサイズと複雑さ ドライランはクエリスロットを使用しないため、ドライランの実行に対しては課金されません。 ドライランによって返された見積もりを料金計算ツールで使用すると、クエリの費用を計算できます。 引用元： https://cloud.google.com/bigquery/docs/running-queries?hl=ja#perform_dry_runs   今回の活用方法 以前投稿した BigQuery Migration Service を使用することで大量のSQLをGoogleSQLの構文に変換しました。 しかし、SQL変換を用いたとしても、必ずしも完璧な（そのまま使用できる）SQLが生成されるわけではありません。 そんなこんなでSQLの修正作業が必要になったのですが、どのSQLが修正対象なのか一つひとつ開いて確認するのがまあメンドクサイ、、、 そんな時に、「ドライランを活用すれば修正が必要なSQLとそうでないものを簡単に分けることができる。」と思いつき実践したところ大変簡単で便利だったので紹介します。   実践：ドライランを使ってエラーを吐くSQLを特定する 準備：テーブル 以下のテーブルを準備します データも入れておきます 準備：SQLファイル 今回は以下の5つの簡単なSQLファイルを用意します。（奇数番目が成功、偶数番目が失敗するSQL例です。） -- testSQL1.sql SELECT * FROM `evocative-entry-277709.yamaguchi_test.dryrun_test` ; -- testSQL2.sql せれくとあすたぁふろむ`evocative-entry-277709.yamaguchi_test.dryrun_test` -- testSQL3.sql INSERT `evocative-entry-277709.yamaguchi_test.dryrun_test` (clm1, clm2, clm3) VALUES ('test', 'test', 'test') ; -- testSQL4.sql いんさあといんとぅ`evocative-entry-277709.yamaguchi_test.dryrun_test` 「あすたぁ」と「いんとぅ」が気になりますね。   準備：Pythonスクリプト 今回はPythonコード内でbqコマンドを叩くという形にします。 「–dry_run」オプションをつけることでドライランを実行することができます。 dryrun.py ''' dryrun.py'''   import   os from   subprocess  import   Popen, PIPE   # プロジェクトID project_id  =   "evocative-entry-277709"   # ドライラン結果テキストファイル result_path  =   "/home/sho_yamaguchi/Blog/DryRun/result.txt"   # SQLファイルのディレクトリ SQLs_path  =   "/home/sho_yamaguchi/Blog/DryRun/SQLs"   # SQLファイルのリストを取得 sql_files  =   [f  for   f  in   os.listdir(SQLs_path)  if   f.endswith( ".sql" )]   # 結果ファイルを開く with  open (result_path,  "w" ) as result_file:      for   sql_file  in   sql_files:          # SQLファイルのパス          sqlfile_path  =   os.path.join(SQLs_path, sql_file)            # SQLファイルの内容を取り込む →query_job          with  open   (sqlfile_path,  "r" ) as f:              query_job  =   f.read()                                # ドライランコマンド          dryrun_command  =   [ "bq" ,  "query" ,  "--use_legacy_sql=false" ,  "--dry_run" ,  "--project_id" , project_id, query_job]            # ドライラン実行          process  =   Popen(dryrun_command, stdout = PIPE, stderr = PIPE)          stdout, stderr  =   process.communicate()            # 結果をファイルに書き出す          result_file.write(f "--- {sql_file} ---\n" )          result_file.write(stdout.decode( "utf-8" ))          if   stderr:              result_file.write(f "エラー：{stderr.decode('utf-8')}" ) 準備は以上です。後はPythonスクリプトを実行するのみです。   実行結果 実行結果のテキストファイルは以下の通りです。 --- testSQL4.sql --- Error in query string: Syntax error: Illegal input character "\343" at [1:1] --- testSQL2.sql --- Error in query string: Syntax error: Illegal input character "\343" at [1:1] --- testSQL5.sql --- Query successfully validated. Assuming the tables are not modified, running this query will process 0 bytes of data. --- testSQL3.sql --- Query successfully validated. Assuming the tables are not modified, running this query will process 0 bytes of data. --- testSQL1.sql --- Query successfully validated. Assuming the tables are not modified, running this query will process 15 bytes of data. いい感じ！！ 「Error in query string: 」が吐かれている「testSQL2.sql」と「testSQL4.sql」が今回の修正対象だと一目でわかりますね。 クエリがエラーを吐かない場合、それぞれのクエリ実行に消費するバイト数も出力してくれています。 大規模なデータを扱う際や、大量のSQLを使用する際に、 「課金額を把握する術」 としても有効活用できます。   クエリ対象のテーブルの方はというと 狙い通り、何も起こっていません。 今回のテストSQLが実際に実行されると、テストデータがINSERTされ、最終的にDROPされてしまうはずですが無傷です。 実際のテーブルに影響を与えることなく クエリが成功するか失敗するかを判断してくれています。   まとめ 今回はBigQuery のドライラン機能をbqコマンドで実行してエラーが吐かれるSQLを特定してみました。 Pythonスクリプトに条件分岐を増やして、shutilで自動的にエラーSQLを他ディレクトリに移動させたりするとより便利ですね。 メンドクサイと思ったそこのあなた、 Geminiさんに書いてもらいましょう！

こんにちは。ひるたんぬです。 今回は小ネタですが、プライベートでAWS環境に触っていてハマったこと、その解決方法についてご紹介いたします。 ハマったこと ずっと眠っていた 学生時代のノートPCから、AWS環境に触ってみよう～と思ったことが発端です。 最近勉強中のCodeCatalyst環境に入ろうとAWS Builder IDでサインインしようとしたところ… …あれ？サインインができませんでした。 自分の中で考えうる問題点を以下のように洗い出し、確認していきました。 パスワードが違う → そんなことはなかった（別PC・iPadでサインインできた） AWSの障害 → そんなことはなかった（別PC・iPadでサインインできた） おかしいなぁ…と思い、今度はマネジメントコンソールはどうなっているか気になったので、同じようにサインインしてみました。 すると、サインインはできたものの、マネジメントコンソールの表示に何か違和感を感じたのです。 「アプリケーション」のデータが取得できていないのです。 もちろん他の端末では問題なく表示できていたため、権限が不足している、などではありませんでした。 原因調査 根本的な原因が分からなかったので、他のリソースのページなどの挙動からヒントが得られないか、様々なページを見てみることにしました。 すると、Lambdaの関数一覧を表示するページに気になる文言がありました。 Signature not yet current : 20240421T160656Z is still later than 20240421T160552Z (20240421T160052Z + 5 min.) …どうやら時刻がずれているため認証などがうまく行っていないのではないか ということに気づくことができました。PCの時刻を確認したところ、 約6分進んでいました。「ずっと眠っていた」ということがここにきて響いていたのですね。 解決 PCの設定より時刻の再同期を実行し、正しい時刻に戻しました。 これによりAWS Builder IDでのサインインやAWSマネジメントコンソールが正常に表示することができました。 おわりに 今回は短いですが、困ったこと・思ったより解決に時間にかかったため記事にまとめました。 同じような症状にお悩みの方にこの記事が届くことを願っております… CodeCatalystの勉強成果については、近日中に記事にまとめたいと思います。 こちらもトラブル中なので…

実際にCatoクラウドを利用されているお客様から、Webサイトへのアクセスが失敗するといったお問い合わせをいただくことがあります。 今回は、実際に問題に直面された方の事象例やその対処法をご紹介したいと思います。 Webサイトへのアクセスが失敗するとはどういう状況か 実際にお問い合わせをいただいたWebサイトへアクセスができない事象について、下記のようなケースがありました。 ・WebサイトへアクセスをするとCatoの Block ページが表示されて先に進まない ・証明書エラーとなりページが表示されない ・「403 Forbidden」や「このサイトにアクセスできません」が表示されてしまう ・ページが正しく表示されない(テキスト表示になってしまう) 上記の状況でどのように原因を発見し解決してきたのかをご紹介します。 記事内に出てきます設定値はあくまでも例になります。 設定を行う際は、ご利用の環境に合わせて設定ください。 WebサイトへアクセスをするとCatoの Block ページが表示されて先に進まない Cato接続時に本来なら閲覧できるはずのWebサイトがなぜかBlockされるというお問合せをいただくことがあります。 その原因の大半はInternet Firewall (FW) により脅威のないサイトが意図せずBlockされていたというものが多いと感じました。 CatoクラウドのInternet FW は、企業のネットワークを保護するために不可欠ですが、時には意図しない形で正当な通信をブロックしてしまうことがあります。 今回は実際にあった２パターンのトラブル例と対処法について記載します。 Internet Firewallの詳細につきましては下記ブログをご参照ください！ CatoクラウドのFirewall機能について CatoクラウドのFirewall機能について解説いたします。 blog.usize-tech.com 2023.09.28 パターン1 Firewallの上位のルールでBlockされていた CatoクラウドのInternet Firewall (FW) は、ルールに基づいて通信を制御しますが、必要な通信が上位のルールで誤ってBlockされてしまっていたケースがあります。 問題の発見方法 CatoのBlockページやCMAのEventsをチェックして、どの機能のルールで通信をBlockしているのかを特定しましょう。 BlockページやEventsでの確認方法 まず以下画像のCatoのBlockページにて「Block Reason」を見てみましょう。 「Corporate Internet Policy Violation」と記載されており、インターネットポリシー(Internet FW)によってBlockされていることがわかります。 次にEventsを確認してみましょう。 [Monitornig]>[Events] 上記の場合は、フィルター機能で「Action」をBlock、「Domain Name」をアクセスしたサイトのドメインとして該当の通信を探しました。Blockされた通信ログを発見できたら「Sub-Type」と「Rule」を確認して、実際にどの機能のどのルールによりBlockされたのか確認してみましょう。 ・Eventsから通信を確認する際は、誰がいつどこにアクセスをしたのかを記録し、フィルターでログを絞ることで、該当する通信ログが発見しやすくなります。 ・「Sub-Type」を見ると、IPSやInternet FW等、Catoのどの機能で Block されているかがわかります！ トラブルシューティングを行うためにフィルター機能を活用していきましょう！ 対処方法 原因であるInternet FWルールを特定できたので、あとは上位に対象通信を許可するルールの追加や例外設定を追加することで事象は解消できます。 Blockルールに例外設定を追加する方法 Blockルールに例外設定を追加する場合はルール横の[…]をクリックし、「Add Exeption」をクリックください。 すると以下画像の設定画面が出てきますので、要件に合わせて例外設定を行ってください。 [Security]> [Internet Firewall] パターン2 異なるカテゴリに分類にされBlockされていた CatoのSWG（Secure Web Gateway）機能により、Webサイトの内容と異なるカテゴリに分類され、本来許可されるべきアクセスがInternet FWにより Block されてしまうことがあります。 問題の発見方法 パターン1と同じ手順で、EventsからInternet FWのどのルールによりBlockされたのかを確認してみましょう。 多い例として誤ってカテゴリが「Games」等に分類されてしまい、デフォルトの Block ポリシーに引っかかってしまうというものがあります。 対処方法 こちらもパターン1のように許可ルールや例外設定で回避することができますが、もっと簡単な方法は、カテゴリを手動で修正してしまうことです。 CMAの[Assets]>[App Catalog]の[Domain Lookup]タブからカテゴリの修正が可能です。 [Domain Lookup]からカテゴリ修正を行う方法の詳細については以下のブログ記事を参照ください！ Catoで業務通信がブロックされてしまう事象の解決策！～SWGで誤分類されたサイトを管理者で修正する機能～ Catoを使っていると、業務でアクセスするドメイン（URL）が誤ったカテゴリに分類され、通信できない！ということがあります。今回は、そんな問題が発生した場合の新しい回避策「カテゴリの手動修正」を紹介します。 blog.usize-tech.com 2024.02.22 証明書エラーとなりページが表示されない Catoクラウドでは、TLSインスペクション機能を通じてHTTPS通信のセキュリティを強化していますが、証明書の書き換えが許可されていないWebサイトへアクセスしてしまうと証明書エラーが発生してしまいページが表示されないケースがあります。 問題の発見方法 ブラウザ側でのエラーとなるため、Eventsを見てもBlockのログは表示されません。そのためブラウザ側で「この接続ではプライバシーが保護されません」、「このWebサイトのセキュリティ証明書には問題があります」といった画面が表示されたら、考えられる原因の一つとしてTLSインスペクション機能があることを頭に入れておきましょう。 対処方法 TLSインスペクションが原因で問題が起きている場合、Webサイトに対してTLSインスペクションを動作させないよう除外リストに追加することで回避ができます。 まず「Security」> 「TLS Inspection」から「New」をクリックしBypassルールを作成しましょう。 新しく作成するTLS Inspectionの名前を記載し、「What」の項目にてIP Range、Domain、FQDN等を設定します。 「Action」の項目では「Bypass」を選択します。 ※その他の設定は環境に合わせて設定ください。 以上が、TLSインスペクションの除外設定となります。 TLSインスペクション機能の詳細につきましては下記ブログ記事をご覧ください！ CatoクラウドのTLS Inspection機能で躓く証明書の仕組み Cato クラウドでHTTPS通信のセキュリティ対策を行うためのTLS Inspection機能で躓くことの多いTLS証明書関連の仕組みや課題について解説します。 blog.usize-tech.com 2023.10.06 「403 Forbidden」や「このサイトにアクセスできません」が表示されてしまう EventsではBlockのログは出ていないのに、「403 Forbidden」や「このサイトにアクセスできません」が表示されて正常にページが表示されない事例がございます。 原因の一つとして、Webサーバや、Firewall（UTM）において、JPNICのIPアドレスのみを許可しているといったように、日本からのアクセスのみに制限をしているため、Cato経由でのアクセスがブロックされるケースがございます。 なぜかというと、 Cato PoPのIPアドレスはJPNICでなく、上位のAPNICからIPアドレスを取得しているからです。 そのため、Webサーバ、Firewall（UTM）にて「日本のアクセスのみに制限する」や、JPNIC DBのみの制限を行われている場合は、APNICアドレスとなるCatoからのアクセスができません。 対処方法 2024/4/8時点での対処方法としましては、３つございます。 1.IPアロケーションで取得したグローバルIPアドレス(Egress IP)経由で、対象のWebサイトへアクセスするよう Network Rulesに設定し、サイト管理者へIPアドレスのアクセス許可依頼を行う。 Catoを利用したままサイトへのアクセスを行いたい場合は、Catoで確保したEgress IPをWebサイト側で許可してもらうことで閲覧が可能になります。 Egress IPとは何かご不明な方は、以下のブログ記事をご参照ください！ CatoクラウドにおけるEgress IP（送信元IP、出口IP）について CatoクラウドにおけるEgress IPについて解説します。 blog.usize-tech.com 2023.08.22 対応手順 まずCMAの[Network]>[IP Allocation]からEgress IPアドレスを取得しましょう。 ※標準で３つまで取得可能で、4つ目以降は有償となります。 次に、取得したEgress IPアドレス経由で、対象のWebサイトへアクセスを行うように[Network]> [Network Rules]から[New]をクリックして新しいNATルールの作成を行いましょう。 環境に合わせて設定いただき、App/Categoryには対象サイトのDomainもしくはFQDNを設定ください。 Routing MethodのRoute/NATで”NAT”を選択し、上記で取得したIPアドレスを設定しましょう。 NAT設定を行う際に「Preserve source port」という項目があります。 この設定はNAT変換時にIPヘッダ内のSource Portを保持する機能です。 一般的なWEBブラウジングなどの場合、ポート番号が変換されても影響ございませんので、チェックは不要です。 NATの設定が完了したら最後にWebサイトの管理者へ、設定したEgress IPを許可いただくよう依頼を行いましょう。 2.対象のWebサイトへのアクセスをCato経由で行わない そもそもCato経由でアクセスを行わないといった方法もございます。 Socket配下(拠点)接続の場合はBypass機能、SDPユーザ(モバイルユーザ)からの接続の場合はSplit Tunnel機能を利用することで、Catoを経由させず直接アクセスさせることができます。設定方法は以下をご参照ください。 ・Catoを経由させない設定のため、Catoによるセキュリティ検査、管理は行われません。 ・Bypass、Split Tunnel機能は、FQDNやドメイン設定は行えず、IPアドレスのみでの設定になります。 (2024/4/8時点) Socket配下(拠点)のBypass設定 [Network]>[Sites]からBypass設定を行いたい拠点を選択し、[Site Configuration]>[Bypass]をクリックします。 Destination(宛先)への通信もしくは、Source(送信元)からの通信をBypassするか選択ができますので、環境に合わせて設定ください。 設定の際は[New]をクリックください。 上記画像の設定項目から宛先もしくは送信元のIPアドレスを設定しましょう。 オプションとしてトラフィックプロトコルやトラフィックをインターネットに直接出力するポートを選択することもできます。 [Apply]、[Save]をクリックし保存を行うと設定が完了します。 SDPユーザのSplit Tunnel設定 まず、[Network] > [IP Ranges]から、[New]をクリックし除外したいIPアドレスを設定します。 [Apply]、[Save]をクリックして保存したら、次に[Access] > [Split Tunnel Policy]から[IP Ranges]で設定したIPを割り当てましょう。 [New]をクリックし、[Split Tunnel]セクションで[Exclude specific IPs]をクリックします。 ※[Exclude specific IPs]は、インターネットに直接ルーティングを行うという設定になります。 すると[Split Tunnel IPs]が出現しますので、上記で設定したIP Rangeを選択します。 ルールの対象となる[User/Groups]や[Platform]等のその他の設定については、ご利用の環境に合わせて設定ください。 最後に[Apply]、[Save]をクリックして設定が完了します。 3. Socket設置拠点に別のインターネット回線がある場合は拠点のインターネットからアクセスを行う こちらは利用例が少ないですが、Socket設置拠点に別のインターネット出口がある場合、Backhauling および Network Rules 設定をすることで、Cato PoPからではなく、拠点のインターネットからWebサイトへアクセスを行うことができます。 ・Network Rulesにて制御を行うため、FQDNやドメインでの設定も可能です。 ・BypassやSplit Tunnelとは異なり、Backhaulingを設定した特定拠点までの通信はCato PoPを通ります。 Backhauling設定の詳細につきましては以下のKnowledge Baseをご参照ください。 Just a moment... support.catonetworks.com ページが正しく表示されない(テキスト表示になってしまう) Cato経由でWebサイトへアクセスすると、画像など必要な部分が正しく表示されずサイトが崩れてしまっているように見える（テキストのみ表示されるように見える）ケースがございました。 一例といたしましては、Internet FWにてPrompt設定を行ったWebサイトで発生しました。 原因 事象が発生したWebページのレンダリングの一部が、Internet FWのPrompt設定によりブロックされてしまっていたためでした。 Internet FWのPrompt設定とは一致するトラフィックをメッセージ付きのWebページにリダイレクトし、ユーザーに対して続行するかどうかを決定するようにさせる設定です。 対処方法 ページ内でブロックされているドメインを確認し、Internet FWルールの例外に設定することで回避が可能です。 本項では、一例としまして、Internet Firewallにてアプリケーション”Fire Storage”をPrompt設定した際の対処方法を記載します。 まず、ブロックされているドメインの確認（Chromeの場合）を行いましょう。 該当のWebサイトへアクセスし、「Prompt」されたページへ遷移します。 次にブラウザから[設定]＞[その他のツール]＞[デベロッパーツール]＞[Console]タブをクリックし開き「Prompt」ページから「進行する」をクリックし、実際のWebページへ遷移します。 [Console]タブに表示されたURLを確認し、ブロックされているドメインの中から、 Webページに関連しているドメインを記録します。 ※例として、Firestorageのサイトの場合は、「firestorage」が入っているドメインを記録します。 ※なお、ドメインはFilterで絞ることも可能です。 ※Edgeの場合は、[設定]＞[その他のツール]＞[開発者ツール]からご確認いただけます。 Blockされているドメインが判明したので、Internet FWルールで例外設定を行いましょう。 まず、Internet FWルールより、[Prompt]設定をしているルールから[…]＞Add Exceptionをクリック。 作成された[Exceptions]のApp/Categoryに、上記で記録したドメインを入力します。 ※その他の設定は環境に合わせて設定ください [Apply]、[Save]で設定が完了です。 設定完了後、Webサイトへアクセスすると、表示崩れは改善されていました。 まとめ 本投稿では、Cato経由でのWebサイト接続のトラブル例とその対処法について説明いたしました。 トラブルでお困りの方のお役に立てれば幸いです。 なお、弊社の FAQ サイトでは 、よくあるご質問やCato クラウドのアップデート情報を公開しておりますので、是非ご参照ください！

こんにちは。SCSKの山口です。 今回は、案件業務で活用した「BigQuery 上に大量テーブルを一括作成する便利な方法」をブログ化します。 私はこの方法で約900のテーブルをBigQuery 上に一括作成しました。   BigQuery テーブル作成方法 BigQuery 上にテーブルを作成する際は、コンソール上で作成する方法とデータ定義言語（DDL）ステートメントを使用する方法があります。 https://cloud.google.com/bigquery/docs/tables?hl=ja#create-table コンソール上で作成する方法は、直感的にテーブルを作成することができ大変便利です。 しかし、大量のテーブルを作成したい際は天文学的な時間を要してしまい、もうBigQuery のコンソールミタクナイ、、、とグロッキーになってしまう可能性があります。 皆さんにBigQuery LOVEのままでいてもらうために、今回はDDLを連続的に実行してBigQuery 上にテーブルを一括作成する方法をご紹介します。   実践：DDLを連続的に実行しBigQuery テーブルを一括作成する DDLファイル ・今回はお試しとして、以下の5つのDDLを準備します testDDL1.ddl — testDDL1.ddl   CREATE TABLE evocative-entry-277709.yamaguchi_test_execDDL.create_table_test1 (   `clm1` STRING,   `clm2` STRING,   `clm` STRING ) ; testDDL2.ddl — testDDL2.ddl   CREATE TABLE evocative-entry-277709.yamaguchi_test_execDDL.create_table_test2 (   `clm1` STRING,   `clm2` STRING,   `clm` STRING ) ; testDDL3.ddl — testDDL3.ddl   CREATE TABLE evocative-entry-277709.yamaguchi_test_execDDL.create_table_test3 (   `clm1` STRING,   `clm2` STRING,   `clm` STRING ) ; testDDL4.ddl — testDDL4.ddl CREATE TABLE evocative-entry-277709.yamaguchi_test_execDDL.create_table_test4 ( `clm1` STRING, `clm2` STRING, `clm` STRING ) ; testDDL5.ddl — testDDL5.ddl CREATE TABLE evocative-entry-277709.yamaguchi_test_execDDL.create_table_test5 ( `clm1` STRING, `clm2` STRING, `clm` STRING ) ;   Pythonスクリプト 今回はBigQuery 用のPython用のクライアントライブラリを使用して、PythonスクリプトからDDLファイルを実行します。 以下が今回作成したPythonスクリプトです。 execDDL.py ”’ execDDL.py”’   import os from google.cloud import bigquery   # DDLファイルのパス ddls_path = ‘/home/sho_yamaguchi/Blog/execDDLs/DDLs’   # SQLファイルのリストを取得 ddl_files = [f for f in os.listdir(ddls_path) if f.endswith(“.ddl”)]   for ddl_file in ddl_files:     # DDLファイルのパス     ddlfile_path = os.path.join(ddls_path, ddl_file)       # DDLファイルの内容を取り込む →query     with open (ddlfile_path, encoding=’utf-8′)as f:         query = f.read()       # BigQuery クライアント作成     client = bigquery.Client()       # クエリ実行     query_job = client.query(query) 今回のPythonスクリプトは「ファイルを開く→内容をクエリとして取り込む→クエリ実行」という作りにしています。   後はPythonスクリプトを実行するだけです。 実行結果 Pythonスクリプト実行後の対象データセット内は以下の通りです。 狙い通り5つのテーブルが作成されていますね。 ジョブ履歴からもDDLが実行されていることが確認できました。 まとめ 今回はDDLを連続的に実行してBigQuery 上にテーブルを一括作成する方法を実際にやってみました。 DDLファイルの量が多くなるとその分時間ががりますが、一度スクリプトを流してしまえば放置でOKなのでとても楽です。 今回のPythonスクリプトの作りとしては、「ファイルを開く→内容をクエリとして取り込む→クエリ実行」という単純な作りなので、 アイデア次第でテーブル作成以外の他のことにも使えそうですね。 最後まで読んでいただきありがとうございました。

オフィス拠点にCato Socketを設置してCatoクラウドに接続する際に契約帯域を決める必要がありますが、いったい何Mbpsで接続すればよいか悩まれる場合もあるかと思います。今回は帯域選定についての話です。 はじめに Cato接続で帯域を意識するのは図1でいうとA・B・Cの3か所ですが、今回取り上げるのは 「図1- A」 の拠点接続の部分です。 「図1-B」 は社内サーバがあるデータセンターなどの接続部分です。ここの帯域決めはお客様によってかなり差があるので、既存回線のトラフィック量をベースにサイジングしないと難しいです。同じくらいの拠点数やユーザー数のお客様でも100Mbpsで足りてるケースもあれば500Mbpsでフルフルのケースもあります。 「図1-C」 はインターネットへの出口となる箇所です。オンプレ環境の場合はFirewallのスループットやセッション数を気にする必要がありますが、Catoでは利用者側で管理する必要はありません。 図1. Catoで考慮が必要な帯域 お客様との会話の中で 「図1-A」 の帯域選定の話になった時、我々からお伝えしているのは以下の通りです。 既存回線のトラフィック利用状況の情報をベースにする。 帯域の増速は随時できるが減速は契約更新月にしかできないので、スモールスタートが原則。 SCSKでは、 帯域の拡張(増速)を行う場合15時までにご注文いただれば当日中に拡張を行うことが可能です！ 拠点の通信量はある程度ユーザー数に依存しますので、拠点の帯域とユーザー数の関連性を調べてみてみました。 尚、実際の通信量はユーザー数だけではなく業務内容やアプリケーションの種類も関わってきます。一概にユーザー数だけという訳ではないので、あくまで参考情報として捉えて下さい。   拠点の帯域サイジングはざっくり「1ユーザー＝1Mbps」 まず、当社でご契約いただいている利用帯域の割合を調べたところ、図2の通りCatoのミニマム帯域である25Mbpsが6～7割を占めていました。ユーザー数がさほど多くない支店や営業所には25Mbpsを割り当てて利用しているという状況が推測されます。 図2. 契約帯域の割合 では、25Mbpsの利用拠点はどのくらいのユーザー数なのでしょうか？ 図3は、Cato Management Application（CMA）で確認した25Mbps拠点の接続Host数の割合です。 尚、Host数はサーバー等も含めた数なのでユーザー数とイコールではありません。ここからはCMAで表示される「Host」を単位として記載しますが、ただ25Mbps拠点にサーバがあるのは稀かと思いますので、ほぼユーザー数とみてもよいでしょう。 図3. 25Mbps拠点の接続Host数 25Mbps拠点は、20Host以下の拠点が半分を超え30Host以下の拠点が約75%という状況でした。 これらの拠点の平日日中の通信量をCMAのMonitoringでみると、20～30Hostの拠点では一日のうち25Mbpsに達する時間帯もありますが、いわゆるトラフィックの張り付き状態ではありませんでした。10Host以下の拠点だとピークでも25Mbpsに達しないという状況でした。 対して40Hostくらいの拠点になると日中時間中ずっと25Mbps上限に迫るくらいの通信量で、80Host超の拠点はトラフィックの張り付き状態が継続しているといった感じでした。 同様に50Mbps接続拠点のHost数もみてみましょう。 図4. 50Mbps拠点の接続Host数   結果は50Hostの拠点が50%弱、75Hostの拠点が75%という状況でした。 平日日中の通信量をみると、50Hostくらいまでならまだ余裕があり60～70Hostになると通信量が多いなと思える状態でした。 これらの結果から、拠点の帯域選定を行う際は「1Host（ユーザー）＝1Mbps」を一つの目安にする事ができるのはと考えています。 但し、もっと高帯域の100Mbps以上の拠点をみると、拠点によって通信量がまちまちで参考にならないものでした。 因みに、100Mbps拠点は10Hostから800Host以上の拠点があり、平均すると180Hostでした。 800Hostを超える拠点も複数あるのですが、必ずしもトラフィックが張り付いているという訳ではないところが不思議です。 2024年のCatoクラウドサービス改定に伴い、従来のサービスメニューにあった75Mbpsや200Mbpsは存在しませんのでご注意下さい。2024年4月現在のサービスメニューでは、25Mbps・50Mbps・100Mbps・250Mbps・500Mbps・・となります。   数が多い小規模拠点にはPooledライセンスがマッチ 話は変わって、少人数多拠点のネットワークなどで10Host未満の拠点が多数ある場合は、Pooledライセンスがマッチするかもしれません。 1拠点10Host未満の拠点や常時PCを使用しないようなトラフィックが少ない拠点であれば25Mbpsでもオーバースペックと言えます。その場合は、通常のSiteライセンスではなくPooledライセンスをご契約いただければ、最低10Mbps単位で各拠点に帯域を割り当てる事ができるので25Mbpsのライセンスを拠点分ご契約いただくよりコストメリットが出る場合があります。 尚、Pooledライセンスは1Gbps以上での契約となります。以下は1Gbpsを各拠点に割り当てる場合の例です。 例1 データセンター：100Mbps 拠点：10Mbps×90拠点 例2 データセンター：100Mbps 拠点：10Mbps×70拠点、20Mbps×10拠点 例3 データセンター：100Mbps 拠点：10Mbps×70拠点 残りの200Mbpsを在庫として確保しておき、通信量が増えた拠点に帯域を追加したり、期間限定の拠点用に割り当て、閉鎖になったらまた在庫として保持する事ができます。 Pooldライセンスを含むCatoクラウドのサービス料金については以下の記事を参照下さい。 Catoクラウドのサービス体系について（2024年最新版） 2024年2月以降のCatoクラウドの新しいサービス体系（基本料金、オプション料金、マネージドサービス）について解説を行っています。 blog.usize-tech.com 2024.01.29   少規模拠点はSDPユーザー接続で済ますことも また、ユーザー数が少ない拠点はSocketを設置せずSDPユーザーだけでCatoに接続する事も可能です。但しSocketを使用しない事による制限や運用管理面でのデメリットが生じます。 詳しくは以下の記事を参照下さい。 Cato Socketを拠点に設置せず、SDPユーザのみで利用する場合の留意点 ユーザしかいない拠点を前提に、Socketを設置しないデメリットを解説します。 blog.usize-tech.com 2023.08.29   最後に 帯域選定の話から脱線してしまいましたが、PooledライセンスやSDPユーザーの事例をご紹介させていただきました。 帯域をどうするか？接続方式をどうするか？については、最終的にはコストと機能面/管理面のトレードオフの話になるかと思います。 SCSKでは、お客様のネットワーク特性・利用状況を考慮して最適な帯域選定をご支援させていただきます。

こんにちは。SCSKの江木です。 Google Cloud Next ’24 Las VegasのKeynoteにて様々なサービスが発表されました。 発表されたサービスの中で、BigQuery Data Canvas（preview）というものが気になったので触ってみました。 Keynoteにて発表されたサービスについて詳しく知りたい方は以下を参照ください。 【現地速報】Google Cloud Next ’24 Las Vegas Keynoteまとめ。 Google Cloud の旗艦イベントである『Google Cloud Next '24』がMandalay Bay, Las Vegasにて開幕しました。 今回は基調講演で発表された新サービスをいち早くお知らせします。 blog.usize-tech.com 2024.04.10 そもそもBigQueryとは？ ご存知の方も多いと思いますが、 BigQuery とは、Google Cloud Platformが提供する、エンタープライズ向けデータウェアハウスサービスです。 ペタバイト級のデータも高速処理できる超高速なデータウェアハウスで、サーバーの管理も不要、標準SQLによるクエリで簡単にデータ分析が行えます。 詳しくは以下のドキュメントを参照してください。 BigQuery の概要  |  Google Cloud cloud.google.com BigQuery Data Canvasとは？ BigQuery Data Canvasは、 データ分析ワークフローを視覚的に構築、管理、実行できる 、BigQueryの新しい機能です。 Gemini を使用しており、データの検索、SQLの作成、グラフの作成などを行うことができます。 詳しくは以下のドキュメントを参照してください。 Analyze with data canvas  |  BigQuery  |  Google Cloud Gives an overview and instructions on working with a data canvas, a feature designed to help users use natural language ... cloud.google.com 実際にさわってみた！！ それでは実際に触っていきます。参照するテーブルを準備した後、キャンバスを使って分析していこうと思います。 テーブルの準備 参照するテーブルを作っていきます。 ① BigQueryコンソールのBigQuery Studioにて、[SQLクエリを作成]を押下します。 ② ペンのようなマークを押下すると、[コーディングをサポート]という画面が出るので、下記のように入力し、[生成]を押下します。 ※データセットはUSリージョンのものを使用してください。 ※今回はGoogle Cloudの公開データセットである「About COVID-19 Public Dataset」を使用します。このデータセットの先頭500個のデータを読み込んでテーブルを作成し、参照するテーブルとします。 ③ SQLクエリが生成されるので、[挿入]を押下します。 ④ [実行]を押下し、テーブルを作成します。 以上でテーブルの完成です。 キャンバスの作成 それではキャンバスを作っていきます。 ① 家マークを押下し、以下の画面に遷移した後、[データキャンバスを作成]を押下します。 ② 先ほど作ったcovid19_open_dataを選択します。 ③ テーブルが読み込まれました。このテーブルに対してクエリを実行したいので、[クエリ]を押下します。 ④ location_key、date、population、population_male、population_femaleの4つの列を抽出しようと思います。以下のようにコンソールに入力し、▻を押下します。 ⑤ クエリが生成されるので、[実行]を押下すると、クエリ結果が表示されます。 ⑥ ⑤の結果に対して、location_keyが何種類あるのか確かめてみたいと思います。[これらのクエリに対してクエリを実行する]を押下し、以下のようにコンソールに入力します。最後に▻を押下すると、クエリが生成されます。 ⑦ [実行]を押下すると、以下の通り、結果が返ってきます。 ⑧ ここで、⑤の結果から、dateが2021-05-06であるデータを抽出してみます。⑤で作成したノードの[これらのクエリに対してクエリを実行する]を押下します。 ⑨ ノードが分岐して作成されるので、以下のようにクエリ生成を指示し、▻を押下します。 ⑩ クエリが生成されるので、[実行]を押下すると、以下のような結果となります。 ⑪ このクエリ結果から円グラフを生成しようと思います。以下の画面ように、【可視化】→【円グラフの作成】を押下します。 ⑫ 円グラフが作成されました！英語になっていますが、説明もつけてくれています。   以上でキャンバスの作成を終わります。作成したキャンバスの全体像は以下の通りです。   おわりに 今回はBigQueryの新機能であるBigQuery Data Canvasを触ってみました。 SQLクエリを一切書くことなく、テーブルを分析することが出来ました。SQLに抵抗がある方にはかなり嬉しい機能ではないでしょうか？ また、過去のクエリ実行結果を簡単に見返すこともできるので、非常に便利であると感じました。 今後も新しいサービスを触っていきたいと思います！ 最後まで読んでいただきありがとうございました！！

Amazon Cognito User PoolにIdentity ProviderとしてOktaを追加することにより、ユーザー認証が可能なのか調べる機会がありました。今回はOktaで管理されているユーザーを用いてService Provider（Cognito）経由でサインインし、ユーザー認証後の処理としてCognitoからアクセストークンの取得を試みました。 やりたいこと Cognitoに新規ユーザーを作成する事なく、作成済みのOktaユーザーを利用してユーザー認証を行い、SAML認証応答をCognitoに送信しアクセストークンを取得してみたいと思います。今回行う要求応答についての関係性は下記図を想定しています。   事前準備 Cognitoでユーザープールを作成しておきます。 チュートリアル: ユーザープールの作成 - Amazon Cognito ユーザープールを使用すると、ユーザーは Amazon Cognito 経由でウェブまたはモバイルアプリにログインできます。 docs.aws.amazon.com   Oktaの設定 SAMLアプリ統合を作成 OktaダッシュボードからApplicationsを展開し「Create App Integration」をクリックすると下記図が表示されます。今回はIdentity Provider(Okta)⇔Service Provider(Cognito)間でSAML認証を行う為、「SAML2.0」を選択し、次のページで任意のアプリケーション名を入力して進めます。 SAMLアプリ統合を作成する | Okta help.okta.com SAML 2.0セットアップ SAMLアプリ統合内の設定として、Service Provider（Cognito）に関する設定を行います。ここでは、事前準備で作成したCognitoの情報を以下の形式で入力します。 Single sign-on URL　https://<Your user pool domain>/saml2/idpresponse Audience URI (SP Entity ID)　urn:amazon:cognito:sp:< region_EXAMPLE> ユーザープールへの SAML ID プロバイダーの追加 - Amazon Cognito ユーザープールへの SAML ID プロバイダーの追加。 docs.aws.amazon.com ユーザープロファイル属性の設定 SAML Settingsにおける属性ステートメントはService Providerに提供される属性となります。Service Provider⇔Identity Provider間で認証に必要となるユーザー情報として、今回はName属性を１つだけ（email）設定して、SAMLアプリ統合を作成します。 SAMLメタデータを取得 SAMLアプリ統合内「SAML Signing Certificates」のType「SHA-2」のActionsより［View IdP metadata］を確認し、表示された内容を拡張子xmlとして保存します。 認証用ユーザーのアサイン OktaユーザーをSAMLアプリ統合にアサインします。「Assignments」タブより、「Assign」をクリックし、「Assign to People」画面で認証用ユーザーのアサインを行います。   Amazon Cognitoの設定 CognitoでOktaを Identity Provider として設定 Cognitoの「サインインエクスペリエンス」タブより、「フェデレーテッドアイデンティティプロバイダーのサインイン」から「アイデンティティプロバイダーの追加」をクリックし、アイデンティティプロバイダーにSAMLを指定し、プロバイダー名を入力します。 SAML属性の設定 Okta側で取得したSAMLメタデータのxmlファイルをアップロードします。 次にOktaからのSAMLアサーションに含まれるSAML属性をCognitoユーザープール属性にマッピングします。 アプリクライアントの作成と設定 Cognitoのユーザープールでアプリクライアントを作成し、認証情報を設定します。 注意点としては、ホストされたUI設定内で、「許可されているコールバック URL」に任意のクライアントアプリケーションのURLを指定します。本設定を行わない場合、ユーザー認証後のリダイレクト先が無く処理が止まるので、忘れずに設定します。 Amazon Cognito でホストされた UI およびフェデレーションエンドポイントの設定と使用 - Amazon Cognito モバイルまたはウェブアプリの Amazon Cognito ユーザープールへの統合 docs.aws.amazon.com   クライアントの設定 クライアントアプリケーションの設定 クライアントアプリケーションからCognitoユーザープールのフェデレーションエンドポイントを呼び出す設定をします。 OAuth 2.0、OpenID Connect、および SAML 2.0 フェデレーションエンドポイントリファレンス - Amazon Cognito このドキュメントでは、Amazon Cognito ユーザープールのホストされた UI、SAML 2.0、OpenID Connect、および OAuth 2.0 の認証および認可エンドポイントについて説明します。これらのエンドポイントは、... docs.aws.amazon.com   動作確認 Oktaユーザーによる認証リクエスト クライアントアプリケーション（今回はPostman）からCognitoフェデレーションエンドポイントを呼び出すとOktaへリダイレクトされ、折り返してサインイン画面が表示されるので、Oktaに登録されているユーザー情報を入力してサインインします。 アクセストークンの取得およびCognitoの状態確認 Oktaでユーザー認証結果をクライアントアプリケーションで受け取り、Cognitoにリダイレクトします。CognitoでAuthorization Codeの確認を行い問題無ければクライアントアプリケーションにアクセストークンを送信します。 Oktaユーザーで認証を行う場合、ユーザー状態はどのように認識されるのか確認したところ、「確認ステータス」で「外部プロバイダー」と表示されており、Cognito User Pool内部に作成されたユーザーとは識別できそうです。   まとめ 本記事では、Amazon Cognito User PoolのIdentity ProviderにOktaをセットアップし、以下の流れを試しました。 Client ApplicationからService Providerのフェデレーションエンドポイントを呼び出す。 Service Providerはユーザー認証要求をIdentity Providerにリダイレクトする。 Client ApplicationからIdentity Providerのログイン画面でIdentity Providerに所属するユーザーを利用してログインする。 Identity Providerでユーザー認証応答を作成する。 Identity ProviderからClient ApplicationへSAML認証応答の送信を行う。 Client ApplicationからService ProviderへSAML認証応答を送信する。 Service ProviderでSAML認証応答を検証し、検証結果をClient Applicationへ返却する。 Client ApplicationからService Providerへアクセストークンを要求・応答を受け取る。 以上の結果から、Amazon Cognitoに新規ユーザーを作成する事なく、作成済みのOktaユーザーを利用してユーザー認証を行い、アクセストークンを取得する事ができました。

こんにちは。SCSKの島村です。 Google Cloud の旗艦イベントである 『Google Cloud Next ’24』 が Mandalay Bay, Las Vegas にて開幕しました。 現地時間４月9日（月）-11日（木） の3日間にわたり基調講演や、先進事例セッション、テーマ別のブレイクアウトセッションなどなど、 最新の技術革新、Genarative AIからセキュリティまで, Google Cloud のあらゆることに関するセッション がご用意されております。また、 この度当社は、 Google Cloud Social Impact Partner of the Yearを受賞 しました。 Enterprise向けに画像（外観検査AI）や音声（コンタクトセンターAI）とマルチモーダルなデータを活用し、お客様課題解決、社会に新たな価値創出したことが認められ受賞に至りました。 —プレスリリースの詳細はこちらから— 国内企業で初受賞「Google Cloud ソーシャルインパクト パートナー オブ ザ イヤー」を受賞 (scsk.jp) 本記事では、3日間に及ぶGoogle Cloud Next ’24 Las Vegas の「 Day1開幕速報 」として、現地の最新情報を共有できればと思います。 [速報] Opening Keynote（Tuesday,April 09,09:00 AMPDT） 概要 本日（日本時間：4月10日2時0分）からKeynoteセッションが行われました。 現地速報として、リリースされた新サービスの情報並びに会場の雰囲気をいち早くお伝えします。 ＊各サービスの詳細については、後日追って共有いたします。 Keynoteアーカイブは以下,Google Cloud 公式Youtubeから確認可能です。 [現地写真] Keynote HALL会場の様子 @Michelob Ultra Arena-Opening Keynote：The new way to cloud 入口では「入場制限」がかかるほどの熱量で、セッションのスタートと同時に会場は大盛り上がりでした。 Keynoteにて発表されたサービス 新たに発表されたサービス一覧 ＊各サービスの詳細については、後日追って共有いたします。次回のブログをお楽しみにしていただければと思います。 General Availability 　 A3 Mega VMs 2x netowork bandwiseに対応したVMs Coming Soon NVIDIA GB200 NVL72 30x 高速なリアルタイム大規模言語モデル (LLM) 推論を支えるGPU General Availability 　 TPU v5p AI向け最先端TPU   Preview   Hyperdisk ML 最新世代のネットワーク ブロック ストレージサービス General Availability Dynamic Workload Scheduler リソースへのアクセスとAI/MLワークロード最適化 General Availability GKE Enterprise Software on GDC GDC上でのエンタープライズ向けGKEソフトウェア General Availability AI Models on GDC GDCで提供されるAIモデル群 General Availability Vector Search on GDC GDC上でのベクトル検索サービス General Availability Vertex AI Solutions wirth GCD GCDを活用したVertex AIソリューション General Availability Sercret and Top Sercret Acceditaions 機密・最高機密情報取扱いに係るアクレディテーション Coming Soon Google Axion Processors 生成AI処理向け独自CPU   Preview   Gemini 1.5 Pro AI処理リソースを抑え性能向上を実現する最新言語モデル General Availability Claude 3 Anthropic  Anthropic社のstate-of-art modelを利用可能 Open model CodeGemma 予測コーディングと生成モデリングを組み合わせたモデル   Preview   Supervised Tunig for Gemini Models Geminiモデル向けの教師ありチューニングオプション   Preview   Grounding with Google Search Google検索を基にしたグラウンディングサービス   Preview   Prompt Management プロンプトを用いたAIモデル管理機能 General Availability Automatic Side-by-Side(AutoSxS) 自動結果比較を可能としたサービス   Preview   Rapid Evaluation 高速モデル評価とフィードバックシステム General Availability Vector Search Google Search like qualityのベクトル検索機能 General Availability [Google workspaces]AI Meetings and Messaging Add-on $10/user/monthのAI会議・メッセージングアドオン General Availability [Google workspaces]AI Security Add-on AI技術を活用したセキュリティ強化アドオン   Preview   [Google workspaces]Gemini in Google Chat Google ChatでのGemini統合機能 Coming Soon [Google workspaces]Google Vids 動画生成アプリケーション シンプルなインターフェイスで手軽に動画を作成可能 General Availability Imagen 2.0 最先端のテキストから画像への生成モデル   Preview   Text-to-Live Image 高度なテキストからライブ画像へのモデル General Availability Digital Watermarking デジタルウォーターマーキング機能 General Availability New Editing Models in Imagen 2.0 Imagen 2.0における新しい編集モデル   Preview   Gemini in Bigquery Gemini x BigQueryの統合機能   Preview   BigQuery Data Canvas Geminiを活用したBigQueryのデータキャンバス機能   Preview   Vector Indexing in Bigquery and AlloyDB BigQueryとAlloyDBに対するベクトル検索機能   Preview   Direct Access to Vertex AI from BigQuery BQデータを直接VertexAIにインポートできる機能   Preview   Gemini in Looker Looker画面を通じてデータxGenAI対話機能提供   Preview   Gemini Cloud Assist Cloud Assistの為にGemini機能提供   Preview   Gemini in Threat Inteligence 会話型検索を使用した最新の脅威分析   Preview   Gemini in Security Command Center 構成ミスや脆弱性に関するリスク検知 新サービスが多数発表されました。 セッションでは、デモを用いたサービス紹介が行われ、都度、会場からは歓声が上がっていました。 また、詳細について発表されていないものもあり、今後が楽しみです。     おまけ：現地会場（ Mandalay Bay ）の様子 今回のGoogle Cloud Next ’24 は、『Las Vegas Mandalay Bay』にて開催されました。 日本とラスベガスの時差は、16時間程度で朝夕は肌寒く、日中は過ごしやすい気候でした。くらいでした。 会場MAP Next 24 Main Venue: Beach - Mandalay Bay Located on 11 lush acres, Mandalay Bay Beach is a world-famous aquatic playground featuring 2,700 tons of real sand, a 1... mandalaybay.mgmresorts.com   最後に 今回はGoogle Cloudの旗艦イベントである Google Cloud Next ’24 Las Vegasについて開幕現地速報をお届けしました。 本日から3日に渡るイベントをGoogle Cloud のPartnerとして一緒に盛り上げていければと思います。 現地では、会場の雰囲気も味わうことができ、Google Cloud の熱気も感じることができました。 また、新サービスの発表もあり日本に帰国してからより詳しい内容については調査・整理し、本ブログにて情報発信できればと思います。 今後とも、AIMLに関する情報やGoogle CloudのAIMLサービスのアップデート情報を掲載していきたいと思います。 最後まで読んでいただき、ありがとうございました！！！

    Smartdbxとは？ 前回の振り返りです。Smartdbxとは何か？についての続編になります。 前回の記事は以下をご確認ください。 Smartdbxとは？~Dropbox統合管理ツール~ SCSKではDropbox管理業務負荷の軽減及びエンドユーザの利便性を向上させるためのDropbox統合管理ツールとして「Smartdbx」を開発いたしました。 blog.usize-tech.com 2024.03.22 Smartdbxは、Dropboxの管理者の業務負荷の軽減やエンドユーザの利便性を向上させるためのツールです。 フォルダ管理については自動化を行い、社外の共有については上長の承認を、アクセス権管理についてもツールを通し一括管理を実現できます。 「Smartdbx」には管理者業務を自動化する事で、管理者業務自体を極力なくし、管理者の運用負荷を軽減させる機能が用意されております。 SmartdbxとDropbox と組み合わせてお使いいただくことでもっと便利に、効率的にDropbox をご利用いただくことができます。 弊社がDropboxの管理ツール開発を始めたのは2017年からになります。 ——————————————————————– 2017年 　ONEUPの開発・運用 Dropboxを導入した時から社内の運用管理の負荷低減、効率アップを目的としたツール（社内呼称：ONEUP）を開発、運用しています。 2022年 　外部共有の管理機能をリリースして機能拡張 2023年 　Smartdbx開発 —————————————————————— ONEUPに更に多くのDropboxプロジェクトで培った知見を取り入れ、多くのお客様からご要望が多い有益な機能をSmartdbxとして実現しました。 機能 機能詳細 基本/オプション アカウント/グループ管理機能 •人事マスタ(組織と人)と自動連係 •Dropboxのアカウントおよびグループの連係 •アカウント情報の照会 •グループ情報の照会 基本機能① 共有フォルダ管理 •共有フォルダ管理機能 •共有フォルダ承認ワークフロー •共有フォルダ棚卸機能 サブフォルダ含みの棚卸しのみ、順次リリース(可視化機能として) •共有フォルダアーカイブ機能 (順次リリース) •フォルダテンプレート 基本機能② 社外共有フォルダ監視 個人フォルダや、共有フォルダ申請で申請されたチーム外共有以外の社外共有の監視・ブロック機能 基本機能③ 全社ナレッジ共有 1,000人以上となるような大規模環境での全社共有するフォルダ管理機能 オプション① カスタムドメイン（ファイル送受信） 社外の方とのファイルの受渡をDropboxドメインを使わずに実現する機能 オプション②   機能紹介 Smartdbxのご紹介記事は2回目になりますので、今回はオプション機能のご紹介です。 オプション機能①　全社ナレッジ共有 Dropboxで利用できるチームフォルダはチームや組織のための便利な共有ツールですが、 一方で、チームフォルダに招待できるユーザが1,000人までというサービス仕様があります。 1,000人以上で共有したり、みんなで編集・更新するという場面が少ないという背景があるためですが、全社で展開する発信文書やポータルとして展開するユースケースもありますので、 本ツール「全社ナレッジ共有」では、Dropboxの仕様はそのままで1,000人ごとにフォルダを自動で分けることができます。 Smartdbxを介して更新を行うことでDropboxのユーザが1,000人以上のチームに対しての効率的な情報共有を可能とします。 管理者はSmartdbxから、コンテンツの追加、変更、削除などの操作や、公開期限を設定でき、期限が来ると自動で公開データを削除することも可能です。 管理者がSmartdbxから更新を行うことで、Dropboxにフォルダが複数あっても1回の更新で同じ内容が反映されます。 本機能で共有されるコンテンツは全社での「参照」を基本とするもので、「編集」などの変更を加える操作は一部のコンテンツ管理者のみが実施することを前提としています。 オプション機能②　カスタムドメイン（ファイル送受信） Dropboxを利用して他社とファイルを共有する際、「DropboxTransfer」というファイル送信機能や「ファイルリクエスト」といったファイルを集める機能お使いいただけます。 ただ企業によってはクラウドストレージへのアクセスを禁止している場合があります。 その場合、Dropboxのファイルを安全に送受信することができません。 そこで本機能「カスタムドメイン」を使えばクラウドストレージがブロックされている取引先とも安全にDropboxのファイルを送受信することができます。 「カスタムドメイン」は、Dropboxとお取引先との間で仲介役として機能し、Dropboxドメインにアクセスせずに取引先がファイルを受け取ることができるようにします。 どのような相手にカスタムドメイン機能を使うかの例を記載します。 ①Dropboxが使える取引先 クラウドストレージがブロックされていない相手とはDropboxの標準機能を使ってファイルの共有が可能です。 Dropboxアカウントあり⇒フォルダ共有 Dropboxアカウントなし⇒送る：Dropbox Transfer　/　受け取る：ファイルリクエスト ②Dropboxが使えない取引先 Transferなどで生成されたdropbox.comドメインのリンクに対してアクセスできずファイルの送受信ができません。 これを回避する機能として本ツールでは「カスタムドメイン」機能をご提供いたします。   カスタムドメインの利用イメージ（下図）です。 ①Smartdbxのカスタムドメイン機能から送信先の情報、メッセージ、送信したいDropboxファイルを指定すると、入力した送信先に認証　　用のメールが届きます。 ②メールアドレスで認証を行います。 ③ダウンロード用のリンクが記載されているメールが届きます。 この③で届くダウンロード用リンクを使用いただくことでdropbox.comのドメインを使わずにDropboxのファイルを送受信していただけます。 現状1回の送信で50GB、将来的には300GBまでを目指しております。 また本機能はデータ転送を伴うためデータ転送にかかる料金については従量課金制となります。     今回はSmartdbxのオプション機能についてのご紹介でした。 Smartdbxについて興味を持っていいただけたら下記のホームページもご確認いただき、詳しい内容についてはぜひお問い合わせください。 詳しくはこちらをご覧ください。 Dropbox： Dropbox ｜ SCSK株式会社

こんにちは、SCSKでAWSの内製化支援『 テクニカルエスコートサービス 』を担当している貝塚です。 皆さん、Session Manager経由でインスタンスに接続できず、調べてみてやっと原因がわかったり調べてみてもさっぱり原因が分からなかったりした経験がありませんか？ 対象インスタンスと同一VPCにssm, ssmmessages, ec2messagesのVPC Endpointを作成(インターネット接続のない環境の場合)し、 AWSSSMManagedCorePolicyを含むRole(インスタンスプロファイル)を作成し、 そのRole(インスタンスプロファイル)を接続対象インスタンスにアタッチし、 EC2インスタンスからVPC EndpointへのHTTPSが許可されるようにSecurity Groupを調整する SSM AgentがプレインストールされたAMIを使用しており、SSM Agentが起動していないとは考えづらい Session Managerのトラブルシューティング を調べてみてもおかしいところは見当たらず、正直もうお手上げ……そんな時に、縋る思いでこの記事をチェックしてみてください。 前提 この記事は、Session Manager経由での接続にVPCエンドポイントを使用する場合を想定しています。インターネットゲートウェイをアタッチしてインターネット接続できる環境にはあてはまりません。 名前解決に注意！ この記事で言いたいことは、名前解決に注意、です。VPC・VPCエンドポイントには、名前解決まわりのはまりポイントが3つあります。多くの場合このはまりポイントはうまく回避できているのですが、ひょんなことからはまりポイントになってしまうことがあるのです。 VPCの属性「DNS ホスト名」が有効になっていることを確認する VPCの属性「DNS 解決」が有効になっていることを確認する VPCエンドポイントの属性「プライベート DNS 名」が有効になっていることを確認する 1. VPCの属性「DNS ホスト名」が有効になっていることを確認する 下記AWSドキュメントを読んでみると、「DNSホスト名(enableDnsHostnames)」は、パブリックIPアドレスを持つEC2インスタンスのパブリックDNS名(ec2-xxx-xxx-xxx-xxx.ap-northeast-1.compute.amazonaws.com のようなインターネットから接続可能なFQDN)を有効にするか否か(のみ)を制御しているように読めます。 VPC の DNS 属性 - Amazon Virtual Private Cloud VPC の DNS サポートを制御します。 docs.aws.amazon.com VPC がパブリック IP アドレスを持つインスタンスへのパブリック DNS ホスト名の割り当てをサポートするかどうかを決定します。 ところが実際はそうではありません。 上記ドキュメントの「ルールと考慮事項」を読むと次のようなことが書かれています。(参照元ドキュメントの日本語機械翻訳がおかしいので、私の方で意味の通る日本語に翻訳し直しています) 「DNS ホスト名」「DNS 解決」のどちらかが無効に設定されている場合、Amazon Route 53 Resolver サーバーは、Amazon が提供するプライベート DNS ホスト名を解決できません。 Amazon が提供するプライベート DNS ホスト名というのは、例えばVPC内でEC2の名前解決に使用できるプライベート IP DNS 名(ip-10-xxx-xxx-129.ap-northeast-1.compute.internal のようなFQDN)などのことですが、他に、インターフェース型VPCエンドポイント名(例えば ssm.ap-northeast-1.amazonaws.com )もこれに含まれます。 以下の記事で書いた通り、本来であればAWSのパブリックIPが返ってくるはずのAWSサービスのエンドポイント ※1 について、Amazon Route 53 ResolverがVPCエンドポイントのプライベートIPアドレスを返すことで、インターフェース型VPCエンドポイントは機能しています。 ※1 例えば ssm.ap-northeast-1.amazonaws.comを名前解決すると99.77.60.93などのパブリックIPアドレスが返ってくる。 AWS インターフェース型 VPC エンドポイントにどのようにアクセスしているのか？ インターフェース型VPCエンドポイントはVPC内のプライベートIPアドレスを持っており、Route 53 Resolverが名前解決時に返すIPアドレスを変えることでVPC内のプライベートIPアドレスにアクセスする仕組みになっています。 blog.usize-tech.com 2024.01.16 「DNSホスト名」を無効にするとこのプライベートIPへの変換ができなくなるので、Session Manager経由の接続ができなくなります。 2. VPCの属性「DNS 解決」が有効になっていることを確認する 「DNS解決(enableDnsSupport)」の方はもっとわかりやすく、これを無効化すると、Amazon Route 53 Resolver(デフォルトで参照しているDNSサーバ)が一切名前解決をしてくれなくなります。 当然、Session Manager経由の接続に必要なVPCエンドポイントの名前解決もしてくれないので、Session Manager経由の接続ができなくなります。 3. VPCエンドポイントの属性「プライベート DNS 名」が有効になっていることを確認する VPCエンドポイントには、例えば vpce-xxxxxxxxxxxxxxxx-xxxxxxxx.ssm.ap-northeast-1.vpce.amazonaws.com のような名前が付き、名前解決するとプライベートIPアドレスに解決されますが、その他に、ssm.ap-northeast-1.amazonaws.com (SSMエンドポイントの場合)のようなプライベートDNS名前も持ち、同じプライベートIPアドレスに解決されます。 VPCエンドポイントの「プライベートDNS名」を無効にすると、後者(ssm.ap-northeast-1.amazonaws.com)の名前解決が機能しなくなり、Session Manager経由の接続ができなくなります。 なぜ無効化されているのか？ VPC属性「DNS ホスト名」は、マネージメントコンソールからのVPC作成時に「VPCなど」(VPC作成時にサブネットやルートテーブルなども一緒に作ってくれる機能)を選択するとデフォルトで有効が選択されているので問題ありませんが、「VPCのみ」を選択するとデフォルトでは無効です(2024年4月4日時点で弊社所有の環境にて確認)。作成時に有効化できないので、「VPCのみ」作成した場合には、作成後に「DNS ホスト名」を有効化しましょう。 VPC属性「DNS 解決」は、マネージメントコンソールからのVPC作成時、「VPCなど」「VPCのみ」どちらを選択してもデフォルト有効です。 「VPCなど」を選択してVPCを作成する画面 「VPCなど」を選択したときのDNSオプション設定画面 VPCエンドポイントの「プライベート DNS 名」はマネージメントコンソールからの作成時にデフォルトで有効が選択されていますが、私の経験では、有効を選択するとなぜか作成エラーになるため無効にして作成したことがありました。(そのことを失念した状態でSession Managerの接続設定をして、なんでつながらないの……とはまっていたわけです） なお、2024年4月4日時点では「プライベート DNS 名」有効で問題なく作成できましたので通常は発生しない問題です。 まとめ VPCを「VPCのみ」で作成したときに「DNS ホスト名」が無効になっている点ははまりどころかと思います。 また、「DNS 解決」「プライベート DNS 名」は意図的に無効化しない限りは有効になっているはずですが、私が経験したように(おそらくマネージメントコンソールのバグか何かで)無効になってしまっている可能性もあるので、チェックしてみるとよいでしょう。

本記事は、本記事の内容は、Cato Networks社の以下の記事を元に日本語へ意訳、再構成したものとなります。 Cato Global Private Backbone レガシーな専用線/閉域網をやめて、インターネット回線ベースとしたSASEへ移行する企業が増えています。 企業ネットワークは、長い間、信頼性が高く、かつ手頃な価格のグローバル接続手段を見つけるのに苦労してきました。 グローバルの専用線（MPLS）接続は、非常コストが高額なため帯域幅を制限しているのが現状だと思います。 一方で、インターネットを利用したネットワーク接続は、長距離グローバル接続の遅延（レイテンシー）により、満足に利用ができない状況かと思います。 Catoクラウドでは、このようなグローバル接続の課題も解決します。 Catoクラウドの グローバルプライベートバックボーン （ Global Private Backbone ）は、世界中の90以上の接続拠点（PoP）にまたがるプライベートネットワークになります。バックボーンは手頃な価格で利用することができ、管理はすべてCato Networks社が行います。 信頼性の高いグローバル接続を手頃な価格で Catoクラウドを利用し、通信帯域を大幅に増強し、高額なIP-VPNなどのWAN回線を排除することで、エンタープライズのグローバル接続コストを劇的に削減することができます。CatoクラウドのPoPは、可用性、遅延（レイテンシー）、パケットロス、ジッターに関するSLA保証された複数のティア1プロバイダー間で相互に接続さています。Catoクラウドのソフトウェアは、プロバイダーネットワークをリアルタイムにパフォーマンス監視し、アプリケーションを意識したルーティングアルゴリズムによって、Catoクラウドのバックボーンを経由する最適なパスを選択します。ルーティングを制御し、SLA保証されたネットワークキャパシティのみを使用することで、パブリックインターネットよりもはるかに凌ぐパフォーマンスを、グローバル専用線（MPLS）よりもはるかに低いコストで実現することが可能になります。 ピークスループットのWAN最適化 Catoクラウドは、グローバルネットワークのレイテンシーを最小化するだけでなく、アプリケーションのスループットを向上させます。内蔵されているWAN最適化機能により、TCP効率が劇的に改善され、サイト（拠点）やモバイルユーザーのデータスループットが最大40倍向上させます。CatoクラウドのPoPはTCPコネクションをプロキシし、TCPクライアントとサーバーがより多くのデータをより早く送信できるようにします。また、高度なTCP輻輳制御により、Catoエッジはより多くのデータを送受信し、利用可能な帯域幅をより有効活用することができます。これらの技術により、エラー修復に必要な時間を短縮し、パケットロスによるデータスループットへの影響を軽減します。 クラウドネイティブソフトウェアによるイノベーションの加速とコスト削減 CatoクラウドのPoPは、完全にマルチテナントでスケーラブルなネットワークスタックにより、経路計算、ポリシーの実施、セキュリティ検査など、ネットワーキングとセキュリティのすべてのコア機能をクラウドネイティブで実行しています。このソフトウェアプラットフォームは、従来のカスタムハードウェア（専用機）でしか実現できなかったようなパフォーマンスを、市販のサーバー上で動作させて実現することを可能にしました。 専用アプライアンスや専用機を一切排除することで、レガシー通信ネットワークの技術面・運用面でのコストが大幅に変わります。独自ハードウェアの調達・導入がないため、Catoクラウドでは、ネットワークのフットプリントを急速に拡大することができています。現在、Catoクラウドのネットワークはすべての主要なビジネス都市をカバーしており、Cato PoPは主にソフトウェアと標準サーバで構成されているため、新しいPoPの開設も迅速に行うことができます。自社でソフトウェアを所有することで、より迅速なイノベーションが可能になり、顧客の求める機能要求に迅速に対応し、サービスの問題を迅速に解決し、運用コストとサードパーティのライセンス料を削減することができます。 セルフヒーリング（自己修復）アーキテクトによる24時間365日運用 Catoクラウドは、完全なセルフヒーリング（自己修復）アーキテクチャにより、最大限の可用性を確保します。障害の検知、フェイルオーバー、フェイルバックのすべてが自動化されており、特別な計画や事前のオーケストレーションは一切必要ありません。各PoPには、Catoのソフトウェアの同一コピーを実行する複数のコンピュートノードがあり、どのコンピュートノードでも、そのPoPに接続されたエッジトンネルにサービスを提供できます。コンピュートノードが故障した場合は、トンネルは自動的に別のノードに切り替わります。PoPへの接続ができなくなると、そのPoPに接続されたエッジ（Socket、またはCato VPNクライアント）は自動的に次に近いPoPに再接続します。また、CatoクラウドのPoP間を接続しているティア1プロバイダーでの障害や劣化が発生すると、PoPは自動的に代替のティア1プロバイダーへ切り替わります。 組み込みのエンドツーエンドの暗号化とセキュリティ Catoクラウドのセキュリティを確保するために、広範な対策が講じられています。PoP間であれ、Cato SocketやCato VPNクライアントとの通信であれ、すべての通信はAES-256暗号化トンネルによって保護されています。攻撃対象領域を最小化するため、許可されたサイトとモバイルユーザーのみがバックボーンに接続し、トラフィックを送信することができます。PoPの外部IPアドレスは、特定のDDoS対策で保護されています。また、Catoクラウドは、ISO 27001認証を取得しています。 まとめ Catoクラウドのサービスの根幹となる グローバルプライベートバックボーン（Global Private Backbone） について解説しました。 Catoクラウドに少しでも興味をお持ちになられた方は、遠慮なくSCSKまで お問い合わせ ください。 SASE、Cato Networks、Catoクラウド（Cato Cloud/Cato SASE Cloud）自体の知名度がまだまだ低い状況です。 SCSKでは、2021年からSASEの主要ソリューションを一同に紹介を行うオンラインセミナー「SCSK SASE Solution Summit（通称S4 エスフォー）」を定期的に開催しております。これまで14回開催し、1,800名以上の方にご参加をいただいております。 S4については、次回2024年4月以降に開催する予定ですので、改めてご案内いたします。 SASEや、Catoクラウドセミナー以外に、Catoクラウドのお客様導入事例の制作、 FAQサイト 運営、この TechHarmony （技術ブログ）にて、皆様のお役に立て、Catoクラウドの知名度アップに少しでも貢献できればと考えております。

Cato クラウドでは、通信先の FQDN をベースとしたトラフィック制御やアクセス制御を行うことができます。一方で、FQDN の根幹を成す DNS はアプリケーションレイヤの技術であり、ネットワークやトランスポートのレイヤからは直接扱えない技術でもあります。 そうしたレイヤの違いから Cato クラウドが通信先の FQDN をどのように識別しているのか気になりましたので、深掘りして調査検証し、いくつか浮かび上がってきた課題をここで説明します。 通信における FQDN の利用 まず、実際の通信において FQDN がどう利用されるか整理します。 クライアントがIPアドレスではなく FQDN を指定して通信を開始しようとしたとき、その通信に先立ってクライアントは FQDN の名前解決を行います。名前解決には DNS や mDNS、あるいはマシン上の hosts ファイルなどを利用し、通信相手のIPアドレスを把握します。その後、そのIPアドレスに対してパケットを送信します。 IP ヘッダや TCP/UDP ヘッダには FQDN を格納する領域がないため、クライアントが送信するパケットには通常は FQDN に関する情報は含まれていません。ただし、上位レイヤのプロトコルによっては、各プロトコルにおける必要性からデータ部 (TCP/UDP ペイロード部) に FQDN を含むものがあります。 よく利用されるプロトコルの中では、HTTP や TLS (HTTPS を含む) では次の箇所に FQDN を含められるようになっています。 HTTP の場合：HTTP リクエストの Host ヘッダまたは :authority 疑似ヘッダ プロトコル仕様： https://www.rfc-editor.org/rfc/rfc9110.html#section-7.2 TLS (HTTPS を含む) の場合：ハンドシェイク開始時に送信される ClientHello メッセージの server_name 拡張 SNI (Server Name Indication) と呼ばれる仕組み プロトコル仕様： https://www.rfc-editor.org/rfc/rfc6066.html#section-3 他にも FQDN をデータとして含むプロトコルもあると思いますが、FQDN を含まないプロトコルのほうが多いです。また、HTTP や TLS であっても FQDN を必ず含むとは限りません。   Cato クラウドによる FQDN 識別の仕組み さて、Cato クラウドはどのようにして通信先の FQDN を把握し、トラフィック制御やアクセス制御を行っているのでしょうか。 この疑問に対する回答の一部は、Knowledge Base の以下のページに記載されています。 参考： Traffic Intermittently Fails to Match Firewall Rules 上記ページによると、PoP に存在する DNS サーバは通信に先立って行われる名前解決の結果（FQDN とIPアドレスの組）をキャッシュして覚えておき、その後に行われる通信のIPアドレスを見て FQDN を識別しているようです。Internet Firewall や WAN Firewall などで通信をイベントログに出力するようにしていれば、各イベントログの “Domain Name” フィールドに識別された FQDN が格納されています。 しかし実際に検証してみると、それだけではなく HTTP 通信や TLS 通信に含まれる FQDN も参照して識別していることがわかりました。複数のパターンで試した結果、次のようになっていました。 TLS (HTTPS 含む) 通信の場合で、ClientHello メッセージに server_name 拡張が含まれている場合、server_name 拡張の値 HTTP (非暗号化) 通信の場合で、HTTP リクエストに Host ヘッダが含まれている場合、Host ヘッダの値 上記以外の場合で、PoP の DNS サーバに名前解決結果のキャッシュがある場合、キャッシュされた FQDN の値 上記以外の場合、FQDN は識別されない (“Domain Name” フィールドが存在しない) FQDN が識別されなかった場合、FQDN を指定して行う各制御機能が正常に働かない (例：Cato PoP からインターネットに出る際のIPアドレスを固定にできない、ブロックさせたい通信がブロックされない）ということにも繋がります。そういったことを避けるためにも、DNS Settings の Primary DNS の設定値を Cato の推奨通り デフォルト値 (10.254.254.1) のままとし、Socket 配下に位置するマシンや Cato Client で接続したマシンに PoP の DNS サーバを参照させることで、FQDN の識別が必ず行われるようにしましょう。   FQDN ベースの制御の課題 Cato クラウドによる FQDN 識別の仕組みがわかると、FQDN ベースの制御における課題、あるいは技術的な制約も見えてきましたので、ここでは4点挙げてみます。 異なる FQDN が同じIPアドレスを共有する場合に誤識別が起きる インターネット上では、1つのIPアドレスで複数の異なる FQDN のサービスを提供するといったことが一般的に行われています。これはクラウドサービスや共有のレンタルサーバ・ホスティングサービスなど、様々な場所で行われています。そうしたとき、異なる FQDN が同じIPアドレスとして名前解決されると、PoP の DNS サーバの名前解決結果のキャッシュ状況によっては、FQDN を識別する際に誤識別が生じる可能性があります。 実際、インターネットで名前解決可能な2つの FQDN を用意し、そのAレコードを同一のIPアドレスとし、その FQDN に対して Cato クラウド経由でアクセスして試してみました。名前解決結果のキャッシュによって FQDN を識別させるために、TLS や HTTP 以外の通信を行うアプリケーションで試しました。 FQDN① にアクセスした際、手元のマシンは PoP の DNS サーバに対して名前解決の問い合わせを行い、アプリケーションの通信は期待通り FQDN① として識別されました。その後、FQDN② にアクセスした際も同様に名前解決が行われ、期待通り FQDN② として識別されました。 その後改めて FQDN① にアクセスすると、手元のマシンには FQDN① の名前解決結果のキャッシュがあるため、PoP の DNS サーバに対して問い合わせを行わず、アプリケーションの通信が行われました。PoP の DNS サーバではIPアドレスに対して FQDN② を紐づけるキャッシュが残っているようであり、アプリケーションの通信は FQDN② として識別されてしまいました。何度か試した結果、後から名前解決を行った FQDN がそのIPアドレスに紐づけられるようでした。 インターネットにおける通信の仕組み上、こういった誤判定を Cato クラウドが技術的に解消することは不可能だろうと思います。そのため、Cato クラウドの機能で通信を明確に制御したい場合は、FQDN ではなくIPアドレスやポート番号によって制御するしかありません。ただし、TLS や HTTP 通信を行うアプリケーションではこの誤判定は生じないため、実際に課題として顕在化してIPアドレスやポート番号による制御を行う必要があるケースは稀かもしれません。 Cato PoP 側の機能のみ FQDN ベースの制御を行える 通信の FQDN を識別するにはパケットの中身を解析したり、DNS サーバの名前解決キャッシュと突き合せたりする必要があるため、現状では Cato PoP で FQDN の識別が行われています。そのため、Cato Client で接続した SDP ユーザの Split Tunnel 機能や、Socket の Bypass 機能などでは、FQDN ベースの制御は行えません。 将来的に Cato Client や Socket で FQDN を識別することで制御を行えるようになる可能性はありますが、パケット処理の負荷が高い内容でもあるため、ユーザのマシンに求められるスペックが高まったり、高価で高スペックな Socket が必要になったりするはずです。 現状では Cato PoP 側で行われる機能のみ FQDN ベースの制御を行えるのだとご理解ください。 悪意あるユーザは各種制御を回避できる TLS の server_name 拡張や HTTP の Host ヘッダの値は、ある程度知識があれば書き換えたり削除したりできます。そのようなことが行われたパケットをインターネット上のサーバが受信したときに、書き換え・削除が行われていないパケットを受信したときと同様の動作を行うようになっていると、悪意あるユーザは Cato クラウド上で行った FQDN ベースの各種制御を回避できてしまいます。 また、TLS や HTTP 以外の通信を行う場合にも、手元のマシンから Cato PoP の DNS サーバに名前解決の問い合わせを行わないようにしておけば、同様に各種制御を回避できてしまいます。 実際、server_name 拡張や Host ヘッダを適当な値に書き換えて通信すると、FQDN がその適当な値に識別されることを確認しました。また、Cato PoP の DNS サーバで名前解決を行わないようにしたうえで、server_name 拡張や Host　ヘッダを削除して通信すると、FQDN が識別されないことも確認しました。 FQDN による制御を回避できてしまうこと自体は、やはりインターネットにおける通信の仕組み上、Cato クラウドとしてはどうすることもできないように思います。悪意がなければ各種制御が回避されることはないため気にしすぎる必要はないと思いますが、厳格に制御する必要がある場合はIPアドレスやポート番号によって制御すべきですね。 Encrypted Client Hello によって通信できなくなる 2018年頃より、 Encrypted Client Hello (ECH) という TLS に関する新しい技術仕様が IETF にて議論されています。TLS 通信開始時に送信される ClientHello メッセージは鍵交換前であるため暗号化されていませんが、この ECH という技術仕様では ClientHello メッセージの一部を暗号化し、とりわけ server_name を秘匿しようとされています。 ECH の詳細はここでは説明せず Cloudflare のブログ や APNIC のブログ にお任せするのですが、端的に言うと、ClientHello メッセージの server_name 拡張の部分にはユーザのアクセス先の FQDN とは異なる値が入り、本当の FQDN は暗号化されて ClientHello メッセージに格納されるようになります。Cato クラウドやその他セキュリティソリューションなどは暗号化された部分を復号できないため、本当の FQDN を知ることができなくなります。 ECH に対応した通信を行うにはクライアントとサーバの両者がそれに対応している必要がありますが、Google Chrome や Microsoft Edge といったブラウザでは既に ECH がデフォルトで有効となっており、Cloudflare のような CDN では ECH を有効にするオプションも用意されています。そのため、今後普及することが予想され、気付かないうちに広まっているかもしれません。 一方で、クライアントが ECH に対応した通信を開始した場合、Cato クラウド側で TLS Inspection を行うようになっていると正常に通信できなくなる可能性があります。実際、日本の通信事業者のセキュリティサービスにおいても ECH により通信が行えなくなったというアナウンス もありました。TLS Inspection をバイパスすれば通信できるはずですが、CASB の各種機能は働かなくなってしまいますし、Cato クラウドが server_name 拡張の値をもとに FQDN を識別するのであれば誤識別も発生してしまいます。 ただし、Cato Client をインストールした Windows マシンを用いて ECH のテストサイトで試したところ、Cato Client 非接続時は ECH が使われたものの、Cato Client 接続時は ECH を使わずに通信していました（HTTPS レコードの問い合わせが行われていませんでした）。ECH が使われなかった理由は不明ですが、そうなるように Cato Client が Windows のレジストリを操作している可能性があります。もしそうであれば、通信できなくなる問題は起きなくて済むので良いのですが、正確な仕様は把握できておりません。   所感 Cato クラウドが通信の FQDN を識別する仕組みについて調査検証し、技術的に行えることはきちんと行う仕組みになっていると感じました。ほとんどの場合は正常に機能しますので、FQDN ベースによる制御も正しく行えるものと思います。 一方で、インターネットにおける通信の仕組み上、誤識別や悪意者が回避できるといった課題が残ってしまっています。これ自体は避けることはできませんが、将来のトラブルシューティング時にもしかしたら役立つかもしれませんので、頭の片隅に残しておきたいと思います。 Encrypted Client Hello という技術仕様については、IETF で議論されている最中でありインターネット標準となっているわけではないため、将来どうなるかはまだわかりません。CASB の各種機能を活かすには ECH を無効にせざるを得ないですが、無効にする設定をマシンに1ずつ導入していかなければならない事態はどうにか避けたいので、Cato クラウド側で何らかの対応（Cato PoP の DNS サーバが HTTPS レコードの問い合わせに応答しないようにする対応）が欲しいですね。

こんにちは！最近元気な挨拶を心がけているMasedatiです。 2023年度のAWSのアップデートを見直していたらAmazon Lexに関する以下の記事を見つけました。 Amazon Lex が Amazon Lex V2 向けの Selective Conversation Log Capture を導入 aws.amazon.com Selective Conversation Log Capture は、セキュリティやプライバシー上の懸念から会話型ログをデフォルトで有効にできない場合に、お客様がトラブルシューティングや詳細な会話分析を行うために役立ちます。… …この機能により、ユーザーが提供した承認や法的同意など、最も関連性の高いデータのみがキャプチャされ、アーカイブされます。 いったいどのような機能なのでしょうか？詳しく見ていきたいと思います。 Amazon Lexとは？ Amazon Lexとは、Amazon Alexa と同じ会話型エンジンを搭載した、音声やテキストを使用して任意のアプリケーションに対話型インターフェイスを構築するサービスです。チャットボットと呼べばイメージしやすいでしょうか。 Amazon Lexではサンプルボットが公開されており、以下は花屋を想定したチャットボットです。 ユーザの注文に対して自動応答を行っています。 なお、Amazon LexにはV1とV2がありますが、今回Selective Conversation Log Captureが使用できるのはV2のみのため、以降はAmazon Lex V2とします。   Selective Conversation Log Captureとは？ Amazon Lex V2 は、会話のテキストログを Amazon CloudWatch Logs に保存することができます。また、会話のオーディオログを S3 バケットに保存することができます。 すべてのログを保存できるのはありがたいですが、これまでは「ログを保存しない or ログを すべて 保存する」の2択だったため、ログを保存する場合、会話の中の機密情報(クレジットカード番号、セキュリティコード)もログの中に含まれる可能性がありました。 今回導入された「Selective Conversation Log Capture」は、有効化することで ログを 一部 保存することができるように なります。 具体例 Selective Conversation Log Capture 有効化前 のログはこちらです。 そして、Selective Conversation Log Capture 有効化後 のログはこちらです。 明らかに少なくなってますね。   やってみた では、花屋のサンプルボットを利用して、「Selective Conversation Log Capture」を導入してみましょう。 ボットの作成 Amazon Lexのページから「ボットを作成」ボタンをクリックします。 「例から開始」を選択し、サンプルボットとして、「OrderFlowers」を選択します。 ボットの名前を入力し、IAMロールを作成します。 児童オンラインプライバシー保護法は「 いいえ 」を選択します。 児童オンラインプライバシー保護法 (COPPA) の対象となるボットでは、会話ログを使用することはできません。 会話ログの記録 - Amazon Lex Amazon Lex V2 ボットを使用してユーザーとの会話を記録する方法を説明します。 docs.aws.amazon.com その他の設定項目はデフォルトとし、「次へ」ボタンを押します。 言語を選択し、チャットボイスの声優さんを選択後、完了ボタンを押します。 声が素敵だと思ったので、私はTomokoさんを選びました。 サンプルで作られる会話の流れは以下のようになっています。 Selective Conversation Log Captureを有効化する 今回は、新たに会話内容(顧客注文の最終確認)を追加し、その会話内容(スロット)のみログを保存してみます。 既存会話内容のログにセンシティブ情報( クレジットカード番号等 )があり、「 顧客注文の最終確認のみ記録する 」必要があると仮定します。 事前準備としてスロットタイプを定義する必要があります。 スロットタイプとは、スロット内のデータの認識と処理方法を定義するものです。 今回最終確認に対して、「はい/いいえ」の答えが期待されるので、以下のように作成します。 事前準備ができたところで、「スロットを追加」ボタンを押し、新しい会話を追加しましょう。 事前準備で作成したスロットタイプを指定し、以下のようにスロットを設定・追加します。 名前：CustomerCheck スロットタイプ：CustomerCheck プロンプト：{FlowerType} を {PickupDate} の {PickupTime} に受け取りますか？ スロットが追加できたら「インテントを保存」後、インテントリストに戻ります。 デプロイ>エイリアスを選択後、デフォルトで作成されているエイリアスを選択します。 「会話ログを管理」を押します。 テキストログを有効化し、Selectively log utterancesに✓を入れます。ログを保存するCloudWatchロググループを選びます。 なお、オーディオログは無効としました。 インテントに戻り、初期応答→詳細オプションをクリックします。 Selective Conversation Log Captureを有効にするインテントとスロットに基づいて、Session attributesに以下の形式で記載します。 [x-amz-lex:enable-text-logging: intent : slot]  = "true" 今回ログを保存するインテント名が[OrderFlowers]、スロット名が[CustomerCheck]なので、以下のように記載しました。 [x-amz-lex:enable-text-logging: OrderFlowers : CustomerCheck]  = "true" 公式ドキュメント には x-amz-lex:enable-text-logging: intent : slot と記載されてましたが、エラーがでました。 [ x-amz-lex:enable-text-logging: intent : slot ] が正しいようです。 インテントを保存後、Buildし、Testしてみましょう。 新しい会話が追加されました。 ログを確認する（再掲） では、CloudWatchログを確認してみましょう。 Selective Conversation Log Capture 有効化前 のログはこちらです。 上記会話の すべて のやりとりが保存されています。 そして、Selective Conversation Log Capture 有効化後 のログはこちらです。 “content”に表示されている内容は、該当会話でのユーザへの返答ですので、今回Selective Conversation Log Captureを有効化した CustomerCheckスロットのログのみ 保存されています。 今回は該当箇所のテキストログのみを保存しましたが、すべての会話をテキストログとして保存し、該当箇所のみオーディオログとして保存することもできます。   感想 一昔前のアップデート内容でしたが、皆様のお役に立てれば幸いです。

こんにちは！SCSKの江木です。 以前、BigQuery MLのML.GENERATE_TEXT関数を使って要約を生成させるというブログを執筆している際に、要約精度が良いモデル・プロンプトは何だろうと疑問が湧きました。 今回はこの疑問について解決するべく、流行りのLangChainを使って、要約精度が良いGoogleのLLMとプロンプトを考えてみようと思います。 ※以前のBigQuery MLのML.GENERATE_TEXT関数のブログが見たい方はこちら。 BigQuery MLのML.GENERATE_TEXT関数を使ってテキストデータを要約してみた BigQuery MLのML.GENERATE_TEXT関数を使って、テキストのデータセットを要約してみたので、実装方法を紹介します。 blog.usize-tech.com 2024.01.19 LangChainとは？ LangChainは、大規模言語モデル（LLM）を活用してサービスを開発する際に役立つオープンソースフレームワークです。LLMは、大量のデータで事前にトレーニングされた大規模な深層学習モデルで、ユーザーのクエリに対する応答を生成できます。 LangChainは、LLMと外部リソース（データソース、言語処理系）を組み合わせて、より高度なアプリケーションやサービスの開発をサポートすることを目的としています。プログラミング言語はPythonとJavaScriptに対応しています。 今回はLangChainが複数のLLMを扱えるという長所を利用します。 LangChain LangChain’s suite of products supports developers along each step of their development journey. www.langchain.com   要約精度をどのように比較するのか？ 人による要約精度評価をすることがベストですが、個人差が出てしまうため、今回は自動評価指標を使いたいと思います。生成AIの要約精度の比較にはROUGE、METEOR、BLEUといった自動評価指標が用いられることが多いですが、今回は比較的新しい指標であるBertScoreを使います。BertScoreを用いて、人が要約した文章と生成AIによって作られた要約の文章の類似度を比較することで、要約精度を導出します。 そもそもBertScoreとは？ BertScoreは、 BERTと呼ばれるTransformerベースの言語モデル を利用して、2つの文章の類似性を測定します。BERTは、文章中の単語だけでなく、文脈も考慮して単語の意味を理解することができます。 BertScoreの具体的な計算方法は以下の通りです。 2つの文章をBERTに入力し、それぞれの文のベクトル表現を得ます。 2つのベクトル表現の距離を計算します。 距離を元に、類似度スコアを計算します。 BertScoreは0~1の値を取り、1に近ければ近いほど文章の類似度が高いといえます。   検証環境およびソースコード 検証環境 本記事で検証環境として使用したのは、Google Colaboratoryです。Google Colaboratoryは、ブラウザ上で動作するJupyter Notebook環境です。無料で利用でき、Pythonコードの実行やデータ分析、機械学習などを行うことができます。 検証に使用したデータセットは 前回のブログ と同様にjson形式の 要約用のデータセット を用いました。 また、比較に使用したモデルはGoogle AIのGemini-pro、Vertex AIのGemini-pro、text-bison、text-unicornです。 ソースコード 検証の際に使用したソースコードを紹介していきます。 最初にモジュールのインストールを行います。 !pip install --upgrade langchain-google-genai langchain-core langchain-google-vertexai langchain langchain_community !pip install google-cloud-aiplatform chromadb==0.3.26 pydantic==1.10.8 typing-inspect==0.8.0 typing_extensions==4.5.0 pandas datasets google-api-python-client pypdf faiss-cpu transformers config --upgrade --user !pip install bert_score 続いて、使用するデータセットを読み込みます。今回は20個の文章を要約して、検証してみます。 import pandas as pd import json #変換したいJSONファイルを読み込む df = pd.read_json('jsonファイルが置いてあるフォルダ/japanese_test.jsonl',orient='records', lines=True) #要約に使用するテキスト df_text = df['text'].iloc[:20] #要約の正解テキスト df_sum = df['summary'].iloc[:20] 続いて、langchainを使って要約を行い、BertScoreで要約結果を比較する関数を作っていきます。 また、要約を行うために、以下の3つのプロンプトを用意しました。 以下の文章を要約して 以下の文章を200文字で要約して 以下の文章を3文で要約して 検証の際にはプロンプトを入力する箇所を適宜変更します。 from langchain_google_genai import GoogleGenerativeAI from langchain.prompts import PromptTemplate from bert_score import score import torch from langchain_google_vertexai import VertexAI from tqdm import tqdm #APIキーの設定 api_key = "Google AIのAPIキーを入れてください" #プロンプトを入力 #プロンプト1:以下の文章を要約して #プロンプト2:以下の文章を200文字で要約して #プロンプト3:以下の文章を3文で要約して template1 = """以下の文章で要約して。 文章：{sentence}""" #関数の作成 def compare_summary_result(llm,text,sum): 　text_list = text.tolist() 　sum_list = sum.tolist() 　result_sum_list = [] #llmによる要約の結果を格納 　sum_list_final = [] #データセットの要約を格納。データによってllmがエラーを出す時があるので、エラーを出したものを飛ばす。 　text_list_final = [] #データセットの元のテキストを格納。データによってllmがエラーを出す時があるので、エラーを出したものを飛ばす。 　for i in tqdm(range(len(text_list))): 　try :   　sentence = text_list[i]   　prompt = PromptTemplate.from_template(template1)   　prompt = prompt.format(sentence=sentence)   　result = llm.predict(prompt)   　result_sum_list.append(result)   　　　text_list_final.append(text_list[i])   　sum_list_final.append(sum_list[i]) 　except IndexError :     print("IndexError") P, R, F1 = score(result_sum_list, sum_list_final, lang="ja") result_bertscore = float(torch.mean(P)) return result_bertscore,result_sum_list,sum_list_final,text_list_final それでは作成した関数を用いて、検証するプログラムを作成します。 以下、Google AIのGemini-proモデルを使用した検証プログラムになります。 llm = GoogleGenerativeAI(model="gemini-pro", google_api_key=api_key) #結果を整形 google_gemini_bertscore,google_gemini_result,google_gemini_sum,google_gemini_text = compare_summary_result(llm,df_text,df_sum) df_google_gemini_result1 = pd.DataFrame(list(zip(google_gemini_result,google_gemini_sum,google_gemini_text)), columns=["summary_result", "summary_label", "text"]) 続いて、Vertex AIのGemini-pro、text-bison、text-unicornを使用した検証プログラムになります。 import sys import IPython import vertexai from google.colab import auth #認証を行う app = IPython.Application.instance() app.kernel.do_shutdown(True) if "google.colab" in sys.modules: 　auth.authenticate_user() #初期化を必ず行う #Gemini-proモデル vertexai.init(project="プロジェクト名",location="us-central1") llm = VertexAI(model="gemini-pro") vertex_gemini_bertscore,vertex_gemini_result,vertex_gemini_sum,vertex_gemini_text = compare_summary_result(llm,df_text,df_sum) df_vertex_gemini_result1 = pd.DataFrame(list(zip(vertex_gemini_result,vertex_gemini_sum,vertex_gemini_text)), columns=["summary_result", "summary_label", "text"]) #text-bisonモデル vertexai.init(project="プロジェクト名",location="us-central1") llm = VertexAI(model="text-bison",project_id="プロジェクト名") vertex_bison_bertscore,vertex_bison_result,vertex_bison_sum,vertex_bison_text = compare_summary_result(llm,df_text,df_sum) df_vertex_bison_result1 = pd.DataFrame(list(zip(vertex_bison_result,vertex_bison_sum,vertex_bison_text)), columns=["summary_result", "summary_label", "text"]) #text-unicornモデル vertexai.init(project="プロジェクト名",location="us-central1") llm = VertexAI(model="text-unicorn",project_id="プロジェクト名") vertex_unicorn_bertscore,vertex_unicorn_result,vertex_unicorn_sum,vertex_unicorn_text = compare_summary_result(llm,df_text,df_sum) df_vertex_unicorn_result1 = pd.DataFrame(list(zip(vertex_unicorn_result,vertex_unicorn_sum,vertex_unicorn_text)), columns=["summary_result", "summary_label", "text"])   検証結果 先ほどのソースコードを実行し、それぞれのプロンプトにおいて、要約結果を言語モデル間で比較してみました。それでは、結果を見てみましょう。 プロンプト1：以下の文章を要約して プロンプト1をLLMに入力して、類似度を出した結果は以下の図の通りです。 縦軸がBertScore、横軸がモデルを表しており、左からGoogle AIのGemini-pro、Vertex AIのGemini-pro、text-bison、text-unicornのモデルの結果を示しています。   Google AI のGemini-proが一番よい要約精度を記録しました。 データセットの先頭のデータに対する要約結果を以下のようにまとめてみました。 元のテキスト このワクチンは複数の動物実験で、安全性や、効果的な免疫反応を引き起こすことが示されている。 今回の第1段階の後には、6000人を対象とした別の臨床試験が今年10月に予定されている。 インペリアル･コレッジ･ロンドンのチームは、2021年の早い時期からイギリスや海外でワクチンを配布できるようにしたいとしている。 ＜関連記事＞ 世界中では約120のワクチンの開発が進められている。英オックスフォード大学の専門家たちはすでに臨床試験を開始している。 新しいアプローチ 多くの従来のワクチンは、弱体化させたウイルスや改変したウイルスなどがもとになっている。しかし今回のワクチンは新しいアプローチに基づいたもので、遺伝子のRNA（リボ核酸）を使う。 筋肉に注射すると、RNAは自己増殖し、新型ウイルスの表面にみられるスパイクタンパク質のコピーをつくるよう、体内の細胞に指示を出す。 この方法で、COVID-19（新型ウイルスによる感染症）を発症することなく新型ウイルスを認識して戦うための免疫システムを訓練できるという。 シャトック教授は、「我々はゼロからワクチンを製造し、わずか数カ月で臨床試験に持ち込むことができた」と述べた。 「我々のアプローチがうまくいって、ワクチンがこの病気を効果的に防御できれば、将来的なアウトブレイク（大流行）への対応方法に革命をもたらす可能性がある」 主任研究員のカトリーナ・ポロック博士は、ワクチンの効果に期待している この研究の主任研究員、カトリーナ・ポロック博士は、「参加者に大きな免疫反応がみられるだろうと、慎重ながらも楽観的に感じられなかったら、私はこの臨床試験に取り組んでいなかっただろう」と付け加えた。 「前臨床データは非常に期待がもてるものだった。感染から保護しておきたい免疫反応である中和抗体応答は確認できているが、このワクチンを評価するにはまだ道のりは長い」 この研究は英政府から4100万ポンド（約54億5500万円）の資金提供を受けている。ほかにも500万ポンド（約6億6500万円）の寄付が寄せられている。 「ウイルスを倒すのに協力したくて志願」 金融業界で働くキャシーさん（39）は、インペリアル･コレッジ･ロンドンの臨床試験に参加している最初のボランティアの1人だ。 新型ウイルスとの戦いの一端を担いたくて志願したという。 「自分に何ができるのかあまりよく分かっていなかったけど、これが私にできることだったと分かった」 「それに、ワクチンができるまで日常に戻れる可能性は低いことを理解したことで、ワクチン開発の一端を担いたいと思った」 キャシーさんは、インペリアル･コレッジ･ロンドンの臨床試験に参加している最初のボランティア300人の1人 こうした中、ケンブリッジ公爵ウィリアム王子はオックスフォード大学の臨床試験に参加しているボランティアたちと、オックスフォード市内のチャーチル病院で面会した。 ウィリアム王子はボランティアに対し、「みなさん全員が参加しているのは、信じられないくらい胸が躍る、非常に待ち望まれたプロジェクトだ。だからみんなが心を奪われている」と述べた。 初日の被験者は1人だけ BBCのファーガス・ウォルシュ医療担当編集委員によると、すべての臨床試験は安全性のリスク軽減のために慎重に、ゆっくり開始される。オックスフォード大学で4月に臨床試験が開始された際には、初日に接種を受けたのはボランティア2人だけで、1週間以内に100人に接種された。 これに対して、インペリアル･コレッジ･ロンドンの臨床試験では初日には1人だけにワクチンを接種する。その後48時間ごとに3人に接種し、徐々に被験者を増やしていく。 また、1回分の投与量を使用するオックスフォード大学とは異なり、インペリアル･コレッジ･ロンドンの臨床試験では4週間の間隔をあけて、2回の接種を行うという。 シャトック教授らのチームは、慎重に進めている理由について、ワクチンに特段の安全性の懸念があるからではなく、単にアプローチが新しいからだと説明している。 新型コロナウイルス特集 感染対策 在宅勤務・隔離生活 （英語記事 Human trial of new coronavirus vaccine starts in UK） 要約の正解データ 新型コロナウイルスの新しいワクチンの臨床試験がイギリスで始まった。インペリアル･コレッジ･ロンドンのロビン・シャトック教授らが率いる試験の一貫で、今後数週間で約300人を対象に実施される。 Google AI Gemini-proによる要約結果 インペリアル・カレッジ・ロンドンは、新しいRNAベースのコロナウイルスワクチンの第1段階臨床試験を開始しました。これまでの動物実験では安全性と免疫反応の有効性が示されており、10月に6000人を対象とした第2段階試験が予定されています。このワクチンは、弱体化したウイルスではなく、自己複製してスパイクタンパク質の複製を生成するRNAを使用しています。主任研究員は、免疫反応に期待を寄せていますが、ワクチンが効果的であるかどうかを評価するにはさらなる調査が必要です。 Vertex AI Gemini-proによる要約結果 インペリアル・カレッジ・ロンドンの新しいmRNAワクチンは、動物実験で安全かつ効果的であることが示され、現在第1段階の臨床試験が行われている。6000人を対象とした第2段階試験は今年10月に予定されており、早ければ2021年初頭にワクチンが配布される見込み。このワクチンは、体内にスパイクタンパク質のコピーを作成し、免疫システムを活性化してCOVID-19と戦う仕組み。 Vertex AI text-bisonによる要約結果  インペリアル・カレッジ・ロンドンは、新型コロナウイルスのワクチンの人間に対する臨床試験を開始した。このワクチンは、遺伝子のRNA（リボ核酸）を使用しており、筋肉に注射すると、自己増殖して新型ウイルスの表面にみられるスパイクタンパク質のコピーをつくるよう、体内の細胞に指示を出す。この方法で、COVID-19（新型ウイルスによる感染症）を発症することなく新型ウイルスを認識して戦うための免疫システムを訓練できるという。臨床試験には、300人のボランティアが参加し、初日には1人 Vertex AI text-unicornによる要約結果 インペリアル・カレッジ・ロンドンの研究チームは、新型コロナウイルス感染症（COVID-19）のワクチンの臨床試験を開始した。このワクチンは、従来のワクチンとは異なる新しいアプローチで開発されたもので、遺伝子のRNA（リボ核酸）を使う。筋肉に注射すると、RNAは自己増殖し、新型ウイルスの表面にみられるスパイクタンパク質のコピーをつくるよう、体内の細胞に指示を出す。この方法で、COVID-19を発症することなく新型ウイルスを BertScoreの結果の通り、Google AIのGemini-proモデルの要約が一番良いように思えます。 プロンプト2：以下の文章を200文字で要約して プロンプト2をLLMに入力して、類似度を出した結果は以下の図の通りです。 text-unicornが最も精度の高い要約を生成したという結果となりました。 以下の公式ドキュメントによると、text-unicornは「複雑な自然言語タスクに使用する PaLM モデル ファミリーの中で最も高度なテキストモデル。」とのことなので、高い精度となったと考えられます。 モデル情報  |  Vertex AI の生成 AI  |  Google Cloud cloud.google.com   また、データセットの先頭のデータに対する要約結果を以下のようにまとめてみました。 元のテキスト このワクチンは複数の動物実験で、安全性や、効果的な免疫反応を引き起こすことが示されている。 今回の第1段階の後には、6000人を対象とした別の臨床試験が今年10月に予定されている。 インペリアル･コレッジ･ロンドンのチームは、2021年の早い時期からイギリスや海外でワクチンを配布できるようにしたいとしている。 ＜関連記事＞ 世界中では約120のワクチンの開発が進められている。英オックスフォード大学の専門家たちはすでに臨床試験を開始している。 新しいアプローチ 多くの従来のワクチンは、弱体化させたウイルスや改変したウイルスなどがもとになっている。しかし今回のワクチンは新しいアプローチに基づいたもので、遺伝子のRNA（リボ核酸）を使う。 筋肉に注射すると、RNAは自己増殖し、新型ウイルスの表面にみられるスパイクタンパク質のコピーをつくるよう、体内の細胞に指示を出す。 この方法で、COVID-19（新型ウイルスによる感染症）を発症することなく新型ウイルスを認識して戦うための免疫システムを訓練できるという。 シャトック教授は、「我々はゼロからワクチンを製造し、わずか数カ月で臨床試験に持ち込むことができた」と述べた。 「我々のアプローチがうまくいって、ワクチンがこの病気を効果的に防御できれば、将来的なアウトブレイク（大流行）への対応方法に革命をもたらす可能性がある」 主任研究員のカトリーナ・ポロック博士は、ワクチンの効果に期待している この研究の主任研究員、カトリーナ・ポロック博士は、「参加者に大きな免疫反応がみられるだろうと、慎重ながらも楽観的に感じられなかったら、私はこの臨床試験に取り組んでいなかっただろう」と付け加えた。 「前臨床データは非常に期待がもてるものだった。感染から保護しておきたい免疫反応である中和抗体応答は確認できているが、このワクチンを評価するにはまだ道のりは長い」 この研究は英政府から4100万ポンド（約54億5500万円）の資金提供を受けている。ほかにも500万ポンド（約6億6500万円）の寄付が寄せられている。 「ウイルスを倒すのに協力したくて志願」 金融業界で働くキャシーさん（39）は、インペリアル･コレッジ･ロンドンの臨床試験に参加している最初のボランティアの1人だ。 新型ウイルスとの戦いの一端を担いたくて志願したという。 「自分に何ができるのかあまりよく分かっていなかったけど、これが私にできることだったと分かった」 「それに、ワクチンができるまで日常に戻れる可能性は低いことを理解したことで、ワクチン開発の一端を担いたいと思った」 キャシーさんは、インペリアル･コレッジ･ロンドンの臨床試験に参加している最初のボランティア300人の1人 こうした中、ケンブリッジ公爵ウィリアム王子はオックスフォード大学の臨床試験に参加しているボランティアたちと、オックスフォード市内のチャーチル病院で面会した。 ウィリアム王子はボランティアに対し、「みなさん全員が参加しているのは、信じられないくらい胸が躍る、非常に待ち望まれたプロジェクトだ。だからみんなが心を奪われている」と述べた。 初日の被験者は1人だけ BBCのファーガス・ウォルシュ医療担当編集委員によると、すべての臨床試験は安全性のリスク軽減のために慎重に、ゆっくり開始される。オックスフォード大学で4月に臨床試験が開始された際には、初日に接種を受けたのはボランティア2人だけで、1週間以内に100人に接種された。 これに対して、インペリアル･コレッジ･ロンドンの臨床試験では初日には1人だけにワクチンを接種する。その後48時間ごとに3人に接種し、徐々に被験者を増やしていく。 また、1回分の投与量を使用するオックスフォード大学とは異なり、インペリアル･コレッジ･ロンドンの臨床試験では4週間の間隔をあけて、2回の接種を行うという。 シャトック教授らのチームは、慎重に進めている理由について、ワクチンに特段の安全性の懸念があるからではなく、単にアプローチが新しいからだと説明している。 新型コロナウイルス特集 感染対策 在宅勤務・隔離生活 （英語記事 Human trial of new coronavirus vaccine starts in UK） 要約の正解データ 新型コロナウイルスの新しいワクチンの臨床試験がイギリスで始まった。インペリアル･コレッジ･ロンドンのロビン・シャトック教授らが率いる試験の一貫で、今後数週間で約300人を対象に実施される。 Google AI Gemini-proによる要約結果 インペリアル・カレッジ・ロンドンは、RNAベースのCOVID-19ワクチンの人間による最初の臨床試験を開始した。このワクチンは動物実験で安全性と免疫反応が実証されており、今後6000人を対象とした第2段階の試験が予定されている。この新しいアプローチは、弱体化したウイルスを使用する従来のワクチンとは異なり、ウイルス表面のスパイクタンパク質をコードするRNAを使用し、免疫システムがウイルスを認識することを訓練する。主任研究員のポロック博士は、前臨床データに期待を寄せており、このワクチンがパンデミックへの対応に革命をもたらす可能性があると述べている。研究チームは、慎重に段階を踏んで試験を進め、ワクチンが安全かつ効果的であることを確認することを目指している。 Vertex AI Gemini proによる要約結果 インペリアルカレッジロンドンの新しいワクチンは、動物実験で安全かつ免疫反応を誘発することが示されました。6000人を対象とした第2段階の臨床試験が計画されており、2021年初頭には配布を目指しています。このワクチンはRNAを使用して、ウイルスの認識を訓練し、免疫システムを構築します。研究者らは、中和抗体応答が確認され、高い免疫反応を期待しています。金融業界のキャシーさんは、ボランティアに参加し、パンデミックの克服に貢献しています。この臨床試験では、慎重に被験者数を増やし、4週間の間隔で2回の接種を行います。安全性上の懸念ではなく、新しいアプローチを慎重に評価するためです。 Vertex AI text-bisonによる要約結果  インペリアル・カレッジ・ロンドンは、新型コロナウイルスに対する新しいワクチンの第1段階の臨床試験を開始しました。このワクチンは、遺伝子のRNA（リボ核酸）を使用しており、筋肉に注射すると、自己増殖して新型ウイルスの表面にみられるスパイクタンパク質のコピーをつくるよう、体内の細胞に指示を出します。この方法で、COVID-19（新型ウイルスによる感染症）を発症することなく新型ウイルスを認識して戦うための免疫システムを訓練できるという。この研究は英政府から4100万ポンド（約5 Vertex AI text-unicornによる要約結果 インペリアル・カレッジ・ロンドンの研究チームは、新型コロナウイルス感染症（COVID-19）のワクチンの臨床試験を開始した。このワクチンは、従来のワクチンとは異なる新しいアプローチで開発されたもので、RNA（リボ核酸）を使う。筋肉に注射すると、RNAは自己増殖し、新型ウイルスの表面にみられるスパイクタンパク質のコピーをつくるよう、体内の細胞に指示を出す。この方法で、COVID-19を発症することなく新型ウイルスを認識して戦 BertScoreが一番良かったtext-unicornモデルの要約が今一つのように思えます。個人的にはGoogle AIのGemini-proモデルの要約が一番良いように感じています。 プロンプト3：以下の文章を3文で要約して プロンプト3をLLMに入力して、類似度を出した結果は以下の図の通りです。 こちらもtext-unicornが最も精度の高い要約を生成したという結果となりました。 また、データセット中の1つのデータに対する要約結果を以下のようにまとめてみました。 元のテキスト このワクチンは複数の動物実験で、安全性や、効果的な免疫反応を引き起こすことが示されている。 今回の第1段階の後には、6000人を対象とした別の臨床試験が今年10月に予定されている。 インペリアル･コレッジ･ロンドンのチームは、2021年の早い時期からイギリスや海外でワクチンを配布できるようにしたいとしている。 ＜関連記事＞ 世界中では約120のワクチンの開発が進められている。英オックスフォード大学の専門家たちはすでに臨床試験を開始している。 新しいアプローチ 多くの従来のワクチンは、弱体化させたウイルスや改変したウイルスなどがもとになっている。しかし今回のワクチンは新しいアプローチに基づいたもので、遺伝子のRNA（リボ核酸）を使う。 筋肉に注射すると、RNAは自己増殖し、新型ウイルスの表面にみられるスパイクタンパク質のコピーをつくるよう、体内の細胞に指示を出す。 この方法で、COVID-19（新型ウイルスによる感染症）を発症することなく新型ウイルスを認識して戦うための免疫システムを訓練できるという。 シャトック教授は、「我々はゼロからワクチンを製造し、わずか数カ月で臨床試験に持ち込むことができた」と述べた。 「我々のアプローチがうまくいって、ワクチンがこの病気を効果的に防御できれば、将来的なアウトブレイク（大流行）への対応方法に革命をもたらす可能性がある」 主任研究員のカトリーナ・ポロック博士は、ワクチンの効果に期待している この研究の主任研究員、カトリーナ・ポロック博士は、「参加者に大きな免疫反応がみられるだろうと、慎重ながらも楽観的に感じられなかったら、私はこの臨床試験に取り組んでいなかっただろう」と付け加えた。 「前臨床データは非常に期待がもてるものだった。感染から保護しておきたい免疫反応である中和抗体応答は確認できているが、このワクチンを評価するにはまだ道のりは長い」 この研究は英政府から4100万ポンド（約54億5500万円）の資金提供を受けている。ほかにも500万ポンド（約6億6500万円）の寄付が寄せられている。 「ウイルスを倒すのに協力したくて志願」 金融業界で働くキャシーさん（39）は、インペリアル･コレッジ･ロンドンの臨床試験に参加している最初のボランティアの1人だ。 新型ウイルスとの戦いの一端を担いたくて志願したという。 「自分に何ができるのかあまりよく分かっていなかったけど、これが私にできることだったと分かった」 「それに、ワクチンができるまで日常に戻れる可能性は低いことを理解したことで、ワクチン開発の一端を担いたいと思った」 キャシーさんは、インペリアル･コレッジ･ロンドンの臨床試験に参加している最初のボランティア300人の1人 こうした中、ケンブリッジ公爵ウィリアム王子はオックスフォード大学の臨床試験に参加しているボランティアたちと、オックスフォード市内のチャーチル病院で面会した。 ウィリアム王子はボランティアに対し、「みなさん全員が参加しているのは、信じられないくらい胸が躍る、非常に待ち望まれたプロジェクトだ。だからみんなが心を奪われている」と述べた。 初日の被験者は1人だけ BBCのファーガス・ウォルシュ医療担当編集委員によると、すべての臨床試験は安全性のリスク軽減のために慎重に、ゆっくり開始される。オックスフォード大学で4月に臨床試験が開始された際には、初日に接種を受けたのはボランティア2人だけで、1週間以内に100人に接種された。 これに対して、インペリアル･コレッジ･ロンドンの臨床試験では初日には1人だけにワクチンを接種する。その後48時間ごとに3人に接種し、徐々に被験者を増やしていく。 また、1回分の投与量を使用するオックスフォード大学とは異なり、インペリアル･コレッジ･ロンドンの臨床試験では4週間の間隔をあけて、2回の接種を行うという。 シャトック教授らのチームは、慎重に進めている理由について、ワクチンに特段の安全性の懸念があるからではなく、単にアプローチが新しいからだと説明している。 新型コロナウイルス特集 感染対策 在宅勤務・隔離生活 （英語記事 Human trial of new coronavirus vaccine starts in UK） 要約の正解データ 新型コロナウイルスの新しいワクチンの臨床試験がイギリスで始まった。インペリアル･コレッジ･ロンドンのロビン・シャトック教授らが率いる試験の一貫で、今後数週間で約300人を対象に実施される。 Google AI Gemini-proによる要約結果 インペリアル・カレッジ・ロンドンが開発したCOVID-19ワクチンは、動物実験で有効性が確認されており、現在第1段階の臨床試験が行われています。このワクチンは従来の方法とは異なり、RNAを使用してスパイクタンパク質の生成を誘導し、免疫システムを訓練します。研究者は、早ければ2021年初頭からワクチンを配布することを目指しています。 Vertex AI Gemini-proによる要約結果 インペリアル・カレッジ・ロンドンの新しい新型コロナウイルスワクチンは、動物実験で安全で効果的であることが示されています。2021年早々に配布可能となることを目指し、6,000人を対象とした臨床試験が予定されています。このワクチンは、遺伝子のRNAを使用して免疫システムを訓練し、将来的にアウトブレイクに対応する方法に革命をもたらす可能性があります。 Vertex AI text-bisonによる要約結果 インペリアル・カレッジ・ロンドンは、新型コロナウイルスのワクチンの人間に対する臨床試験を開始した。 このワクチンは、遺伝子のRNA（リボ核酸）を使用しており、筋肉に注射すると、自己増殖し、新型ウイルスの表面にみられるスパイクタンパク質のコピーをつくるよう、体内の細胞に指示を出す。 臨床試験には、300人のボランティアが参加し、4週間の間隔をあけて2回の接種を行う。 Vertex AI text-unicornによる要約結果 インペリアル・カレッジ・ロンドンで、新型コロナウイルスワクチンの臨床試験が開始された。このワクチンは、従来のワクチンとは異なる新しいアプローチで開発されたもので、RNA（リボ核酸）を使う。臨床試験は、安全性を確認するために慎重に進められている。 BertScoreの結果の通り、text-unicornモデルの要約が一番良いように思えます。 プロンプト間での比較 プロンプト間で比較してみるとプロンプト3「以下の文章を3文で要約して」が最もよい結果となりました。文字数で指定するよりも、文の数を指定したほうが少し精度が上がるのかもしれません。   まとめ 本記事では、GoogleのLLMを用いたテキスト要約タスクにおける性能比較検証を行いました。自動評価指標であるBertScoreを用いた評価において、Text-Unicornは高い精度を示しました。また、プロンプトに文の数を指定することで、どのモデルにおいても要約精度がわずかに向上することが確認されました。これは、文の数を指定することで、要約すべき内容をより明確に理解できるためと考えられます。 しかし、実際に生成された要約を見てみると、Text-Unicornの要約は必ずしも最適とは言えないことがわかりました。これは、BertScoreと人間の評価基準が必ずしも一致していないことを示唆しています。人間の評価基準に沿った要約生成においては、Google AIのGemini-proが優れているように思えます。 以上の結果から、AI評価と人間の評価の間には乖離が存在することが明らかになりました。これは、AIモデルの開発において、人間の評価を考慮することが重要であると思います。 今回の検証では、GoogleのLLMの性能比較という限定的な結果しか得られませんでした。今後は、AI評価と人間の評価の乖離についても考慮しつつ、より多くのモデルおよびプロンプトを比較検討することで、タスクごとに最適なモデルおよびプロンプトを決定できるようにしたいと考えています。 最後までご覧いただきありがとうございました。

こんにちは、SCSKのひるたんぬです。 もう4月になりますね…2024年度の幕開けです。 昨年の4月に新入社員としてSCSKに入社し社会人デビューをした身としては、あっという間の一年だったなぁ…と思うと同時に、「もう後輩が来るんですか！？」というのが正直なところです。少しでも先輩らしい(？)振る舞いができるようになりたいものです。 今回は、仕事上…というよりもプライベートで取り組んでみたことについてご紹介いたします。 背景 私は学生時代の友人と、「まれによく¹」Minecraftをして遊びます。 学生時代はサーバやインフラに関する知識などは全くと言っていいほどなかったため、 月額固定料金のサーバを契約 → Minecraftサーバとしての初期設定 → 一定期間遊ぶ → 飽きる → 解約する を繰り返していました。この「まれによく」という頻度がくせ者でして、 よく遊ぶ…固定料金を契約して好きなだけ遊ぶ まれに遊びたくなる…その気持ちをこらえて、忘却を待つ とできないのです。皆さんも今回の話に限らず、このようなことありませんか…？ ある日、私がクラウド関係の仕事をしていると友人に話したところ、 マイクラ(Minecraft)って、急に無性に遊びたくなるんだよねぇ… 今までみたいに いちいち契約して設定して使うっていうのは面倒くさい・時間かかる し、かと言って ずーーっと契約して遊ぶほどでもないんだよね。お金の無駄だし。 なんとかならない？？ ※若干脚色しております。 …なんとわがままなのでしょうか。 しかし、言っていることはごもっともであり、そういうことなら何か仕組みを作ってみよう！ということで、今回の取り組みが幕を開けました。 ¹ 「まれによく」という言葉は正しい日本語ではないですが、この頻度を適切に表す表現が他に見当たらないためこの表現を用いています。 こちらの図解 「1. よくある(頻発する)ことが稀に起こる状態」が私が表現したい頻度です。   取り組み概要 今回は「 友人と普段の通話やチャットで用いている Discord 」と「 私が業務で触れている AWS 」を組み合わせて、先程の友人のわがままを叶えようと考えました。調べたところ、既に同様のことに取り組まれている方々がおり、それらを参考に以下のようなアーキテクチャを構築しました。 ここでの特徴は 「Lambdaが多段構成」となっている 点です。このようにすることで、EC2に関する処理に時間がかかってもタイムアウトとなることを防いでいます。 もう少し詳しく説明いたします。 通常は下図に示すアーキテクチャが一般的だと思われます。 こちらの場合ですと、「App」のLambdaがServerとのやり取りをし、その結果をAPI Gateway経由でDiscordに返すという処理の流れになります。しかし、Discordのドキュメントを確認すると、 Interaction  tokens  are valid for  15 minutes  and can be used to send followup messages but you  must send an initial response within 3 seconds of receiving the event . If the 3 second deadline is exceeded, the token will be invalidated. 引用元：Discord Developper Potal 「 Interactions: Receiving and Responding 」 と記載があります。つまり、 Discordに対して3秒以内に一度応答を返さないとエラーになってしまう のです。そのため、通常の構成ですとEC2の起動や終了の命令を出すことはできても、EC2側においてそれらの処理が正常に完了したかを確認する時間がありません。 そこで、最初に示したようにLambdaを多段構成にすることで、「App」が対応するLambdaを非同期で呼び出し、仮の応答(ACK)をDiscordに返します。そして、対応するLambdaがそれぞれの処理を実行し、メッセージを更新するという形で仮の応答を更新します。これにより、タイムアウトのエラーを防ぎ、適切な応答を返すことができるようになります。 記事の構成上、参考サイト等は記事の末尾に記載しております。   構築手順 ここからはアーキテクチャの構築手順について、Discord Botの作成からAWSでのリソース構築までを画像での解説を交えながら順に説明いたします。 少々長い内容とはなりますが、最後までお付き合いいただけますと幸いです。 Discord Botの作成 Discord Developer Portal にアクセス 「New Application」を押下し、Botのアカウント名を入力し「Create」を押下する。 遷移先の画面（General Infomation）にて、 ・APPLICATION ID ・PUBLIC KEY を控えておく。 左ペインより「Bot」を選択し、「Reset Token」を押下してトークンを発行する。 発行されたトークンを控えておく。                        このタイミングで「USERNAME」を編集しても問題ありません。 ここで設定する名前が、Discordの表示名となります。 発行されたトークンは画面遷移などにより再表示できなくなる場合があるので、発行したタイミングで必ず控えておくようにしてください。 控え忘れてしまった場合は再度「Reset Token」を押下してトークンを発行してください。 スラッシュコマンドの登録 実際にDiscordからBotを呼ぶ際に、多くの方は「/XXXXX」という形式でコマンドを入力すると思います。 今回作成するBotもこのような形で利用するため、コマンドの登録を行います。 以下のコードの「認証情報」を自身の情報に置換した上、Python（実行環境は問いません）で実行してください。 “Registration Completed!!”と表示されれば正常に処理が行われています。                                       # register-slash-commands.py import requests import json # 認証情報 BOT_ACCESS_TOKEN = "トークンを記載" APPLICATION_ID = "APPLICATION IDを記載" commands = {   "name": "server",   "description": "EC2の起動状態を管理します",   "options": [       {           "name": "action",           "description": "開始(start)・停止(stop)・状態確認(status)",           "type": 3,           "required": True,           "choices": [               {"name": "start", "value": "start"},               {"name": "stop", "value": "stop"},               {"name": "status", "value": "status"},           ],       },   ], } def main():   url = f"https://discord.com/api/v10/applications/{APPLICATION_ID}/commands"   headers = {       "Authorization": f'Bot {BOT_ACCESS_TOKEN}',       "Content-Type": "application/json",   } try: res = requests.post(url, headers=headers, data=json.dumps(commands)) res.raise_for_status() print("Registration Completed!!") except Exception as e: print("Error occurred.", e) if __name__ == "__main__": main()   リソースの構築 事前準備 今回は前提条件として、サーバとなるEC2インスタンスは既に作成されているものとします。 そのため、この時点でEC2インスタンスを作成していない方は作成してください。 今回の要件においては、EC2インスタンスを作成するのみで問題ありません。 サーバとしての設定等は不要です。 また、下記に示す4つのPythonコードを指定名で保存し、一つのzipファイルに圧縮してください。zipファイル名は任意です。 そして、そのzipファイルを適当なS3バケットにアップロードしてください。 ※…コメントアウト等で処理内容を残すべきですが、コードの量が多いため削除しております。 # ファイル名 -> app.py import os import json import boto3 import logging from nacl.signing import VerifyKey logger = logging.getLogger() logger.setLevel("INFO") def lambda_handler(event: dict, context: dict):   try:       headers: dict = {k.lower(): v for k, v in event["headers"].items()}       rawBody: str = event.get("body", "")       signature: str = headers.get("x-signature-ed25519", "")       timestamp: str = headers.get("x-signature-timestamp", "")       if not verify(signature, timestamp, rawBody):           return {               "cookies": [],               "isBase64Encoded": False,               "statusCode": 401,               "headers": {},               "body": "",           }       req: dict = json.loads(rawBody)       if req["type"] == 1:           return {"type": 1}       elif req["type"] == 2:           action = req["data"]["options"][0]["value"]           if action == "start":               token = req.get("token", "")               parameter = {                   "token": token,                   "DISCORD_APP_ID": os.environ["APPLICATION_ID"],               }               payload = json.dumps(parameter)               boto3.client("lambda").invoke(                   FunctionName="DiscordSlashCommandController-Start",                   InvocationType="Event",                   Payload=payload,               )           elif action == "stop":               token = req.get("token", "")               parameter = {                   "token": token,                   "DISCORD_APP_ID": os.environ["APPLICATION_ID"],               }               payload = json.dumps(parameter)               boto3.client("lambda").invoke(                   FunctionName="DiscordSlashCommandController-Stop",                   InvocationType="Event",                   Payload=payload,               )           elif action == "status":               token = req.get("token", "")               parameter = {                   "token": token,                   "DISCORD_APP_ID": os.environ["APPLICATION_ID"],               }               payload = json.dumps(parameter)               boto3.client("lambda").invoke(                   FunctionName="DiscordSlashCommandController-Status",                   InvocationType="Event",                   Payload=payload,               )           else:               Exception("Unexpected Command")       return {           "type": 5,       }   except Exception as e:       logger.error(str(e))       return e def verify(signature: str, timestamp: str, body: str) -> bool:   PUBLIC_KEY = os.environ["PUBLIC_KEY"]   verify_key = VerifyKey(bytes.fromhex(PUBLIC_KEY))   try:       verify_key.verify(           f"{timestamp}{body}".encode(), bytes.fromhex(signature)       )   except Exception as e:       logger.warning(f"failed to verify request: {e}")       return False   return True # ファイル名 -> start.py import os import json import requests import boto3 import logging logger = logging.getLogger() logger.setLevel("INFO") def lambda_handler(event, context):   logger.info("Starting script")   instance_id = os.environ["INSTANCE_ID"]   result = start_ec2(instance_id)   application_id = event["DISCORD_APP_ID"]   interaction_token = event["token"]   message = {}   if result["status"] == 1:       message = {"content": "Server is already running\n```\n{}\n```".format(result["ip"])}   elif result["status"] == 0:       message = {"content": "Server becomes ready!\n```\n{}\n```".format(result["ip"])}   elif result["status"] == 2:       message = {"content": "Starting instance process failed"}   else:       message = {"content": "Unexpected error at starting process"}   payload = json.dumps(message)   r = requests.post(       url=f"https://discord.com/api/v10/webhooks/{application_id}/{interaction_token}",       data=payload,       headers={"Content-Type": "application/json"},   )   logger.debug(r.text)   logger.info("Finished starting script")   return r.status_code def start_ec2(instance_id: str) -> dict:   try:       logger.info("Starting instance: " + str(instance_id))       region = os.environ["AWS_REGION"]       ec2_client = boto3.client("ec2", region_name=region)       status_response = ec2_client.describe_instances(InstanceIds=[instance_id])       if (status_response["Reservations"][0]["Instances"][0]["State"]["Name"] == "running"):           logger.info("Instance is already running: " + str(instance_id))           return {"status": 1, "ip": get_public_ip(status_response)}       else:           logger.info("Start instance: " + str(instance_id))           response = ec2_client.start_instances(InstanceIds=[instance_id])           logger.debug(response)           logger.info("Waiting for Instance to be ready: " + str(instance_id))           try:               waiter_running = ec2_client.get_waiter("instance_running")               waiter_status = ec2_client.get_waiter("instance_status_ok")               waiter_running.wait(InstanceIds=[instance_id])               waiter_status.wait(InstanceIds=[instance_id])               logger.info("Starting instance: " + str(instance_id))               return {"status": 0, "ip": get_public_ip(ec2_client.describe_instances(InstanceIds=[instance_id]))}           except Exception as e:               logger.error("Starting instance process failed.")               logger.error(str(e))               return {"status": 2}   except Exception as e:       logger.error(str(e))       return {"status": 3} def get_public_ip(response: dict) -> str:   try:       ip_address = response["Reservations"][0]["Instances"][0]["PublicIpAddress"]   except KeyError as e:       logger.warning("Failed Extract ip address.")       ip_address = "XXX.XXX.XXX.XXX"   except Exception as e:       logger.error(str(e))       ip_address = "XXX.XXX.XXX.XXX"   return ip_address # ファイル名 -> stop.py import os import json import requests import boto3 import logging logger = logging.getLogger() logger.setLevel("INFO") def lambda_handler(event, context):   logger.info("Starting script")   instance_id = os.environ["INSTANCE_ID"]   result = stop_ec2(instance_id)   application_id = event["DISCORD_APP_ID"]   interaction_token = event["token"]   message = {}   if result["status"] == 1:       message = {"content": "Server is already stopped"}   elif result["status"] == 0:       message = {"content": "Server stopped!"}   else:       message = {"content": "Unexpected error at stopping process"}   payload = json.dumps(message)   r = requests.post(       url=f"https://discord.com/api/v10/webhooks/{application_id}/{interaction_token}",       data=payload,       headers={"Content-Type": "application/json"},   )   logger.debug(r.text)   logger.info("Finished stopping script")   return r.status_code def stop_ec2(instance_id: str) -> None:   try:       logger.info("Stopping instance: " + str(instance_id))       region = os.environ["AWS_REGION"]       ec2_client = boto3.client("ec2", region_name=region)       status_response = ec2_client.describe_instances(InstanceIds=[instance_id])       if (status_response["Reservations"][0]["Instances"][0]["State"]["Name"] == "stopped"):           logger.info("Instance is already stopped: " + str(instance_id))           return {"status": 1}       else:           logger.info("Stop instance: " + str(instance_id))           response = ec2_client.stop_instances(InstanceIds=[instance_id])           logger.debug(response)           logger.info("Waiting for Instance to be stopped: " + str(instance_id))           try:               waiter_stopped = ec2_client.get_waiter("instance_stopped")               waiter_stopped.wait(InstanceIds=[instance_id])               logger.info("Stopped instance: " + str(instance_id))               return {"status": 0}           except Exception as e:               logger.error("Stopping instance process failed.")               logger.error(str(e))               return {"status": 2}   except Exception as e:       logger.error(str(e))       return {"status": 3} # ファイル名 -> status.py import os import json import requests import boto3 import logging logger = logging.getLogger() logger.setLevel("INFO") def lambda_handler(event, context):   logger.info("Starting script")   instance_id = os.environ["INSTANCE_ID"]   result = status_ec2(instance_id)   application_id = event["DISCORD_APP_ID"]   interaction_token = event["token"]   message = {}   if result["status"] == 1:       message = {"content": "Server: Stopped"}   elif result["status"] == 0:       message = {"content": "Server: Running\n```\n{}\n```".format(result["ip"])}   elif result["status"] == 2:       message = {"content": "Server: Pending"}   elif result["status"] == 3:       message = {"content": "Unexpected instance status"}   else:       message = {"content": "Unexpected error at status check process"}   payload = json.dumps(message)   r = requests.post(       url=f"https://discord.com/api/v10/webhooks/{application_id}/{interaction_token}",       data=payload,       headers={"Content-Type": "application/json"},   )   logger.debug(r.text)   logger.info("Finished status checking script")   return r.status_code def status_ec2(instance_id: str) -> None:   result = {}   try:       region = os.environ["AWS_REGION"]       ec2_client = boto3.client("ec2", region_name=region)       status_response = ec2_client.describe_instances(InstanceIds=[instance_id])       status = status_response["Reservations"][0]["Instances"][0]["State"]["Name"]       if (status == "running"):           logger.info("Instance is running: " + str(instance_id))           result["status"] = 0           result["ip"] = status_response["Reservations"][0]["Instances"][0]["PublicIpAddress"]       elif (status == "stopping" or status == "stopped"):           logger.info("Instance is stoppping: " + str(instance_id))           result["status"] = 1       elif (status == "pending"):           logger.info("Instance is pending: " + str(instance_id))           result["status"] = 2       else:           logger.warning("Unexpected instance status")           result["status"] = 3       return result   except Exception as e:       logger.error(str(e))       result["status"] = 4       return result アップロード後、zipファイルのオブジェクトを開き、キーを控えておいてください。     Layerの作成 先ほどのLambda関数において、外部ライブラリを使用します。 それにあたり、必要なパッケージを用意します。 私はCloud9にてPython 3.12を使用し作成しました。 そのため、デプロイするLambdaのランタイムもPython 3.12にしてあります。 下記引用に記載があるように、Lambdaのレイヤー作成にはLinux環境が必要です。 Windowsやmac OSでレイヤーファイルを作成した場合、Lambdaが動作しないケースがあります。 ※…私はWindowsで作成してしまい、一度引っかかりました。 The first step to creating a layer is to bundle all of your layer content into a .zip file archive. Because Lambda functions run on  Amazon Linux , your layer content must be able to compile and build in a Linux environment. If you build packages on your local Windows or Mac machine, you’ll get output binaries for that operating system by default. These binaries may not work properly when you upload them to Lambda. 引用元：AWS Lambda Document「 Packaging your layer content 」※…日本語版は機械翻訳のため、英語版サイトから引用しています。 カレントディレクトリ上に「requirements.txt」を作成します。テキストファイル内には以下を入力してください。 PyNaCl==1.5.0 requests urllib3<2 以下のコマンドを実行します。 $ mkdir python $ pip install -r requirements.txt -t ./python $ zip -r9 layer.zip python カレントディレクトリに「layer.zip」ができていることを確認し、そのzipファイルを適当なS3バケットにアップロードしてください。アップロード後、コードと同様にzipファイルのオブジェクトを開き、キーを控えておいてください。 レイヤーファイルのアップロード場所は、先程コードをアップロードしたバケットと同一でも問題ありません。 CloudFormationによる構築 今回構築するAPI Gateway, Lambda, IAMのCloudFormationテンプレートを用意しました。 以下のYAMLファイルを使用し、リソースをデプロイしてください。 パラメータには ApplicationID…Discord Bot作成時の「APPLICATION ID」 CodeS3BucketName…事前準備で格納したコードの宛先S3バケット名 CodeS3Key…コードのキー EC2InstanceID…制御したいEC2インスタンスのID LayerS3BucketName…事前準備で格納したレイヤーの宛先S3バケット名 LayerS3Key…レイヤーのキー PublicKey…Discord Bot作成時の「PUBLIC KEY」 をそれぞれ入力してください。 AWSTemplateFormatVersion: 2010-09-09 Parameters: ApplicationID:   Type: String PublicKey:   Type: String EC2InstanceID:   Type: String CodeS3BucketName:   Type: String CodeS3Key:   Type: String LayerS3BucketName:   Type: String LayerS3Key:   Type: String Resources: # API Gateway ControlAPIGateway:   Type: AWS::ApiGatewayV2::Api   Properties:     Name: DiscordSlashCommandController-Api     ProtocolType: HTTP ControlAPIGatewayIntegration:   Type: AWS::ApiGatewayV2::Integration   Properties:     ApiId: !Ref ControlAPIGateway     IntegrationType: AWS_PROXY     IntegrationUri: !GetAtt AppFunction.Arn     PayloadFormatVersion: 2.0 ControlAPIGatewayRoute:   Type: AWS::ApiGatewayV2::Route   Properties:     ApiId: !Ref ControlAPIGateway     RouteKey: POST /     Target: !Sub integrations/${ControlAPIGatewayIntegration} ControlAPIGatewayStage:   Type: AWS::ApiGatewayV2::Stage   Properties:     ApiId: !Ref ControlAPIGateway     StageName: $default     AutoDeploy: true # Lambda layer LambdaLayer:   Type: "AWS::Lambda::LayerVersion"   Properties:     CompatibleRuntimes:       - python3.12     Content:       S3Bucket: !Ref LayerS3BucketName       S3Key: !Ref LayerS3Key     LayerName: DiscordSlashCommandController-Layer # Lambda function AppFunction:   Type: AWS::Lambda::Function   Properties:     Code:       S3Bucket: !Ref CodeS3BucketName       S3Key: !Ref CodeS3Key     Handler: app.lambda_handler     Runtime: python3.12     FunctionName: DiscordSlashCommandController-App     Layers:       - !Ref LambdaLayer     MemorySize: 1024     Timeout: 10     Environment:       Variables:         PUBLIC_KEY: !Ref PublicKey         APPLICATION_ID: !Ref ApplicationID     Role: !GetAtt LambdaExecutionRole.Arn StartFunction:   Type: AWS::Lambda::Function   Properties:     Code:       S3Bucket: !Ref CodeS3BucketName       S3Key: !Ref CodeS3Key     Handler: start.lambda_handler     Runtime: python3.12     FunctionName: DiscordSlashCommandController-Start     Layers:       - !Ref LambdaLayer     MemorySize: 1024     Timeout: 600     Environment:       Variables:         INSTANCE_ID: !Ref EC2InstanceID     Role: !GetAtt LambdaExecutionRole.Arn StopFunction:   Type: AWS::Lambda::Function   Properties:     Code:       S3Bucket: !Ref CodeS3BucketName       S3Key: !Ref CodeS3Key     Handler: stop.lambda_handler     Runtime: python3.12     FunctionName: DiscordSlashCommandController-Stop     Layers:       - !Ref LambdaLayer     MemorySize: 1024     Timeout: 60     Environment:       Variables:         INSTANCE_ID: !Ref EC2InstanceID     Role: !GetAtt LambdaExecutionRole.Arn StatusFunction:   Type: AWS::Lambda::Function   Properties:     Code:       S3Bucket: !Ref CodeS3BucketName       S3Key: !Ref CodeS3Key     Handler: status.lambda_handler     Runtime: python3.12     FunctionName: DiscordSlashCommandController-Status     Layers:       - !Ref LambdaLayer     MemorySize: 1024     Timeout: 10     Environment:       Variables:         INSTANCE_ID: !Ref EC2InstanceID     Role: !GetAtt LambdaExecutionRole.Arn # Lambda execution log groups AppFunctionLogGroup:   Type: AWS::Logs::LogGroup   Properties:     LogGroupName: !Sub /aws/lambda/${AppFunction}     RetentionInDays: 30 StartFunctionLogGroup:   Type: AWS::Logs::LogGroup   Properties:     LogGroupName: !Sub /aws/lambda/${StartFunction}     RetentionInDays: 30 StopFunctionLogGroup:   Type: AWS::Logs::LogGroup   Properties:     LogGroupName: !Sub /aws/lambda/${StopFunction}     RetentionInDays: 30 StatusFunctionLogGroup:   Type: AWS::Logs::LogGroup   Properties:     LogGroupName: !Sub /aws/lambda/${StatusFunction}     RetentionInDays: 30 # Lambda invoke permission ApiGWInvokeAppFunction:   Type: AWS::Lambda::Permission   Properties:     Action: lambda:InvokeFunction     FunctionName: !GetAtt AppFunction.Arn     Principal: apigateway.amazonaws.com     SourceArn: !Sub arn:aws:execute-api:${AWS::Region}:${AWS::AccountId}:${ControlAPIGateway}/*   # Lambda IAM Role LambdaExecutionRole:   Type: AWS::IAM::Role   Properties:     AssumeRolePolicyDocument:       Version: 2012-10-17       Statement:         - Action: sts:AssumeRole           Effect: Allow           Principal:             Service: lambda.amazonaws.com     Policies:       - PolicyDocument:           Version: 2012-10-17           Statement:             - Action:                 - lambda:InvokeFunction                 - ec2:DescribeInstances                 - ec2:DescribeInstanceStatus                 - ec2:StopInstances                 - ec2:StartInstances               Effect: Allow               Resource: "*"         PolicyName: IPL-DiscordSlashCommandController     ManagedPolicyArns:       - "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"     RoleName: IRL-DiscordSlashCommandController Outputs: EndpointURL:   Value: !Sub https://${ControlAPIGateway}.execute-api.${AWS::Region}.${AWS::URLSuffix}/ 構築が完了すると、出力にエンドポイントのURLがありますので、そちらを控えておきます。 Discord Botの利用 Discord Developer Portal に再びアクセスし、先程作成したApplicationをクリックします。 中段にある「INTERACTIONS ENDPOINT URL」に、先程控えたエンドポイントURLを貼り付けます。 「Save Changes」を押下すると、接続テストが行われ正常に疎通確認が取れるとエンドポイントURLが保存されます。 ここで何かしらのエラーが出る場合は、APIが正常に構築できていない・貼り付け先のBOTを間違えている可能性があります。 Botの招待 左ペインより「OAuth2」を選択し、下段「OAuth2 URL Generator – SCOPES」から「bot」と「applications.commands」にチェックを入れます。その後、その下に表示されている「GENERATED URL」をコピーします。 コピーしたURLにアクセスして、サーバーにBotを招待します。 Botをサーバへ招待するには、サーバの管理者など「サーバ管理権限」を持つアカウントでの操作が必要です。 動作確認 Botが招待されたサーバのテキストチャンネルにて、スラッシュコマンドを入力します。 下記画像では「/server」を入力したあとに、コマンドの候補や説明が適切に表示されていることが分かります。 それぞれのコマンド（start, stop, status）を入力し、所望の応答が得られることを確認します。 コマンド入力直後（共通） サーバ開始時（/server start） サーバ終了時（/server stop） サーバステータス確認時（/server status） IPアドレス欄のみコードブロックにて独立して配置することで、IPアドレスのコピーを容易にしています。   参考サイト 今回の実装にあたり、以下のサイトを参考にさせていただきました。 構成や実際のコードを参考にいたしました。 discord の slash commands からEC2を操作できるようにしてみた - Qiita はじめにはじめまして、@nahiro_tus です。突然ですが、皆さんはdiscordのslash commands機能をご存知ですか？… qiita.com 応答方法の処理について参考にいたしました。 Discord Interaction Endpoint を多段 Lambda 構成にしてタイムアウトを回避する | DevelopersIO 前回の記事の続きです。 Discord の Interaction Endpoint は仕様上、Interaction リクエストから応答までに制限時間が設けられています。 制限時間を超えてしまう場合は、一旦仮の応答を返 … dev.classmethod.jp Discord Developer Portal — API Docs for Bots and Developers Integrate your service with Discord — whether it's a bot or a game or whatever your wildest imagination can come up with... discord.com Layerを作成する際に参考にいたしました。 AWS Lambda (Python 3.12) で使用可能な pandas の Lambda Layer を準備する データ分析や加工でよく使われるライブラリに、pandas があると思います。本記事では、AWS Lambda (Python 3.12) で動作する pandas の Lambda Layer を準備する手順を紹介します。 blog.usize-tech.com 2022.06.07 Lambda+PythonでLayerを使うときにハマったこと | ドクセル ドクセルはスライドやPDFをかんたんに共有できるサイトです www.docswell.com CloudFormationテンプレートを作成する際に参考にいたしました。 Amazon API Gateway と AWS Lambda の連携でもうハマりたくない [AWS CloudFormation テンプレート付き] Amazon API Gateway と AWS Lambda の連携がうまくできず時間を浪費してしまう方は結構いらっしゃるのではないかと思います。Amazon API Gateway のタイプや AWS Lambda との統合の仕方によって AWS Lambda 関数のコードも変わるので厄介です。私はそこでハマるのが嫌で、Amazon API Gateway と AWS Lambda 関数の標準設定パターンを決めて使い回ししています。 blog.usize-tech.com 2022.04.11 この他にも、API GatewayやLambdaのCloudFormationに関するドキュメント、Discord Developer Potalの公式ドキュメントも参考にしております。   終わりに 今回は、インフラのことを知らない人でもDiscord上から簡単にEC2インスタンスの開始・停止を行うための仕組みをご紹介いたしました。インスタンスを使いたい人が自分の好きなタイミングで開始や停止ができるので、運用面や費用面でも大きなメリットがあるのではないかなと思っております。 個人的にも一からこのような仕組みを構築することができ、達成感や学ぶことが多くありました。 （アイデアやコードは多くのサイトを参考にさせていただきました。） とても長くなってしまいましたが、最後までご覧いただきありがとうございました！ 余談：私はDiscordやVS Codeをライトテーマで使うタイプです。

こんにちは、SCSKでAWSの内製化支援『 テクニカルエスコートサービス 』を担当している貝塚です。 以前、AWSのVPC上で双方向1対1NATを実現するという記事を書きました。 AWSで双方向1対1NATインスタンスを構築する AWS環境でNATが必要なとき、NAT Gatewayなどのマネージドサービスが用意されていますが、双方向のNATが行えないなどの制約があります。双方向(SNAT, DNAT)での1対1NATを実現したい場合には、EC2でNAT用のインスタンスを構築することがひとつのソリューションとなりえるでしょう。本記事では、iptablesを使用した双方向NAT用インスタンスの構築手順を説明します。 blog.usize-tech.com 2024.01.04 今回は、オンプレミスもからんだ、やや複雑な環境で2社間をNATして接続することを考えてみます。 接続要件 接続要件は下図の通りです。 Direct Connect接続構成 A社オンプレミス環境とB社オンプレミス環境を接続したいとします。A社はAWSのアカウントを持っており、既にDirect Connectで接続しています。Direct ConnectはVPCのひとつに、仮想プライベートゲートウェイ経由で関連付けされています。 一方、B社はAWSアカウントを持っていません。キャリアの閉域網を契約しており、そのサービスの一つに閉域網とAWSを接続するサービスがあるので、それを使ってAWSアカウントに接続することができます。B社はAWSアカウントを取得する予定がないため、A社の管理するAWSアカウントにPrivate VIFで接続することを希望しています。(※) ※Transit VIFが出せないので、Direct Connect – Direct Connect Gateway – Transit Gateway という構成は取れないということです。 通信要件 通信要件は大きくふたつ、以下の通りです。 １．A社オンプレミス上のクライアントからB社オンプレミス上のサーバへの通信(通信要件(1)) TCPを用いて、A社 → B社のコネクションが発生します。 ２．A社AWSアカウント上のクライアント兼サーバとB社オンプレミス上のクライアント兼サーバの通信(通信要件(2)) TCPを用いて、A社 → B社、B社 → A社の両方のコネクションが発生します。 NAT要件 B社は、A社のIPアドレスを隠蔽して、B社の指定するIPアドレス(10.129.0.0/16)にNATしてもらいたいという要件があります。 A社も、B社のIPアドレスがA社で既に使用しているレンジであれば当然NATをする必要がありますが、調査の結果、B社の使用するIPアドレスはA社では使用していないと判明したため、B社のIPアドレスは隠蔽しないことにしました。 ソリューション A社を支援する立場で構築した環境は下図の通りです。 既存VPCの仮想プライベートゲートウェイAにB社のDirect Connectを接続するのは問題があると考え、B社接続専用の新規VPCを構成し、仮想プライベートゲートウェイBとB社Direct Connectを関連付ける設計としています。 NAT要件は、EC2のLinuxインスタンスでiptablesを使用したNATインスタンスを構築することにより満たすことにしました。一見、NAT Gatewayでも要件を満たせるように思えますが、NAT GatewayではB社からA社へコネクションを開始する通信要件(通信要件(2))が満たせません。 既存VPCと新規VPCはTransit Gatewayで接続します。VPC間接続というとVPC Peeringが思い浮かびますが、VPC PeeringだとNAT構成がより複雑になってしまうという点と、Transit Gateway構成にしておくと将来的にInspection VPCを導入してセキュリティを強化するという選択肢が増えるため、Transit Gatewayを選択しました。 また、この構成ではA社オンプレからB社オンプレや新規VPCに直接通信することができないので、既存VPCにNetwork Load Balancerをはさむことでこの問題を解決しています。 以下、このような設計とした意図を解説します。 Direct Connectの接続ポイント 以下の図のような、仮想プライベートゲートウェイAにB社ダイレクトコネクトのVIFを関連付ける構成を考えてみます。 Network Load Balancerを経由してA社オンプレとB社オンプレを接続する理由は別項で解説することにして、まずはB社Direct Connectを仮想プライベートゲートウェイAに関連付けることの良し悪しについて検討します。 この構成の場合、B社側の設定ミス等により、例えばデフォルトルート(0.0.0.0/0)などをA社にアドバタイズできてしまいます。その場合、A社オンプレとA社AWS環境間の通信に問題が発生する可能性があります。 また、仮想プライベートゲートウェイAは既存VPCのCIDR全体をB社にアドバタイズしてしまいます。そのため、B社から、A社既存VPC上の、今回の通信要件と関係のないサーバに通信を試みることができます。ネットワークACLを使用することで上手く制御できるかもしれませんが、セキュリティ管理上の難易度が高くなってしまいます。 以上の理由から、B社Direct Connectを収容するための専用のVPCを構成する設計としました。(前項『ソリューション』の図参照) この構成であれば、B社側からデフォルトルートがアドバタイズされてきたとしても経路を持ってしまうのは仮想プライベートゲートウェイBだけですから、既存VPCとA社オンプレの通信に影響が出ることはありません。 NATインスタンス NAT要件を満たすために、A社新規VPCにNAT機能を有するデバイスを配置します。 A社 → B社 方向の通信を考えると、A社のアドレスさえ隠蔽できればよく(送信元NAT, SNAT)、A社側からはB社のIPアドレスに通信すればよいので、NAT Gatewayで通信要件を満たせるように見えます。 しかし、通信要件(2)はB社 → A社 方向のコネクションも発生します。NAT Gatewayの提供する機能はN対1 NAT(IPマスカレード)と呼ばれるものなので、B社からNAT GatewayのIPアドレスに通信を試みても、A社内のサーバと通信することはできません。 以上の理由から、EC2を用いて独自にNAT用のインスタンスを作成することにしました。(※) ※ここで言うNAT用のインスタンスは、 AWSが過去にNATインスタンスと呼んでいたもの のことではありません。AWSがNATインスタンスと呼んでいたものは既にAMIのサポートが終了しており、また、基本的にはNAT Gatewayと同様にN対1 NAT(IPマスカレード)の機能提供を前提にしているため、本件の用途に向きません。 LinuxのEC2インスタンスを使用して双方向のコネクションに対応したNATインスタンスを作成する方法については、以下の記事を参考にしてください。 AWSで双方向1対1NATインスタンスを構築する AWS環境でNATが必要なとき、NAT Gatewayなどのマネージドサービスが用意されていますが、双方向のNATが行えないなどの制約があります。双方向(SNAT, DNAT)での1対1NATを実現したい場合には、EC2でNAT用のインスタンスを構築することがひとつのソリューションとなりえるでしょう。本記事では、iptablesを使用した双方向NAT用インスタンスの構築手順を説明します。 blog.usize-tech.com 2024.01.04 VPC間接続(Transit Gateway) 既存VPCと新規VPCを接続する必要があります。まずはVPC Peeringで接続することを検討してみます。VPC Peeringは無料で使用できるので、要件に合うのであればVPC Peeringを採用したいところです。 VPC Peeringの特徴は、接続したVPC同士の経路情報しか持っていない点です。この図でいうと、既存VPCと新規VPCの通信はできますが、既存VPCとB社オンプレは直接通信できません。VPC PeeringがB社オンプレへの経路を持っていないからです。 これに対処する方法としては、NATインスタンスでB社オンプレのIPアドレスを隠蔽するようにNATを設定し、A社からは新規VPC上のIPアドレス(10.129.0.0/16)と通信しているように見せかけるというものがあります。 この構成を採用してもよいのですが、せっかく通信要件・NAT要件を整理した結果、B社オンプレのIPアドレスを隠蔽する必要はないという結論に至ったのに、結果としてB社オンプレのIPアドレスを隠蔽するNATを導入することになります。運用面・障害対応面から見た場合、構成はできるだけシンプルにしたいので、この構成は検討の余地があります。 また、VPC Peeringの制約事項としてよく言われることですが、二つのVPCを接続するごとに一つのVPC Peeringを設定する必要があります。この図では必要なVPC Peeringの数は1ですが、他のVPC(図に書いていないだけでいくつかあります)からB社に接続する要件が出てきたら？とか、B社以外にもC社、D社と今回の接続形態でつなぐことになったら……？と考えると、VPC Peeringの管理負荷が重くのしかかってきます。 管理のシンプル化という観点と、将来的にC社、D社……と同様の形態で接続することを考えたときに、必要に応じて Inspection VPC という形ですべてのVPC間通信をひとつのNetwork Firewallで集約して検査する機能を導入することで、相対的に低い運用負荷で高度なセキュリティを実装できるという点から、Transit GatewayでVPC間を接続する構成を選択しました。 Transit Gateway構成であれば、前述の直接接続したVPC同士でしか通信できないという制約も受けないので、A社既存VPCからB社オンプレに通信するのに、B社オンプレIPを隠蔽する必要もありません。 Network Load Balancer 最後に既存VPCに配置したNetwork Load Balancerについて解説します。 実は仮想プライベートゲートウェイは、Direct Connect側(オンプレ側)に対しては比較的自由に経路を設定できるのですが、仮想プライベートゲートウェイが関連付けられているVPCの”先”のネットワークへの経路を持つことができません。 この図を例にとると、仮想プライベートゲートウェイAは、新規VPCやB社オンプレへの経路を持っていません。同様に、仮想プライベートゲートウェイBは、既存VPCやA社オンプレへの経路を持ちません。 つまりどういうことかというと、A社オンプレは、既存VPC以外とは通信できません。ここからB社オンプレにたどり着くためには、NATを駆使することになります。この場面で活躍する優秀なデバイスがNetwork Load Balancerです。 A社オンプレから既存VPC上のNetwork Load BalancerのIPアドレスに通信すると、送信先をNetwork Load BalancerのターゲットであるB社オンプレミス上の通信要件(1)サーバのIPアドレスに変換します(実質、送信先NAT, DNAT)。この時、送信元IPアドレスはA社オンプレのIPアドレスから、Network Load BalancerのIPアドレスに変換されます(実質、送信元NAT, SNAT)。 Transit Gatewayには、隣接するVPCにしか到達できないという制限がありませんので、Network Load Balancerから発信されたB社オンプレミス向けの通信はTransit Gatewayを通過し、NATインスタンスを通過していくことができます。そして仮想プライベートゲートウェイBに到達しますが、仮想プライベートゲートウェイBはB社オンプレへの経路を持っているので、無事B社オンプレ上のサーバに到達することができます。 次に、戻りの通信を考えます。B社オンプレミスからA社オンプレミスへの通信となりますが、行きの通信の時にNATインスタンスでA社のIPを隠蔽しB社体系のIP(新規VPCのCIDR)にNATされているので、送信先IPアドレスは新規VPC上のIPアドレスとなり、仮想プライベートゲートウェイBで破棄されることなく通過することができます。 NATインスタンスはNATを行って、Network Load BalancerのIPアドレスを送信先とします。VPC間はTransit Gatewayで接続しているので問題なく通過することができます。 Network Load Balancerは送信先をA社オンプレ上の通信要件(1)用クライアントのIPアドレスに変換します。送信元はNetwork Load BalancerのIPアドレスに変換されます。仮想プライベートゲートウェイAはA社オンプレへの経路を持っているので、A社オンプレ上のクライアントに戻っていくことができます。 まとめ 以上、NATを必要とする2社間のオンプレ/VPC接続構成について検討してみました。 Network Load Balancerは、実質的に送信元NAT、送信先NATを同時に行ってくれるので、仮想プライベートゲートウェイやVPC Peeringをいくつも越えないといけないときに大変重宝することが分かりました。ただし、ターゲットに定期的にヘルスチェックを実施してしまうので、他社のサーバをターゲットにする場合にはお断りを入れておくのがよいでしょう。 また、今回、双方向の通信要件に対応するためにEC2で独自にNAT機能を実装しましたが、EC2を使用するとOS以上はユーザー管理になってしまうので監視・運用の負荷が大きくなってしまう点が設計上の悩みどころです。AWSマネージドで柔軟かつ大規模なNATを実現できるサービスが出てくれると嬉しいですね。

皆様、こんにちは。 SCSK入社１年目の佐藤海渡です。 もう今月で、「入社１年目」と言えなくなってしまうことに恐怖を覚えている今日この頃です。 そんな私ですが、確実にこの１年で成長した点があります。 それは…   VCP-DCV 2024に合格したことです！ 今回の記事では、クラウド初学者である私が、VCP-DCVを受験し、合格するまでの流れをまとめてみようと思います。 VCP-DCVとは？ まず、最初に”VCP-DCV”とはどんな資格なのかを説明します。 VCP-DCVとは、”VMware Certified Professional – Data Center Virtualization”の略で データセンタを仮想化する技術に関するVMware社の認定資格です。 クラウドサービスを提供する基盤側の技術に関する資格で、 SCSKのクラウドサービスである ” USiZE ” も、このVMwareをベースにして構築されています。 「 ” USiZE ” ってなに？」って思ったそこのあなたはぜひ、私の執筆した第一回ブログをご参照ください。 USiZEってなに？～新人目線でまとめてみた～ – TechHarmony (usize-tech.com) ちなみに、VMwareの資格は難易度によって名称が分かれており、簡単な順に VCTA（VMware Certified Technical Associate） ↓ VCP（VMware Certified Professional）　 ←今回受験したのはこれ ↓ VCAP（Vmware Certified Advanced Professional） ↓ VCDX（Vmware Certified Design Expert） となっています。 また、分野によっても分かれており Data Center Virtualization（DCV）　 ←今回受験したのはこれ Network Virtualization（NW） Cloud Management and Automation（CMA） Security（SEC） ・・・ などなどに分かれています。 では、VCP-DCVがどんな試験で、どの立ち位置の試験なのか分かったところで 続いては、実際の受験の流れを記載していきます。 受験までの流れ 受験までの大きな流れとしては ①トレーニングコースの受講 ②資格試験の申込 ③試験対策の勉強 となります。それぞれについて以下で簡単に説明します。 ①トレーニングコースの受講 VCP認定資格を保有していない場合、トレーニングコースの受講が必須となります。 トレーニングはvSphereのバージョンや受講用途に応じていくつか種類がありますが、私は VMware vSphere: Install, Configure, Manage [V8] を受講しました。 上記のコースでは5日間でVMware vSphereの導入から管理までをみっちりINPUTしました。 コースの中ではハンズオンによるトレーニングもあり、実際にvSphereを操作することでより具体的なINPUTをすることが出来ました。 ハンズオンの中では、vCenterのデプロイからネットワークやストレージの作成、仮想マシンの作成からその管理方法、ライフサイクルの管理など実際の運用でも重要な内容が盛りだくさんとなっていました。 もっと詳しく内容が知りたいという方は、 こちら のリンクからコース概要についてご確認ください。 ②資格試験の申込 こちらは、AWSなどの資格試験と同様に Pearson VUE からの申し込みが可能となっています。 私は、テストセンターで受験しましたが、オンラインによる自宅からの受験も可能となっています。 （オンライン受験は準備が大変という噂を聞き、私はテストセンター受験にしました…笑） ③試験対策の勉強 こちらは、大きく行ったことは以下3点です。 ①のトレーニングコースのテキスト復習 Web上の問題集で演習 VMwareの公式ドキュメントを読む テキストの復習でINPUTをしっかりと行う ↓ 問題集を解いてみて知識のOUTPUTを行う ↓ 問題集を解いて疑問が残った部分について、公式のKBなどを読んで理解を深める 上記の勉強方法を資格受験の1か月前くらいから継続して行っていました。 試験当日 私は、テストセンターでの受験でしたので実際に試験会場に出向いての受験となりました。 当日、問題を見て困ったのが日本語→英語の問題文翻訳がなかったことです。 英語の問題集で対策をしていた方は、注意が必要かもしれません。 受験が終了すると、その場で合否と点数が出る試験になっています（合格点は300/500）。 勉強を頑張った甲斐もあり、何とかギリギリ合格することが出来ました。 受験から合格を振り返ってみて まず合格直後に思ったことは「受かって良かった！」ということでした。 短い時間でとにかくたくさんのINPUTをしていたので、中々試験までにすべてを覚えきることが難しく、試験中に何度も 「見たことはあるけど、どっちが正解だっけ」となることがありました。 そのため、その場で合格が分かった際には、まずほっとした感じでした。 しかしながら間違いなく、このVCP-DCVの受験を通してVMware vSphereに関するスキルは格段に向上したと思います。 今回の学びを活かして、USiZEのサービスをよりよくしていこうと思いますので ここまで読んでくださった方はぜひUSiZEに関しても興味をもっていただければと思います！ USiZEに関する情報は以下をご参照ください。 USiZEってなに？～新人目線でまとめてみた～ – TechHarmony (usize-tech.com) 　 ←USiZEについて簡単にまとめたもの クラウド移行だけでは描けない、理想のDXを実現する (scsk.jp) 　 ←USiZEホームページ お問い合わせ｜クラウド移行だけでは描けない、理想のDXを実現する (scsk.jp) 　 ←USiZEお問い合わせ先   以上、SCSK佐藤海渡の新卒1年目最後の記事でした。