TECH PLAY

SCSKクラウドソリューション

SCSKクラウドソリューション の技術ブログ

1268

Catoクラウドにリモート接続する際に、個人所有のPCやスマートデバイスなどのBYOD利用を制限するというニーズは多く、Catoのデバイス制御機能を使用しているお客様も数多くいらっしゃいます。 Catoのデバイス制御は、2024年5月現在では以下の3つの機能があります。 Catoで設定できるデバイス制御 1.Device Posture デバイスのセキュリティ状態をチェックして、条件を満たした場合Cato接続を許可します。 自社の標準PCの仕様に合わせてCato側の設定を行えるので手間なくデバイス制御が実装できます。 当初はSDPユーザーのみがサポート対象でしたが、Cato Socket配下でもDevice Posture機能が適用されるようになりました。但し、SDPユーザーではblockされてもSocket配下からアクセスすると接続できてしまったり、 Always-On 設定と組み合わせて使用する事が推奨だったりするので、現時点ではSDPユーザーに対する利用がベターです。 2.Device Authentication 認証局で発行したルート証明書をCatoクラウドに登録し、各デバイスにはクライアント証明書をインストールして証明書認証によるデバイス制御を行います。証明書の配布や更新の手間はあるかもしれませんが柔軟なコントロールが可能です。 証明書による認証については以下の記事をご参照下さい。 Catoクラウドでのデバイス証明書認証について Catoクラウドでのデバイス証明書認証の設定方法、エラー事例をご紹介します。 blog.usize-tech.com 2024.01.11 【Catoクラウド】iPhoneでのデバイス証明書認証 Catoクラウドのデバイス証明書認証について、iPhoneへの設定例とエラー事例を解説します。 blog.usize-tech.com 2024.01.04 3.MAC Authentication こちらは補足となりますが、Cato Socket配下のデバイスに対してMACアドレスによるデバイス認証が可能です。 実装方法は、Cato接続を許可するデバイスのMACアドレスを記載したcsvファイルを作成しCatoクラウドにアップロードします。 MACアドレスの追加や削除がある場合はCato Management Application(CMA)で操作はできず、都度csvファイルを更新する必要があります。 それでは、今回はDevice Postureの設定と動作結果をご紹介します。 Device Postureの設定方法 Device Postureの設定方法は以下の 3Step です。 [条件]を作成する Cato側で準備されている “OSの種類・ベンダー名・プロダクト名” などを選択して「条件」を作ります。 [条件]を組み合わせて[プロファイル]を作る 「条件」を組み合わせて「プロファイル」を作成します。プロファイルとは条件の組み合わせです。 例えば、Windows Firewallが有効になっているという条件と、会社指定のウィルス対策ソフトがバージョンxx以上になっているという条件を組み合わせて1つのプロファイルにするといったものです。 [プロファイル]を用いて[ポリシー]を作る Device Postureを適用するユーザー・プロファイル・アクションなどを決めて「ポリシー」を作成します。 では、実際にDevice Postureの設定を行いその挙動をみてみましょう。 <検証>Windows Firewallが無効のPCをブロックする 1.条件(Device Check)を作成する Device checkの設定は、Cato Management Application(CMA)のAccess >Device Posture >Device Checksで行います。 「New」ボタンをクリックすると設定ウィンドウが開きます。設定ウィンドウの最初にある「Device Test Type」(図1)でチェックに使いたいベンダーやプロダクトを設定していく事になります。 図1. Device Test Typeの画面 2024年5月時点では以下の6つタイプがありますが、Catoのアップデートによりタイプの種類はどんどん増えています。 各タイプで指定できる条件と選択できるプロダクトをいくつかピックアップしてみました。 No タイプ 指定条件と選択できるプロダクト例 1 Anti-malware 各種ウイルス対策ソフトウェアがインストールされているか? Windows Defenderや、Trend Micro、McAfeeなど 2 Firewall 各種ファイアウォールソフトウェア(OS標準のFirewall含む)がインストールされているか? Windows Firewallが有効、Trend Micro Deep Security Agent、Crowdstraikeなど 3 Disk Encryption ディスクの暗号化がされているか? 4 Patch Management 各種パッチ管理ソフトウェアがインストールされているか? Intune Client、 McAfee ePolicy Orchestrator Agentなど 5 Data Loss Prevention 各種DLPソフトウェアがインストールされているか? Trend Micro Apex One Security Agent、 McAfee DLP Endpointなど 6 Cato Client Catoクライアントが指定のバージョンかどうか? 今回の検証ではシンプルに「Windows FirewallをオフにしているPCはCato接続させない」という設定を行います。 下記の通りタイプは「Firewall」を選択し「Microsoft Corporation」から「Windows Firewall」という条件を作成します。 尚、Windows Firewallのversion指定もできますが、今回は「any version」を選択しています。 図1. Device Checkの設定 図2のように指定のversionとイコール若しくは指定のバージョン以上という設定も可能です。 図2. Device Checkの設定(バージョン指定)   2.プロファイルを定義する 次に、作成した条件からプロファイルを定義します。今回は「Windows Firewall」の1つのみとしますが、前述の通り複数の条件をまとめてプロファイルを定義する事もできます。 設定箇所は Access >Device Posture > Device Posture Profilesです。ここで 「New」ボタンをクリックして以下の設定ウィンドウで設定を行っていきます。ここではプロファイル名をつけた後は全て選択形式となっています。 図3. プロファイル設定 3.ポリシーを作る ポリシーの設定は、Access > Client Connectivity Policyで行います。 ここでも「New」ボタンをクリックして、これまでと同様に表示される設定ウィンドウに設定をしていきます。 ポリシーの設定項目は以下の通りです。 ・制御対象のユーザー/グループを選択します ・プラットフォームでOSの指定ができます ・制御対象の国を選択できます ・作成したプロファイルを選択します ・アクションでAllowかblockを選択します 設定画面を貼り付けると縦に長くなるので設定後に表示される画面を以下に添付します。 また、このDevice PostureもFirewallと同様で、上位のポリシーからマッチしたもが適用されるという動きなので「順番」は要注意です。 図4. 作成したポリシー    複数のポリシーを作成する例としては、例えばグループ会社毎にPC環境の違いや導入しているアプリケーションが異なる場合、会社毎のポリシーを作成して接続を許可するという使い道があります。 ポリシー01(A社用): Windows Firewallが有効 + McAfee Agentのバージョンが××以上 + 指定の証明書が入っている ポリシー02(B社用): Windows Firewallが有効 + TrendMicro Agentのバージョン××以上 + 特定のディスクドライブの暗号化 <検証>モバイルユーザーからアクセスした結果 今回作成したDevice Postureの設定はWindows Firewallが有効なPCはCato接続を許可し、Windows Firewallが無効になっているPCはブロックするという設定です。 実際にCato Client を入れたPCでWindows Firewallを有効/無効にして接続を試してみました。 Windows Firewallが有効だと問題なく接続できましたのでこの説明は割愛させていただき、次にWindows Firewallを無効にして接続してみました。 図5. Windows Firewallを無効化 この状態でCatoに接続しようとすると、図6の通り認証エラーとなりました。 エラー画面の「Details」をクリックすると「Windows Firewall」のルールでブロックされたとの内容が確認できます。 ネットワーク管理者は、ユーザーからこの内容を聞き出す事で切り分けができると思います。 図6. ブロックエラー画面 図6. ブロックの理由 また、CMAではブロックされたログが出力されていました。 図7. CMAのブロックログ 設定したプロダクトやバージョンを検出してくれない Device Postureで設定したベンダーのプロダクトやバージョンを期待通りに検出してくれず、稀にClient Connectivity Policyのルールをスルーする事があるようです。 その原因ですが、Cato Clientは「OPSWAT Framework」を使用してアプリケーションの識別をしているため、実際のプロダクト・バージョンと何らかの差異があった場合に検出がされないようです。 <参考>OPSWATのカテゴリ Windows https://software.opswat.com/OESIS_V4/Win/docs/support_charts/support_charts.html macOS https://software.opswat.com/OESIS_V4/Mac/docs/support_charts/support_charts.html 2024年5月時点で、上記URLにあるOPSWATのカテゴリのうち、以下がDevice Checkの対応製品となりますがこれ以外のカテゴリは未対応です。 Device Test Type(Cato) OPSWAT Category Anti-Malware  ANTIMALWARE Firewall FIREWALL Patch Management  PATCH_MANAGEMENT Data Loss Prevention DATA_LOSS_PREVENTION また、OPSWAT Frameworkの更新がされる際は、Catoのプロダクトアップデート情報にて次の様な内容が掲載されます。 Updated Vendors and Versions for Device Posture Checks:  We updated the  OPSWAT framework used by the Client to version x.x.xx.xxx 期待通りに検出されない場合の対処法は、一旦バージョン指定を無くして「Any-version」にするとか、別のベンダープロダクトに変更するかしか今のところはないように思います。 ただアップデートの頻度は多いので、暫くすると改善される可能性はあるかと思います。 まとめ 今回はDevice Postureの簡単な設定例をご紹介しました。 実際のDevice Checkでは複数の条件を組み合わせてポリシーを作成し、期待通りに接続が許可されるか又はブロックされるかのテストが必要になります。 またCatoが用意している条件はかなりの数があるので、そこから自社のデバイス環境に合うものを選択して動作テストする事も必要です。 更に条件のアップデートもどんどん行われるので、自社の環境により合うものをウォッチする必要もあるかもしれません。 ちょっと大変そうな気もしますが、ただこういった機能の利用をコンソール1つでコントロールできるのはクラウドならではの事だと思いますので是非活用してみて下さい。
こんにちは、SCSK株式会社の川原です。 今年も、延べ 30,000 人が参加する、日本最大の “AWS を学ぶイベント” AWS Summit Japan 2024 が  6月 20 日(木) 、 21 日(金) の二日間に渡り 幕張メッセ にて開催されます。 AWS Summit Japan 2024では、基調講演や150を超えるセッション、250を超えるEXPOコンテンツが用意されており、クラウド技術の最前線に触れる絶好の機会です。 SCSKはプラチナスポンサー として、パートナーセッションでの事例紹介とブースの出展を行います! すでに満席のセッションもございますので、お早めにご登録ください ↓↓ ※登録の際は、招待コード【 SPC7274802 】のご入力をお願いします。 SCSKセッションのご紹介 パートナーセッション(セッションID:AP-27)では、「 データセンターのラックぜんぶ抜く!SCSK だからできる脱オンプレの秘策とは? 」というテーマで、 沖電気工業様と当社メンバーの取り組みを事例に基づきご紹介いたします。 開始日時:6/21(金)16:00~16:30 登壇者: 沖電気工業株式会社 常務理事 情報責任者 髙島 豊徳様      SCSK株式会社 ソリューション事業グループ クラウドサービス事業本部 事業推進部 岸岡 学 【概要】 クラウドのメリットを理解し活⽤を進めようとするものの、様々な理由で「まだ⾏けない」「やっぱり⾏けない」と踏みとどまっている企業は多く存在します。Lift/Shift フェーズで障壁となる既存システム課題、コネクティビティ、どこまでクラウドネイティブに作るかなど。数多くの⼤規模クラウド移⾏にて AWS のベストプラクティスとクラウドコネクティビティをフル活⽤して開発した「クラウド Lift & Shift の秘訣」を、⼤⼿製造業の沖電気⼯業株式会社 CIO 髙島様と共に語ります。”ラックぜんぶ抜く” ために両社がどう⼿を取り合い、その難局を超えたのか。そしてクラウドネイティブへどう旅をしていくのか。本講演では、そのクラウドジャーニーへの挑戦記録を秘訣と共にお伝えします。 本セッションでは、 SCSKのクラウド移行のノウハウと知見を共有し、参加者の皆様の課題解決の糸口を提供できればと思います。 ぜひセッションをご登録してお待ちください!   「AWS 愛が、凄い 。SCSK」 ブースのご紹介 展示ブースでは、「 AWS愛が、凄い。SCSK 」をテーマに、 お客様のAWS利活用ステージに合わせて、クラウド移行、データ活用、生成AI、製造現場のデジタル化など、SCSKの独自ソリューションをご紹介します。 さらに、 ミニシアターでは7つのAWS関連ソリューションについて発表いたします。 最新のクラウド技術を活用したSCSKの取り組みやソリューションを間近でご体感いただけます。 ぜひAWS Summit JapanでSCSKのブースにお立ち寄りください! では皆様、 AWS Summit Japanを楽しみにお待ちください。 当日はSCSKセッションならびに展示ブースへの来場を心よりお待ちしております!
こんにちは。SCSKの山口です。 先日、あるアーティストのライブに当選したのですが、当選通知&料金支払いのメールが迷惑メールフォルダに入っていて、せっかくの強運が危うくオジャンになるところでした。 メールのフィルタリング基準が気になって少し調べたのですが、URL等が含まれているメールだとフィッシングを疑われてしまい、迷惑メールと判断されることがあるそうです。 しっかりと守ってくれていることはいいことですが、過保護すぎて必要なものまでブロックされてしまうのは考え物ですね。 「URLが含まれてるから怪しいメールだけど、コイツこのライブ申し込んでたから必要なメールだ。仕方ねえ通してやるか。」 みたいな判断をしてくれたらいいのに。と感じました。 いきなり何の話だと皆さん思っているころだと思いますが、先日業務でも似た(?)ような場面がありました。 通信要件:インスタンスからの下り通信を全拒否したいが、特定のURLへの通信だけは許可したい 要するに、 IPアドレス制御で下り通信を全拒否 しつつ、 FQDN制御で特定サイトへのアクセスを許可 する。ということです。 さらに嚙み砕くと、「 外部のサイトは危険なものも多いから、アクセスできないようにする 」かつ「 特定のサイトだけは通信ができるようにする 」ということです。 二段階で噛み砕きましたが、全然要約できていない気がするので、次章から詳しく書いていきます。   実現したいこと 今回実現したいことを図式化します。 ①GCEからの下り通信を全拒否(IPアドレスで制限) こちらはファイアウォールルールを設定することで簡単に実現可能ですね。 ②特定のURL(https://xxxx.jp)への通信を許可 問題はこっちです。Google Cloud のVPCファイアウォールルールでは、「 IPアドレスによる制御 」のみが可能です。FQDNによる制御は出来ません。 FQDNによる制御は、 ファイアウォール ポリシー ルール を使用することで実現することができます。 今回は、すでに FWルール(IPアドレス制御) がある状態で、新たに FWポリシールール(FQDN制御) を作成し、合わせ技で要件を実現してみます。   ファイアウォール ポリシー ルール 概要については、今回使用する部分のみ簡単に説明します。 詳細については下記ドキュメントをご参照ください。 参考資料 ファイアウォール ポリシー: https://cloud.www.google.com/firewall/docs/firewall-policies-overview?hl=ja   FWルールとFWポリシールールの評価順序 前述したとおり、今回はFWルールとFWポリシールールの合わせ技になります。(名前がややこしいですがついてきてください。。。) そのため、両者の 評価順序 が非常に重要になります。 デフォルト状態での評価順序は以下の通りです。上から下の順序で評価されます。 ①階層型 FW ポリシールール  ①-1 プロジェクトを含む組織レベル  ①-2 プロジェクトから最も遠い(上位)フォルダレベル  ①-3 プロジェクトに近い次のフォルダレベル ② VPC FW ルール ③ネットワーク FW ポリシールール  ③-1 グローバルネットワークのFWポリシールール  ③-2 リージョンネットワークの FW ポリシールール ④暗黙の FW ルール(上り全拒否+下り全許可) 図にすると以下の通りです。   実践①:FWルールとFWポリシールールの合わせ技による通信制御 改めて、要件を整理します。 要件①:GCEからの下り通信をすべて拒否する 要件②:特定のURLへの下り通信のみ許可する 今回は要件②で使用するFQDNとして「 www.google.com 」を使用します。 環境準備 下記環境を用意します。 要件①:GCEからの下り通信をすべて拒否する 下記FWルールを作成します。 FWルール名称 yamaguchi-egress-deny-all 説明 GCEからのすべての下り通信を拒否 ネットワーク vpc-test-yamaguchi 優先度 65534 方向 下り(内向き) 一致した時のアクション 拒否 ターゲットフィルタ IP範囲:0.0.0.0/0 プロトコルとポート all これによって、GCE(gce-test-yamaguchi)からのすべての下り通信が拒否されるはずです。 試しに www.google.com への疎通確認をしてみます。 pingを打っても応答がありません、下り通信が正常にブロックされているようです。 要件②:特定のURL( www.google.com )への下り通信のみ許可する 次に、FWポリシールールを使用して、 www.google.com への通信を許可します。 下記FWポリシーを作成します。 FWポリシー名称 fwpolicy-test-yamaguchi 説明 (省略) デプロイのスコープ リージョン リージョン asia-northeast1(東京) ※1 ルールの追加 なし(デフォルトで設定されるルール削除) ※2 ポリシーと VPC ネットワークの関連付け vpc-test-yamaguchi ※1 ルールの追加 ・この項目でFWポリシールールを作成することもできます。今回は説明のためにFWポリシーのみをまず作成し、その後ポリシーに含めるルールを作成します。 ※2 ポリシーと VPC ネットワークの関連付け ・FWポリシーはVPCに関連付けることができます。今回は「vpc-test-yamaguchi」に関連付けます。 作成したFWポリシーを見てみましょう FWポリシールールを作成しなかったので、デフォルトのポリシールールのみが表示されています。 デフォルトのポリシールールでは、上り/下りの通信を全て 「次に移動」 するルールがIPv6とIPv4で設定されています。 FWポリシーでは、「許可/拒否」に加えて 「次に移動」 のアクションが用意されています。それぞれ以下のように動きます。 許可 トラフィックを通す(階層が下位のルールは見ない) 拒否 トラフィックを通さない(階層が下位のルールは見ない) 次に移動 階層の下位のルールに評価を委ねる つまり、「次に移動」では「ここでは評価しないけど、次で決めてもらって。」みたいに次に当たるルールに判断を任せる動きをします。 では、作成したFWポリシーに「 www.google.com 」へのアクセスを許可(次に移動)するルールを作成していきましょう。 FWポリシーの詳細画面(上図)の 「+ルールを作成」 のボタンから作成することができます。 優先度 2147483640 説明 www.google.com への下り通信を許可(TCP/443,ICMP) トラフィックの方向 下り 一致した時のアクション 許可 ログ オフ ※1 対象 サービスアカウント サービスアカウントのスコープ このプロジェクト内 ターゲットサービスアカウント Compute Engine default service account 宛先 FQDN: www.google.com 送信元 10.20.30.0/24 プロトコルとポート 指定したプロトコルとポート TCP ポート:443 その他 icmp ※1 対象 FWポリシールールでは、ターゲット(対象)に「ネットワークタグ」を使用することができません。 代わりに、「ターゲットVPCネットワーク」もしくは「ターゲットサービスアカウント」を使用する必要があります。 今回は、「ターゲットサービスアカウント」を使用しています。 参考資料 : https://cloud.google.com/vpc/docs/using-firewall-policies?hl=ja#limitations では、この状態で www.google.com へpingを飛ばしてみましょう。 おや??? www.google.com へのicmp通信を許可するポリシールールを作成したのに通信ができませんね。 タネ明かしは次の章で行います。   再掲:FWルールとFWポリシールールの評価順序 初めの方に述べた、「FWルールとFWポリシールールの評価順序」の図をもう一度貼ります。 一番下の段に注目です。 評価順序が、 「② VPC FWルール → ③ ネットワークFWポリシールール」 となっています。 つまり、今回の要件では 先に「GCEからの下り全拒否」のFWルールが適用されてしまっている ため、 その後の「 www.www.google.com 」への許可ルールが意味をなしていません 。 じゃあ要件みたせないじゃん、、、となりそうですが、なんとこの 評価順序を変更する方法 があります。次の章で説明します。   実践②:FWポリシールール適用順序変更 下記のコマンドを実行することで、FWルールとFWポリシールールの評価順序を入れ替えることができます。 コマンド gcloud compute networks update VPC-NETWORK-NAME \     –network-firewall-policy-enforcement-order  BEFORE_CLASSIC_FIREWALL(AFTER _CLASSIC_FIREWALL ) 参考資料 : https://cloud.google.com/firewall/docs/firewall-policies-overview?hl=ja#change_policy_and_rule_evaluation_order FW ポリシー適用順序変更コマンドでの適用順序の変化 1. デフォルト状態 ① 階層型 FW ポリシールール ②  VPC FWルール ③  ネットワークFWポリシールール ④ 暗黙のFWルール(上り全拒否+下り全許可) 2. 以下を実行 gcloud compute networks update VPC-NETWORK-NAME \     –network-firewall-policy-enforcement-order  BEFORE_CLASSIC_FIREWALL ① 階層型 FW ポリシールール ②  ネットワークFWポリシールール ③  VPC FWルール ④ 暗黙のFWルール(上り全拒否+下り全許可) 3. 以下を実行 gcloud compute networks update VPC-NETWORK-NAME \     –network-firewall-policy-enforcement-order  AFTER _CLASSIC_FIREWALL ① 階層型 FW ポリシールール ②  VPC FWルール ③  ネットワークFWポリシールール ④ 暗黙のFWルール(上り全拒否+下り全許可) ⇒デフォルト状態に戻る 先ほどの実践①の環境でこのコマンドを実行します。 プロンプトが塩対応で適用できているか不安ですが、再度pingを飛ばしてみます。 応答が返ってきました。大成功です。 他のURL(FQDN)へのアクセスはというと 想定通り拒否されていますね。大成功です。 適用順序をもとに戻して再度 www.google.com へpingを投げてみましょう。 想定通り、通信できなくなりました。大成功です。 実践①、実践②で試した方法を使うことで、「インスタンスからの下り通信を全拒否したいが、特定のURLへの通信だけは許可する」という要件を満たすことができました。   まとめ 今回は、「インスタンスからの下り通信を全拒否したいが、特定のURLへの通信だけは許可したい」という要件を、FWルールとFWポリシールールの合わせ技で実現してみました。 今回はインスタンスからの下り通信を全拒否をあらかじめFWルールで実装しました(ちょうどその環境があった)が、初めから今回のような要件が見えている場合は、ルールを作成する際に 「FWポリシーの作成」の中にすべて吸収させた方が良い と感じました。 そうすることで、作成時の混乱を避けることができますし、管理やメンテナンスがより簡単になると思います。 今後の教訓にしたいと思います。
こんにちは。SCSK三上です。 今回は、先日参加したパートナー向けのAmazon Bedrockセミナーのセッションの1つにあった、 “ 本番稼働に至る生成AIプロジェクトにするための4つの質問 ” がとても印象的だったので、共有させていただこうと思います。 背景 最近ホットな生成AIですが、皆様 生成AIプロジェクトの本番稼働はうまくいっていますでしょうか? 一般的に、学習なしで利用できる生成AIは日本企業でのAI活用を約20%伸長させるポテンシャルがあります。 その一方で、日本では米国と約7倍差で、データ活用が売上増加やコスト削減に繋がりにくい傾向があると言われています。 生成AI活用も大体70~90%で失敗 、 機械学習プロジェクトは80%の確率で失敗 すると言われています。 実際に、皆様このようなお悩みを抱えていないでしょうか。 パートナーの方は、 PoC案件が多く、本番稼働に移れない 。本番環境に値する生成AIを活用した ユースケースの探索 に課題がある。 ユーザの方は、 生成AIをどのような業務に活かして良いか分からない 。生成AIを活用したいがどう進めて良いか分からない。 このようなお悩みを抱えている皆様に、少しでも役立つ4つの質問をご紹介します! これは、AWSのAI活用事例をもとに導かれた質問なので実践的に活用いただくことが出来ると思います。   生成AIプロジェクトを本番稼働にするために必要な4つの質問 生成AIが利益につながるための3つのステップ 質問を始める前に、生成AIが利益につながるためには3つのステップが重要です。 この先は、このステップに沿った質問を順番にご紹介します。 Biz:生成AIによる成長サイクルを設計する インパクトがあり実現・実装可能なユースケースを選ぶ Dev:迅速に顧客体験を検証する マネージドサービスを活用し、小さく・多く経験する ML:顧客から得られたフィードバックで体験を改善する より良い体験をコスト効率、よいモデルで提供する   第1問: 『生成AIの活用にあたり求められている成果はありますか。また、「あなた」の業績評価やキャリアにどのような影響がありますか?』 質問 『生成AIの活用にあたり求められている成果はありますか。』 1.自社のプロダクトに組み込み「売り上げ」を拡大する 2.自社の業務・開発プロセスを改善し「コスト」を削減する 3.良く分からない 『 また、「あなた」の業績評価やキャリアにどのような影響がありますか? 』 背景 この質問の背景としては、以下の通りです。 生成AIの活用にあたり求められている成果はありますか。 売り上げ・コストといった経営指標を改善するのか、市場認知を取ることなのか、従業員の意識改革なのかで施策が異なる。 また、「あなた」の業績評価やキャリアにどのような影響がありますか? 評価にかかわらない活動にモチベーション高く取り組むのは困難。 Biz:生成AIによる成長サイクルを設計する AI/MLで価値が高まるサイクルは、 ①顧客体験の改善②ユーザ増加による利益の増加③データの蓄積によるモデルの改善④データドリブンな意思決定 です。  実際に生成AIプロジェクトで成功している理想的な企業はどのようにこのサイクルを実現しているでしょうか? 事例①:デザイン作成サービスCanvaの価値が高まるサイクル ①顧客体験の改善:作りたいパンフレットに適したイラストがなければテキストで要望を書けばよい ②ユーザ増加による利益の増加:画像の生成量が増えると編集機能(有償)を使いたい人も増える ③データの蓄積によるモデルの改善:蓄積されたログから需要の高い用途に特化したモデルを生成 事例②:画像共有サービスPinterestの価値が高まるサイクル ①顧客体験の改善:分析したいアイディアをテキストで書けば、テーブルやクエリの提案が受けられる ②ユーザ増加による利益の増加:短期間で分析できれば、収益につながる様々な仮説を検証できる ③データの蓄積によるモデルの改善:蓄積されたテキストと実行可否をもとに、よりモデルの生成を制御できる ★各事例の共通ポイント★ 使用頻度が高いユースケースに挑戦している。 使用頻度が高く、効果が高い、ハイインパクトのユースケースに注目すること。 ★生成AIプロジェクトを進める第一歩★ 「ピザ2枚チーム」で素早く活動を開始する。 小規模なチーム(10名未満)で意思決定の速度を上げる。 参考: ジェフ・ベゾスの秘策「ピザ2枚」ルール。 アマゾンはこれで無駄をなくした | Business Insider Japan   第2問: 『身軽なチームで頻繁かつ改善効果が高いユースケースに注目していますか? 』 質問 『身軽なチームで頻繁かつ改善効果が高いユースケースに注目していますか。』 背景 この質問の背景としては、以下の通りです。 生成AIは進化が早い。身軽なチームが自社のフィードバックだけでなく外部の技術変化にも適応していく必要がある。 その一方で、 身近なチームは組織的権力が弱い傾向があるため、ハイインパクトではにと関係者の協力を得ることが難しい 。 Dev:迅速に顧客体験を検証する Devフェーズで検証すべきポイントとしては、②ユーザ増加による利益の増加 重要なこと 実際にやってみないと成立するかわからない。ので…迅速かつ低コストで検証したい。 事例から見る学び 事例①Canva: 3週間 で画像生成機能を実装。 事例②Pinnterest:テキストからSQLを生成するLLMをパートタイムのエンジニア 2人2ヶ月 で構築。データ分析の時間を40%効率化。 ⇒ AWSの20件以上の生成Ai事例でも、大半が小規模で2~3ヶ月でリリースされている。 ★注目ポイント★ 高頻度のユースケースに着目して高い効果を出す 有価証券報告書、毎日の文書作成、営業日報、会議、デザイン 分析時間の40%効率化、700時間の削減。   少人数・短時間 2~4名、数週間から1~3ヶ月 ★重要なこと★ リリース基準をきめておくこと。 評価の観点は、3H(Helpful/Honest/Harmless) ⇒ リリース基準がない状態だと、プロンプトの改善が生産的にならない。   第3問: 『短期間で本番稼働しフィードバックを得るには、どんな人を評価に巻き込む必要がありますか?』 質問 『短期間で本番稼働しフィードバックを得るには、どんな人を評価に巻き込む必要がありますか。』 Dev:迅速に顧客体験を検証する Who:評価者は? What:評価にはどんなデータを使うか? How:どのように評価するか? ML:顧客から得られたフィードバックで体験を改善する 生成AIを蓄積したデータでカスタマイズすることで顧客体験や業務プロセスを競争優位にする。 生成AIをそのまま使うこともできるが、それだと成長しない。優位に立てない。 通常の機械学習モデルを学習し続けると競争優位に立てる 。 競争優位につながる改善ポイント より良い応答を、より小さいモデルで実現する 体験向上によるインパクト増加、モデル縮小によるコスト削減 より良い応答へ改善する手段 プロンプトをチューニングする 回答の精度を上げるために、回答を人間が3段階で評価。 モデルそのものをチューニングする。 Amazon BedrockでFine Tuningを実施可能。 プロンプトの改善からモデル学習へ移行するタイミングは意外と早い。 第4問: 『生成AIによるインパクトを継続的に高めていくにはどんなデータを蓄積し誰に伝える必要がありますか?』 質問 『生成AIによるインパクトを継続的に高めていくにはどんなデータを蓄積し誰に伝える必要がありますか。』 ML:顧客から得られたフィードバックで体験を改善する 生成AIはまだ発展途上の技術のため、 継続的改善を前提 に考えてもらう。 改善結果が社内の認知や関係者の業績評価に繋がるよう な組織内のレポートラインの構築も不可欠 最後に、ポイントをまとめます。 ★今日から始めるチャレンジ★ 1.生成AIで狙う効果と関係者にとっての意義は? 2. 身軽なチームが効果の高い用途に注目しているか? 3.短期間でのフィードバック獲得を実現する関係者は? 4.蓄積するデータと共有先は? まとめ いかがでしょうか。私自身、お客様に生成AIを活用いただくために、この4つの質問は役立つと思いました。 特に印象に残った点は、①評価者はだれなのか?評価基準はなにか?を明確にすること。②高頻度のユースケースに着目し高い効果に着目すること。そのためには、お客様に”社内にはどんなユースケースが存在するか”を把握していただくことが大切だと感じました。 これから生成AIプロジェクトを進めていこうと思っている方は、ぜひ参考にしてみてください。 また、この日のセミナーのメインセッションはAmazon Bedrockについてでした。Amazon Bedrockは、API経由で基盤モデルにアクセスが可能となるサービスです。 こちらもとても興味深かったので、また記載していこうと思います!
こんにちは、SCSK松岡です。 本記事では、Power BIからSnowflakeにSSO(シングルサインオン)を使用して接続するための一連の手順と注意点をご紹介します。 Snowflakeに蓄積したデータをBIツールで可視化することは、データの価値を最大限引き出すために重要なポイントの一つです。 Microsoftのサービスと高い親和性を持つPower BIでは、SSOによりMicrosoft Entra IDの認証を利用して、データへのセキュアな接続が可能です。 SSOによりユーザーはシステム毎に別アカウントでログインする手間が省かれますが、そのためにはSnowflake側でのセキュリティ統合や、Power BI側での有効化などの事前設定が必要となります。 前提 これからご紹介する手順には、Snowflakeのアカウント全体に影響する設定と、Microsoftの組織全体に影響する設定が含まれます。そのため、設定を行うには次のユーザーが必要です。 ACCOUNTADMINロールを持つSnowflakeユーザー グローバル管理者権限を持つPower BIユーザー また、手順は以下のマニュアルをベースに記載していますので、設定の際は合わせてご参考ください。 Microsoft Learn:Power BI サービスで Snowflake に接続する Power BI で Snowflake に接続する - Power BI Power BI で Snowflake に接続し、SSO 認証またはゲートウェイ用に Microsoft Entra ID を使って構成する方法について説明します。 learn.microsoft.com   設定の流れ (Snowflake設定) Power BIセキュリティ統合 まず初めに、Snowflake側でPower BIとのセキュリティ統合の設定を行います。設定にはACCOUNTADMINロールを持つユーザーが必要です。 設定にあたり、Microsoft Entra ID (旧称:Microsoft Azure Active Directory)のテナントIDが必要なので、事前に取得しておきましょう。テナントIDは、Entra IDのトップページ(概要)から取得できます。 テナントIDが取得できたら、その値を「external_oauth_issuer」に含める形で以下のようなコマンドを実行します。 create security integration powerbi type = external_oauth enabled = true external_oauth_type = azure external_oauth_issuer = 'https://sts.windows.net/ [テナントID] /' external_oauth_jws_keys_url = 'https://login.windows.net/common/discovery/keys' external_oauth_audience_list = ('https://analysis.windows.net/powerbi/connector/Snowflake', 'https://analysis.windows.net/powerbi/connector/snowflake') external_oauth_token_user_mapping_claim = 'upn' external_oauth_snowflake_user_mapping_attribute = 'login_name' 例として、テナントIDがa828b821-f44f-4698-85b2-3c6749302698の場合、 external_oauth_issuerは、https://sts.windows.net/a828b821-f44f-4698-85b2-3c6749302698/ となります。 テナントIDの後にスラッシュ(/)を含める点に注意してください。 CREATE SECURITY INTEGRATION (Snowflake OAuth) | Snowflake Documentation docs.snowflake.com   (Snowflake設定) ユーザー作成 セキュリティ統合が成功すれば、Entra IDユーザーのUPN属性値と、Snowflakeユーザーのlogin_name属性値が紐づきます。 逆に言うと、Entra IDのユーザーからSSOを使用してSnowflakeに接続するためには、対象のUPNと同じlogin_nameのSnowflakeユーザーを作成する必要があります。 各ユーザーのUPN(ユーザープリンシパル名)は、Entra IDのユーザー一覧から、対象のユーザーを選択した概要ページから確認できます。 取得したUPNをもとに、SQLの実行等でSnowflakeユーザーを作成しましょう。 CREATE USER [ユーザー名(任意)] PASSWORD = '[パスワード(任意)]' LOGIN_NAME = ' [EntraIDのUPN] ' DEFAULT_ROLE = [デフォルトロール] CREATE USER | Snowflake Documentation docs.snowflake.com 注意点として、ユーザーを作成する際は、後にPower BIのレポートから参照しようとしているデータに応じた権限をデフォルトロールで設定する必要があります。また、Power BIから使用されるウェアハウスに対するUSAGE権限が付与されている必要があります。 付与された権限に不足がある場合、PowerBI側の認証時にエラーになってしまいます。 Snowflake Community Join our community of data professionals to learn, connect, share and innovate together community.snowflake.com   (Power BI設定)Snowflake SSOの有効化 続いて、Power BI側の管理設定です。 グローバル管理者権限を持つユーザーでPower BIにサインインし、 [設定]>[Power BI設定] > [管理ポータル] を選択します。 そこから、[テナント設定] > [統合の設定] > [Snowflake SSO] を選択して展開し、 設定を[有効]に切り替えた後、[適用]を選択します。 マニュアルだと、有効にしてから反映までに最大1時間かかるとの記載がありました。   (Power BI Desktop設定) データソースの追加 ここからは、Power BIでSnowflakeのレポート作成する際の考慮点になります。 まず、レポートを作成するためにはデータソースの用意が必要ですが、 データソースとしてSnowflakeに接続する場合、Power BI Desktopから行う必要があります。 Power BI Desktopと、ブラウザのPower BIサービス(クラウドベース)の違いや、 Power BI Desktopの取得方法は以下をご参考ください Power BI Desktop と Power BI サービスの比較 - Power BI Power BI Desktop ダウンロード アプリケーションとクラウドベースの Power BI サービスの違いについて説明し、比較します。 learn.microsoft.com Power BI Desktop の取得 - Power BI Power BI Desktop をダウンロードできるさまざまな方法と、それをインストールするために使用できるオプションについて説明します。 learn.microsoft.com 大まかな違いとしては、 Power BI Desktopはレポート作成用途の機能が充実しており、 Power BIサービス(クラウドベース)は、レポートの共有用途の機能が充実しています。 Power BI Desktopは、PowerBIサービスと同じアカウントでサインインできます。 データソースとしてSnoflakeに接続する場合は、レポートのデータ追加画面から、「別のソースからデータを取得する」をクリックし、Snowflakeを選択します。 Snowflakeのサーバ情報、ウェアハウス情報を入力した後にユーザー情報が聞かれますが、SSOを使用する場合はこのときに、「Microsoft Account」を選択します。 Snowflake側の設定が上手くいっていれば、Entra IDのユーザー情報による認証で、Snowflakeのデータが参照できるようになるはずです。   (Power BI設定) セマンティックモデル設定 Power BI Desktopで作成したレポートは「発行」ボタンからPower BI サービスに共有が可能です。 Power BI Desktop からの発行 - Power BI セマンティック モデルとレポートを Power BI Desktop から Power BI サービスに発行する方法について説明します。これにより、モデル内のデータが Power BI ワークスペースに発行されます。 learn.microsoft.com 発行先のワークスペースを選択すると、レポートとセマンティックモデルがPower BIサービスにアップロードされます。 Power BIのセマンティックモデルには、データソースに接続する際の認証に必要な情報が含まれます。 アップロードされたセマンティックモデルの設定にアクセスし、[データソースの資格情報]に進んでから[資格情報を編集]を選択します。 認証方法が「OAuth2」に選択されている場合、SSOを利用した設定が引き継がれています。 Power BI サービスのセマンティック モデル - Power BI Power BI サービスのセマンティック モデルについて説明します。これはレポート作成と視覚化の準備ができたデータのソースを表します。 learn.microsoft.com   最後に 上記の手順だと、利用ユーザーが増えるたびに手動でSnowflakeユーザーを作成する必要があります。追加でプロビジョニングの設定を行えば、その作業を自動化することも可能なようです。 チュートリアル: Snowflake を構成し、Microsoft Entra ID を使った自動ユーザー プロビジョニングに対応させる - Microsoft Entra ID Snowflake に対してユーザー アカウントのプロビジョニングとプロビジョニング解除を自動的に実行するための Microsoft Entra ID の構成方法について説明します。 learn.microsoft.com これで、接続のための設定は完了です。 設定してみて詰まったポイントがいくつかあったので、少しでも参考になれば幸いです!
みなさん、こんにちは。SCSKで飼われているひつじです! 最近の私、なんと週3でサウナに通ってるんだ。サウナって最高だよね! さてさて、半年前くらいからちょっとしたことがきっかけで、当社新人様の指導をすることになっちゃったんだ。そしたらね、みんなで一緒に考えたんだけど、新人のみんなが自分たちでテックブログを書いてみんなで楽しめるイベントをやろうってことになったんだ! うちの会社にはね、ありがたいことに「TechHarmony」というブログサイトがあるんだよ。そこで新人のみんなが自由に発信できるんだ。それを使って新人たちにブログを書いてもらっちゃったんだ。楽しみだよね、みんなの書いたブログを読むの。 そもそもなんでブログを書くのか? 新人様の取り組みとしてなぜブログなのか。以下に列挙したいと思います! 人に伝えようとすることで自分の理解になる。 昔の人は言いました「100回の購読より、1回の寄稿だと。」 新人様はインプットする機会は多いですがアウトプットすることで知識定着に寄与できます。 「テックブログを書く」という道の最初の一歩を作る。 テックブログなんて社外に発信できるなんてすごいエンジニアだけなんだ。という畏怖の取り除きを解消することができます。 新人育成の中で先輩社員がリードしてあげることで新人様の最初の一歩を促すことができます。 社内外に顔を売るチャンスを作る。 社外発信することにより人目につき、名前や顔が売れていきます。 パブリックな活動を評価するような仕組みも社外にはあるので、そこに取り上げてもらうことで当社としても個人としても対外的な評価を受けれるのは素晴らしいことです。また社内向けには報告会を行うこと新人様と役職者をつなげるような活動にも発展できます。 新人様の取り組み紹介 ということで今期取り組んだ新人様4名の記事を紹介したいと思います。 ヒルタさんの記事 AWS関連のブログをメインに寄稿頂きました。ブログ寄稿を通じて得られた自身の体験をわかりやすく整理していただきました! マセダさんの記事 親しみやすい記事をモットーにAWS、AIサービス関連のブログを寄稿頂きました。 ブログ寄稿にあたり最新の技術アップデートを意識できるようになったとのことです! サトウさんの記事 明るく楽しく元気よくをキャッチフレーズに当社クラウドサービス「USiZE」に関する寄稿をいただきました。 ブログ執筆を通してお客様からフィードバックを頂いたりと良いご経験もあったようです! エギさんの記事 Google関連のカンファレンスの参加レポートやご自身のGCP関連の業務に関する記事を投稿頂きました。 「知識の整理になった!」「創造性の刺激になった!」「カンファレンスのモチベになった!」など前向きに取り組んでいただきました。 まとめ 今期はなんと、4人の新人たちがブログに寄稿してくれたんだ!さらに、たくさんの役職者に向けて成果をプレゼンしたよ。 忙しい日々だけど、これからも会社内外で情報発信を頑張っていきたいね!初めの一歩を忘れずに! 末筆になりますが、ご査収のほど、よろしくお願い申し上げます。
はじめまして。SCSK渡辺(大)です。 シティーハンターの実写映画が面白かったので続編を熱望しています。 今回は、 Amazon Bedrock の Knowledge Base で 文字変換 をやってみました。 Pythonのreplaceメソッドを使えば簡単に文字変換することが出来るのですが、敢えてBedrockのKnowledge Baseを使いました。 まだまだ修行中の身ですので間違いが多々あるかもしれませんが、暖かい目で見て頂けると幸いです! 目標 文字変換前のテキストファイルをS3にアップロードするだけで、文字変換後のテキストファイルを得ることが出来るようになる! 結果 先に結果を見たい方のみクリック!    2回目で想定通りに変換することが出来ました! 概要 フロー図 処理の流れ ①.ユーザーは変換前のテキストを所定の S3 にアップロードします。 ②.Lambda は S3 にファイルがアップロードされたことをトリガーにして実行されます。 ③.Lambda は Bedrock を呼び出し、変換前のテキストを渡します。 ④.Bedrock は Knowledge Base OpenSearch に変換ルールの有無を確認します。 ⑤.Knowledge Base OpenSearch は Bedrock に変換ルールを返します。 ⑥.Bedrock は変換ルールに沿って変換前のテキストを変換することで、変換後のテキストを生成します。 ⑦.Bedrock は変換後のテキストを Lambda に返します。 ⑧.Lambda は変換後のテキストを所定の S3 にアップロードします。 Agents for Amazon Bedrock で Claude モデルに問い合わせる分岐のある RAG をつくる Agents for Amazon Bedrock を使用して簡単な RAG をつくってみましたので、RAG の分岐部分の設定や基盤モデルへの問い合わせコードを紹介します。 blog.usize-tech.com 2024.02.26   構築手順 記事執筆時点ではBedrockのKnowledge Baseを使えるリージョンはバージニア北部とオレゴンのみでしたので、今回はバージニア北部(us-east-1) で各資源を作成しました。Knowledge Baseを使えるリージョンの最新情報は ユーザーガイド を確認してください。 S3 S3バケットの作成 まずはS3バケットを3つ作成します。 バケット名を入力し、その他の設定はノールック(=デフォルト)で作成します。 変換ルール格納先 : Bedrock Knowledge Baseと再同期する際に変換ルール以外のファイルが存在していると、想定通りの変換をしない 可能性があるため専用で作成。 変換前テキスト格納先 : Lambdaのトリガーになるバケットであり、ここに変換前テキスト以外が格納されてしまうと、そのタイミングでもLamdaが 稼働してしまうため専用で作成。 変換後テキ スト格納先 : 上記に伴い、専用で作成。 変換ルールのアップロード 変換ルール格納先のS3バケッ トに「rule.txt」 をアップロードします。 このテキストに記載されているルールに則って変換処理を行ってください。 ルール①:りんご→赤色の丸い果物 ルール②:オレンジ→オレンジ色の丸い果物 ルール③:葡萄→紫色の丸くて小さい果物 ルール④:メロン→緑色の丸くて大きい果物 ルール⑤:バナナ→我が子がこよなく愛する黄色い果物 ルール⑥:ルール①からルール⑤のどれにも当てはまらない場合は、未知の果物   Bedrock Knowledge Base Bedrock Knowledge Base の作成 下記の記事を参考にBedrock Knowledge Baseを作成します。 生成AI初心者がAmazon BedrockのKnowledge baseを使ってRAGを試してみた AWS re:Invent2023にて、Amazon BedrockのKnowledge baseとAgentsがGAされたと発表がありました。今回はこのうちKnowledge baseを利用して、RAG(Retrieval Augment Generation)を試してみたいと思います。 blog.usize-tech.com 2023.12.07 続いて、下記の記事を参考に機械学習モデルの有効化を行います。 今回は流行りのClaude 3 Haikuを使用したかったので、有効化されていることを確認しました。 Amazon Bedrockの良いところを実感しよう Amazon Bedrockがリリースされました。python boto3を使ってAPIアクセスします。2つのモデルへの簡易的なアクセスをするプログラムを比較し、Amazon Bedrockの特徴を考えます。 blog.usize-tech.com 2023.10.02 ナレッジベースIDを控える Lambda(Python)の中でナレッジベースIDを指定する必要があるため控えておきます。   Lambda Lambdaの作成 「関数の作成」→「設計図の使用」にて下記で作成します。 設計図名:Get S3 object(Python3.10) 実行ロール:AWSポリシーテンプレートから新しいロールを作成 ポリシーテンプレート – オプション:Amazon S3 オブジェクトの読み取り専用アクセス権限 S3トリガー バケット:変換前テキスト格納先のバケット イベント:PUT ランタイム設定の変更 最新のPythonランタイムに変更します。 今回はPython3.12に変更しました。 アクセス制限の変更 LambdaがBedrockを使用できるようにする為、ロールにインラインポリシーで下記を追加します。 { "Version" : "2012-10-17" , "Statement" : [ { "Effect" : "Allow" , "Action" : "bedrock:*" , "Resource" : "*" } ] } また、AWSLambdaS3ExecutionRoleがアタッチされていますが、S3からファイルを取得(Get)する権限しかない為、こちらはデタッチします。 {     "Version": "2012-10-17",     "Statement": [         {             "Effect": "Allow",             "Action": [                 "s3:GetObject"             ],             "Resource": "arn:aws:s3:::*"         }     ] } 代わりにAmazonS3FullAccessをアタッチします。 {     "Version": "2012-10-17",     "Statement": [         {             "Effect": "Allow",             "Action": [                 "s3:*",                 "s3-object-lambda:*"             ],             "Resource": "*"         }     ] } boto3のバージョンアップ 下記の記事にある通り、boto3 ver.1.28.72が内包されているPython3.12がリリースされた為、boto3のバージョンアップは実施不要です。 後程出てきますが、私が理解出来ていなかっただけで、バージョンアップは必要でした。 Amazon Bedrock(Titan Textモデル)でAWSブログを要約して通知する 昨年、AWSブログの更新を検出しTeamsに通知するという記事を発信しました。 そこで今回はこれに生成AIの要素を追加し、記事を要約して通知することにチャレンジしてみたいと思います。 blog.usize-tech.com 2023.12.25 コードの修正 最初に掲げた目標の通りにLambdaが動くよう、コードを修正します。 下記は私が人生で初めて書いたPythonのコードです。ご査収ください。 RAGの一般的な使い方では資料リンクを付けて回答させるのが良いかと思いますが、今回は文字変換させたいだけで変換ルールテキスト(rule.txt)の リンクを貰っても使わないので、回答にリンクは付いてこないようにしています。 モデルID はリンクから確認してしてください。 ★の3箇所は適宜修正してください。 import json import boto3 import urllib.parse import sys s3 = boto3.client('s3') boto3 = boto3.client('bedrock-agent-runtime')   # Bedrock処理 def convert_text(knowledge_txt):     response = boto3.retrieve_and_generate(         input={"text": knowledge_txt},         retrieveAndGenerateConfiguration={             "type": "KNOWLEDGE_BASE",             "knowledgeBaseConfiguration": {                 'generationConfiguration': {                     'promptTemplate': {                         'textPromptTemplate': 'あなたは、ユーザーがs3にアップロードしたテキストの内容を変換して回答するエージェントです。'\                         '変換のルールは「rule.txt」に記載されています。回答は必ず日本語にしてください。'\                         'ユーザーには変換後のテキストのみを回答してください。ユーザーには変換前のテキストを回答しないでください。'\                         '$search_results$'                     }                 },                 "knowledgeBaseId": "★ナレッジベースID★",                 "modelArn": "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-haiku-20240307-v1:0",                 "retrievalConfiguration": {                     "vectorSearchConfiguration": {                         "overrideSearchType": "HYBRID"   # or SEMANTIC                     }                 },             },         },     )     return response["output"]["text"] def lambda_handler(event, context):     # トリガーされたイベントからバケット名とオブジェクトキーを取得     bucket = event['Records'][0]['s3']['bucket']['name']     key = urllib.parse.unquote(event['Records'][0]['s3']['object']['key'])          # 元のオブジェクトの内容を取得     response = s3.get_object(Bucket=bucket, Key=key)     original_txt = response['Body'].read().decode('utf-8')     # Bedrock処理コール     response_output = convert_text(original_txt)     # 新しいオブジェクト名を決める     new_key = ★新しいオブジェクト名★     # 書き換えた内容を新しいオブジェクトとしてS3にアップロード     bucket = ★変換後テキスト格納先S3バケット名★     s3.put_object(Bucket=bucket, Key=new_key, Body=response_output.encode('utf-8'))     print(f'Successfully uploaded {new_key} to {bucket}')     return {         'statusCode': 200,         'body': 'Object uploaded successfully'     }     sys.exit()   いざ出陣! ついに変換前テキストが出陣する時が来ました。 今回はAWSコンソールのS3画面から、下記の「果物.txt」を変換前テキスト格納先にアップロードしました。 りんご バナナメロン 葡萄 Orange オレンジ パパイヤ ドーナツ 林檎はりんごです りんごは林檎です エラー発生 下記のエラーとなりました。 [ERROR] ParamValidationError: Parameter validation failed: Unknown parameter in retrieveAndGenerateConfiguration.knowledgeBaseConfiguration: "generationConfiguration", must be one of: knowledgeBaseId, modelArn Unknown parameter in retrieveAndGenerateConfiguration.knowledgeBaseConfiguration: "retrievalConfiguration", must be one of: knowledgeBaseId, modelArn Traceback (most recent call last):   File "/var/task/lambda_function.py", line 48, in lambda_handler     response_output = convert_text(original_txt)   File "/var/task/lambda_function.py", line 10, in convert_text     response = boto3.retrieve_and_generate(   File "/var/lang/lib/python3.12/site-packages/botocore/client.py", line 553, in _api_call     return self._make_api_call(operation_name, kwargs)   File "/var/lang/lib/python3.12/site-packages/botocore/client.py", line 962, in _make_api_call     request_dict = self._convert_to_request_dict(   File "/var/lang/lib/python3.12/site-packages/botocore/client.py", line 1036, in _convert_to_request_dict     request_dict = self._serializer.serialize_to_request(   File "/var/lang/lib/python3.12/site-packages/botocore/validate.py", line 381, in serialize_to_request    raise ParamValidationError(report=report.generate_report()) boto3のバージョン更新履歴と思われるページ を見てもいまいち分からず。 Claude 3 Haikuに聞いてみました。 認識できないAPIがある様子なので、最新のboto3をインストールしてLambdaレイヤーにセットすることにしました。 boto3インストールはAWS CloudShellから実施しました。 全量ではありませんがログは下記の通りです。 なお、最新のboto3はv.1-34-100でした。 [cloudshell-user@ip-xx-xxx-xxx-xx ~]$ mkdir boto3work [cloudshell-user@ip-xx-xxx-xxx-xx ~]$ pip install -t ./boto3work boto3 Collecting boto3   Downloading boto3-1.34.100-py3-none-any.whl (139 kB)      |████████████████████████████████| 139 kB 3.6 MB/s           Collecting botocore<1.35.0,>=1.34.100   Downloading botocore-1.34.100-py3-none-any.whl (12.2 MB)      |████████████████████████████████| 12.2 MB 26.9 MB/s           Collecting jmespath<2.0.0,>=0.7.1   Downloading jmespath-1.0.1-py3-none-any.whl (20 kB) Collecting s3transfer<0.11.0,>=0.10.0   Downloading s3transfer-0.10.1-py3-none-any.whl (82 kB)      |████████████████████████████████| 82 kB 413 kB/s             Collecting python-dateutil<3.0.0,>=2.1   Downloading python_dateutil-2.9.0.post0-py2.py3-none-any.whl (229 kB)      |████████████████████████████████| 229 kB 44.1 MB/s           Collecting urllib3<1.27,>=1.25.4   Downloading urllib3-1.26.18-py2.py3-none-any.whl (143 kB)      |████████████████████████████████| 143 kB 49.3 MB/s           Collecting six>=1.5   Downloading six-1.16.0-py2.py3-none-any.whl (11 kB) Installing collected packages: six, urllib3, python-dateutil, jmespath, botocore, s3transfer, boto3 Successfully installed boto3-1.34.100 botocore-1.34.100 jmespath-1.0.1 python-dateutil-2.9.0.post0 s3transfer-0.10.1 six-1.16.0 urllib3-1.26.18 [ cloudshell-user@ip-xx-xxx-xxx-xx   ~ ] $ mv ./boto3work ./python [cloudshell-user@ip-xx-xxx-xxx-xx ~]$ zip -r boto3-1.34.100.zip ./python 以下省略 zipファイルをダウンロード後、レイヤーを作成し、Lambdaにセットしました。 ということで、再度「果物.txt」をアップロードしてみました。 タイムアウト発生 エラーは解消されましたが、タイムアウトが発生しました。 2024-XX-XXXXX:XX:XX.XXXX XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX Task timed out after 3.02 seconds Claude 3 Haikuから回答を得るまでに3秒以上掛かっているようなので、タイムアウトを30秒に変更してみました。 ということで、再々度、「果物.txt」をアップロードしてみました。 成功? 変換後テキストが作成されました! 中身を確認してみます。 りんご 黄色い果物メロン 紫色の丸くて小さい果物 オレンジ色の丸い果物 オレンジ 未知の果物 未知の果物 りんごはりんごです りんごはりんごです 惜しいですね。 質問するたびに回答精度が上がるかもしれないので、もう一度、変換前テキストをアップロードしてみました。 成功! 赤色の丸い果物 我が子がこよなく愛する黄色い果物、緑色の丸くて大きい果物 紫色の丸くて小さい果物 オレンジ色の丸い果物 オレンジ色の丸い果物 未知の果物 未知の果物 赤色の丸い果物 赤色の丸い果物 空白行を詰められてしまいましたが、、、 2回目で想定通りに変換することが出来ました! まとめ 良かった点は、新技術に触れることが出来たことは勿論として、業務経験が浅くても頑張ればモノづくりが出来ることに気づけたことです。 反省点としては、エラーとなってしまったboto3バージョン不足については事前に気づくべきでした。 また、後から気づいたのですが、今回のやってみたをやってみる前に下記の記事を見ておくべきでした。 ガイドラインに則ったプロンプトであれば、1回目で想定通りに変換することが出来たかもしれませんね。 Amazon Bedrockでプロンプトエンジニアリングを学ぶ Amazon Bedrockを使ってプロンプトエンジニアリングのコツやパラメータ調整についてご説明します。 blog.usize-tech.com 2024.01.25
こんにちは、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 テーブルの大事なデータを消してしまったとき。 大丈夫、 3つ目は救えます 。 今回はそんなブログです。   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 は、企業のネットワークを保護するために不可欠ですが、時には意図しない形で正当な通信をブロックしてしまうことがあります。 今回は実際にあった2パターンのトラブル例と対処法について記載します。 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時点での対処方法としましては、3つございます。 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アドレスを取得しましょう。 ※標準で3つまで取得可能で、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属性を1つだけ(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 にて開幕しました。 現地時間4月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 名」は意図的に無効化しない限りは有効になっているはずですが、私が経験したように(おそらくマネージメントコンソールのバグか何かで)無効になってしまっている可能性もあるので、チェックしてみるとよいでしょう。