TECH PLAY

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

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

1230

Prisma Cloudは、クラウド環境のセキュリティとコンプライアンスを一元管理するツールで、リアルタイムの脅威検出やリソースの監視が可能です。今回は、実際にGoogle Cloud環境(プロジェクト)をPrisma Cloudに接続してみました。 作業する前に まずは接続する前に接続方法や前提条件の確認から行います。 接続パターン Azure環境をPrisma Cloudに接続するには、以下の2つのパターンがあります。 1 組織 GCP組織内のすべてのプロジェクトをPrisma Cloudに接続します。 2 プロジェクト 単一のプロジェクトのみを接続します。   接続方法 Prisma CloudにGoogle Cloud環境を接続するためには、Google Cloud環境側で必要なリソースを作成する必要があります。 以下の方法が利用できます。 1 Terraform(推奨) 自動的にPrisma Cloudアプリケーションをセットアップし、プロジェクトへのアクセスを許可します。 2 カスタムロールJSON 手動でカスタムロールを作成し、Prisma Cloudアプリケーションに必要な権限を付与します。   前提条件 サービスアカウントの権限 Prisma CloudがGCPアセットを監視するためには、サービスアカウントに特定の権限を与える必要があります。組織全体での監視を行う場合は、組織のIAMポリシーにロールを割り当てることが必要です。プロジェクト単位での監視も同様に、各プロジェクトのIAMポリシーにロールを設定します。 サービスアカウントに必要な権限は以下の通りです。 Viewer :基本的な読み取り権限です。 Prisma Cloud Viewer :クラウドストレージのメタデータを読み取り、IAMポリシーを更新するためのカスタムロールです。 Compute Security Admin(オプション) :自動修正を有効にする場合にのみ必要なロールです。 Organization Role Viewer(オプション) :組織全体のオンボーディングに必要です。単一プロジェクトの場合は不要です。 Dataflow Admin(オプション) :データフローログを圧縮する際場合に使用します。 Folder Viewer(オプション) :GCPフォルダのメタデータをオンボードし、特定のフォルダを選択し(フォルダを含めるか除外するか)、フォルダ階層に基づいてアカウントグループを自動的に作成する場合にのみ必要なオプションの権限です。 GCP APIのレート制限 Prisma CloudからのAPI呼び出しは、オンボーディングしたGCPプロジェクトのクォータを使用します。そのため、レート制限を超えないように注意が必要です。レート制限エラーを回避するためには以下を確認してください。 作成するサービスアカウントに serviceusage.services.use の権限を持たせる メタデータを取得する監視対象のプロジェクトで主要なGCPサービスAPI※を有効化する ※GCP サービス (appengine.googleapis.com、commender.googleapis.com、sqladmin.googleapis.com、apikeys.googleapis.com、iam.googleapis.com、cloudresourcemanager.googleapis.com、orgpolicy.googleapis.com、cloudasset.googleapis.com、accessapproval.googleapis.com is.com、 essentialcontacts.googleapis.com) GCP APIの利用 Prisma Cloudは、さまざまなGCP APIからデータを取り込むことができます。オンボーディングをスムーズに行うためには、必要なAPIを事前に有効にしておくことが重要です。 オンボーディングでPrisma Cloudに用意されているTerraformテンプレートを使用する場合、必要なアクセス許可は自動的に有効になります。 手動でカスタムロールを作成してオンボーディングを行う場合、以下のページを参考に必要なAPIを有効化してください。 ・GCP 組織とプロジェクトをオンボーディングするための前提条件( https://docs.prismacloud.io/jp/enterprise-edition/content-collections/connect/connect-cloud-accounts/onboard-gcp/prerequisites-to-onboard-gcp )   接続してみる 前提条件等の確認ができたのでここからは実際に接続してみます。 今回はTerraformを使ってGoogle CloudのプロジェクトをPrisma Cloudに接続します。 作業準備 Google Cloud環境(プロジェクト)とPrisma Cloudの接続作業には、以下の準備が必要です。 プロジェクトIDおよびテナントIDの情報を用意してください。 ネットワークの監視を行いたい場合はフローログの取得は必要となるため、フローログを保管しているストレージバケットの名前を控えておいてください。 接続するプロジェクトに対してPrisma Cloud用のサービスアカウントを追加するため、以下の権限を持っていることを確認してください。 ・サービスアカウント管理者 ・サービスアカウントキー管理者 ・Project IAM 管理者 ・Service Usage 管理者 ・ロールの管理者 Google CloudでCloudShellが使えることを確認してください。 Terraformスクリプトの取得 Prisma Cloudにログインします。 「設定」から「プロバイダ」>「クラウドアカウント」を選択し、「プロバイダーに接続する」>「クラウドアカウント」をクリックします。 クラウドプロバイダーで「Google Cloud Platform」を選択します。 「始めましょう」の画面が表示されたら、範囲で「プロジェクト」を選択します。 今回はCSPM機能だけ利用できればよいので、エージェントレスワークロードスキャンやサーバレス機能スキャン、エージェントベースのワークロード保護はチェックを外して次に進みます。 「アカウントの設定」画面が表示されたら、以下を入力します。 ・プロジェクトID ・アカウント名 ※自由に指定できます ・「修復」機能は利用しないためチェックを外したままにします ・フローログを有効化したいため「フローログのストレージバケット名」にあらかじめ控えておいたストレージバケット名を入力します ・Dataflowを利用した圧縮ログ生成機能は今回は使用する想定がないためチェックを外したままにします 上記を入力するとTerraformスクリプトがダウンロードできるようになるので、「Terraformスクリプトのダウンロード」をクリックします。   これでTerraformスクリプトのダウンロードは完了です。 Terraformスクリプトの実行 Terraformスクリプトがダウンロードできたので、次はGoogle Cloud環境上でTerraformスクリプトを実行します。 Google Cloudプロジェクトに必要な権限(上記の「前提条件」を参照)を持ったユーザーでログインします。 今回はオーナー権限でログインしました。 CloudShellのアイコンをクリックしてCLI画面を表示します。ここからはCloudShell上での作業になります。 任意のパスにディレクトリを作成して、先ほどダウンロードしたTerraformスクリプトををアップロードします。 作成したディレクトリに移動します。 以下のコマンドを実行します。 # terraform init 「Terraform has been successfully initialized!」と表示されればOK 以下のコマンドを実行します。 # terraform apply 以下のポップアップが表示されたら「承認」をクリックします。 実行するか確認されるので、「 yes 」と入力します。 「Apply complete!」と表示されたら実行完了です。 「Please download the file~」と表示されているjsonファイル名を控えておきます。 前項で名前を控えたファイルをダウンロードをダウンロードします。 Prisma Cloudに接続 Terraformスクリプトを実行して必要なリソースをGoogle Cloud環境に設定できたので、次はいよいよPrisma Cloudに接続します。 Prisma Cloudにログインします。 Terraformスクリプトの取得でプロジェクトID等を入力したところまで同じ設定をして進みます。 「アカウントの設定」画面で、「Terraformスクリプトのダウンロード」の下にある以下の画面で、Terraformスクリプト実行後にダウンロードしたファイルをアップロードします。         ↓アップロードが完了して以下赤枠部分が表示されることを確認します。 「アカウントグループ」の項目で任意のアカウントグループを指定します。 今回は事前に作成しておいたGoogle Cloud環境用のものを指定します。 「Next」をクリックして次の画面に進むと接続が始まります。 レビューステータスがすべて成功(緑色)になれば接続OKです! 「保存して閉じる」をクリックして完了します。 監視設定してみる AzureサブスクリプションをPrisma Cloudに接続できたので、監視設定をしていきます。 アラートルールの設定 セキュリティ的によくないクラウド設定等を検知するため、アラートルールを設定していきます。 Prisma Cloudコンソール画面上部にある「アラート」を選択します。 「アラートルールを表示」を選択し、「アラートルールの追加」をクリックします。 アラートルール名を入力します。 「ターゲットを割り当て」の画面に進んだら、監視対象のアカウントグループを指定します。 今回は先ほど接続したAzureサブスクリプションで指定したアカウントグループを選択して次に進みます。 「ポリシーを割り当て」の画面に進んだら、監視するポリシーを選択します。 今回は一旦すべてのポリシーで監視してみるので「すべてのポリシーを選択」を有効にして、次に進みます。 「概要」画面に進んだら設定した内容を確認し、「保存」します。 これでアラートルールの設定ができました。 アラート検知 アラートルールを設定してしばらくすると、ポリシーに違反したリソースを検知してPrismaCloudコンソール上にアラートが表示されました。 アセット情報 アラートルールによる監視とは別で、Prisma Cloudに接続されたGoogle Cloudプロジェクトのアセット情報がPrisma Cloudコンソール上で確認できます。こちらは追加の設定等は不要で、Prisma Cloudと接続できれば表示されてきます。 Prisma Cloudコンソール画面上部にある「インベントリ」>「アセット」を選択すると確認できます。 検証したPrisma Cloud環境は、Google Cloud以外にもAWSやAzureも接続されています。 「GCP」をクリックすると各サービスごとに表示されます。さらに選択していくと、Google Cloud環境上に存在しているリソース情報の詳細を表示することができます。 まとめ 今回は、Prisma CloudにGoogle Cloudプロジェクト接続してアラート検知するところまで確認できました。 今後も、実用的な情報をお届けできればと思います。 また、当社では、複数クラウド環境の設定状況を自動でチェックし、設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。 マルチクラウド設定診断サービス with CSPM| SCSK株式会社 マルチクラウド環境のセキュリティ設定リスクを手軽に確認可能なスポット診断サービスです。独自の診断レポートが、運用上の設定ミスや設計不備、クラウド環境の仕様変更などで発生し得る問題を可視化し、セキュリティインシデントの早期発見に役立ちます。 www.scsk.jp ご興味のある方は是非、お気軽にお問い合わせください。
こんにちは。今回初めてAzureを触った薮谷です。AWS CloudFormationを利用してAWSのリソースをIaCで構築したことはありましたが、AzureのリソースをIaCで構築したのは初めてでした。 同じOSイメージを使用しAzureVMを複数たてるために、Bicepファイルを使用し、IaCで自動展開することで、設定漏れをなくし、手動で1つずつVMを作成するよりも作業時間を短縮することができます。  AzureはAWSと違い参考になる記事が少なく、経験年数の少ない自分は周りの優秀な先輩に不明点を聞きながら構築を行いました。 Microsoft公式ページにもBicepを使用したVMのIaC構築のやり方は記載がありますが、Azure初心者がこんな感じで構築を行ったというのが別のAzure初心者の方の参考に少しでもなればうれしいです。 はじめに 今回は以下の構成を実現します。 リ ソースグループ/ VNET/サブネットは手動で予め作成した上 で、同じOSイメージを使用した VM1[yabu-vm-1] と VM2[yabu-vm-2] をBicepファイルを使い、デプロイします。 OSはWindows11を使用し、グループポリシーや言語設定などがVM1とVM2にも引き継がれていることがゴールとなります。   1.Bicep拡張機能のインストール IaCのテキストエディタとしてVisual Studioコードを使用します。 未インストールの場合は こちら からインストールしてください。 Visual Studioコードをインストール済の場合は以下➀~④のソフトウェアをインストールしてください。 ➀AzureCLI Bicep の開発およびデプロイ環境のセットアップ – Azure Resource Manager | Microsoft Learn ②Bicep(Bicepコードが正しく作成されていることを検証できる便利ツール) Bicep – Visual Studio Marketplace ③Japanese Language Pack for Visual Studio Code(コメントアウトに日本語を利用できるようになる) https://marketplace.visualstudio.com/items?itemName=MS-CEINTL.vscode-language-pack-ja ④Azure Account(これがないとコードをデプロイできない) Azure Account – Visual Studio Marketplace   2.マスターVMの作成(イメージ準備) マスターVMを手動で作成します。 今回上の図で作成するVM1とVM2のイメージを作成するためにマスターVM(vm-master)を1台作成しますが、こちらのマスターVMは一般化(※後述の手順で説明します)すると起動できなくなってしまいます。 以下に今回行う設定を記述しますが、要件にあった設定を各々行ってください。 ※ 赤字の設定は同じ設定を行ってください。 VMの手動作成方法が不明の場合はこちらを参考に実施してください。 クイック スタート – Azure Portal で Windows VM を作成する – Azure Virtual Machines | Microsoft Learn [基本]タブの設定箇所 ➀ 仮想マシン名:vm-master (マスターVM名、命名は適当で大丈夫です)   ② セキュリティの種類: Standard (こちらを選択しないと今回の手順ではイメージ作成ができなくなります。)  イメージ: Windows 11 Pro, version 23H2 – x64 Gen 2   ③ ユーザ名、パスワード名:任意の値を設定します [ネットワーク]タブの設定箇所 仮想ネットワーク:作成済の「vnet-yabutani(10.101.0.0/24)」を選択 サブネット:WindowsVMSubnet(今回は10.101.0.0/25のIPで事前作成済)を選択   今回他に設定したい箇所はないので最下部の、「確認および作成」を選択します。 検証に成功しました、の表示を確認し「作成」を選択します。   3.マスターVMのOS設定 Bastionの作成 ➀OSログインのためにBastion経由で接続できるようにします。 作成したマスターVM「vm-master」に移動し、「Bastion」を選択します。   ②「Bastionのデプロイ」を選択します。 ※時間がかかります。数分ほどお待ちください。 Bastionですが使用していなくても1時間あたり課金されてしまうので使用後は削除するのを忘れないでください。 Azure Bastion Basicでも1時間あたり30円課金されてしまうので、注意。 ※画像は2024年7月31日時点のものです。最新の情報は下記URLからご確認ください。 価格 – Azure Bastion | Microsoft Azure   ③VMの作成時、[基本]タブの設定箇所-③で設定したユーザ名/パスワードを入力し、「接続」を選択します。   ④OSログインでき、Windowsのデスクトップ画面が表示されます。 OS設定 今回設定する箇所として、以下3点とします。 ・タイムゾーン ・言語設定 ・グループポリシー ➀タイムゾーン [Setting]-[Time&Language]-[Date&time]-[Time zone]へ移動し、「(UTC+09:00)Osaka,Sapporo,Tokyo)」を選択する。 ②言語設定 [Setting]-[Time&Language]-[Language&region]へ移動し、「Add a language」を選択する。 検索窓に’ja’と入力すると「日本語」が表示されるので、選択し「Next」を選択する。 [Optional language features]で以下を選択し、「Install」を選択する。 ・Language pack(言語パック) ・Text-to-speech(基本の入力) ※ダウンロードが完了するまで数分かかります。   [Setting]-[Time&Language]-[Language&region]へ移動し、[Windows diaplay language]を「日本語」へ変更する。 ③グループポリシー [Local Group Policy Editor(ローカルグループポリシーエディター) ]-[Windows Settings(Windowsの設定)]-[Security Settings(セキュリティの設定)]-[Account Policies(アカウントポリシー)]-[Password Policies(パスワードのポリシー)]へ移動し、以下の要件へ変更する。 ・Minumum password length(パスワードの長さ):8 ・Minumum password length audit(パスワードの最小文字数の監査):10   ➀~③の設定が完了した後再起動し、設定が反映されていることを必ず確認してください。 4.マスターVMのSysprep Sysprep(OSの操作) PCそれぞれに割り振られる固有情報を削除し、複数のPCに対して一貫したデータ展開を可能にするためSysprepを行います。 エクスプローラーの「C:\Windows\System32\Sysprep」に移動し、「Sysprep」をダブルクリックします。 シャットダウンオプションにて「シャットダウン」を選択し、「OK」を選択します。 PCの接続が切断されます。   Sysprep(Azureコンソールの操作) CloudshellからVMを一般化します。 Cloudshellを使用するにはストレージアカウントが必要なので、使用できるストレージアカウントがない場合は以下を参考に作成してください。 永続的なストレージを使った Azure Cloud Shell の概要 | Microsoft Learn 以降、既にストレージアカウントを作成済の前提で手順を記載します。 ➀コンソール右上の>_のようなマークがCloudshellのターミナルになります。クリックしてCloudshellのターミナルを開いてください。 ②「切り替え先PowerShell」を選択し、BashからPowerShellに切り替えます。 ③PowerShellのターミナルが立ち上がります。少し経つとプロンプトがかえってくるので、以下の一般化コマンドを実行します。 >> Set-AzVm -ResourceGroupName “リソースグループ名” -Name “先ほどSysprepしたVM名” -Generalized 成功するとStatus:Succeededと応答が返ってきます。 ④「最新の状態に更新」をクリックすると、マスターVMが開始できなくなります。 イメージ作成 起動できなくなったマスターVMからイメージを作成します。 ➀[キャプチャ]-[イメージ]を選択します。 ②「Azure コンピューティング ギャラリーにイメージを共有する」を「いいえ、マネージド イメージのみをキャプチャします。」の項目に変更して「確認および作成」を選択します。 ③「検証に成功しました」と表示されたことを確認し「作成」を選択します。 ④通知に「仮想マシンが一般化されました」という表示がされます。これで一般化が完了したことがわかります。 「リソースに移動」を選択します。 ⑤[設定]-[プロパティ]に移動し、「リソースID」をコピーします。 こちらでコピーしたリソースIDを使用し、この後イメージをBicepで展開していきます。 5.Bicepファイルを使用したVMの展開※対象:yabu-vm-1 ※対象:yabu-vm-1 Bicepを用いてマスターVMのイメージからVM1[vm-yabu-1]とVM2[vm-yabu-2]をデプロイします。 VM作成に必要なBicepはMSの公式ページを参考にしてください。 クイックスタート: Bicep ファイルを使用した Windows VM の作成 – Azure Virtual Machines | Microsoft Learn 今回は以下のコードを使用します。 ➀作成するリソースを記載したmain_test.bicep ②各リソース内の変数をパラメータとして外だしし記載したtest.bicepparam ➀main_test.bicepを記述(エディター:Visual Studio Code) // targetScope = ‘resourceGroup’ // リソースグループ(デフォルト)レベルでデプロイする場合は省略可   // 全般設定 param location string = ‘japaneast’ // デプロイするリージョン   // VMの設定 param vmName string // VMの名前 param adminUsername string // VMの管理者ユーザー名 @secure() param adminPassword string // VMの管理者パスワード   param vmSize string // VMのサイズ param vmHostName string   param osDiskName string // OSディスク名 param osDiskSize int //OSディスクのサイズ param osDiskType string // OSディスクの種類   param customImageId string // カスタムイメージのリソースID   // ネットワークインターフェースの設定 param nicName string //NIC名 param nicPrivateIP string //指定したいプライベートIPアドレス param ipConfigName string //IP構成名   // 参照する既存リソース param existingVnetName string // 既存VNet param existingSubnetName string // 既存サブネット param existingRgName string // 参照する既存リソースの所属リソースグループ   //参照する既存リソース resource existingVnet ‘Microsoft.Network/virtualNetworks@2023-06-01’ existing = {   name: existingVnetName   scope: resourceGroup(existingRgName) }   resource existingSubnet ‘Microsoft.Network/virtualNetworks/subnets@2023-06-01’ existing = {   name: existingSubnetName   parent: existingVnet }     // ネットワークインターフェースのリソース resource networkInterface ‘Microsoft.Network/networkInterfaces@2023-06-01’ = {   name: nicName   location: location   properties: {     ipConfigurations: [       {         name: ipConfigName         properties: {           subnet: {             id: existingSubnet.id           }           privateIPAllocationMethod: ‘Static’           privateIPAddress: nicPrivateIP         }       }     ]   } }   // 仮想マシンのリソース resource virtualMachine ‘Microsoft.Compute/virtualMachines@2023-09-01’ = {   name: vmName   location: location   zones: [‘1’]   properties: {     hardwareProfile: {       vmSize: vmSize     }     osProfile: {       computerName: vmHostName       adminUsername: adminUsername       adminPassword: adminPassword       windowsConfiguration: {         enableAutomaticUpdates: false       }     }     storageProfile: {       imageReference: {         id: customImageId // カスタムイメージを使用する場合に使用。       }          // OSディスクの設定       osDisk: {         name: osDiskName         createOption: ‘FromImage’         diskSizeGB: osDiskSize         managedDisk: {           storageAccountType: osDiskType         }       }     }     networkProfile: {       networkInterfaces: [         {           id: networkInterface.id         }       ]     }   } }     ②test.bicepparamを記述(エディター:Visual Studio Code) using ‘./main_test.bicep’ //ここでmain_test.bicepを参照している記述を記載   // 全般設定 param location = ‘Japan East’ // デプロイするリージョン   // VMの設定 param vmName = ‘yabu-vm-1’ // VMの名前(VMごとに変更) param adminUsername = ‘azureuser’ // VMの管理者ユーザー名 param adminPassword = ‘abcdefg’ // VMの管理者パスワード param vmSize = ‘Standard_F4s_v2’ // VMのサイズ(VMごとに変更) param vmHostName = ‘yabu-vm-1’     param osDiskName = ‘osdisk-yabu-name’ // OSディスク名(VMごとに変更) param osDiskSize = 127 //OSディスクのサイズ(VMごとに変更) param osDiskType = ‘StandardSSD_LRS’ // OSディスクの種類     // カスタムイメージのリソースID param customImageId =’サブスクリプションID/resourceGroups/rg-technologyservice-1/providers/Microsoft.Compute/images/vm-master-image-20240801154224′ //4-⑤でコピーしたイメージのリソースIDを記載する   // ネットワークインターフェースの設定 param nicName = ‘nic-yabu-name’ //NIC名(VMごとに変更) param nicPrivateIP = ‘10.101.0.11’ //指定したいプライベートIPアドレス(VMごとに変更) param ipConfigName = ‘Ipconfig-name’ //IP構成名     // 参照する既存リソース param existingVnetName = ‘vnet-yabutani’ // 既存VNet(事前手動作成) param existingSubnetName = ‘WindowsVMSubnet’ // 既存サブネット(事前手動作成) param existingRgName = ‘rg-technologyservice-1’ // 参照する既存リソースの所属リソースグループ(事前手動作成)   ③それぞれのファイルをエクスプローラーの同じフォルダ内に配置し、VisualStudioCodeからファイルを開く ④コード右上の表示される雲マークをクリックします。 test.bicepparamのファイルから選択してください。 ⑤[Deploy]をクリックします。 画面では前回リプレイスした際の情報(サブスクリプション、リソースグループ)が残っていますが、初めてデプロイする場合はAzureサインインを求められます。Azureテナントにサインインした上でVMをデプロイしたいサブスクリプション、リソースグループを選択してください。 ⑥デプロイ成功 RESULT:Succeededと帰ってきたらyabu-vm-1のデプロイ成功です。 6.Bicepファイルを使用したVMの展開※対象:yabu-vm-2 ※対象:yabu-vm-2 ➀test.bicepparamを記述(エディター:Visual Studio Code) yabu-vm-1をデプロイした際に使用したコードをそのまま流用します。test.bicepparamファイルはyabu-vm-1と2で分けて記載した方が良いです。書き換えている部分だけ赤字にしています。 ※main_test.bicepファイルの内容は変更しません。 using ‘./main_test.bicep’ //ここでmain_test.bicepを参照している記述を記載   // 全般設定 param location = ‘Japan East’ // デプロイするリージョン   // VMの設定 param vmName = ‘yabu-vm- 2 ‘ // VMの名前(VMごとに変更) param adminUsername = ‘azureuser’ // VMの管理者ユーザー名 param adminPassword = ‘abcdefg’ // VMの管理者パスワード param vmSize = ‘Standard_F4s_v2’ // VMのサイズ(VMごとに変更) param vmHostName = ‘yabu-vm- 2 ‘     param osDiskName = ‘osdisk-yabu-name- 2 ‘ // OSディスク名(VMごとに変更) param osDiskSize = 127 //OSディスクのサイズ(VMごとに変更) param osDiskType = ‘StandardSSD_LRS’ // OSディスクの種類     // カスタムイメージのリソースID param customImageId =’サブスクリプションID/resourceGroups/rg-technologyservice-1/providers/Microsoft.Compute/images/vm-master-image-20240801154224′ //4-⑤でコピーしたイメージのリソースIDを記載する   // ネットワークインターフェースの設定 param nicName = ‘nic-yabu-name 2 ‘ //NIC名(VMごとに変更) param nicPrivateIP = ‘10.101.0.1 2 ‘ //指定したいプライベートIPアドレス(VMごとに変更) param ipConfigName = ‘Ipconfig-name -2 ‘ //IP構成名     // 参照する既存リソース param existingVnetName = ‘vnet-yabutani’ // 既存VNet(事前手動作成) param existingSubnetName = ‘WindowsVMSubnet’ // 既存サブネット(事前手動作成) param existingRgName = ‘rg-technologyservice-1’ // 参照する既存リソースの所属リソースグループ(事前手動作成)   コードを書き換えたら、yabu-vm-1と同様の手順(5-③~⑤の手順)を再度実行してyabu-vm-2をデプロイしてください。 ②コンソール画面での確認 yabu-vm-1とyabu-vm-2がそれぞれ指定したリソースグループ、サイズ、OS、プライベートIP、VNETにて作成されていることを確認できました。 ※コンピュータ名についてはマスターVM(vm-master)の名前が引き継がれてしまいます。OSログインした上でホスト名を手動で任意の名前に変更してください。 7.Bicepファイルを使用したVMにOS設定が複製されているか確認する 3.マスターVMのOS設定にてvm-masterに設定したOSの設定がyabu-vm-1とyabu-vm-2に引き継がれているか確認します。 ※今回はyabu-vm-1のみの確認となります。 3-③の手順同様[VM]-[接続]-[Bastion]からyabu-vm-1のBicepで指定したユーザ名とパスワードを入力し、Bastion経由でyabu-vm-1のOSにログインします。 ➀タイムゾーン: ②言語設定 ・Language pack(言語パック) ・Text-to-speech(基本の入力) がインストールされており、表示も日本語の状態でデプロイされている。   ③グループポリシー ・パスワードの長さ:8文字以上 ・パスワードの最小文字数の監査:10文字 上記設定がマスターVM(vm-master)から引き継がれて、他のポリシーはデフォルトのままであることを確認できている。   おわりに 同じOSイメージを使用した VM1[yabu-vm-1] と VM2[yabu-vm-2] をBicepファイルを使い、デプロイすることができました。 マスターVMで設定したOSの各種設定(タイムゾーン/言語設定/グループポリシー)がVM1とVM2にも引き継がれていることを確認することができました。
こんにちは。SCSK の樋口です。 デジタルイノベーションの総合展『CEATEC 2024』が、今年も千葉県の幕張メッセで開催されています。 CEATEC(シーテック) は日本最大級の展示会として有名で、2024年の今年は、10月15日(火)~18日(金)の計4日間、国内外から808もの団体が、先進技術やイノベーションの種を展示しています。 実は、当社SCSKも、CEATEC にブースを出展しています。 そして、この私が CEATEC の出展リーダーをしています。 この記事では、CEATEC 2024 における SCSK ブースの概要について、現地から速報でお届けいたします。 「現場レポート動画」も作りました。 SCSK ブースの様子を、動画でもご理解いただけます。                         CEATEC の様子 とにかく会場が大きいです。 ホール3から8まで、実質6ホールがCEATECの会場で、端から端まで歩くだけでも時間がかかります。 加えて、併設の「Japan Mobility Show Bizweek」も加えると、ホール1から8までの展示会となり、幕張メッセの会場全てが CEATEC とも言えるような状況です。   SCSK ブースの様子 SCSK のブースは、ホール3-016 にあります。 横幅が9メートルあり、CEATEC全体の中では中規模なブースです。 大きな通路に面した分かりやすい場所にあるのが、個人的にポイント高いです。 お客さんが来てくれるかどうか、準備段階ではとてもヒヤヒヤしていたのですが、 いざ始まってみると、 朝10時の開場からSCSKブースは大盛況で、リーダーの私は感激しています。     SCSK の出展内容 SCSK のブースでは、製造業のお客様向けに、 製造現場におけるデータの「収集」「可視化」「分析」そして「異常検知」を支援するソリューションの「Duetics(デュエティクス)」を紹介 しています。 各機能について、コーナーごとに分けて詳しく紹介をしています。 分析コーナー:多変量解析アプリケーション 製造現場で発生するデータを分析するのが、「多変量解析アプリケーション」です。 工場にあるPLCやセンサーのデータを分析することで、不良品の原因や機器の故障原因を特定し、生産性の向上と品質改善につなげることができます。 CEATECでは、製造現場を再現したミニチュア工場を動かしながら、データの取得、可視化、分析のデモンストレーションを行い、生成AIを実装した分析機能もご紹介しています。 詳しくはこちら: https://www.scsk.jp/product/common/duetics/index.html   可視化コーナー:製造業デジタルツイン 製品や工場全体を、デジタル空間上で精緻に再現するのが、「製造業デジタルツイン」です。 デジタルツインを作ることで、仮想空間上で様々な検証を行うことができるので、現実世界での製造ラインの立ち上げや切り替えを早めることなどが可能です。 CEATECでは、物理的なミニチュア工場と、バーチャル空間上に構築したデジタルツイン工場との連携をお見せすることで、お客さんに具体的な活用イメージを提供しています。 詳しくはこちら: https://www.scsk.jp/sp/nvidia/omniverse/index.html 収集コーナー:自律分散型 IoT ネットワーク IoT機器向けの自律分散型ネットワーク技術が「CollaboView」です。 SCSKグループの Skeed 社が持つP2P通信技術を用いて、製造機器のデータを、低電力かつ効率的に、障害にも強い方法で収集する技術です。 CEATEC では、人感センサーで人を検知すると、CollaboView のネットワークを経由してサーバに情報を送信し、パトランプを光らせるデモンストレーションを実施しています。 詳しくはこちら: https://collaboview.scsk.jp/ 異常検知コーナー:異常検知ソリューション 設備の故障予兆や不良品の検出に使えるのが、製造業向けの「異常検知ソリューション」です。 様々な機能を搭載しており、面白いものだと、工場作業員の作業工程の動画から、組み立て手順のミスを見つける。といったことも可能です。 詳しくはこちら: https://www.scsk.jp/news/2024/pdf/20240927.pdf 最後に & お問い合わせ先 この記事では、CEATEC 2024 が開催中の幕張メッセから、SCSK ブースの出展内容を速報でご紹介いたしました。 会場全体がものすごい熱気ですが、当社 SCSK の担当者たちも、ほぼフル回転でお客さん対応にあたっています。 詳しい話を聞きたいと思った際には、ぜひ幕張メッセのホール3-016 SCSKブースまで足をお運びください。 また、以下のメールアドレスからお問い合わせをいただいても構いません。(TechHarmony の記事を見た。と記載ください。) SCSK 株式会社  Duetics 担当 duetics-sales@scsk.jp 最後まで読んでいただき、ありがとうございました。 ※ 本記事の内容は、CEATEC 2024 の Day2 と Day3 に基づきます。今後変更が発生する可能性もございます。 #SCSK は #CEATEC 2024 に出展しています。 製造業向けの、デジタル化ソリューションを紹介中! 10月18日(金)まで。幕張メッセ ホール3-016でお待ちしております! @umeno_senri @moe_hoshino https://t.co/xGQXCjG1rY pic.twitter.com/Fv4wolys3B — SCSKクラウドソリューション【公式】 (@SCSK_Cloud) October 17, 2024  
これからCatoクラウドが新たに導入予定の「自然言語検索によるイベントフィルタリング」機能を、先行して使ってみました。 ・ 自然言語検索(EA)によるイベントのフィルタリング この機能は、複雑なクエリやコマンドを使わずに、日常の言葉でイベントデータを検索できるというものです。 これまでの検索方法は、自分で適切なフィルタを決める必要がありました。 用意されているフィルタの数は膨大で、いったいどれを指定すればよいのか、一度は迷ったことがあるのではないでしょうか。 新機能では、検索バーに自然言語でクエリを入力すると、AIエンジンがそのクエリをフィルタに変換し、関連するイベントデータを表示します。 なお、今回利用した段階では日本語未対応でしたが、今後の機能追加が予定されています。 今回の利用では、ユーザが実際に入力しそうな日本語を DeepL で英語翻訳した結果を、そのままコピペして試しています。 それでは、この新機能の使い方や実際に試してみた結果について詳しく紹介していきます。 使い方 使い方は簡単で、フィルタを入力する欄の右端🔍虫眼鏡アイコンをクリックすると、文字が入力できるようになります。 ここで表示したいログを指示します。 試してみる それでは、実際に試してみます。 Cato社紹介のユースケースから まずはCato社の 新機能紹介ページ で説明されているユースケースの通りに入力してみて、想定通り動作するか見てみます。 今回は2パターン見てみました。 ゲームカテゴリの URL からのインターネットファイアウォールのセキュリティイベントを表示する 「Show me Internet Firewall security events from game category URLs」 【フィルタ結果】 Event Type:Security Sub Type:Internet Firewall Category:Games 続いて2つめ。 アプリケーションの脆弱性と脅威に関連する最近のセキュリティインシデントとアラートを表示する 「Show recent security incidents alerts related to anti-malware」 【フィルタ結果】 Event Type:Security Sub Type:Anti Malware 結果として、Cato社が紹介している例ということもあり、問題なく2例とも想定通りのフィルタがかかりました。 また、文字を入力してから、フィルタが決定されるまで体感1秒程度でした。 手動でフィルタするよりも明らかに早く、利便性がかなり高いと言えます。 エンドユーザ目線で ここからは、実際にいただいたお問い合わせをもとに、私自身でユースケースを考えてみました。 色々と日本語・英語をチューニングして試しています。 あるユーザが特定のサイトへアクセスできない 私(なかがわ きょうすけ)が、任天堂のサイトへアクセスしてブロックされた結果を表示できるか試してみます。 中川さんが任天堂のサイトが見られなくて困っている。見られない。 「Mr. Nakagawa is having trouble viewing Nintendo’s website.」 「Mr. Nakagawa can’t see Nintendo’s website.」 結果はフィルタできず。フィルタ指定に失敗すると以下のエラーになる。 「 Error – unsupported filters The search engine returned a response, but your request uses unsupported filters and can’t be displayed. Please check the filters and try again.」  あまりに口語的な表現をすると、失敗してしまうようです。 次に、Cato社の紹介例のように、ログが見たいという意図を伝えてみます。 中川さんが任天堂のサイトにアクセスできなかったので、そのログが見たい。 「Mr. Nakagawa accessed Nintendo’s website and would like to see the blocked logs.」 【フィルタ結果】 Action:Block Domain Name:nintendo.com フィルタはかかるが、ユーザ指定するには情報が足りないのかフィルタできず。 ドメイン名はフィルタされたが、 www. nintendo.comのログが見たいため不十分。 今度は、ユーザ名とドメイン名を正確に入力してみる。 中川恭介さんのwww.nintendo.comのドメインでブロックされたログが見たい。 「I would like to see the log of Kyosuke Nakagawa’s www.nintendo.com being blocked.」 【フィルタ結果】 Domain Name:www.nintendo.com Action:Block User Display Name:Kyosuke Nakagawa ようやく、満足のいく結果に。 まだ正確な情報で入力する必要があり、”よしなに”フィルタをかけることは難しそうです。 日時指定でブロックされたログが見たい 今度は日時指定ができるか試してみます。 10月2日にブロックされたイベントが見たい。 「I would like to see an event blocked communication in 2nd October.」 【フィルタ結果】 Action:Block 日時指定:10/2 0:00~23:59 右上の日時指定が更新され、アクションもきちんとブロックで指定されました。 今度は、少し表現を複雑に変えてみます。 10/2の午前中にブロックされたイベントが見たい。 「I would like to see an event on the morning of 10/2 with blocked communication.」 【フィルタ結果】 Action:Block 日時指定:10/2 0:00~12:00 「2nd October」を「10/2」に変更し、午前中という表現も加えてみましたが、きちんとフィルタされました。 日時指定の表現はいくらか融通が利きそうです。 あるアプリの操作をブロックしているログを見たい 最後に、セキュリティオプションのCASB機能でブロックされたログが見られるか、確かめてみたいと思います。 今回は、Gmailにてファイル添付をブロックしているログを見てみたいと思います。 結果として、一筋縄ではフィルタされず、色々と表現を変えながら試すこととなりました。 まずは、以下に失敗したスクリプトをご紹介します。 ファイル添付がブロックされた / できなかったログが見たい 「I would like to see a log of blocked file attachments in Gmail.」 「I would like to see a log of files that could not be attached in Gmail.」               Gmailアプリのファイル添付に関するログが見たい 「I want to see logs about file attachments in the application “Gmail”.」 Gmailに関するログが見たい 「I want to see logs about Gmail.」 「I want to see logs with application name Gmail.」 ここで、「Gmailに関するログが見たい」という単純な表現に変えても出力されず。 Gmailという表現をここであきらめて、Googleに広げて聞いてみました。 Googleに関連するアプリケーションのログが見たい。 「I would like to see logs of google related applications.」 【フィルタ結果】 Application:Google Drive、Google ようやくフィルタがかかりましたが、Google DriveとGoogleのみで、なぜかGmailは含まれませんでした。 英語の表現が適切でないと感じ、Gmail に関する(about,with) ではなく、Gmail 上(on) のログという表現に変えてみました。 Gmailアプリ上でブロックされたログが見たい 「I would like to see the blocked logs on the gmail application.」 【フィルタ結果】 Action:Block Application:Gmail すると、ようやく、Gmailでブロックされたログにフィルタされました。 続いて、ファイル添付がブロックされたログが見られないか、スクリプトを考えていきます。 Gmailアプリ上で、ファイル添付がブロックされたログが見たい 「I would like to see a log of blocked file attachments on the gmail application.」 【フィルタ結果】 Action:Block Application:Gmail ファイル添付はくみ取ってもらえず、「Gmailでブロック」のフィルタのみとなりました。 次に、Gmailは一旦あきらめて、イベントフィールドの値を「ファイル添付」で指定するようなスクリプトにしてみます。 アプリケーションアクティビティがファイル追加のログが見たい I would like to see a log of the application activity add attachment.× 残念ながらエラーの結果に。。 他にも色々と表現を変えながら試しましたが、「ファイル添付」でフィルタしてもらうことは出来ませんでした。。 諦めようとしたその時、気づきました。 新機能紹介ページ によると、そもそもApp Activityが今後追加予定のフィールドになっていることに。。 想定していた全てのフィルタを設定することはできず、残念でしたが、 自然言語では未対応のフィルタとわかったため、気持ちよくあきらめることができました。 また、その他の注意点として、同じスクリプトを入力しても、時間を空けるとフィルタの結果が変わったり、場合によってはフィルタ出来なくなったりすることがあります。 【補足】単語のみでフィルタ可能か? ちなみにですが、以下のように、文ではなく単語の列挙に近い記載でフィルタできるかも試してみましたが、結果はあまり芳しくありませんでした。 最低限、所有の’s や前置詞は記載する必要があるようです。 検索ワード フィルタ結果 Block × block event 〇 Action:Block IPS 〇 sub-type:IPS sub-typeに登録されているキーワードであれば、単語のみの検索でも比較的表示されました。 today ips block 〇 日時:当日午前0時から現在時刻 Event-Type:Security sub-type:IPS Action:Block today nakagawa block× × today’s nakagawa block event × today’s block event of Nakagawa 〇 日時:当日午前0時から現在時刻 User Name:Nakagawa Action:Block Kyosuke Nakagawa www.nintendo.com Block × Kyosuke Nakagawa’s Block event to www.nintendo.com 〇 User Name:Kyosuke Nakagawa Action:Block Domain Name:www.nintendo.com   まとめ 率直に、予想していたよりもフィルタを効かせることはできるな、という感想を持ちました。 ただし、生成AIのチャットボットを利用する際も同様ですが、スクリプトにはコツが要ります。 慣れるまでは、今まで通り手動でフィルタする方が早いかと思います。 今後、Cato内のAIが学習を進め、ラフな自然言語でも読み解いてくれて、 上手くフィルタしてくれるようになるまで成長してくれるといいです。
はじめに 今回はPrisma CloudのCWPP領域のセキュリティ機能であるランタイム防御(Runtime Defense)でLambda関数を監視し、 許可していないプロセスの起動を拒否してみようと思います。 そもそものCWPPについて知りたい方は弊社、鎌田の以下記事が参考になると思います。 Prisma Cloud の主要機能の1つ CWPP のアーキテクチャを解説 また、ランタイム防御を設定するためには、事前にLambda関数にディフェンダー(エージェントのようなもの)を導入する必要があります。 本記事ではディフェンダーがLambda関数に導入済みである前提で、導入手順については記載しません。 ディフェンダーの導入手順については弊社、渡邊の以下記事が参考になると思います。 【CWPP】Prisma Cloud のサーバーレスディフェンダーの導入方法 本記事はPrisma Cloudのランタイム防御に関する以下公式ドキュメントを参考に作成します。 Runtime Defense for Serverless Functions (prismacloud.io)   ランタイム防御でできること ランタイム防御では、コンテナに対する予測的保護と、実行中のコンテナ、ホスト、サーバーレス機能に対する脅威からの保護を提供しています。 予測的保護は、コンテナが元のイメージに含まれていないプロセスを実行したり、予期せぬネットワークソケットを作成したりする際に、それを検出してくれます。 脅威からの保護は、ワークロードにマルウェアが追加された場合や、ワークロードがボットネットに接続する場合に、それを検出してくれます。 ランタイム防御では検出以外にも、プロセス、ネットワーク、ファイルシステムにおけるアクティビティを許可、拒否することができます。 本記事では実際に、ランタイム防御でLambda関数のプロセスのアクティビティを拒否してみます。   サーバレスランタイムポリシー まずは、サーバレスランタイムポリシーを作成します。 本ポリシーでランタイム防御で利用する機能や防御対象とするLambda関数などを指定します。 「Defend > Runtime > Serverless policy」を開き、「Add rule」をクリックします。 ポリシーのルール画面が表示されます。 Scopeではランタイム防御の対象を設定することができます。この対象をcollectionと呼びます。 Scopeの「Click to select collections」をクリックします。   collectionを選択して、「Select collections」をクリックします。 今回は既に作成していたcollectionを選択しますが、右上「Add collection」で新たにcollectionを作成することもできます。   ポリシーを作成できたので、ここからはランタイム防御でプロセスのアクティビティを拒否してみます。   許可していないプロセスの起動を拒否 それでは、許可していないプロセスがLambda内で起動するのを拒否してみます。 実行するプログラムはPythonのsubprocessモジュールを使って、「ls -l」コマンドを実行するプロセスをLambda内に立ち上げ、その結果を返すプログラムとなります。 ランタイム防御の適用前にプログラムを実行すると以下が出力されます。 ポリシーは以下設定とします。Lambda内でPythonプロセス以外はプロセスが立ち上がらない設定としました。 ポリシーを保存した後、TW_POLICY環境変数を取得し、Lambdaに設定することでポリシーが適用されます。 ※TW_POLICY環境変数の取得方法は弊社渡邊の以下記事に記載があります。 【CWPP】Prisma Cloud のサーバーレスディフェンダーの導入方法 Lambdaを実行したところ失敗し、「ls -l」コマンドを実行するプロセスが立ち上がらなかったことが分かります。   検知結果の確認 ランタイム防御でポリシー違反をおこしたリソースを確認できます。 「Monitor > Events」を開き、検知行をクリックすると検知の詳細が表示されます。   まとめ 本記事では、Prisma CloudのCWPP領域のランタイム防御(Runtime Defense)でLambda関数を監視し、 許可していないプロセスを拒否してみました。本記事でPrisma Cloudを利用することのメリットが伝わりましたら幸いです。 また当社ではPrisma Cloud利用して、複数クラウド環境の設定状況を自動でチェックし、設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。 https://www.scsk.jp/sp/cloud_diag/ ご興味のある方は是非、お気軽にお問い合わせください。
こんにちは。SCSK 中山です。   今回はちょっとニッチな記事にはなりますが、CatoクラウドのStand-alone Countries(単独で価格設定されている国)である、中国/ベトナム/モロッコのサイトをご利用の方向けにライセンス毎の帯域利用量を確認する方法を記事として書きたいと思います。 一応、中国/ベトナム/モロッコのサイトをご利用の方向けではありますが、他にも応用が利くかもしれない内容ではあるので、使っていない方も記事を読んでいただけると幸いです。   その前に何故中国/ベトナム/モロッコのStand-alone Countriesに限った話をしているかというと、 通常、Catoではライセンスをサイトごとに帯域のライセンスを提供しておりますが、中国/ベトナム/モロッコに限っては国内/国外の通信ごとでライセンス(Regional/Global)に分かれており、1つのサイトでもRegional/Globalのライセンスを契約する必要があります。そのため普通にCatoを使って通信をしていても、この通信はRegionalのライセンス側の帯域を利用していて、あの通信はGlobalのライセンスを使っているということが起こります。 これだけなら問題ないのですが、通信が遅い等でライセンスごとの帯域の利用量を確認しようとすると、現在(2024/9月時点)のCatoの機能では直接ライセンスごとの帯域使用量を確認できないため、チューニングが難しい状況です。 そこで、ちょっと工夫して事前に設定を行うことで各ライセンスごとに確認することができるようになるため、今回はその方法を紹介したいと思います。   通信要件の整理 設定・確認方法に行く前に通信要件を整理したいと思います。 お客様ごとに通信要件は異なるかと思いますが、一旦、日本拠点が1つとベトナム拠点が2つのみ設定しているという想定で記載したいと思います。 先程、国内/国外でごとでライセンスが分かれると記載しましたが、正確に言うと国内/国外の判定はどこの国へ通信するかではなく、どこのPoPから出ていくかで決まります。 そのため、様々な通信があるかと思いますが、Regional/Global Licenseの観点で整理すると、基本的には以下の①~③になるかと思います。加えて何かの要件で別のPoPから出ていく必要がある場合には、④も発生するという具合になります。 ①ベトナムサイト⇒ベトナムサイト ②ベトナムサイト⇒日本サイト ③ベトナムサイト⇒Internet(ベトナムPoP) (④ベトナムサイト⇒Internet(その他PoP))   上記①~④のうち、①③にRegional License、②④にGlobal Licenseが適用されます。 ※ここではベトナム想定で記載をしておりますが、中国でサイトを作成する場合も同様のライセンス形態をとっており、中国の場合はGreat Firewallがある関係でGoogleアプリ等を利用する際には別PoPからアクセスする必要があるため、中国の場合には④も必須かもしれません。   事前設定 通信要件が整理できたので、事前設定をしていきたいと思います。 今回設定する内容はBand widthのPriorityをタグのように設定し、通信要件で整理した①~④をRegional/GlobalのLicenseごとにNetwork RuleでBand widthのPriority割り振っていくという内容になります。 1.CMAより、「Network」>「Bandwidth Management」を開き、新規で2つRegional/Global License用の「Priority」を作成します。   各サイトのRegional/Globalのライセンス分Priorityの割り当てを行う必要があるので、今回は以下のように4つ設定し、それぞれ用途に合うように割り当てをしていきたいと思います。 P50 :ベトナムサイトA/Regional P60 :ベトナムサイトA/Global P70 :ベトナムサイトB/Regional P80 :ベトナムサイトB/Global        ※ベトナムサイトBの設定については、ベトナムサイトAと手順が同様のため以降の手順では割愛します。 2.「Network」>「Network Rules」を開き、1サイトにつき以下3つのルールを作成します。(④がある場合には4つ作成します。) 用途 ①ベトナムサイト ⇒ベトナムサイト (サイトA⇒サイトB) ②ベトナムサイト ⇒日本サイト ③ベトナムサイト ⇒Internet(ベトナムPoP) ④ベトナムサイト⇒Internet(その他PoP) Type WAN WAN Internet Internet Source ベトナムサイトA ベトナムサイトA ベトナムサイトA ベトナムサイト Destination ベトナムサイトB Any Any <要件次第> Bandwidth Priority P50 P60 P50 P60 これで設定自体は完了になります。 この設定を行ったことで、設定したサイトのRegionalの通信は P50 、Globalの通信は P60 に集約することができました。   トラフィックの確認方法 Regional/Globalの通信をP50/P60に割り当てしましたので、P50/P60のトラフィックを確認することで、各サイトのRegional/Globalのトラフィックを確認します。   1.「Network」>「Sites」より、確認したいサイトをクリックします。   2.左ペインより「Priority Analyzer」をクリックします。   3.上記で設定したPriorityを展開しますと、選択した期間に通信が発生している場合、トラフィックがグラフで確認できます。   ※選択した期間内に通信が発生しているのにも関わらず、表示されない場合は別のNetwork Ruleによって割り振りがされていない可能性があります。その場合にはEvent等を確認し、どのルールが適用されているか確認し、調整する必要があります。   まとめ 今回はベトナム/中国サイトのトラフィックの見方についてご紹介いたしました。 現時点、きちんと中国/ベトナム/モロッコサイトも帯域の管理をしようとすると、今回紹介した方法くらいしかないと思いますので、ご利用の方は検討してみては如何でしょうか。 ただし、Network Ruleを変更することもあり、既存の通信にも影響が出かねないので、変更にあたっては十分注意していただくようお願いいたします。
こんにちは、SCSKの吉田です。 今年もServiceNow社の年次イベント「 ServiceNow World Forum Tokyo 2024 」が開催されます。 当社はGoldスポンサーとしてブース出展しますので、ご案内いたします! 開催日:2024年10月15日(火)-10月16日(水) 会場:ザ・プリンスパークタワー東京 イベント内容:基調講演、事例セッション、パートナー企業による展示ブースなど イベントの詳細、参加登録は以下をご確認ください。 ServiceNow World Forum Tokyo 2024 SCSKブースのご紹介 SCSKのブースでは、ServiceNowの ESG・GRCソリューションの紹介や機能デモ を実施いたします。 ESG(環境・社会・ガバナンス)・GRC(ガバナンス・リスク・コンプライアンス)ソリューションは企業のESGの取り組みとリスクを、効率的に管理、追跡、報告するための強力なツールです。 2027年に見込まれるESGやGRCなどサステナビリティ情報の開示義務化、企業のグルーバル化やDX等により出現した多種多様なリスクの管理、法規制強化への対応など、企業のサステナビリティ経営を取り巻く状況は大きく変化しています。 そのため、企業にはこれら環境の変化に迅速に対応しつつ、サステナビリティ経営を推進することで、持続可能なビジネス成長を実現することが求められます。 SCSKでは、大規模・グルーバルでの導入実績、導入から運用改善までのフルラインアップにより、お客様の要件に合わせた最適なESG・GRCソリューションを提供します。 以下に該当する方は是非、当社ブースにお立ち寄りください! ESG、GRCなどサステナビリティ情報の収集・管理が何故企業にとって重要なのか知りたい方 サステナビリティ経営に関わる業務にお悩みを抱えている方 ServiceNowのESG、GRCソリューションに興味を持っている、導入を検討している方 また、当社ではESGやGRC以外のServiceNowソリューションも多く扱っておりますので、お気軽にご相談ください。 詳細は以下HPをご参考ください。 ServiceNow ServiceNowは、企業の生産性向上や業務プロセス改善を支えるサービスマネジメントクラウドソリューションです。従業員満足度・顧客満足度の向上、業務効率化を強力に支援します。 www.scsk.jp
Catoでは、モバイルユーザ用に用意されたアドレスレンジの中から動的にモバイル端末にアドレスを割り振ることによりモバイル接続が可能となります。そのモバイルユーザ用に用意されたアドレスレンジはデフォルトで10.41.0.0/16に設定されています。 つまり、デフォルト設定のままモバイルユーザがCatoクラウドに接続をすると10.41.0.0/16の中からランダムにアドレスが割り当てられます。実際に試してみると10.41.0.0/16の中から10.41.17.227が割り当てられました。 デフォルトではこのように動的な割り当てになっていますが、ある特定のユーザに対して固定IPを割り当てることができるので今回はその設定方法や注意点についてまとめていきます。 設定上の注意点 設定するにあたり注意点があるので先にお伝えします。 固定IPを割り当てる場合は 動的IPレンジ (デフォルト設定:10.41.0.0/16) と は重複しないようにアドレスを設定する必要がある 点に注意が必要です。 また、Catoでは1ユーザアカウントで3台まで同時接続が可能ですが、 固定IPは1ユーザアカウントに対して1つだけ 割り当てられます。そのため、2台同時接続した場合は片方の端末には動的IPレンジからの割り当てになります。 では、上記を踏まえて実際に設定および動作確認をしてみます。 固定IPの利用シーン 固定IPは通常、ヘルプデスクがリモートデスクトッププロトコル(RDP)を使用してユーザーの端末にアクセスする際や、共有フォルダへのアクセスが必要な場合に主に利用されますよね。 他にも、古い セキュリティ制御システム(Firewall)をご利用されていてIPアドレスで制御する必要がある場合などでも使われているかもしれません。 Catoでも同じ用途で利用します。 今回は、ヘルプデスクがRDPを使用してユーザーAの端末にアクセスするというシナリオで、ユーザAに固定IP 192.168.2.1を割り当て、接続を試してみました。 設定方法 まず2つの端末にCatoクライアントをインストールし、それぞれCatoクラウドに接続をさせます。 ※この手順は長くなるので割愛しますが、ご不明な方はこちらの記事をご参照ください。 Catoクラウド はじめの一歩 次に、ユーザAに対して固定IPを割り当てていきます。 設定箇所はAccess>IP Allocation Policyです。 手順は以下の通りです。 有効化 デフォルトでは無効になっているので、有効化します。 アドレスレンジの設定 今回の例の場合は、192.168.2.0/24を設定します。 アドレスの割り当て 対象のユーザをプルダウンで選択し、先ほど設定したアドレスレンジ(192.168.2.0/24)の中から1つアドレスを割り当てます。 今回の例の場合は、192.168.2.1を設定します。 その後、「Add」ボタンから追加を行います。 保存 設定内容を確認し保存を行います。 これで設定は完了です。 動作確認 設定を行ってから約5分後、ユーザAのクライアントは自動的に再接続が行われ、アドレスは192.168.2.1に変更されました。 次にこのユーザAの端末へ、ヘルプデスク用の端末からRDP接続を試してみます。 まず、ヘルプデスク用の端末でCatoクライアントを起動し、Catoクラウドに接続します。 ヘルプデスク用のユーザ(ユーザB)には固定IPを割り当てていないので動的IPの10.41.142.3が割り当てれられました。 このヘルプデスク用の端末からユーザA(192.168.2.1)に対してRDP接続を試してみます。 すると、このように無事接続できました。 ちなみに、この時のログはきちんと残っていました。 まとめ 今回、動的IPにて接続された状態で固定IPを割り当てた場合の挙動が気になり、接続状態で固定IPを設定してみました。 結果としては、自動的に再接続が行われ断時間はほとんどありませんでした。 個人的にはなんとなく、切断してから設定する方が安全なのでは?と思っていましたが、断時間がほとんどないことから切断せずに固定IPを割り当てる方が断時間は短いので、切断する必要は特にないと思いました。 もちろんはじめから固定IPを割り当てることが決まっている場合などは切断されている状態から固定IPを設定するでも全く問題はないと思います。 また、2台同時接続を行った場合は仕様通り、1台目の端末が192.168.2.1を持ち続け2台目の端末には動的IPレンジから10.41.179.103が割り当てられました。つまり固定IPが必要な端末数に合わせてユーザを作成する必要があるということなので、ライセンス数も検討が必要だなと感じました。 最後に固定IPの設定をする際のポイントをまとめて本記事は終わりにします。 動的IPレンジに設定されているアドレスレンジと重複しないように設定をする 動的IPにて接続した状態で固定IPを割り当てた場合、固定IPを使って自動的に再接続され通信断時間はほとんどない 2台同時接続した場合、固定IPが割り当てられるのは最初に接続を行った1台のみで、2台目には動的IPレンジから割り当てられる おわりに 今回、モバイルユーザのアドレス設定についてまとめてみました。 Catoクラウドを導入する際にお役立ていただければ幸いです。
こんにちは。SCSKのふくちーぬです。生成AIが盛んな中、なかなか最新のアップデートについていけていない方は多いのではないでしょうか。私もその中の1人です。。 今更ながらですが、生成AI・Amazon Bedrockに入門してみようと思います。2024年にリリースされたChat with your documentを一緒にみてみましょう。 用語解説 簡単に用語から整理したいと思います。 生成AIとは テキストや画像、音楽等新しいコンテンツを生成できる技術を指します。 ハルシネーションとは 生成AIが事実とは異なる間違った回答をしてしまうことを指します。 生成AIが事実とは異なる回答を自信ありげに提供してしまうことがあるため、私たちユーザーはその回答が真実かどうか判断することが求められています。 この現象は、生成AIが利用している基盤モデルの学習済みのデータには、該当の情報が存在しないため発生してしまいます。 RAGとは RAGは「Retrieval-Augmented Generation」の略で、検索と生成AIを組み合わせた技術です。 質問に関連するドキュメントと質問文を生成AIに読み込ませることで、そのドキュメント情報を元に、応答するコンテンツの作成が可能になります。この手法を使うことで、より正確で信頼性の高い応答が可能となり、ハルシネーションを抑制することに繋がります。 RAGの利用用途として、カスタマーサポートが挙げられます。あらかじめFAQや製品仕様書を読み込ませておくことで、ユーザーに適切な回答を提供することが可能となり、ユーザーヘルプデスク体制の効率化を図ることができます。 AWSでのRAGの選択肢 AWSで実現する選択肢として頻繁に利用されるサービスとして、以下が挙げられます。 どれもデータベースの準備が必要のものとなり、ある程度の技術が要求されます。 Amazon Kendraを利用する Amazon Bedrock Knowledge Basesを使う 2024年4月にリリースされたChat with your documentでは、データベースを作成することなく、RAG の仕組みを簡単に利用できます。 Amazon Bedrock のナレッジベースで個々のドキュメントから簡単に質問できるようになりました aws.amazon.com Amazon Bedrock Knowledge Bases now simplifies asking questions on a single document | Amazon Web Services At AWS re:Invent 2023, we announced the general availability of Amazon Bedrock Knowledge Bases. With Amazon Bedrock Know... aws.amazon.com Chat with your documentを利用した検証 今回はChat with your documentの機能で、簡単にRAGの世界を体験してみます。 モデルアクセスの有効化  サポート対象である、バージニア北部リージョンにて作業を実施します。 Bedrockコンソール上で、「モデルアクセス」ペインを押下します。 Anthropic社の”Claude 3 Sonnet”が利用できるか確認します。 “リクエスト可能”であった場合は、「モデルアクセスをリクエスト」を押下します。 “アクセスが付与されました”であった場合は、本作業は必要ありませんので、次のセクションに移ってください。   “Claude 3 Sonnet”にチェックマークが付いていることを確認します。   「Next」を押下します。   内容を確認して、「Submit」を押下します。 少々時間を置いた後再度「モデルアクセス」ペインを開くと、”Claude 3 Sonnet”に”アクセスが付与されました”が表示されます。 これでClaude 3 Sonnetの基盤モデルが利用できる準備が整いました。 RAGを利用しない一般的なチャットの場合 プレイグラウンド内の「チャット」ペインを開きます。 モデルの選択画面にて、”Claude 3 Sonnet”を選択し、「適用」を押下します。 プロンプト入力画面にて、以下の文章を入力してみます。 AWS Summit Japan 2024は、いつどこで開催されましたか?     AWS Summit 2023については、ハルシネーションが発生していますね。AWS Summit 2023は、2023/4/20,4/21に開催されています。 AWS Summit 2024についても、既に開催済みなはずですが、ハルシネーションとは言わないまでも、想定していた回答が返却されません。 Claude3のモデルは、2023年8月までのデータを学習済みですが、それ以降の出来事は学習されていません。 そのため、上記のような結果になったことが分かります。 https://blog.usize-tech.com/contents/uploads/2024/10/Model_Card_Claude_3.pdf RAGを利用したチャットの場合 オーケストレーション内の「ナレッジベース」ペインを開きます。 モデルの選択画面にて、”Claude 3 Sonnet”を選択し、「適用」を押下します。 Dataの画面にて、下記のAWS Summit資料をアップロードします。 https://blog.usize-tech.com/contents/uploads/2024/10/AWS-Summit-Tokyo-2024-EXPO-Guide.pdf 先程と同様にプロンプト入力画面にて、以下の文章を入力してみます。 AWS Summit Japan 2024は、いつどこで開催されましたか? AWS Summit Japanは、2024 6/20,6/21に幕張メッセにて開催されましたよね。上記のように正しい回答が返却されることを確認できました。 Chat With your documentの留意点 対象リージョン:バージニア北部、オレゴン、ムンバイ、シドニー、アイルランド、ロンドン、パリ、カナダ、サンパウロ 対象基盤モデル:Claude 3 Sonnet ファイルの種類: PDF、MD、TXT、DOC、DOCX、HTML、CSV、XLS、XLSX。 10 MB 未満のファイル制限があります。 10 MB 未満のテキスト中心のファイルでも、設定された20,000個のトークン制限を超える可能性があります。 ドキュメントやそのデータは基盤モデルには、保存されません。そのため、他のユーザーに利用してもらうためにはきちんとデータベースとして用意してあげる必要があります。 Chat with your document without a knowledge base configured - Amazon Bedrock Learn how to test play an Amazon Bedrock knowledge base without the need to configure a knowledge base. docs.aws.amazon.com によるモデルサポート AWS リージョン - Amazon Bedrock 次の表はFMs、他の リージョンで使用できる と、各リージョンでサポートされているかどうかを示しています。 docs.aws.amazon.com 最後に いかがだったでしょうか。 Amazon Bedrockの Chat with your documentを利用することで、RAGの難しい構成を意識することなく容易に体験することができました。 機会があれば、自分でもデータベースを作成しRAGを利用していこうと思います。 本記事が皆様のお役にたてば幸いです。 ではサウナラ~🔥
どうも、SCSK齋藤です。 今回は、Amazon SQSから直接AWS Lambdaを呼び出す際に意識するポイントを3つ紹介します。(個人的につまづいたポイントです。。) Lambda側でSQSからのメッセージを受信する権限が必要 とっても当たり前ですが、忘れがちなポイントです。 具体的には、受信以外にもいろいろな権限が必要になります。 ざっくりと必要な権限は下記です。 {  "Version" : "2012-10-17",  "Statement" : [   {    "Effect" : "Allow",    "Action" : [     "sqs:ReceiveMessage",     "sqs:DeleteMessage",     "sqs:GetQueueAttributes",    ],    "Resource" : "*"   }  ] } SQSを受信するだけでなく、受信した後にメッセージを削除する権限と、SQSの属性の読み取りを行う権限が必要です。 ここら辺の権限については、AWSのマネージドポリシーである「AWSLambdaSQSQueueExecutionRole」を付与すれば一発で権限を充足できます。 AWSLambdaSQSQueueExecutionRole - AWS Managed Policy About the AWS managed policy: AWSLambdaSQSQueueExecutionRole docs.aws.amazon.com   SQSの可視性タイムアウトはLambdaの関数タイムアウト時間の6倍にすること。 SQSのタイムアウト時間を、Lambdaの処理が終了する時間より短く設定すると、Lambda関数が処理中にも関わらず、メッセージがSQSで再度利用可能となり、別のLambda関数が同じメッセージを処理し始めるという事態になります。 Lambda関数の実行中にスロットリングが発生するなどもあり得るため、十分な実行時間を確保しておく必要がございます。 そこで、AWSのドキュメントではLambdaのタイムアウトの6倍を割り当てることを推奨しております。 Lambda が有効な Amazon SQS メッセージを再試行する場合のトラブルシューティング Amazon シンプルキューサービス (Amazon SQS) キュー内のメッセージを処理するように AWS Lambda 関数を設定しました。有効な Amazon SQS メッセージの中には、maxReceiveCount まで複数回受信... repost.aws   SQSのリドライブポリシーでmaxReceiveCount属性を最低5にすること。 Lambdaの同時実行数が最大で、タイミング悪くLambdaが実行できない場合があります。 そういったケースの際に、すぐにDLQに転送するのではなく、合間を置いて再度Lambdaにメッセージを送信することで正しく処理を行うことが可能となります。 maxReceiveCountは、その再試行の回数を指定します。 AWSの推奨では、5以上とのことなのでそのように設定すると良いでしょう。   まとめ 今回は、SQS→Lambdaを呼び出す際に意識するポイントを勝手に3つ挙げました。 SQSもLambdaもいろいろな機能があるため、ユースケースによっては他にも意識することはあるかもしれませんので、引き続き勉強していきたいと思います。 今回あげたポイントは、CloudFormationなどでデプロイする際に、満たしていない場合はデプロイエラーになったりするポイントなので、意識してみることをお勧めします!
本記事はANGEL Dojo 2024参加者によるアドベントカレンダー「ANGEL Calendar」の最終日の記事になっております。 他のみなさんが書かれた記事は こちら からご覧ください! ※…ANGEL Dojo 2024に関しましては AWS JAPAN APNブログ をご覧ください。 こんにちは、ひるたんぬです。 今日で2024年度上半期が終わりますね。これを書いてふと思ったのですが、なぜ「YYYY年度」は4月始まりなのでしょうか? 1月から始めてくれていれば色々スッキリするのに…と思い、なぜ4月からになったのか調べてみました。 (前略)当初から4月始まりだったわけでなく、明治政府により会計年度が初めて制度化された明治2年(1869)は、10月始まり。続いて、西暦を採用した明治6年からは、1月始まりになりました。つまり、暦年と年度の始まりが同じ時代があったのです。明治8年からは、地租の納期にあわせるという目的で、7月始まりになりました。 次に会計年度を変更したのは、明治17年(1884)。その頃の日本は、 国権強化策から軍事費が激増し、収支の悪化が顕著に なっていました。当時の大蔵卿である松方正義は、 任期中の赤字を削減するために、次年度の予算の一部を今年度の収入に繰り上げる施策 を実施。この施策は珍しくなく、当時はよく行われていました。そして、 予算繰り上げによるやりくりの破綻を防ぐため 、松方は一策を講じました。明治19年度の会計年度のスタートを7月始まりから4月始まりに法改正したのです。(後略) 引用…国立公文書館ニュース「 会計年度はなぜ4月始まりなのか 」 何度も変更されており、その理由も予算の兼ね合いだったんですね。ちょっと予想外でした。 さて、今回はタイトルにもあります通り、Lambda関数を使わずにStep Functionsのみで完結できるケースについて簡単なアプリケーションの比較を通してご紹介します。 この記事は、ANGEL Dojo活動中に紹介された以下の記事に着想を受けて執筆しました。 AWS Step Functions の機能を活用して、Lambda 関数無しで実現できることを確認してみよう ! - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS AWS Step Functions の機能を活用して、Lambda 関数を使用せずに様々なタスクを実行する方法をご紹介します。 aws.amazon.com 参考記事でも注意書きとして記載がありますが、本記事においても「全てにおいてStep Functionsを使え!Lambdaは悪!!」という主張はいたしません。私自身LambdaもStep Functionsも大好きです。 「Step Functionsだけでも処理が書けるケースがあるんだ~」くらいの感覚で読んでいただけますと幸いです。 Step Functionsとは? AWSのサーバレスサービスの一つです。複数のアプリケーションやサービスをつなぎ合わせる(オーケストレーション)機能を提供しています。また、コンソール上でビジュアルプログラミングのようにアプリケーションをブロックとして直感的に組み合わせることができるので、プログラミング言語が苦手な人や経験がない人でも触りやすいと思います。 より詳細な特徴などにつきましては、下記サイトをご覧ください。 特徴 - AWS Step Functions | AWS AWS Step Functions を使用して、AWS Lambda 関数や AWS の複数のサービスを、ビジネスクリティカルなアプリケーションに組み立てます。 aws.amazon.com Lambdaをなくしてみた 今回は簡単に、以下のアプリケーションを作ってみました。 ここでご紹介しているアプリケーションは本ブログ執筆のためだけに作ったものです。 Angel Dojoなどで作っているものではありません。 お出かけアシスタント このアプリケーションは今日お出かけしたい場所を入力として与えると、 お出かけしたい場所の最寄り駅 今日の気温に適した服装 を教えてくれます。最寄り駅や気温の取得には外部APIを使用し、気温に適した服装はBedrockに教えてもらうことにします。 Lambda まずはこれをPythonを使ってゴリゴリ書いていきましょう。 今回はStep Functionsの魅力を伝えるため上記要件の処理を並列で処理するようにしています。 Pythonの並列処理についてはいろいろな種類があります(厳密には並列処理でないものも)が、私はひとまずconcurrentというライブラリで書いています。 個人的には以下のサイトで各ライブラリの特徴を学びました。 その並列処理待った! 「Python 並列処理」でググったあなたに捧ぐasync, threading, multiprocessingのざっくりとした説明 - Qiita 対象読者「Python 並列処理」でググってたどり着いたPython, 並列処理の初心者の方。並列処理を使ったことはあるけど、概念をよく知らない方。async, threading, mult… qiita.com このようにして出来上がったのが以下のコードです。 import boto3 import requests import json from concurrent.futures import ThreadPoolExecutor from botocore.exceptions import ClientError def lambda_handler(event, context): # 並列処理 with ThreadPoolExecutor() as executor: near_station = executor.submit(get_near_station, event) outfit_prompt = executor.submit(suggest_outfit_flow, event) near_station_response = near_station.result() outfit_prompt_response = outfit_prompt.result() station = near_station_response["response"]["station"] outfit = outfit_prompt_response["content"] return { "station": station, "outfit": outfit } # 最寄り駅の取得 def get_near_station(location:dict) -> dict: url = "https://www.heartrails-express.com/api/json" params = { "method": "getStations", "x": location["longitude"], "y": location["latitude"] } try: response = requests.get(url, params=params) except requests.exceptions.RequestException as e: raise("Error: ",e) return json.loads(response.content.decode("utf-8")) # 気温の取得 def get_temperture(location:dict) -> dict: url = "https://api.open-meteo.com/v1/forecast" params = { "longitude" : location["longitude"], "latitude" : location["latitude"], "hourly": "temperature_2m", "timezone": "Asia/Tokyo", "forecast_days": "1" } try: response = requests.get(url, params=params) except requests.exceptions.RequestException as e: raise("Error: ",e) return json.loads(response.content.decode("utf-8")) # 服装の考案 def suggest_outfit(temp_data: dict) -> dict: client = boto3.client("bedrock-runtime") # プロンプトの生成 temp = str(temp_data["hourly"]["temperature_2m"]) prompt = "あなたは私の友人で、コーディネーターとして働いています。私は気温に応じて着たり脱いだりすることが嫌いです。今日0時から23時まで1時間ごとの気温は別のリストに与えるとおりです。1日通して私が外出するのに適した上下のコーディネートを簡潔に教えて下さい。" native_request = { "anthropic_version": "bedrock-2023-05-31", "max_tokens": 600, "temperature": 0.5, "messages": [ { "role": "user", "content": [ {"type": "text", "text": prompt}, {"type": "text", "text": temp} ], } ] } request = json.dumps(native_request) try: response = client.invoke_model( body=request, modelId="arn:aws:bedrock:ap-northeast-1::foundation-model/anthropic.claude-3-haiku-20240307-v1:0" ) except (ClientError, Exception) as e: print(f"ERROR: Can't invoke '{model_id}'. Reason: {e}") raise(e) return json.loads(response["body"].read().decode("utf-8")) # 気温の取得 -> 服装の考案 def suggest_outfit_flow(location:dict) -> dict: temp_data = get_temperture(location) suggest_result = suggest_outfit(temp_data) return suggest_result …読めなくはないけど、めんどくさい。というのが正直な感想でしょうか。 プログラミングにあまり触れていない方は、この時点で手を離してしまうかもしれません。 また、今回のコードでは「requests」というライブラリを使用しており、これはLambdaで標準では使用できないため、レイヤーなどでライブラリが使用できるようにする必要もあります。 …これも面倒です。 【初心者向け】AWS Lambda Layerの作成方法をわかりやすく解説【Python3.9】 - Qiita 2024年春バージョン を作成しました。AWS Lambdaの開発をしてみようと思うんだけど、Layerって何?Lambdaにどうやったらpip installするの?と思って固まってしまった・… qiita.com Cloud9につきましては使用できない方もいらっしゃると思います。 経緯や代替策につきましては公式サイトなどをご確認ください。 ※ 本記事では本筋と逸れてしまうため割愛させていただきます。 Step Functions 次に同じ処理をStep Functionsで実装してみます。 …ん?それだけ?? そうなんです。こんなにシンプルに書けるのです。 出力結果は…? 両者で同じ入力を与えてみました。 { "latitude": "35.656315", "longitude": "139.795486" } Lambda 戻り値として以下が得られます。 { "station": [ { "name": "豊洲", "prefecture": "東京都", "line": "東京メトロ有楽町線", "x": 139.79621, "y": 35.654908, "postal": "1350061", "distance": "170m", "prev": "月島", "next": "辰巳" }, { "name": "豊洲", "prefecture": "東京都", "line": "新交通ゆりかもめ", "x": 139.795414, "y": 35.653792, "postal": "1350061", "distance": "280m", "prev": "新豊洲", "next": null }, { "name": "新豊洲", "prefecture": "東京都", "line": "新交通ゆりかもめ", "x": 139.789996, "y": 35.648718, "postal": "1350061", "distance": "980m", "prev": "市場前", "next": "豊洲" }, { "name": "越中島", "prefecture": "東京都", "line": "JR京葉線", "x": 139.792713, "y": 35.667946, "postal": "1350044", "distance": "1320m", "prev": "八丁堀", "next": "潮見" } ], "outfit": [ { "type": "text", "text": "はい、分かりました。気温の変化に合わせて、1日中快適に過ごせるようなコーディネートをご提案します。\n\n朝から夕方にかけては、半袖Tシャツに薄手のシャツやカーディガンを羽織るのがおすすめです。\n午後からは、Tシャツ1枚でも問題ありません。\n夕方から夜にかけては、長袖の薄手のシャツやブラウスを着用するのがよいでしょう。\n\n気温の変化に合わせて、上下を調整しながら過ごせば、1日中快適に過ごせると思います。\n軽めの上着を持参するなど、状況に応じて調整できるようにするのがポイントです。" } ] } Step Functions 処理の流れを視覚的に確認することができます。 また、出力「output」として以下が得られます。 { "output": [ { "outfit": [ { "type": "text", "text": "はい、気温の変化に合わせて以下のようなコーディネートをおすすめします。\n\n午前中(0時~11時)は長袖Tシャツとジーンズが適しています。\n午後(12時~17時)は半袖Tシャツとスカートやショートパンツがよいでしょう。\n夕方(18時~23時)は長袖Tシャツとジーンズに戻すのがおすすめです。\n\nコーディネートのポイントは通気性のよい素材を選び、日中は涼しげな服装で、外出時の気温の変化にも対応できるよう、外羽織りを持参することです。\n天候や活動内容によって微調整が必要かもしれませんが、この提案で1日中快適に過ごせると思います。" } ] }, { "station": [ { "name": "豊洲", "prefecture": "東京都", "line": "東京メトロ有楽町線", "x": 139.79621, "y": 35.654908, "postal": "1350061", "distance": "170m", "prev": "月島", "next": "辰巳" }, { "name": "豊洲", "prefecture": "東京都", "line": "新交通ゆりかもめ", "x": 139.795414, "y": 35.653792, "postal": "1350061", "distance": "280m", "prev": "新豊洲", "next": null }, { "name": "新豊洲", "prefecture": "東京都", "line": "新交通ゆりかもめ", "x": 139.789996, "y": 35.648718, "postal": "1350061", "distance": "980m", "prev": "市場前", "next": "豊洲" }, { "name": "越中島", "prefecture": "東京都", "line": "JR京葉線", "x": 139.792713, "y": 35.667946, "postal": "1350044", "distance": "1320m", "prev": "八丁堀", "next": "潮見" } ] } ], "outputDetails": { "truncated": false } } Bedrockの返答に差はあるものの、同じ構造で回答が得られていることが分かりますね。 脱いだり着たりするのが嫌いなのに、Step Functionsではパンツの履き替えまで要求されてますが… プロンプトに関する勉強がまだまだ足りていない模様です。 Step Functionsのここがすごい! ここからは、Step Functionsの個人的な魅力について、先程のアプリケーションをベースにご説明します。 直感的に作ることができる 先程のキャプチャでお分かりいただけたかもしれませんが、Step Functionsはデザインエディタを用いてブロックを並べるだけで処理が実現してしまいます。 特に各種AWSサービスを呼び出して行うものについては220のAWSサービス・10,000以上のAPIと直接統合されています。 ▼ 統合されているAWSサービスの一部 また、この他にも外部APIを叩く機能もあるので、AWSに閉じていないサービスであってもStep Functions上で完結してしまうケースもあります。 外部APIを使用するためには、「Amazon EventBridge Connection」の設定が必要です。 設定は煩雑ではなかったので、詳細は省略いたします。下記参考記事をご覧ください。 タスク状態のテストと外部エンドポイントが AWS Step Functions で利用できるようになりました | Amazon Web Services AWS Step Functions HTTPS エンドポイントでは、サードパーティー API と外部サービス aws.amazon.com プログラミングのような処理も可能 各種AWSサービスや外部APIとの統合に加え、Step Functionsでは「フロー」という項目でプログラミングのような以下の処理を行うことができます。 Choice if-then-elseロジックが実装できます。 Parallel 並列処理が実装できます。 Map 繰り返し処理が実装できます。 Pass 入出力のフィルタや書き換えを実装できます。 ※ 入出力のフィルタやマッピングなどは各処理ブロックでも行えます。 Wait 指定時間フローを停止できます。 Success / Fail フローの成功・失敗を定義できます。 私がLambdaの方でわざわざ並列処理を加えた理由も、このParallelを紹介したかったからです… この他にも各フローでエラー発生時の処理を定義することができますので、エラーハンドリングも実装可能です。 初心者にも上級者にも優しい デザインエディタで直感的に作ることができるメリットは先程ご説明したとおりですが、Step Functionsではフローを指定の言語で記載することもできます。この言語を「Amazon States Languages (ASL)」といいます。 これによりコードベースでの管理も可能ですし、これを利用してCloudFormationでのIaCも実現可能です。 Amazon States Language を使用した Step Functions ワークフローの定義 - AWS Step Functions Amazon States Language を使用して、 で AWS Step Functions ワークフローをタスク、選択肢、結果などの状態のコレクションJSONとして定義します。 docs.aws.amazon.com AWS CloudFormation を使用して Step Functions でワークフローを作成する - AWS Step Functions を使用して Step Functions AWS Lambda ステートマシンを作成する方法について説明します AWS CloudFormation。 docs.aws.amazon.com さらに、コードで作成・編集したものとデザインエディタで作成・編集したものは相互に変換可能です。 個々人にスキルや好みに応じてスタイルを自在に選べるのは嬉しいポイントですね。 本記事の最後に本アプリケーションのStep Functionsで記述したコードを載せます。 ランタイム・ライブラリを気にしなくて良い このポイントが個人的に大きなメリットかなと感じています。 特にPythonなどのプログラミング言語はアップデートも盛んで、当時最新のランタイムで実装していたアプリケーションが、いつの間にか数世代前…なんてことも。 ライブラリについても、標準で入っていないものについては自身で追加が必要など、少し手順が複雑になってしまいます。 Lambdaではレイヤーを導入することにより柔軟性が実現される、という考え方ももちろんできます。 その点Step Functionsではランタイムを気にする必要がなくなるので、その点においては運用上のコストやセキュリティ上のリスク低減に貢献するのではないかと考えています。 Step Functionsは銀の弾丸…? ここまで読むと「Step Functions最高!!」「Lambdaいらね!!!」と思われた方もいらっしゃるかもしれません。。 残念ながらそんなことはありません。 上記のアプリケーションの例でいいますと、Step Functionsを用いて1時間ごとの気温から平均気温を出すことはできないのです。 組み込み関数の機能により、数学的な処理も行えるようになっているものの、まだ加減算のみしかできません。 Step Functions ワークフローの Amazon States Language の組み込み関数 - AWS Step Functions 組み込み関数を使用して Step Functions ワークフローで基本的なデータ処理タスクを実行する方法について説明します。 docs.aws.amazon.com ここの部分に関しましては今後のアップデートで対応される可能性も大いにあると思いますが、個人的には AWSサービスとの連携にはStep Functions データの加工や処理にはLambda と、用途に応じて適切にサービスを組み合わせることが良いと感じました。 おわりに 今回はStep Functionsの魅力についてお伝えしました。 「思ったよりできること多い!」とというのが個人的な感想です。 今回利用させていただいた外部API 会員登録不要・かつ無料で利用できるAPIを使用しました。 このような便利なサービスが無料で使えることはとてもありがたいことだと実感しています。 天気予報:Open-Meteo( https://open-meteo.com/ ) 最寄り駅:HeartRails Express( https://express.heartrails.com/api.html ) Step FunctionsのフローのASL Amazon EventBridge ConnectionのARNについてはマスキングを行っています。 { "Comment": "A description of my state machine", "StartAt": "並列処理", "States": { "並列処理": { "Type": "Parallel", "Branches": [ { "StartAt": "気温の取得", "States": { "気温の取得": { "Type": "Task", "Resource": "arn:aws:states:::http:invoke", "Parameters": { "ApiEndpoint": "https://api.open-meteo.com/v1/forecast", "Method": "GET", "Authentication": { "ConnectionArn": "arn:aws:events:ap-northeast-1:XXXXXXXXXXXX:connection/Connect_name/abc123-456-7890" }, "QueryParameters": { "latitude.$": "$.latitude", "longitude.$": "$.longitude", "hourly": "temperature_2m", "timezone": "Asia/Tokyo", "forecast_days": "1" } }, "Retry": [ { "ErrorEquals": [ "States.ALL" ], "BackoffRate": 2, "IntervalSeconds": 1, "MaxAttempts": 3, "JitterStrategy": "FULL" } ], "Next": "服装の考案" }, "服装の考案": { "Type": "Task", "Resource": "arn:aws:states:::bedrock:invokeModel", "Parameters": { "ModelId": "arn:aws:bedrock:ap-northeast-1::foundation-model/anthropic.claude-3-haiku-20240307-v1:0", "Body": { "anthropic_version": "bedrock-2023-05-31", "max_tokens": 600, "messages": [ { "role": "user", "content": [ { "type": "text", "text": "あなたは私の友人で、コーディネーターとして働いています。私は気温に応じて着たり脱いだりすることが嫌いです。今日0時から23時まで1時間ごとの気温は別のリストに与えるとおりです。1日通して私が外出するのに適した上下のコーディネートを簡潔に教えて下さい。" }, { "type": "text", "text.$": "States.JsonToString($.ResponseBody.hourly.temperature_2m)" } ] } ] } }, "End": true, "ResultSelector": { "outfit.$": "$.Body.content" } } } }, { "StartAt": "最寄り駅の取得", "States": { "最寄り駅の取得": { "Type": "Task", "Resource": "arn:aws:states:::http:invoke", "Parameters": { "ApiEndpoint": "https://www.heartrails-express.com/api/json", "QueryParameters": { "method": "getStations", "x.$": "$.longitude", "y.$": "$.latitude" }, "Method": "GET", "Authentication": { "ConnectionArn": "arn:aws:events:ap-northeast-1:XXXXXXXXXXXX:connection/Connect_name/abc123-456-7890" } }, "Retry": [ { "ErrorEquals": [ "States.ALL" ], "BackoffRate": 2, "IntervalSeconds": 1, "MaxAttempts": 3, "JitterStrategy": "FULL" } ], "End": true, "ResultSelector": { "station.$": "$.ResponseBody.response.station" } } } } ], "End": true } } } 入力の場所は…? 今回は「35.656315,139.795486」を与えましたが、ここは…弊社の本社ビルです。 駅近が魅力的ですね!
こんにちは。SCSKの山口です。 今回は、 過去のブログ で作成したモデルが算出した予測値を説明させてみよう。の回です。 以前作成した線形回帰モデルで、工場の製造コスト、人件費、生産効率、従業員数から、工場の「原材料費」を予測するモデルを作成し、下記の予測値を出力として得ました。 この結果、 モデルがどうやって算出したのか 気になりませんか、、、? そんな時に役立つのが、 XAI とも呼ばれる BigQuery Explainable AI です。早速見ていきましょう。   BigQuery Explainable AI  BigQuery Explainable AI の概要  |  Google Cloud cloud.google.com Explainable AI は、データ行の各特徴がどのように予測結果に影響を与えるかを定義することで、予測 ML モデルが分類タスクと回帰タスクに対して生成する結果の理解を容易にします。この情報を 「特徴アトリビューション」 と呼びます。 カンタンにいうと 特徴アトリビューション = データ内の各特徴が予測値にどの程度影響を及ぼしたか です。特徴アトリビューションを活用することで、 モデルが 期待通りに動作していること の確認 モデルの バイアスを認識 すること モデルやトレーニングデータの 改善方法を知る こと が可能です。 ローカルとグローバルの説明可能性 説明可能性には、ローカルの説明可能性とグルーバルの説明可能性の2種類があります。 それぞれの説明可能性から「ローカルな特徴重要度」と「グローバルな特徴重要度」を得ることができます。 ローカルの説明可能性 説明された各列の特徴アトリビューション値を返します。 これらの値は、それぞれの特徴が ベースラインの予測に対してどの程度影響を及ぼすか を示します。 ローカル説明関数の「 ML.EXPLAIN_PREDICT 」を使用することで取得可能です。 グローバルの説明可能性 データセット全体の特徴アトリビューション を集計し、モデルに対する特徴の全体的な影響を返します。 絶対値が大きいほど、特徴がモデルの予測により大きな影響を与えたことを示します。 グローバル説明関数の「 ML . GLOBAL _ EXPLAIN 」を使用することで取得可能です。   ここから実践に入りますが、以前作成したモデルは単一のテーブルで学習させたので、今回はローカルの説明可能性を試してみます。   実践:ローカルな特徴重要度を取得 ローカル説明関数の「ML.EXPLAIN_PREDICT」を使った下記クエリを実行します。 SELECT * FROM ML.EXPLAIN_PREDICT( MODEL `yamaguchi_test_bqml.test_model_liner_reg`,   (   SELECT     IFNULL(cost_manufacturing, 0) AS cost_mf,     IFNULL(cost_material, 0) AS label,     IFNULL(cost_employees, 0) AS cost_emp,     IFNULL(manufacturing_line, 0) AS manu_line,     IFNULL(manufacturing_efficiency, 0) AS manu_eff,     IFNULL(employees, 0) AS emp   FROM     `yamaguchi_test_bqml.test`   WHERE     employees=476   ),   STRUCT(5 AS top_k_features)   ) 上記クエリのサブクエリのSELECT句 SELECT IFNULL… で評価データを生成するクエリを入力します。今回は以前のブログで実際の予測をする際に使用したクエリを流用します。 また、 STRUCT(5 AS top_k_features) の部分で、 影響力が上位何番目までの特徴を見るか を指定します。今回は上位5個(すべて)の特徴を出力します。 出力結果は下記のとおりです。 predicted_label: モデルが算出した予測値 top_feature_attributions.feature :特徴名(影響度で降順) top_feature_attributions.attribution :各特徴の影響度 baseline_prediction_value :モデルの予測におけるベースライン baseline_prediction_value についてちょっと寄り道します。 モデルを作成する際、最初にある程度の”アタリ”をつけたうえで、そこから微調整をかけていくのですが、baseline_prediction_valueは 「最初につけたアタリ」 を指します。 調べた結果、 モデル学習のトレーニングに使われたデータ内での 目的変数の平均値 が採用されていました。 このベースラインの値を基準として、モデルが 各特徴の影響度を加味して予測値を算出 してくれます。下記のイメージです。 最初にアタリをつけたベースライン(青矢印)に対して、各特徴の影響を与えていきます。するとベースラインの値の青丸が調整され、赤丸になっていきます。 こうしてベースラインの青矢印が各特徴に影響され、赤矢印のような動きをして予測値を算出してくれます。 今回はベースラインの方が正解値に近い残念な結果になっています。。。 ただ、 各特徴がどの程度影響を与えた結果、予測値がどう外れているか をある程度掴むことができました。 この情報をモデルの性能改善へと活用すること が可能です。 モデルの性能改善については今後ブログ化していきます。   まとめ 今回は、以前作成した線形回帰モデルの予測結果をExplainable AI(XAI)を使って説明させてみました。 どの特徴が予測結果にどの程度影響を与えているかが数値的につかめるので、かなり便利だと思いました。 この情報をどう生かすべきか。については今後検証してブログ化していこうと思うのでご期待ください。 最後までご覧頂きありがとうございました。
SASE に関する実態調査について 昨年(2023年)に引き続き、今年度(2024年)も、SASE実態調査を実施しました。 SASEの認知度、実際の導入企業はどれくらいなのか? SASE (Secure Access Service Edge)に関する実態調査結果と、Cato Networks社のCatoクラウドの認知度について blog.usize-tech.com 2023.09.01 SASE実態調査のきっかけは、SCSKで2021年より主要なSASE 4ソリューションを一同に紹介を行うオンラインセミナー「 SCSK SASE Solution Summit(通称 S4 エスフォー) 」となります。これまで 18 回開催しており、直近の2024年6月の開催では250名以上、延べ 1,800 名以上の方々にご参加頂いております。この S4 セミナー等を通じて多くの参加者の皆さまからのアンケートを集めると、SASEに関する世間の類似調査結果(例. SASE導入済み企業が4割、SASE導入着手企業が6割など)よりも、実際の認知度や導入率はもっと低いのではないかという仮説が上がっていました。 SASEは、昨年(2023年)より本格的な普及期に入ると予測されていましたが、海外と比べると日本国内でのSASE普及は遅れているとされていることもあり、2023年6月に外部調査企業の協力を得て、国内企業への実態調査を実施し、その調査結果(レポート)を無料公開しました。 昨年(2023年度)のレポートについては、以下のリンクよりダウンロードください。 https://www.scsk.jp/news/2023/pdf/20230809i.pdf そして、今年(2024年)も、普及期におけるSASE認知度・導入率がこの一年間でどれくらい増加したのかを把握するために、ちょうど一年後(2024年6月)に同じ調査を実施し、その調査結果(レポート)を同じく無料公開したものとなります。 2024年度の詳細なレポートについては、以下のリンクより是非ダウンロードください。 https://www.scsk.jp/news/2024/pdf/20240905.pdf SASE 認知度 SASE認知度が45%まで大きく向上しています。まだまだ認知度が低いのでは?、55%の人が知らないじゃないか?と言う方も居られると思いますが、このようなIT関連の調査において、特にITインフラに関する認知度は、50%を超えると非常に良い方で、60-70%に達成することはあまりありません。 「マイクロソフト」や「アップル」、「Windows」、「iPhone」であれば、認知度は90%を超える結果になると思いますが、例えば、「クラウド」、「AWS」、「Azure」、「GCP」などが 60-70%に達成することは、まずありえません。 広くIT関連業務へ従事する方へのアンケートとなりますので、インフラ業務に従事されていない方(ex. 開発業務の方)も含まれるからです。来年以降に同様の調査を実施すると、50%は超えるのでなないかと思いますが、60-70%に達するのはおそらく不可能だと思っています。 つまり、本調査での45%は、非常に高い認知度であることを示しています。 SASE 導入率(普及率) SASE導入率(普及率)については、導入済み企業が 10%(10.0%)から16%(15.5%)と1年で大きく向上しました。 キャズム理論における初期市場であるイノベーター(2.5%)、アーリーアダプター(13.5%)の計16%、市場普及の溝(キャズム)を超え、メインストリーム市場に入ったことが判明しています。 現在導入中・導入計画中の企業を考慮すると、導入率は今後も大きく向上すると判断できます。 Catoクラウド認知度 一方で、調査結果(レポート)には掲載していませんが、昨年度と同様にCato Networks(ケイトネットワークス)社 Catoクラウド(Cato Cloud/Cato SASE Cloud)について個別の認知度調査を実施しております。 2023年は、Catoクラウドを知っている方は 12% という結果でしたが、2024年は 16%(+4%)と少ないながら認知度が向上していることが判明していますが、まだまだ認知度が低いことが分かりました。 SASE 検討で気を付けるべきこと SASEの認知度が大きく向上し、普及(導入)率においてもキャズムを超え、メインストリーム市場に入ったことが分かりました。また、Cato Networks社、Catoクラウド(Cato Cloud/Cato SASE Cloud)も少しづつ認知度が上がってきています。 Catoクラウドを取り扱うパートナー(ディストリビューター、リセラー)も急激に増えてきており、今では100社近くの企業が取り扱いを始めています。一般的な製品やサービスであれば、パートナー企業数は概ね100社程度で上限になるのですが、SASE は、ネットワーク・セキュリティ分野になるので、システムインテグレータだけはなく、通信事業者(通信キャリア含む)、ネットワークインテグレータ、通信機器メーカ等も参入し始めており、今後どこまでパートナーの数が増えるのかは分かりません(AWSのように700-800社になるかもしれません) SASEは、企業ネットワークやセキュリティの代替となるサービスなのですが、単純な物販(モノ売り)として取り扱いをしているパートナーもあり、導入がきちんと行われておらず、その後のサポート・保守(マネージドサービス等)も提供されておらず、お客様が困って当社へご連絡が来る事例も増え始めています。 Catoクラウドのサービスを殆ど理解されず、多くの機能を活用できていない例もあります。 また、クラウドサービスなので、AWS等のパブリッククラウドと同じく、多くの場合はスモールスタートを行い、必要に応じて随時増速・アカウント追加を行うのが一般的なのですが、クラウド(AWS等)と異なるのは、お客様自身がクレジットカード決済で自由に増速・アカウント追加ができないことです。Catoクラウドでは、パートナー経由で、見積・注文を行うことが前提で、注文後にライセンス発行がされて初めて、増速・アカウント追加ができるようになっています。 つまり、パートナー(ディストリビューターおよびリセラー)の見積り作成・提示や、注文後の受注処理およびライセンス発行処理が遅いと、非常に困った事態になります。拠点の帯域が不足しているのに、いつまで経っても帯域増速ができない、従業員が増え、モバイルユーザのアカウントを付与したいのにできない等が発生します。 見積りの取得に数週間掛かったり、ライセンス発行に1ヵ月以上掛かる例もあるようです。 パートナーが急増し、Catoクラウドのエコシステムの形成がされ、全体のビジネスが拡大していますが、その一方で様々な弊害も出始めています。 弊害のひとつは、パートナー(ディストリビューターおよびリセラー)による 劣化コピーの問題 です。 劣化コピーとは、すでにある作品や表現などの、程度や品質が劣る模倣のことで、要するに出来の悪い二番煎じのことです。 例えば、当社の実施するCatoクラウドのお客様の導入事例(制作)や、2022年からリリースしているFAQシステムや、この技術ブログ(TechHarmony)を例にすると、後発でパートナー(ディストリビューターおよびリセラー)が、劣化コピーの導入事例を制作したり、劣化コピーFAQサイトをリリースしたり、劣化コピーブログ(?)をリリースしたりすることです。 劣化コピーではなく、お客様にとって「より良いもの」、今存在しているものより「さらに良いもの」をリリースして欲しいと思います。個人的には、そもそも同じようなものは、紛らわしく、混乱を招くだけなので不要だと思っていますので、全体のエコシステムを意識されるのであれば、劣化コピーを作る労力は、Catoクラウドに必要なもの(今は存在しないもの)をリリースすることに使って欲しいと思います。 全体の意識がなく、案件レベルでの競争(コンペ)としか見ることができないのだと思いますが。。。 最後に SCSKでは、SASE を単純な物販(モノ売り)ではなく、お客様のビジネスインフラの根幹となるネットワーク・セキュリティと捉えています。 きちんとしたサービスのご紹介から、PoCを含めサービスのレクチャーから技術検証のご支援、その後の設計/構築(移行)はもちろん、導入後の各種マネージドサービスもフルラインナップでご提供しております。毎週新たなサービスや機能がリリースされるため、その情報共有も積極的に実施し、FAQを始めとし、お客様自身(セルフ)で問題解決できる各種施策を提供しております。 また、見積りを含む受発注やライセンス発行などのリードタイム(LT)も常に改善を図っており、特にライセンス発行に関しては15時までにご注文書をいただければ、最短で当日中にライセンス発行を行っております。 パートナーが急増し、劣化コピーも増えていますが、お客様導入事例、FAQ、技術ブログについては、是非オリジナルをご覧いただければ幸いです。 ・SCSKが導入し、マネージドサービスを提供しているお客様の導入事例 Catoクラウド 導入事例 | よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Catoクラウドのお客様導入事例ライオン株式会社 様株式会社 ブルボン 様 cato-scsk.dga.jp ・Catoクラウド FAQシステム よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Cato SASE Cloud Platform. powered by SCSK cato-scsk.dga.jp ・SCSK技術ブログ(TechHarmony) Cato Cloud 「Cato Cloud」の記事一覧です。 blog.usize-tech.com ・Catoクラウド 導入・運用の悩みは“パートナー選び”で解決できる Catoクラウド導入・運用の悩みは“パートナー選び”で解決できる | SCSK株式会社 SASEプラットフォーム「Catoクラウド」の導入・運用の悩みを解決する“パートナー選び”のポイントを解説します。 www.scsk.jp ・SASEに関するセミナー、Catoクラウド各種セミナー Catoクラウド イベント・セミナー情報 | よくあるご質問 | Cato Cloud ケイトクラウド - SCSK 定期的にCatoクラウドをご紹介するセミナーを開催しております。・2024年9月26日(木)Catoクラウド ハンズオンセミナー【札幌開催分】 ~全国5都市開催(東京/大阪/名古屋/博多/札幌)~ ... cato-scsk.dga.jp
Azure では仮想ネットワーク (VNet) 内に配置されたリソースの名前解決を行う方法として、以下の 4 つの方法が用意されています。 Azure が提供する名前解決 プライベート DNS ゾーンによる名前解決 カスタム DNS サーバーによる名前解決 DNS Private Resolver による名前解決 本稿では、「 Azure が提供する名前解決 」の動作についてAzure 仮想マシン (VM) に注目して確認します。 同じ VNet に配置された VM を名前解決する 次の構成を用意して、同じ VNet に配置された VM の名前解決動作を確認します。 Windows VM からの名前解決とその設定を確認する Windows VM win-vm-1 から正引き/逆引きでの名前解決動作を確認してみます。   正引きの名前解決 正引き (前方参照) の名前解決を行うと、Azure 提供 DNS 168.63.129.16 が参照され各 VM のホスト名に対応する IP アドレスを応答します。 ホスト名で要求すると自動的に DNS サフィックス *.internal.cloudapp.net が付与されて名前解決が行われています。 この前方参照ゾーン *.internal.cloudapp.net は特にこちらでは構成しておらず MS によって自動作成され管理されています。 逆引きの名前解決 逆引きの名前解決を行うと、こちらも Azure 提供 DNS 168.63.129.16 が参照され各 VM の IP アドレスに対応するホスト名を応答します。 IP アドレスで要求すると対応する逆引きレコード  x.x.x.x.in-addr.arpa が参照されて名前解決が行われています。 この逆引きレコード  x.x.x.x.in-addr.arpa は特にこちらでは構成しておらず MS によって自動作成され管理されています。 DNS 参照設定の確認 Windows 上で DNS 参照設定がどのように構成されているかを確認します。 まずは、NIC の設定がどのように構成されているか確認します。 IP アドレスや DNS 設定は DHCP から自動的に配布されたものを利用する設定になっています。 DNS サフィックスは明示的に設定されていません。 続いて、 NIC に実際に反映された設定を確認します。 IP アドレスや DNS 設定は Azure 提供 DHCP 168.63.129.16 から配布されており、自動的に設定されています。 DNS サフィックスも NIC の Connection-specific DNS Suffix に MS 管理のゾーン *.internal.cloudapp.net が DHCP から配布されています。 Windows IP Configuration の DNS Suffix Search List に Connection-specific DNS Suffix の値が反映されています。 Linux VM からの名前解決とその設定を確認する Linux VM lin-vm-1 から正引き/逆引きでの名前解決を確認してみます。   正引きの名前解決 正引き(前方参照)の名前解決を行うと、スタブリゾルバ 127.0.0.53#53 が参照され各 VM のホスト名に対応する IP アドレスを応答します。 ホスト名で要求すると自動的に DNS サフィックス *.internal.cloudapp.net が付与されて名前解決が行われています。 この前方参照ゾーン *.internal.cloudapp.net は特にこちらでは構成しておらず MS によって自動作成され管理されています。 逆引きの名前解決 逆引きの名前解決を行うと、こちらもスタブリゾルバ 127.0.0.53#53 が参照され各 VM の IP アドレスに対応するホスト名を応答します。 IP アドレスで要求すると対応する逆引き参照ゾーン x.x.x.x.in-addr.arpa が参照されて名前解決が行われています。 この逆引き参照ゾーン x.x.x.x.in-addr.arpa は特にこちらでは構成しておらず MS によって自動作成され管理されています。 DNS 参照設定の確認 Linux (Ubuntu 24.04 LTS) 上で DNS 参照設定がどのように構成されているかを確認します。 まずは、NIC の設定がどのように構成されているか確認します。 IP アドレスや DNS 設定は、DHCP から自動的に配布されたものを利用する設定になっています。 DNS サフィックスは明示的に設定されていません。 続いて、 NIC に実際に反映された設定を確認します。 IP アドレスや DNS 設定は Azure 提供 DHCP 168.63.129.16 から配布されており、自動的に設定されています。 DNS サフィックスも NIC の DNS Domain に MS 管理のゾーン *.internal.cloudapp.net が DHCP から配布されています。 /etc/resolv.conf の search に DNS Domain の値が反映されています。 Ubuntu では、ローカルクライアントを systemd-resolved 内部の DNS スタブリゾルバに接続し、スタブリゾルバが名前解決を中継します。このため、 nslookup の結果ではスタブリゾルバのアドレス 127.0.0.53#53 が表示されますが、実際にはスタブリゾルバは resolvectl status で出力されている通り、DHCP から配布された DNS 参照先として Azure 提供 DNS 168.63.129.16 を参照しています。 DNS レコードの更新動作を確認する 新しい VM を作成する 新しい VM を作成した際に DNS レコードが自動的に登録されるかを確認します。 win-subnet に新しい Windows VM win-vm-2 を作成する lin-subnet に新しい Linux VM lin-vm-2 を作成する Windows VM win-vm-2 のレコード 正引き/逆引きともに自動的にレコードが追加されます。 Linux VM lin-vm-2  のレコード 正引き/逆引きともに自動的にレコードが追加されます。 IP アドレスを変更する 既存の VM の IP アドレスを変更した際に、DNS レコードが自動的に更新されるかを確認します。 Windows VM win-vm-2 の IP アドレスを 10.1.0.5 から 10.1.0.15 に変更する Linux VM lin-vm-2 の IP アドレスを 10.1.1.5 から 10.1.1.15 に変更する Windows VM win-vm-2 のレコード 正引き/逆引きともに自動的にレコードが更新されます。   Linux VM lin-vm-2 のレコード 正引き/逆引きともに自動的にレコードが更新されます。 ホスト名を変更する 既存の VM のホスト名を変更した際に、DNS レコードが自動的に更新されるかを確認します。 Windows VM win-vm-2 のホスト名を win-vm-2 から win-vm-2x に変更する Linux VM lin-vm-2 のホスト名を lin-vm-2 から lin-vm-2x に変更する Windows VM win-vm-2 のレコード 正引き/逆引きともに自動的にレコードが更新されます。(要再起動) Linux VM lin-vm-2 のレコード 正引き/逆引きともに自動的にレコードが更新されます。(要再起動) 仮想マシンを停止する 既存の VM を停止した際に DNS レコードがどうなるかを確認します。 Windows VM win-vm-2 を停止する Linux VM lin-vm-2 を停止する Windows VM win-vm-2 のレコード 正引き/逆引きともに名前解決ができなくなります。 Linux VM lin-vm-2 のレコード 正引き/逆引きともに名前解決ができなくなります。 異なる VNet に配置された VM を名前解決する 次の構成を用意して、異なる VNet に配置された VM の名前解決動作を確認します。 VNet vnet-1 の VM から名前解決する VNet vnet-1 の Windows VM win-vm-1 から VNet vnet-1 の名前解決を確認します。 同じ VNet の VM は正引き/逆引きともに名前解決できます。 VNet vnet-1 の Windows VM win-vm-1 から VNet vnet-2 の名前解決を確認します。 異なる VNet の VM は正引き/逆引きともに名前解決できません。 VNet vnet-2 の VM から名前解決する VNet vnet-2 の Windows VM win-vm-2 から VNet vnet-2 の名前解決を確認します。 同じ VNet の VM は正引き/逆引きともに名前解決できます。 VNet vnet-2 の Windows VM win-vm-2 から VNet vnet-1 の名前解決を確認します。 異なる VNet の VM は正引き/逆引きともに名前解決できません。 FQDN を指定して名前解決する VNet 毎に DNS ゾーンが異なることで、ホスト名 (サフィックスなし) での名前解決ができない可能性があるため、FQDN を指定して名前解決してみます。 VNet vnet-1 の VM win-vm-1 から VNet vnet-2 の VM を FQDN で名前解決してみます。 FQDN 指定でも異なる VNet の VM は名前解決できません。 VNet vnet-2 の VM win-vm-2 から VNet vnet-1 の VM を FQDN で名前解決してみます。 FQDN 指定でも異なる VNet の VM は名前解決できません。 カスタム DNS サーバーを中継して名前解決を試みる これまでの確認により、DNS 参照のスコープが VNet であり、異なる VNet 間での名前解決はできないことがわかりました。ここからは蛇足となりますが、異なる VNet に配置した DNS サーバーを中継することで名前解決ができるかを確認します。 VNet vnet-2 の Windows VM を DNS サーバーにして VNet vnet-1 の VM から名前解決する 次のような構成で、VNet を跨いで名前を参照できるか確認します。 VNet vnet-1 の Windows VM win-vm-1 から VNet vnet-2 の VM の名前解決を行います。 ホスト名 (DNS サフィックスなし) /FQDN ともに名前解決できません。 VNet または NIC の DNS 設定で、カスタム DNS サーバーを参照させると、DHCP から配布される DNS サフィックスは reddog.microsoft.com という存在しないゾーンになります。   VNet vnet-2 の Windows VM を DNS サーバーにして VNet vnet-1 の VM から名前解決する (DNS フォワーダーあり) 次に、すべてのリクエストを Azure 既定の DNS 168.63.129.16 に転送するように DNS サーバーを構成します。 VNet vnet-1 の Windows VM win-vm-1 から VNet vnet-2 の VM の名前解決を行います。 FQDN の場合は、正引きの名前解決ができます。 続いて、逆引きの名前解決についても確認します。 DNS サーバー自身の IP アドレスは逆引きに失敗します。 DNS サーバー以外の VM は、逆引きの名前解決ができます。 恐らく DNS サーバー自身の IP アドレスはフォワードせずに、自身のもつ逆引きゾーンで解決しようとして、ゾーンがないためエラーになる動きをしているように思えますが、本稿の本質ではないためここまでの確認とします。 まとめ 本稿では、Azure が提供する名前解決により、VM の名前解決がどのように行われるかを確認しました。 追加の構成や管理を行うことなく、正引き/逆引きともに名前解決することができ DNS レコードの更新も自動的に行われるため、とても便利で手軽ですが、VNet を跨いで名前解決を行うことができないことや VM 停止時には DNS レコードが参照できないなどの制約があることから、利用可能なシナリオが限定されることがわかりました。 特に、エンタープライズシナリオにおいて一般的な Hub & Spoke 型のネットワークトポロジーにおいては、DNS リゾルバを Hub VNet に配置して集中管理することが一般的ですが、このとき Azure が提供する名前解決では DNS リゾルバが存在する Hub VNet の VM しか名前解決できないことがネックになってくると思います。 Azure が提供する名前解決の特徴や考慮事項は次の公式ドキュメントにもまとめられています。 Azure 仮想ネットワーク内のリソースの名前解決 Azure IaaS、ハイブリッド ソリューション、異なるクラウド サービス間、Active Directory、および独自の DNS サーバーの使用に関係する名前解決シナリオです。 learn.microsoft.com 今回は以上です。次回は、プライベート DNS ゾーンによる VM の名前解決動作を確認してみたいと思います。
こんにちは。SCSK株式会社の安藤です。 10/2 に、 SCSK主催のZabbixセミナーを開催 します。(開催まであと1週間を切りました・・・!)   本セミナーでは、Zabbix 7.0の新機能と改善点について詳しくご紹介させていただきます。   特に今回は、以下のような点に焦点を当てて解説してまいります。 より直感的になったユーザーインターフェース 新しい監視機能と拡張された統合オプション パフォーマンスの大幅な向上 セキュリティ強化の取り組み   セミナーの後半では、実際にバージョンアップする際の要点についてご説明し、Zabbix 7.0への移行をスムーズに進めるためのヒントもお伝えいたします。   セミナー概要   主催 SCSK株式会社 日時 2024年10月2日(水) 15:00~16:00 (ログイン開始時間 14:45~) 会場 オンラインセミナー(お申し込み後、受講用URLをご案内致します。) 定員 100名 対象 Zabbixを導入済、導入ご検討中の方 Zabbixにご興味がある方 参加費 無料   プログラム詳細とお申込みは、以下ページをご参照ください。 Zabbix7.0セミナー~新機能とバージョンアップの要点~ 本セミナーでは、Zabbix 7.0の新機能と改善点について詳しくご紹介させていただきます。実際のアップグレード手順についてもご説明し、皆様のZabbix 7.0への移行をスムーズに進めるためのヒントもお伝えいたします。 www.scsk.jp   最後に 弊社ではZabbix関連サービスを展開しています。以下ページもご参照ください。 SCSK Plus サポート for Zabbix SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします www.scsk.jp   ★YouTubeに、SCSK Zabbixチャンネルを開設しました!★ SCSK Zabbixチャンネル 本チャンネルでは、SCSK株式会社でのZabbixに関するトレンド/事例紹介などを動画にまとめて取り上げております。 最新のトピックについては、以下の弊社HPもしくはツイッターアカウントをぜひ参照ください。 ツイッターアカウント: www.youtube.com   ★X(旧Twitter)に、SCSK Zabbixアカウントを開設しました!★ x.com x.com
こんにちは。SCSKの山口翔平です。 最近、大谷翔平選手の活躍が凄まじいので便乗してフルネームで名乗ってみました。 2024年9月20日。大谷翔平選手が前人未到の 【50-50】 を達成した裏で、私、山口翔平がひっそり GCP認定資格【11冠】 を達成しました。 2022年9月にGoogle Cloud の部署に新人として配属され、ちょうど二年後の2024年9月に 認定資格11冠(全冠) を達成しました。せっかくなので全冠までの2年間の軌跡をブログに残そうと思います。 試験の概要は 公式ドキュメント や SCSKの別社員の全冠ブログ に分かりやすく記載されており、これ以上のことは書けないので丸投げするとして、本ブログでは、 ・各資格の印象(受験した所感などを筆者の主観で) ・オススメの取得順序(これまた筆者の主観で) にフォーカスし、筆者の主観たっぷりで書きたいと思います。 では、山口翔平の記念すべき 【20本目】 のブログスタートです。 取得年表 フルネーム呼びがそろそろしんどくなってきたので早速内容に入ります。 説明に入る前に、長い資格名の略称を整理しておきます。 サイトごとに略称が異なりますが、当ブログでは以降下記略称を使います。 正式名称 略称(※大文字部分をとってます) Cloud Digital Leader CDL Associate Cloud Engineer ACE Professional Cloud Architect PCA Professional Cloud Developer PCD Professional Cloud DevOps Engineer PCDOE Professional Data Engineer PDE Professional Cloud Database Engineer PCDE Professional Cloud Security Engineer PCSE Professional Cloud Network Engineer PCNE Professional Google Workspace Administrator PGWA Professional Machine Learning Engineer PMLE   年表は下記のとおりです。 あらためて年表を見返してみて、一番の反省点は ACE→PCAの空白の4か月 です。 後ほど詳しく書きますが、 ACEとPCAは問題の類似度が非常に高い ため比較的学習がしやすくスムーズに取得を目指せるほか、PCAまで取ってしまうと 他のProfessional資格へのアクセルが踏みやすい です。 私はここで4か月の隙間が空いてしまったため、PCA受験前にACEと重複する部分も学習しなおす手間と時間がかかってしまいました。 ここからは、各資格試験の印象、オススメの取得順序について深掘りしていきます。   各試験の印象 各資格取得時の筆者の状況と、試験の印象を書きます。 (注)筆者が受験した当時の情報です。最新情報はドキュメントをご参照ください。 資格名 Google Cloud歴 (※m:months) 実業務で触っていたサービス等 所感 CDL 3 m VPC、GCE 配属から3か月が経ち、右も左もわからない状況から、 なんとなくクラウド(Google Cloud)がどういいうものか掴み始めたタイミング で受験+合格。 最近受検した人に聞くとAIに関することも聞かれたらしい。当時はそんなことなかった。 ACE 5 m VPC、GCE、Cloud Router、Cloud DNS、Cloud Interconnect 2つ目の受験にして 早速躓いた 。公式ドキュメントを見て かなり幅広いサービスに関する知識が必要 であることを知り、2か月間みっちり対策しなんとか合格。 PCA 9 m BigQuery、Data Fusion、Cloud Functions ACEの知識を取り戻すのに時間を要したが、学習にはそこまで苦労しなかった。あくまでACEの延長線上の印象。ACEの苦労の影響でかなりじっくり対策して臨んだ。 インフラ領域のサービスに加え、BigQueryを扱いだした経験が生きた。 「おめでとう」を言ってくれる人がCDL,ACEより格段に増えた。割と影響力のある資格なんだと感じたと同時にすこし一人前になれた気がした。 PDE 11 m BigQuery、Data Fusion、Cloud Functions Google Cloud歴も1年近くになり、扱うサービスも増えてきた段階で受験、カリキュラムの過渡期だったのか、 AI/ML関連の知識も多く問われた 印象。 筆者のメイン担当領域がDWH・ETLだったこともあり、勉強はサクサク進んだ。メイン領域が違う他の人は割と苦労しているようだった。 PCD 1y1m BigQuery、Data Fusion、Cloud Functions アプリケーション設計、CI/CDの領域 に親しみがなく苦労した。GKEやCloud Buildの問題が頻出+さわったことない状況だったので Skills Boostで実際にサービスに触れて 理解を深めた。 実際にサービスを触ると理解が加速する ことを改めて実感した。 PCDOE 1y5m BigQuery、Data Fusion、Cloud Functions PCDの出題内容とかなり似通っている印象。ここも4か月開けたことを後悔した。 PCDのおかげでスムーズに学習が進んだ。 PCNE 1y6m BigQuery、Data Fusion、Cloud Functions インフラ領域のサービスに関してはそこそこ触っている自負があったが、 NWの専門的な知識が必要 でかなり苦労した。 案件業務で Cloud DNS、Cloud Interconnect(検証環境で触れづらい) に触れていた経験にかなり救われた。 PCSE 1y7m BigQuery、Data Fusion、Cloud Functions 内容は PCNEと共通する部分が多い 印象。先にPCNEを取得済みだったので少し追加の学習をするだけで取得できた。 個人的には PCSE→PCNEの順序もオススメ。 PGWA 1y8m BigQuery、Data Fusion、Cloud Functions、Cloud Pub/Sub、VertexAI Google Wrokspaceの管理コンソールを触った経験がなかったためかなり苦労した。 公式ドキュメント に割と詳細な内容が書いてあったため、まずはここを読み込んで理解を深めた。 PCDE (英語) 1y9m BigQuery、Data Fusion、Cloud Functions、Cloud Pub/Sub、VertexAI PDE、PCNEの知識 があれば比較的楽に突破できる印象。初の英語試験だったが、問題文が理解できれば問題なく解けた。(筆者のTOEICスコアは630。) PMLE(英語) 2y BigQuery、VertexAI 所属部署がAI/ML関連部署になり、その3か月後に初受検。筆者にAI/MLの知識がほぼなかったこともあり一度目は撃沈。 その後、 AI/MLに関する基礎知識 と頻出だった BigQuey ML やパ イプラインの選定基準(VertexAI Pipeline、Kubeflow Pipeline TFXなど) について二か月間徹底的に調査・学習。その結果なんとか合格。 (AI/MLの知見がある先輩の力を借りて理解を深めた。) 個人的に躓いた資格を三つピックアップし簡単にコメントします。 Associate Cloud Engineer 意外に思われるかもしれませんが、一つ目はAssociateレベルの「ACE」です。 他のブログを見ると、あくまで中級の資格として紹介されていますが、 出題されるサービスも多く、かなり広範囲の知識必要になる 印象です。 Google Cloudの認定資格にはAssociateレベルの資格がこの一つしかないこともあり、カバー範囲が広くなっているのかもしれません。 一か月間勉強したら大丈夫だろうくらいで構えていましたが、時間が足りず一か月先延ばしして、二か月間の学習で合格できました。 ただ、この資格を突破すると、 PCAを突破するための知識がほとんど身についている状態 だと思います。 ACE→PCAは時間をあけず取得することを強くオススメします。 Professional Cloud Network Engineer 二つ目が「PCNE」です。 私の周りもここで躓いた人が多かった印象です。 ネットワークに関する専門知識が必要になることはもちろんですが、検証環境で実際に触ってみることが難しい Cloud Interconnect に関する具体的な手順等の知識なども求められます。 筆者は運よく案件業務でCloud Interconnect の実装に携わった経験があったためそれに救われましたが、経験がない方は公式ドキュメントを読み込んでおくことをオススメします。 加えて、下記に関する出題が多かったです。 ハブアンドスポークトポロジでのオンプレミス環境との接続 VPC Service Controlsと限定公開のGoogleアクセスによるアクセス制御 共有VPC Cloud Loadbalancing 上記に関する知識は持ったうえで受験することをオススメします。 限定公開のGoogleアクセスに関しては 過去にブログ にまとめているのでぜひご覧ください。 Professional Machine Learning Engineer 三つめは「PCMLE」です。 AI/MLの知識がほとんどなかった筆者にとっては一番難しかったです。 Google Cloud上で機械学習モデルを構築、トレーニング、デプロイ、管理する手順と、使用するサービス選定に関する知識が多く問われます。 ただ、それだけでなく AI/MLに関する一般的な知識 も多く問われます。 ユースケースに沿ったサービス選定をする問題が多く出題され、その中でAI/MLの「一般的な知識」と「Google Cloudサービスに関する知識」の両者が求められるイメージです。 各サービスで できる事、できない事、不向きな事 を一度頭の中で整理しておくことをオススメします。   オススメの取得順序 以上の内容をふまえた上で、オススメの取得順序をご紹介します。 筆者の主観が強く反映されているので、あくまで参考程度にご覧ください。 順序を整理するにあたって、各資格を 筆者の独断と偏見でグルーピング します。 各グループ内の順序は前後して問題ないですが、 同グループの資格は連続して(できれば短い期間で一気に)取得すること を強くオススメします。 上記グループをふまえて、筆者おすすめの順序は下記です。 「オススメの順序」とは言いましたが、データ系、運用系、NW(ネットワーク)系の三つはどれから攻めても問題ないと思います。 これら三つは全て PCAまでの内容を基礎として、それぞれの領域に発展した内容 が多いです。 各グループ内の資格は連続してとる 前提で、 どの系統から順に攻めても問題ない 。というのが私の考えです。 順序を考えるうえで一番悩んだのが PGWAとPMLE です。この二つは領域が異色なので、どこに挟むか悩みましたが、 Google Cloud全般の知識をつけた上で臨むのに越したことはない と思い、最後の方にプロットしました。 しいて言うなら、私が受験した時の PDEがAI/MLの内容が多かった ので、 データ系→PMLEの順序 もオススメです。 二年前に戻り、私が再度全冠を目指すのであれば、 CDL → ACE → PCA → [NW系] → [運用系] → [データ系] → PMLE → PGWA の順序で受けると思います。   まとめ 私が二年間かけてGoogle Cloud認定資格を全冠した軌跡と所感について書きました。 各試験の内容はかなり流動的なので、各資格の詳細というよりは全般的な内容にフォーカスして書きました。具体的な勉強法は 他社員のブログ で紹介されているのでぜひご覧ください。 全試験通じていえることですが、やはり 「実際にサービスを触ってみる」 ことが一番の近道です。 公式ドキュメントで出題サービスを確認する 各サービスに対する学習の中で、ピンと来ないところは Skills Boostで実際に触ってみる という流れを踏むことが効果的だと思います。 また、GoogleがAI/ML関連のビジネスに注力していることもあり、いろんな資格に AI/MLの問題が出題され始めている ように感じます。CDLにAI/MLの問題が出され始めたのが良い例ですね。 Google Cloudの認定資格を全冠するうえで、 AI/MLの知識はより強く求められるもの になっていきそうです。 私自身、今年度からAI/MLを専門とする部署に異動になったので、これからより一層AI/MLの知識をつけていこうと思っているのですが、その足掛かりとしてPMLEにも挑戦しました。 経験や知識をアウトプットする場として資格試験を活用することはもちろんですが、 新しい領域にチャレンジする足掛かりとして資格試験を活用する こともアリだと個人的には思います。 また、本ブログでも何度か引用していますが、同部署の一年後輩にあたる社員がすごいスピードで資格を取得していた(筆者の一年分を3か月で抜かれた)ので、密かにいい刺激をもらい、負けじと勉強頑張りました。誰かと競いあって全冠を目指すのもアリです。   最後までご覧いただきありがとうございました。 これからも役立つ情報を(大谷選手の本数に負けないよう)どんどん発信していきますのでご期待ください。  
こんにちは。SCSKの磯野です。 BigQueryでTBレベルの大きなデータを扱うとき、意図しない高額課金のリスクを抑えたいと思ったことはありませんか? 今回は、大きなテーブルを扱う上で、コスト削減につながるTipsをいくつかご紹介します。 BigQueryの課金体系 BigQuery の料金は主に次の 2 つの要素で構成されています。 コンピューティングの料金  は、SQL クエリ、ユーザー定義関数、 スクリプト、特定のデータ操作言語(DML)とデータ定義 言語(DDL)ステートメントがあります。 ストレージ料金 は、ストレージ BigQuery に読み込むデータを保存できます 本記事では、「コンピューティング料金」「ストレージ料金」それぞれのコストを削減する方法をご紹介します。   コンピューティング料金削減方法 その1:パーティショニングやクラスタリングを使用する BigQueryには、パーティショニングとクラスタリングという機能があり、テーブル作成時にそれらを設定することで、クエリ実行時のパフォーマンスを向上させることができます。 なお、BigQueryには パーティションとクラスタの Recommender という機能があり、過去のワークロードに基づいてテーブルのパーティショニングやクラスタリングの適切な設定を推奨してくれます。Recommender API を有効にすることで利用できるため、是非活用してみてください。 パーティションとクラスタの推奨事項を表示する  |  BigQuery  |  Google Cloud cloud.google.com その2:パーティションフィルタを必須とする パーティションを使用したテーブルであっても、適切なクエリを書かないとうっかりフルスキャンが走ってしまう可能性があります。 そこで、パーティションフィルタを必須としておくことで、where句を適切に指定していないクエリはエラーとなるため、フルスキャンを防止することが可能となります。 パーティション分割テーブルに対するクエリ  |  BigQuery  |  Google Cloud cloud.google.com その3:オンデマンドクエリの上限値を設定する BigQuery API には以下のような 割り当て  (Quota) が設けられています。これらは、プロジェクト単位で指定が可能です。  Query usage per day (1 日あたりのクエリ使用量)  Query usage per day per user(ユーザーごとの 1 日あたりのクエリ使用量) クォータと制限  |  BigQuery  |  Google Cloud BigQuery のジョブ、クエリ、テーブル、データセット、DML、UDF、API リクエストに適用される割り当てと上限について説明します。 cloud.google.com デフォルトでは「無制限」に設定されているため、割り当て (Quota) を設定することで上限を超えるクエリの実行を制限することが可能となります。   ストレージ料金削減方法 その4:ストレージ課金モデルの変更 BigQueryのストレージ料金には、2つの課金モデルがあります。 論理ストレージ(Logical Storage)課金 テーブルに格納されたデータの、 圧縮前 のデータサイズに対して課金するモデル 物理ストレージ(Physical storage)課金 圧縮後 のデータサイズに対して計算が行われる課金モデル。 BigQuery では、データは圧縮されて格納されています。圧縮率はデータによって異なりますが、4分の1〜12分の1程度、あるいはそれ以上に圧縮されている可能性があります。 デフォルトでは、 論理ストレージ (Logical Storage)課金が設定されています。 物理ストレージ 課金へ変更することで、圧縮後の小さいデータサイズに対して課金されるため、利用料金が削減できる可能性があります。 ただし、 物理ストレージ 課金の場合、データサイズあたりの単価は高くなります。また、データの性質によって圧縮率が異なるため、物理ストレージ課金に変更することで必ずしもコストが削減されるとは限りません。ご自身の環境で圧縮率やデータサイズを確認したうえで、課金モデルの変更をご検討ください。 新しい料金モデルで BigQuery の物理ストレージの費用を削減 | Google Cloud 公式ブログ お客様が BigQuery でクラウドのデータ ウェアハウジングを拡張するにつれて、スケーラブルなクラウドデータ ストレージに対する費用の最適化が重要になります。 cloud.google.com   まとめ いかがだったでしょうか。 BigQueryでTBレベルの大きなデータを扱うとき、費用を抑えるための方法をいくつかご紹介しました。 なお、万が一意図しない高額課金が発生してしまった場合、GCPのサポートに連絡すると、何らかの救済措置をしていただけるかもしれません。 本記事が皆様のお役に立てれば幸いです。
こんにちは。SCSKの磯野です。 BigQueryのパーティションフィルタについて、気になったことをいくつか調べてみました。 パーティションフィルタとは パーティションフィルタを有効にすると、パーティション列を適切に指定したWHERE句が存在しないときに、エラーとすることができます。これにより、必ずパーティションが効くクエリしか実行できなくなるため、フルスキャンによる高額課金を防止することができます。 パーティション分割テーブルの管理  |  BigQuery  |  Google Cloud cloud.google.com   パーティションフィルタを有効にする方法 terraformで管理している場合、以下の一文を追加することでパーティションフィルタを有効にすることが可能です。 require_partition_filter =  true   Terraform Registry registry.terraform.io なお、テーブル作成後でもパーティションフィルタを有効化することは可能です。 ( 参考 ) パーティション分割テーブルを作成するときに、 パーティション フィルタを要求する オプションを有効にしない場合でも、テーブルを更新してオプションを追加できます。   動作検証 検証方法 BigQueryの公開データセットを使っています。 bigquery-public-data.wikipedia.pageviews_2024 を自分のプロジェクトへコピーし、パーティションフィルタの設定を変えて検証してみました。 本テーブルはサイズが大きいため、パーティションフィルタを無効にした状態での実行は自己責任でお願いいたします。 パーティションフィルタを有効にすると? 有効化前(パーティションフィルタ省略可能) パーティションフィルタを省略可能な状態にしたままクエリを実行すると、フルスキャンが走ることが確認できました。 有効化後(パーティションフィルタ必須) パーティションフィルタを必須にした状態でクエリを実行すると、where句がないためエラーとなることが確認できました。 WHERE句を誤って指定していても、パーティションフィルタは効く? では、パーティションが効かないようなwhere句を指定した場合はどうなるでしょうか? 以下のようなクエリで試してみました。本クエリは、パーティション列(datehour)によるwhere句が記載されていますが、パーティショニングが効かず、フルアクセスとなってしまいます。 SELECT * FROM `myproject.mydateset.wikipedia_pageviews_2024` -- 公式データセットをコピーしたテーブル WHERE DATETIME_ADD(datehour, INTERVAL 9 HOUR) BETWEEN "2024-7-3 9:00:00" AND "2024-7-3 15:00:00"; 本データ場合、datehourはTIMESTAMP型であるためDATETIME_ADDではなくTIMESTAMP_ADDを使用するのが適切です。検証のために意図的にDATETIME_ADDを使用していますが、TIMESTAMP_ADDを使用すれば、パーティショニングが効き、フルスキャンを避けることができます。 有効化前(パーティションフィルタ省略可能) パーティショニングが効かないクエリのため、フルスキャンが走ることが確認できました。 有効化後(パーティションフィルタ必須) パーティションフィルタが効いており、エラーとなることが確認できました。 → パーティションフィルタは、where句が適切でないことを認識できています。 Jupyter Notebookからクエリを実行しても、パーティションフィルタは効く? import pandas as pd from google.cloud import bigquery client = bigquery.Client(project=project_id) # クエリを定義 query = """ SELECT * FROM `myproject.mydateset.wikipedia_pageviews_2024` WHERE DATETIME_ADD(datehour, INTERVAL 9 HOUR) BETWEEN "2024-7-3 9:00:00" AND "2024-7-3 15:00:00"; """ # クエリを実行して結果をDataFrameに読み込む df = client.query(query).to_dataframe() # 結果を表示 print(df.head()) Cloud Shellエディタより試しましたが、以下のようにエラーとなり、パーティションフィルタが効いていることが確認できました。 BadRequest: 400 Cannot query over table ‘myproject.mydateset.wikipedia_pageviews_2024’ without a filter over column(s) ‘datehour’ that can be used for partition elimination; reason: invalidQuery, location: query, message: Cannot query over table ‘myproject.mydateset.wikipedia_pageviews_2024’ without a filter over column(s) ‘datehour’ that can be used for partition elimination   結論 パーティションフィルタは、単純に 「パーティション列を使用したwhere句の有無」 をチェックしているのではなく、 「パーティションが効くクエリかどうか」 をチェックしていることがわかりました。 パーティション列を使用したwhere句を書いていても、不適切な書き方だとパーティションが効かないことがあります。そのような場合でも、パーティションフィルタを有効にしていればエラーとなるため、意図しないフルスキャンを防止することができます。 また、コンソールだけではなく ノートブックからの実行でも、パーティションフィルタは効く ことがわかりました。 本記事が皆様のお役に立てれば幸いです。
こんにちは。SCSKの磯野です。 Dataformで、同一のSQLXファイルから複数環境(dev、prod)向けにリリースを行う方法を記載します。 使用するプロジェクトが1種類( project-a -dev、 project-a -prd)であれば、下記公式ドキュメントの方法で問題ないと思います。 スキーマとプロジェクトごとに開発と本番環境を分割する | Dataform | Google Cloud 今回は、複数のプロジェクトかつ複数環境( project-a -dev、 project-a -prd、 project-b -dev、 project-b -prd)を使用する場合におけるリリース方法を記載します。 ユースケース 本記事は、以下のユースケースにおけるリリース方法を記載しています。 実行環境は、開発(dev)と本番(prod)の2つ 開発テーブルと本番テーブルで共通のSQLXファイルを使いたいが、プロジェクトは分けたい 1つのリポジトリで複数のプロジェクトへのリリースを管理したい   リリース方法概要 カスタムコンパイル変数 を使用します。主な手順は以下の通りです。 workflow_settings.yaml でコンパイル変数を定義する。デフォルトの値としてdev環境で使用する値を設定する dev環境でリリースする際は、デフォルトの値を使用する。 prod環境でリリースする際は、リリース構成にてコンパイル変数をオーバーライドする 設定 開発環境(dev) 本番環境(prod) Google Cloud プロジェクト project-a-dev project-a-dev project-a-prd project-a-prd Gitのブランチ ワークスペースの名前 main ワークスペースのコンパイルのオーバーライド なし なし リリース構成 なし ※ワークスペースから、手動で「実行を開始」する。 production ※カスタムコンパイル変数にてそれぞれのプロジェクトをオーバーライド   リリース方法詳細 事前準備 workflow_settings.yaml vars: projectADefault: "project-a-dev" projectBDefault: "project-b-dev" definitions/project_a/analytics/sample_table_a.sqlx config { type: "table", database: dataform.projectConfig.vars.projectADefault, schema: "analytics", name: "sample_table_a", } SELECT * FROM ${ref("sample_table_b")} definitions/project_b/mydataset/sample_table_b.sqlx config { type: "declaration", database: dataform.projectConfig.vars.projectBDefault, schema: "mydataset", name: "sample_table_b", } リリース構成 リリースID:production git Commitish:main コンパイル変数 キー 値 projectADefault project-a-prod projectBDefault project-b-prod これにより、コンパイル変数がオーバーライドされる。 手順 開発環境(dev)の場合 ワークスペースから、手動で「実行を開始」します。 カスタムコンパイル変数を上書きせずに実行することで、デフォルトのコンパイル変数の設定で実行可能です。 本番環境(prod)の場合 <手動実行の場合> 事前にmainブランチへマージ・コンパイルしておく 手動ワークフローの実行にて、リリース構成 production を指定して実行。 →オーバーライドされた状態で実行される <スケジュール実行の場合> リリース構成 production を指定してワークフロー構成を作成する   まとめ いかがだったでしょうか。 今回はDataformにて、カスタムコンパイル変数を使用する場合におけるリリース方法をご紹介しました。 本記事が皆様のお役に立てれば幸いです。  
こんにちは。SCSKのふくちーぬです。今回は、EC2(Amazon Linux 2023)にDockerをインストールする方法をご紹介します。 本手順は、閉域網環境を対象としてますが、もちろんインターネットゲートウェイまたはNatゲートウェイがあるパブリック環境に対しても有効なものとなります。 アーキテクチャー インターネットゲートウェイ、NATゲートウェイが存在しない閉域網ネットワーク(プライベート環境)とする。 Systems Managerの管理下にするために、EC2はマネージドインスタンスとする。また、OSはAmazon Linux 2023を利用します。 運用者は、セッションマネージャーを利用してEC2に接続します。 Run Commandを利用して、マネージドインスタンスに対してDockerインストールコマンドを実行します。 S3にRun Commandの実行ログを出力します。   完成したCloudFormationテンプレート 以下のテンプレートをデプロイしてください。 AWSTemplateFormatVersion: 2010-09-09 Description: CFN template EC2 Parameters: ResourceName: Type: String AMIId: Type: String Resources: # ------------------------------------------------------------# # S3 # ------------------------------------------------------------# S3BucketFor: Type: AWS::S3::Bucket DeletionPolicy: Delete Properties: BucketName: !Sub ${ResourceName}-s3-bucket AccessControl: Private PublicAccessBlockConfiguration: BlockPublicAcls: true BlockPublicPolicy: true IgnorePublicAcls: true RestrictPublicBuckets: true # ------------------------------------------------------------# # VPC # ------------------------------------------------------------# VPC: Type: AWS::EC2::VPC Properties: CidrBlock: 10.0.0.0/16 EnableDnsSupport: true EnableDnsHostnames: true Tags: - Key: Name Value: !Sub ${ResourceName}-VPC # ------------------------------------------------------------# # Private Subnet # ------------------------------------------------------------# PrivateSubnet1a: Type: AWS::EC2::Subnet Properties: VpcId: !Ref VPC CidrBlock: 10.0.1.0/24 AvailabilityZone: ap-northeast-1a MapPublicIpOnLaunch: false Tags: - Key: Name Value: !Sub ${ResourceName}-subnet-Private-1a PrivateSubnet1c: Type: AWS::EC2::Subnet Properties: VpcId: !Ref VPC CidrBlock: 10.0.11.0/24 AvailabilityZone: ap-northeast-1c MapPublicIpOnLaunch: false Tags: - Key: Name Value: !Sub ${ResourceName}-subnet-Private-1c # ------------------------------------------------------------# # Route Table and Routes # ------------------------------------------------------------# PrivateRouteTable: Type: AWS::EC2::RouteTable Properties: VpcId: !Ref VPC Tags: - Key: Name Value: PrivateRouteTable PrivateSubnet1aAssociation: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PrivateSubnet1a RouteTableId: !Ref PrivateRouteTable PrivateSubnet1cAssociation: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PrivateSubnet1c RouteTableId: !Ref PrivateRouteTable # ------------------------------------------------------------# # VPC Endpoint # ------------------------------------------------------------# ssmEndpoint: Type: AWS::EC2::VPCEndpoint Properties: ServiceName: !Join - '' - - com.amazonaws. - !Ref 'AWS::Region' - .ssm SubnetIds: - !Ref PrivateSubnet1a - !Ref PrivateSubnet1c VpcId: !Ref VPC VpcEndpointType: Interface SecurityGroupIds: - !Ref VPCeSecurityGroup PrivateDnsEnabled: true ec2messagesEndpoint: Type: AWS::EC2::VPCEndpoint Properties: ServiceName: !Join - '' - - com.amazonaws. - !Ref 'AWS::Region' - .ec2messages SubnetIds: - !Ref PrivateSubnet1a - !Ref PrivateSubnet1c VpcId: !Ref VPC VpcEndpointType: Interface SecurityGroupIds: - !Ref VPCeSecurityGroup PrivateDnsEnabled: true ssmmessagesEndpoint: Type: AWS::EC2::VPCEndpoint Properties: ServiceName: !Join - '' - - com.amazonaws. - !Ref 'AWS::Region' - .ssmmessages SubnetIds: - !Ref PrivateSubnet1a - !Ref PrivateSubnet1c VpcId: !Ref VPC VpcEndpointType: Interface SecurityGroupIds: - !Ref VPCeSecurityGroup PrivateDnsEnabled: true S3VpcEndpoint: Type: AWS::EC2::VPCEndpoint Properties: ServiceName: !Join - '' - - com.amazonaws. - !Ref 'AWS::Region' - .s3 VpcId: !Ref VPC VpcEndpointType: Gateway RouteTableIds: - !Ref PrivateRouteTable # ------------------------------------------------------------# # Security Group # ------------------------------------------------------------# SecurityGroup: Type: AWS::EC2::SecurityGroup Properties: GroupDescription: For EC2 VpcId: !Ref VPC VPCeSecurityGroup: Type: AWS::EC2::SecurityGroup Properties: VpcId: !Ref VPC GroupDescription: For VPCEndpoint SecurityGroupIngress: - SourceSecurityGroupId: !Ref SecurityGroup IpProtocol: tcp FromPort: 443 ToPort: 443 # ------------------------------------------------------------# # IAM Role and Instance Profile # ------------------------------------------------------------# SSMRole: Type: AWS::IAM::Role Properties: RoleName: !Sub ${ResourceName}-ec2-role AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Principal: Service: ec2.amazonaws.com Action: sts:AssumeRole Path: / ManagedPolicyArns: - arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore - arn:aws:iam::aws:policy/AmazonS3FullAccess InstanceProfile: Type: AWS::IAM::InstanceProfile Properties: Roles: - !Ref SSMRole # ------------------------------------------------------------# # EC2 Instance # ------------------------------------------------------------# EC2Instance: Type: AWS::EC2::Instance Properties: InstanceType: t2.micro ImageId: !Ref AMIId SubnetId: !Ref PrivateSubnet1a IamInstanceProfile: !Ref InstanceProfile SecurityGroupIds: - !Ref SecurityGroup Tags: - Key: Name Value: !Sub ${ResourceName}-ec2    Dockerのインストール セッションマネージャーを利用してEC2に接続 セッションマネージャーを利用して、EC2に接続します。「接続」を押下します。 下記のコマンドを実行して、Dockerがインストールされていないことを確認します。 docker --version Run Commandの実行 Systems Managerのコンソールのペインから、Run Commandを選択します。「Run Command」を押下します。   Dockerをインストールするためのコマンドである”AWS-ConfigureDocker”を検索ボックスに入れて、選択します。 コマンドドキュメントプラグインリファレンス - AWS Systems Manager コマンドタイプ SSM ドキュメントでプラグインを指定して、マネージドインスタンスで実行するアクションを選択します。 docs.aws.amazon.com   インストールするEC2を選択します。   実行ログをS3またはCloudWatchロググループに出力することができます。 「実行」を押下します。 Run Commandが完了すると以下の画面になります。 インスタンスIDを選択すると、ログの内容が確認できます。 また今回は、S3バケットにもログを出力するように設定しているためファイルが格納されています。 Dockerのインストール確認 先程度同様にセッションマネージャーを利用して、EC2に接続します。 セッションマネージャーで利用しているユーザーに対して、sudo権限でDockerコマンドを操作できるように以下のコマンドを実行します。 sudo gpasswd -a ssm-user docker 設定を反映させるために「終了」を押下して一旦ログアウトした後に、再度EC2に接続します。 以下のコマンドを実行し、Dockerがインストールされたことを確認します。 docker --version sudo権限なしで実行できました。 docker images   最後に いかがだったでしょうか。 Systems ManagerのRun Commandを利用することで、手動でDockerをインストールするコマンドを実行することなく、容易にコンテナを利用できるようになります。他のRun Commandについても便利なため、是非ドキュメントも覗いてみてください。 本記事が皆様のお役にたてば幸いです。 ではサウナラ~🔥