こんにちは、2024年度入社の秋葉です！ クラウドやアプリ開発の現場でよく聞く「コンテナ技術」。 「結局何なの？」と疑問を持っている方も多いのではないでしょうか？コンテナは、アプリを軽く素早く動かせる仮想化技術で、開発・運用のスピードや効率を大きく向上させます。この記事では、私が新人研修を通して実際にコンテナ技術に触れて感じた魅力や使い方、初心者でも理解しやすいポイントを解説します。 これからコンテナを試してみたい方、ぜひ一緒に一歩踏み出してみましょう！ コンテナとは コンテナは、ホストOS上にアプリケーションの実行に必要な本体・ライブラリ・設定ファイルなどを一括管理し、「コンテナエンジン」を介して動かす技術です。分かりやすく例えると、PC内に仮想のミニPCを作ってアプリを動かすようなものと考えるとイメージしやすいでしょう。 従来の仮想化技術では、1つの仮想環境内にOSから必要な全ての要素を構築するため、異なるOSが求められるケースには便利でした。しかし、開発や運用の現場では「OSは共通で良い」という場合も多く、OSまで含めて用意するのはリソースの無駄になっていました。 その点、コンテナ技術では、 OS部分は共有 しつつ、アプリごとに必要なCPU・メモリ・ファイル・プロセス空間を独立した「コンテナ」として管理します。このため、軽量でかつ高速に起動することができどの環境でも同じように動作するのです。 仮想化と比較した際のメリット・デメリット メリット デメリット とにかく処理が軽量 環境構築に要する時間の大幅な削減 リリースサイクルの高速化に関わる「DevOps」と相性が良い 複数のホストでのコンテナ運用が煩雑になる 新しい技術であり学習コストが比較的高い コンテナ環境でベースとなるOSと異なるOSのシステムを動かすことはできない 各コンテナやコンテナサポートの特徴 Docker コンテナ技術を広く普及させたオープンソースのプラットフォームで、アプリケーションとその依存関係を単一のコンテナイメージにまとめ、異なる環境でも一貫性のある動作を提供します。 軽量で高速な起動 が特徴です。 Kubernetes コンテナ化されたアプリケーションをオーケストレーションするためのプラットフォームです。自動スケーリング、自己修復、および複雑なデプロイ戦略のサポートが可能です。 OpenShift Kubernetesをベースにしたエンタープライズ向けのコンテナプラットフォームで、Red Hatが提供しています。セキュリティ機能や開発者向けツールが統合されています。 Podman コンテナの運用と管理を行うためのオープンソースツールで、デーモンを必要としないアーキテクチャを採用しています。Docker CLIとの高い互換性があり、セキュリティリスクを低減するRootlessオペレーションをサポートしています。    Dockerとは Docker社が開発している、コンテナ型の仮想環境を作成、配布、実行するためのプラットフォームのことであり、コンテナのデファクトスタンダードとして広く使われている技術の1つです。 Dockerは、 Dockerイメージ と Dockerコンテナ という2つの主要な要素を使って動作します。 Dockerのメリット コード化されたファイルを共有することで、どこでも誰でも同じ環境が作れる。 作成した環境を配布しやすい。 スクラップ＆ビルドが容易にできる。 Dockerは、 軽量で迅速にデプロイ できるという利点から広く普及していますが、他のコンテナ技術と比較すると、用途や環境により異なる利点と欠点があります。 例えば、セキュリティ重視ならPodmanやrktが適しており、大規模オーケストレーションならKubernetesと組み合わせた利用が効果的です。目的に応じて技術を選定することで、効率的なシステム運用が実現できます。   Dockerイメージ作成からコンテナ起動までの流れ Dokcerイメージ作成 Dockerイメージは、 Dockerfile と呼ばれる設定ファイルから作成されます。Dockerfileには、イメージに含めるアプリケーションや依存関係、設定が記述されています。例えば、どのベースOSを使用するか、アプリケーションのインストール方法、環境変数の設定などが記載されます。（下記コードはDockerfileの例） FROM ubuntu:18.04 COPY . /app RUN cd /app CMD python /app/app.py Dockerfileが準備できたら、以下のコマンドを実行してDockerイメージを作成します。 $ docker build -t イメージ名:タグ Dockerfileのあるディレクトリ Dockerイメージの共有 作成したDockerイメージは、自分のローカル環境だけでなく、他の開発者やチームメンバーとも共有できます。一般的には、Dockerイメージの共有には Docker Hub というパブリックリポジトリが利用されます。Docker Hubは、他のユーザーがイメージをダウンロードできるプラットフォームです。（※研修ではECRへイメージを共有しました） Docker Hubのアカウントを作成し、ログインした後に以下のコマンドを実行することでイメージを共有します。 $ docker push ユーザー名/イメージ名:タグ Dockerコンテナの起動 以下のコマンドを使用することでDockerコンテナを起動します。 $ docker run [オプション] イメージ　[コマンド] [引数]   Dockerに触れてみた 初めてDockerとAWSのECRを使って、自分の作成したDockerイメージをクラウド上にデプロイしてみました！ ここでは、Dockerイメージの作成から、AWS ECRを利用してコンテナを起動するまでのステップを紹介します。 Dokcerイメージ作成 FROM amazoncorretto:17 COPY target/web-ui-teamG-0.0.1-SNAPSHOT.jar /web_app/ COPY src/main/resources/application-d0.yml /web_app/ WORKDIR /web_app ENTRYPOINT ["java", "-jar"] CMD ["-Dspring.profiles.active=local", "/web_app/web-ui-teamG-0.0.1-SNAPSHOT.jar"] 前節で紹介したコード例を参考に上記のようなDockerfileを作成しました。ベースイメージはDockerhubでなく、Amazon ECR Public Gallery のamazoncorretto を使用しています。 JARファイルを起動するように Dockerfile を記述し、下記コマンドでContainer ImageをBuildします。（※今回はtest） $ docker build -t test . Dockerイメージの共有 ECRへイメージをプッシュする前にAWS CLIコマンドを使用してECRにログインします。この際に、開発環境であるCloud9にAmazonEC2ContainerRegistryFullAccessなどのポリシーをアタッチしないとエラーになるので注意です！ $ sudo aws ecr get-login-password --region <your-region> | docker login --username AWS --password-stdin <your-account-id>.dkr.ecr.<your-region>.amazonaws.com ECRにログイン出来たら下記コマンドを実行してイメージをECRリポジトリ向けにタグ付けします。 $ docker tag <repository-name>:<tag> <your-account-id>.dkr.ecr.<your-region>.amazonaws.com/<repository-name>:<tag> タグ付けが完了したら下記コマンドを実行してECRへイメージをプッシュします。 $ docker push <your-account-id>.dkr.ecr.<your-region>.amazonaws.com/<repository-name>:<tag> Dockerコンテナの起動 最後に前節のコンテナ起動のコマンドを実行してコンテナを起動できたら終了となります。 コンテナが起動したら下写真のようにDockerファイル内で指定しているjavaアプリケーションが実行されます。   終わりに ～Dockerに触れてみた感想～ Dockerを使用した最初の印象は、「シンプルで強力なツール」というものでした。コンテナ技術により、アプリケーションの設定や依存関係が一つのイメージにまとめられ、どの環境でも同じように動作することに驚きました。 初めて触れる際には学びのハードルも感じるかもしれませんが、その魅力を理解し、実際に触れてみることで多くの可能性を感じることができましたので今後もコンテナについて学び続けたいと思います！！

初めまして。 SCSKの多田といいます。 今まではAWSでサーバレス環境の構築等を行うことが多かったのですが、今期よりEC2を使ったサービスを提供している部署に異動となり、最初の仕事としてEC2の運用周りを見直す機会に携わりました。 その中で、サービス提供中のEC2のバックアップとしてAMI作成を手動で作成しているのを人手を介さずに自動化できないかなーとお題をいただいたので、EC2周りの勉強がてら実施してみることにしました。 最初は「EC2のマネジメントコンソールのアクションボタンからイメージ作成を選択するのを自動化するだけの簡単なお仕事」と思っていたのですが、思いのほか、はまったり、悩んだりといったことがありましたので、皆さんに共有できればと思い記事にしてみました。 なお、簡単な(当初は)お仕事の概要としては以下のポイントとなります。 運用中のEC2からゴールデンイメージ(AMI)を作成 ゴールデンイメージにはEC2のログやテンポラリのファイルなどを含めないようにしたい 完全自動化(上記のEC2内部のクリーンアップや作成したイメージの管理まで) 構成について   利用した主なAWSサービス 今回、利用した主なAWSのサービスは以下の2つとなります。 EC2 Image Builder Image Builder とは - EC2 Image Builder Image Builder は、安全なカスタム Amazon マシンイメージ (AMIs) またはコンテナイメージを作成し、 内の送信先アカウントとリージョンで使用できるように配布するために使用できるフルマネージドサービスです AWS。 docs.aws.amazon.com Systems Manager Automation AWS Systems Manager Automation - AWS Systems Manager Systems Manager Automation により、Amazon EC2 インスタンスおよびその他の AWS リソースの一般的なメンテナンスとデプロイを簡素化します。 docs.aws.amazon.com 全体の構成について いきなりですが、今回の機能の全体の構成図は以下の通りとなります。 図1 全体イメージ図 まず、このSystems Manager AutomationとEC2 Image Builderの2つを組み合わせた構成になった背景について説明します。 EC2 Image Builder自体はAMI(図1 ①)を起点にして最終的なAMI(図1 ⑨)を作成するサービス となります。 そのため、稼働中のEC2から最終的なAMIを作成するためには、EC2 Image Builderだけでは実現できなく、 Systems Manager Automationを使って起点となる一時的なAMI(図1 ①)を作成 しています。 その後、EC2 Image Builderの設定、起動(図1 ②～⑦)などもSystems Manager Automationを使って実行しています。 そして最後に一時的に作成したAMIは不要なものになるため、最後に削除(図1 ⑧)しています。 AWS Systems Manager Automationの構成について 次にSystems Manager AutomationとEC2 Imager Builderの詳細について説明していきます。 まず、実際に検証で使用したSystems Manager Automationの構成は以下の通りとなります。 図2 Systems Manager Automationの構成図 Systems Manager Automation内のワークフローの詳細は以下の表の通りとなります。 表1 Systems Manager Automationのステップ一覧 項番 アクション Service API 概要 1 aws:createImage – – EC2から一時的なAMIを作成 2 aws:executeAwsApi imagebuilder CreateImageRecipe EC2 Image Builderのレシピを作成 3 aws:executeAwsApi imagebuilder UpdateImagePipeline EC2 Image Builderのパイプラインを更新 (項番2で作成したレシピをパイプラインに組み込む) 4 aws:executeAwsApi imagebuilder StartImagePipelineExecution EC2 Image Builderのパイプラインを起動 5 aws:waitForAwsResourceProperty – – AMIが作成されるまで待つ 6 aws:executeAwsApi imagebuilder TagResource 作成されたAMIにタグを付与 7 aws:executeAwsApi imagebuilder UpdateImagePipeline EC2 Image Builderのパイプラインを更新 (項番3で組み込んだレシピをパイプラインから取り外す) 8 aws:executeAwsApi imagebuilder DeleteImageRecipe EC2 Image Builderのレシピを削除 (項番7で取り外したレシピを削除する) 9 aws:deleteImage – – 項番1で作成した一時的なAMIを削除 実際の定義は以下になります。なお、各パラメータ等はご要件に併せて変更していただくようお願いします。 schemaVersion: '0.3' assumeRole: arn:aws:iam::XXXXXXXXXXXX:role/XXXXXXXXXX mainSteps: - name: CreateAMI action: aws:createImage nextStep: CreateImageRecipe isEnd: false inputs: ImageName: XXXXXXXXXX NoReboot: true InstanceId: XXXXXXXXXX - name: CreateImageRecipe action: aws:executeAwsApi nextStep: UpdateImagePipeline isEnd: false inputs: Service: imagebuilder Api: CreateImageRecipe parentImage: '{{ CreateAMI.ImageId }}' components: - componentArn: arn:aws:imagebuilder:ap-northeast-1:XXXXXXXXXXXX:component/XXXXXXXXXX/1.0.0/1 semanticVersion: 2.0.0 name: XXXXXXXXXX outputs: - Type: String Name: ImageRecipeArn Selector: $.imageRecipeArn - name: UpdateImagePipeline action: aws:executeAwsApi nextStep: StartImagePipelineExecution isEnd: false inputs: Service: imagebuilder Api: UpdateImagePipeline imageRecipeArn: '{{ CreateImageRecipe.ImageRecipeArn }}' distributionConfigurationArn: arn:aws:imagebuilder:ap-northeast-1:XXXXXXXXXXXX:distribution-configuration/XXXXXXXXXX workflows: - workflowArn: arn:aws:imagebuilder:ap-northeast-1:XXXXXXXXXXXX:workflow/build/XXXXXXXXXX/1.0.0/1 executionRole: arn:aws:iam::XXXXXXXXXXXX:role/XXXXXXXXXX imagePipelineArn: arn:aws:imagebuilder:ap-northeast-1:XXXXXXXXXXXX:image-pipeline/XXXXXXXXXX infrastructureConfigurationArn: arn:aws:imagebuilder:ap-northeast-1:XXXXXXXXXXXX:infrastructure-configuration/XXXXXXXXXX - name: StartImagePipelineExecution action: aws:executeAwsApi nextStep: WaitOnAWSResourceProperty isEnd: false inputs: Service: imagebuilder Api: StartImagePipelineExecution imagePipelineArn: arn:aws:imagebuilder:ap-northeast-1:XXXXXXXXXXXX:image-pipeline/XXXXXXXXXX outputs: - Type: String Name: ImageBuildVersionArn Selector: $.imageBuildVersionArn - name: WaitOnAWSResourceProperty action: aws:waitForAwsResourceProperty timeoutSeconds: 3600 nextStep: TagResource isEnd: false inputs: Service: imagebuilder Api: GetImage PropertySelector: $.image.state.status DesiredValues: - AVAILABLE imageBuildVersionArn: '{{ StartImagePipelineExecution.ImageBuildVersionArn }}' - name: TagResource action: aws:executeAwsApi nextStep: UpdateImagePipeline_default isEnd: false inputs: Service: imagebuilder Api: TagResource tags: AMIType: XXXXXXXXXX resourceArn: '{{ StartImagePipelineExecution.ImageBuildVersionArn }}' - name: UpdateImagePipeline_default action: aws:executeAwsApi nextStep: DeleteImageRecipe isEnd: false inputs: Service: imagebuilder Api: UpdateImagePipeline imageRecipeArn: arn:aws:imagebuilder:ap-northeast-1:XXXXXXXXXXXX:image-recipe/default/1.0.0 distributionConfigurationArn: arn:aws:imagebuilder:ap-northeast-1:XXXXXXXXXXXX:distribution-configuration/XXXXXXXXXX imagePipelineArn: arn:aws:imagebuilder:ap-northeast-1:XXXXXXXXXXXX:image-pipeline/XXXXXXXXXX infrastructureConfigurationArn: arn:aws:imagebuilder:ap-northeast-1:XXXXXXXXXXXX:infrastructure-configuration/XXXXXXXXXX - name: DeleteImageRecipe action: aws:executeAwsApi nextStep: DeleteAMI isEnd: false inputs: Service: imagebuilder Api: DeleteImageRecipe imageRecipeArn: '{{ CreateImageRecipe.ImageRecipeArn }}' - name: DeleteAMI action: aws:deleteImage isEnd: true inputs: ImageId: '{{ CreateAMI.ImageId }}' Step Functionsを利用したことがあると、ステップ間の情報の渡し方、情報の参照のや方法はイメージしやすいかも。   Systems Manager Automation構成のポイントについては、QA方式でまとめてみます。 表1の項番2 なぜ、実行するたびにイメージレシピを作成しなおしているの？ イメージレシピを作成する際には、元になるAMIのIDを指定する必要があります。 今回のようにSystems ManagerのAutomationを実行するたびに起動中のEC2からAMIを作成している場合には、AMI IDが毎回異なるため、イメージレシピを作成(もしくは更新)してあげる必要があります。                                       では、何故、毎回イメージレシピを新規作成にしているかというと、 イメージレシピを更新する場合はイメージレシピのバージョンを変更しなければならなく、例えば1.0.0→1.0.1のように既存のものとは異なるバージョンにする必要がありますが、 バージョン番号を実行するたびに動的に生成したくなかったというのが理由になります。 動的というのは例えばですがバージョン番号を既存のイメージレシピから取得してインクリメントした値を返すようなLambdaの作成が想定されますが、今回はなるべくコード作成などは行わずにしたかったため、バージョンは固定(2.0.0)として作成して、利用が終わったらイメージレシピを表1の項番 8で削除するようにしています。    イメージレシピの新しいバージョンを作成する - EC2 Image Builder Image Builder イメージレシピの新しいバージョンを作成します。 docs.aws.amazon.com   表1の項番5   どうして、AMIが作成されるまで待つ必要があるの？ これは表1の項番4で実行されている 「StartImagePipelineExecution」が非同期のAPI となっているためです。 その後の表1の項番7で作成されたイメージレシピを削除するためにイメージパイプラインから切り離すようにしているのですが、イメージパイプラインが実行中だと切り離しができません。 そのため、イメージが作成されてイメージパイプラインが実行されてない状態になるまで待つようにしています。     表1の項番6   何のためにイメージにタグを付与しているんだろう？ 目的としては作成されたイメージに対してライフサイクルポリシーを適用するためです。 今回のように自動的にAMIを作成していくとどんどんイメージがたまっていくため、保存していくイメージ数を管理していく必要がでてきます。 EC2のImage Builderにはイメージのライフサイクルを設定できるライフサイクルポリシーという機能がありますが、その中で ポリシーの適用の対象をタグで指定するようにしているため です。 ここでのタグはEC2のImage Builderでのイメージに付与されるタグになります。AMIのタグとは別のものになりますのでご注意ください。 ライフサイクルポリシーの作成 - EC2 Image Builder EC2 Image Builder ライフサイクル管理ポリシーを作成します。 docs.aws.amazon.com   Amazon EC2 Image Builder の構成について Image Builder の構成のポイントとなる機能について説明します。 イメージパイプライン 最初にイメージパイプラインについて説明します。 AMI イメージパイプラインの作成と更新 - EC2 Image Builder Image Builder AMIイメージパイプラインを作成および更新します。 docs.aws.amazon.com 「イメージパイプラインの作成」ボタンを押下して作成しますが、今回の目的におけるポイントは次の3つになります。 「ビルドスケジュール」の選択について                            図3 EC2 Image Builder設定例-1 「ビルドスケジュール」については、 今回はSystems ManagerのAutomationからEC2のImage Builderを実行することになる ため、「手動」で設定します。 また、Systems ManagerのAutomationを定期的に自動で実行したい場合には、別途EventBridgeでスケジュール設定を行います。 「レシピの詳細」の選択について                             図4 EC2 Image Builder設定例-2 Systems ManagerのAutomationの箇所でも触れましたが実際に使用されるイメージレシピは表1の項番2で作成された後、項番3でイメージパイプラインに設定、項番7でイメージパイプラインから取り外されます。 そのためここの「レシピの詳細」で設定されるレシピは項番8から項番2までの状態のイメージパイプラインに設定されているイメージレシピとなります。 なお、このイメージレシピは実行されることのないものになりますので、今回は「Amazon管理」で提供されている適当なコンポーネントを選んで作成したイメージレシピを選択するようにしています。 上記の図4では、事前に「Default」という名前のレシピを作成済みのため、それを選択しています。 「タイプ」で選択するワークフローの選択について                                   図5 EC2 Image Builder設定例-3 今回は図5のようにオリジナルのイメージワークフローの「CreateAMI-WorkFlow」を設定しています。 詳細については次の「イメージワークフロー」にて説明します。 イメージワークフロー 「タイプ」で選択するワークフローについて説明します。 Image Builder でイメージパイプラインワークフローを設定する - EC2 Image Builder Image Builder パイプラインのイメージワークフローを設定します。 docs.aws.amazon.com 簡単に言うと、EC2 Image BuilderでAMIを作成する際の手順が定義されたものになります。 参考までにAWSが提供しているbuild-imageのイメージワークフローの内容を以下に貼付します。 name: build-image description: Workflow to build an AMI schemaVersion: 1.0 steps: - name: LaunchBuildInstance action: LaunchInstance onFailure: Abort inputs: waitFor: "ssmAgent" - name: ApplyBuildComponents action: ExecuteComponents onFailure: Abort inputs: instanceId.$: "$.stepOutputs.LaunchBuildInstance.instanceId" - name: InventoryCollection action: CollectImageMetadata onFailure: Abort if: and: - stringEquals: "AMI" value: "$.imagebuilder.imageType" - booleanEquals: true value: "$.imagebuilder.collectImageMetadata" inputs: instanceId.$: "$.stepOutputs.LaunchBuildInstance.instanceId" - name: RunSanitizeScript action: SanitizeInstance onFailure: Abort if: and: - stringEquals: "AMI" value: "$.imagebuilder.imageType" - not: stringEquals: "Windows" value: "$.imagebuilder.platform" inputs: instanceId.$: "$.stepOutputs.LaunchBuildInstance.instanceId" - name: RunSysPrepScript action: RunSysPrep onFailure: Abort if: and: - stringEquals: "AMI" value: "$.imagebuilder.imageType" - stringEquals: "Windows" value: "$.imagebuilder.platform" inputs: instanceId.$: "$.stepOutputs.LaunchBuildInstance.instanceId" - name: CreateOutputAMI action: CreateImage onFailure: Abort if: stringEquals: "AMI" value: "$.imagebuilder.imageType" inputs: instanceId.$: "$.stepOutputs.LaunchBuildInstance.instanceId" - name: TerminateBuildInstance action: TerminateInstance onFailure: Continue inputs: instanceId.$: "$.stepOutputs.LaunchBuildInstance.instanceId" outputs: - name: "ImageId" value: "$.stepOutputs.CreateOutputAMI.imageId" 内容をご覧いただくと分かりますが、上の方でも記載しているSystems ManagerのAutomationの定義のようなフローが記述された設定となっています。 ちなみにこの中で実際に行われている処理の内容は以下のリンクに記載があります。 ワークフロードキュメントでサポートされているステップアクション - EC2 Image Builder Image Builder YAML ワークフロードキュメントの でサポートされているステップアクションを使用します。 docs.aws.amazon.com 上記の処理の内容については一通り把握しておくことをお勧めします。 特に「SanitizeInstance」の処理は、AWSが想定しているインスタンスのサニタイズ処理がされるため、作成するイメージとして問題がないかは確認をしたほうがよいです。 もし、イメージワークフローで実施してほしくない処理などがあれば、既存のものを参考にして「イメージワークフローを作成」ボタンから作成して、イメージパイプラインに組み込むことが可能です。 今回は「SanitaizeInstance」の処理の一部が不要なものであったので、オリジナルのイメージワークフロー「CreateAMI-WorkFlow」を作成しています。   コンポーネント 最後にコンポーネントについて説明します。 コンポーネントを使用して Image Builder イメージをカスタマイズする - EC2 Image Builder コンポーネントを使用して EC2 Image Builder イメージをカスタマイズします。 docs.aws.amazon.com 今回はインスタンスに対して独自の処理(ログファイルや一時作成のファイルの削除など)を行いたかったため、独自のコンポーネントを作成しています。 作成にあたっては以下のリンクを参考にしました。 Image Builder イメージのカスタムコンポーネントを開発する - EC2 Image Builder Image Builder イメージのカスタムコンポーネントを開発する docs.aws.amazon.com Use the AWSTOE component document framework for custom components - EC2 Image Builder Use YAML component documents with AWS Task Orchestrator and Executor component document framework to create custom compo... docs.aws.amazon.com なお、イメージレシピにはこのコンポーネントを組み込む形になります。(上記のSystems ManagerのAutomation定義の一部抜粋) - name: CreateImageRecipe action: aws:executeAwsApi nextStep: UpdateImagePipeline isEnd: false inputs: Service: imagebuilder Api: CreateImageRecipe parentImage: '{{ CreateAMI.ImageId }}' components: - componentArn: arn:aws:imagebuilder:ap-northeast-1:XXXXXXXXXXXX:component/XXXXX/1.0.0/1 semanticVersion: 2.0.0 name: XXXXXX outputs: - Type: String Name: ImageRecipeArn Selector: $.imageRecipeArn   以上で、設定に悩んだ、もしくははまった個所については触れることができました。 上記以外の機能(インフラストラクチャ設定、ディストリビューション設定、ライフサイクルポリシー)については、大きく悩む箇所はなかったため割愛させていただきます。   最後に   以上、ざっとですが今回のお題をクリアするための構成ができたことになります。 最後までお読みいただき、ありがとうございました。 最初の想定に比べると倍以上は複雑になってしまったのと、加えてSystems ManagerのAutomationでのパラメータ設定などはドキュメントから読み取れないことも多くトライ&エラーの連続でした。 今回の設定が同じようなことを試そうとしている方に少しでもお役に立てればと思います。

こんにちは、2024年度入社の齋藤です。 現在私は、フルスタック人材の育成を目的とした新人研修に取り組んでいます。Webアプリケーションの開発からAWSを用いたインフラ構築まで幅広い知識を習得できるため、非常に充実した研修内容だと感じています。 今回は、その一環としてAWS Cloud9上でWebアプリケーションの開発を行った際に用いた、 Spring Boot というフレームワークを紹介します。 Spring Boot の概要 まず、Spring Boot の概要について説明します。 Spring Boot とは Spring Boot とは、JavaでのWebアプリケーション開発を迅速かつ効率的に行うための フレームワーク です。 Spring Frameworkに搭載されているフレームワークの1つで、手軽な設定と少ないコード量でアプリケーションを作成するのに役立ちます。 Spring Boot の特徴 ①Webコンテナの内包 Spring Boot は、Webアプリケーション開発を容易にするために、WebコンテナをJAR(JavaARchive)ファイルに内包することができます。これにより、単一のJARファイルでWebアプリケーションを作成し、 手軽にデプロイ することが可能です。デフォルトでTomcatコンテナが含まれていますが、必要に応じて他のコンテナに切り替えることもできます。 ②DI(依存性の注入)   依存しているとは？ 「依存している」とは、「クラスAを正しく動作させるためには、クラスBが必要である」という状態を指します。これは、クラスAがクラスBに依存してることを意味しており、この状態ではクラスAが利用する機能をテストする際にも、クラスBが完成している必要があります。 通常、下の図のようにクラスAがクラスBを直接呼び出す場合、強い依存関係が発生します。 DI(Dependency Injection)を利用することで、クラスAはインターフェースを通じてクラスBを使用します。これにより、クラスBに依存せず、クラスAの単体テストを実行することが可能です。 Spring Boot では、 アノテーション を使用することで、 依存関係のあるインスタンスの管理を自動化 します。これにより、インターフェイスを介すことなく依存関係を保つことができ、コードの可読性と保守性が向上し、開発効率が向上します。 これらの特徴を活かすことで、Spring Boot はJavaによるWebアプリケーション開発をより効率的かつ容易に行うことができる協力なツールとなっています。   開発環境 AWS Cloud9 での Spring Boot のアプリケーション開発方法について説明します。 実施方法 Spring Boot のプロジェクトの作成 Cloud9の画面下部のTerminalで下記コマンドを入力 spring init -j=17 --build=maven -d=web,thymeleaf -g=jp.scsk --package-name=jp.scsk.training.trgapp -a=web-ui-team-developer -n=web-ui-team-developer web-ui-team-developer 実行された結果、web-ui-team-developerの Spring Boot のプロジェクトが作成されたことを確認する。 アプリケーションの実行 Cloud9の画面中央上部にある「Run」ボタンをクリックしてアプリケーションを実行します。 画面下部のターミナルにアプリケーションのログが表示されることを確認します。 実行結果 Using service at https: //start .spring.io Project extracted to  '/home/ec2-user/environment/web-ui-team-developer' ディレクトリ構造 Spring Boot プロジェクトを作成すると、以下のディレクトリ構造が作成されます。この構造は、プロジェクトを整理し、コードの管理を容易にするために設計されています。 web-ui-team-developer/ └── src/ ├── main/ │ ├── java/ │ │ └── jp/scsk/training/trgapp │ │ ├── Application.java │ │ ├── controller/ │ │ ├── service/ │ │ └── repository/ │ └── resources/ │ ├── application.properties │ ├── static/ │ └── templates/ └── test/ └── java/ └── jp/scsk/training/trgapp   Spring Boot を使ってWebアプリケーション開発に挑戦 Spring Boot を使ってWebアプリケーション開発に挑戦してみました。Webアプリケーション開発は設定ファイルの記述量が多く、敷居が高く感じていました。しかし、Spring Boot は設定ファイルが自動生成され、アノテーションで簡単に機能を追加できるため、非常に快適な開発体験でした！ とはいえ、初めての Spring Boot 開発で、いくつか戸惑ったポイントもありました。今回は、その中でも特に難しかったと感じた2つのポイントを紹介します。 アノテーションの付与 Spring Boot は、 アノテーション と呼ばれるメタデータを使って、さまざまな機能を追加できます。アノテーションは、コードに特別な意味を付与し、Spring Boot にどのように動作させるかを指示する役割を果たします。 しかし、アノテーションの種類が多く、どのアノテーションをどの場所に付与すればいいのか、最初は戸惑いました。特に、複数のアノテーションを組み合わせる場合、その動作を理解するのに苦労しました。 Spring Boot のアノテーションについて、実際に作成したコントローラークラスを用いて紹介します。 @Controller 、 @GetMapping 、 @Autowired などのよく使うアノテーションの用途と使い方を理解することで、Spring Boot アプリケーションをよりスムーズに開発できるようになります。 @Controller このクラスがコントローラークラスであることを示します。つまり、Webリクエストを受け取って処理を行う役割を担うクラスであることを宣言しています。 @GetMapping HTTP GETリクエストを処理するメソッドを定義します。 @Autowired Springの依存性注入機能を利用して、Serviceクラスに自動的に連携させます。   pom.xmlファイルの修正 Spring Boot プロジェクトを作成しただけでは、Webアプリケーションをビルドして実行することができませんでした。 pom.xmlファイル に、ビルド設定を追加する必要がありました。 pomファイルとは？ pomファイルは、 プロジェクトの構成と依存関係を管理する ための重要な設定ファイルです。pomファイルには、プロジェクトのビルド、パッケージング、実行に必要な情報が記述されており、開発者はこのファイルを使用してプロジェクトを効率的に管理できます。 具体的には、以下の2つのプラグインを追加しました。 maven-jar-plugin： Javaソースコードをコンパイルするためのプラグイン maven-compiler-plugin： Javaソースコードをコンパイルして生成されたクラスファイルをjarファイルにパッケージングするためのプラグイン この修正で、Spring Boot アプリケーションが適切にパッケージングされ、実行時に起動クラスが正しく呼び出されるようになりました。 ただ、pom.xmlファイルは、プロジェクトの構成情報全体を定義するため、変更する際は慎重に進める必要があります。特に、プラグインのバージョンや依存関係のバージョンを間違えると、ビルドエラーが発生したり、アプリケーションが正常に動作しなくなる可能性がありますのでご注意を。。   おわりに 本投稿では、Spring Boot の基本的な機能や特徴や触ってみた感想について書いてみました。JavaによるWebアプリケーション開発を効率的に進めるための役立つツールであることを理解いただけたでしょうか。Spring Boot を利用することで、迅速な開発と保守性の高いコードの実現が可能となります。ぜひ Spring Boot を開発に活かしていただければと思います。

GCPのCloud Data Fusionはデータパイプラインを作成、管理できるサービスです。Data FusionとCloud Pub/Subを組み合わせることで、日々発生するデータをリアルタイムにDWHへ格納することができます。 今回はデータをリアルタイムにDWHへ連携するパイプラインを、Cloud Data Fusion上に構築してみたいと思います。 作成方法と作成時のポイントを記載します。 使用するサービスの概要 Cloud Pub/Sub アプリケーションとデータ統合用の Pub/Sub | Google Cloud Pub/Subは非同期メッセージサービスです。 リアルタイムデータはスマホやIoT機器などから生成されますが、Cloud Pub/Subを中継するように設計することで、 より便利によりセキュアになります。 また、GCPのリソースと連携がしやすく、フルマネージドサービスのため簡単に作成ができます。 今回はPub/Subにデータ発生元からデータが連携された想定でパイプラインの構築と検証を行います。 BigQuery BigQuery エンタープライズ向けデータ ウェアハウス | Google Cloud BigQueryはフルマネージドのデータウェアハウスサービスです。 今回はこのBigQueryにデータを格納できることをゴールとします。 Cloud Data Fusion Cloud Data Fusion | Google Cloud Data Fusionはコードを意識せずにデータパイプラインを作成、管理できるフルマネージドサービスです。 作成できるパイプラインは、実行するごとに処理が流れる バッチパイプライン と、パイプラインを実行し続けトリガーがあった際に都度処理が走る リアルタイムパイプライン の2種類あります。 今回はリアルタイムパイプラインを使用して構築していきます。   なお、バッチパイプラインの作成方法については、下記の記事をご確認ください。 下記の記事ではGCS上のファイルからデータを連携する方法が記載されています。 【GCP】Cloud FunctionsのCloud StorageトリガーでDataFusionパイプラインを起動 – TechHarmony   実際に作ってみる 実現したい事 今回実現したいことは下記です。 ゴール Cloud Pub/Subに投入したデータがBigQueryに格納される フロー Cloud Pub/Subにて「1111 aaaa」という文字列を公開する Pub/Subでデータが公開されたら、DataFusionリアルタイムパイプラインにてPub/Subからデータを受け取り、データを修正した後BigQueryに格納する BigQueryにて「1111」と「aaaa」が異なるカラムに入る IAMの設定 まず、本検証を実行するのにあたって必要な権限を各サービスアカウントに付与します。 GCPのIAMのページを開き、画面右上にある「Include Google-provided role grants」にチェックを入れます。 「Cloud Data Fusion Service Account」に「Pub/Sub編集者」のロールを付与します。 Cloud Pub/Sub作成 GCPのPub/Subページからトピックを作成します。 「デフォルトのサブスクリプションを追加する」にチェックを入れると自答的にサブスクリプションが作成されます。 トピック：userlist サブスクリプション：userlist-sub（自動で作成） BigQuery作成 GCPのBigQueryページから以下のネーミングにてデータセットとテーブルを作成します。 データセット：user テーブル：list スキーマ：id、name パイプライン構築 Data Fusionインスタンス作成 Data Fusionインスタンスが作成されていない場合は、まずはGCPのData Fusionページからインスタンスを作成します。 作成時のポイントとして、「認可」項目に以下の警告が出た場合は「権限を付与」ボタンをクリックしないと後続のパイプラインを実行する際にエラーがでたため、許可を押しています。 また、インスタンスの作成には数十分時間がかかるので注意が必要です。   リアルタイムパイプライン作成 インスタンスが作成されたら、インスタンス一覧の「インスタンスを表示」を押します。 以下の画面になるので、「List」を押します。 画面右上の+マークから「CREATE」を押します。 パイプラインの作成画面が出るので、左上部にある「Data Pipeline – Batch」を「Data Pipeline – Realtime」に変更します。 画面上部の赤枠の部分から、名前を任意の値に変更します。（今回は「Realtime-userlist」と命名） ここから先は、各プラグインを選択していきます。   Source：Pub/Sub Sourceでは、データの投入元情報を設定します。 今回はデータ投入元はPub/Subのため、左側の「Source」項目から「Pub/Sub」をクリックします。 表示されたPub/Subプラグインにマウスカーソルを合わせると、「Properties」ボタンが表示されるのでクリックします。 表示された画面で、以下の情報を入力します。 Reference Name：pubsub Subscription：userlist-sub Topic：userlist これでSourceの設定は完了です。 入力後、右上の×マークをクリックし、元の画面に戻ります。   Transform：Wrangler 次に入ってきたデータを変換するTransformの設定を行います。 「Transform」から「Wrangler」を選択します。 表示されたら「Pub/Sub」から矢印を引っ張ります。 WranglerのPropertiesの中身は以下にて設定します。 Recipe： keep :message set-type :message string split-to-columns :message \s+ drop :message rename message_1 id rename message_2 name Output Scema：id (string)、name (string)　に設定し、チェックボックスにチェックを入れる   Recipeではデータを変換する処理を記述しています。 詳細な作成方法は割愛しますが、Pub/Subから連携されるデータは、JSON形式のmessageキーの値として引き渡されるため、受け取った値をBigQueryのスキーマに合わせて「id」と「name」に分割しています。 Output Scemaでは次のプラグインに引き渡すスキーマ情報を設定しています。   Sink：BigQuery 最後にデータを別リソースに引き渡すSinkを設定します。 今回はBigQueryにデータを投入したいため、「Sink」から「BigQuery」を選択します。 表示されたら「Wrangler」から矢印を引っ張ります。 BigQueryのPropertiesの中身は以下にて設定します。 Use connection：YES Connection：（BROUSE CONNECTIONSをクリックして選択）BigQuery Default Reference Name：bigquery Dataset：user Table：list また、画面最下部にある「Output Scema」がWranglerと同様に「id」「name」と設定されていることを確認します。（されていなければWrangler同様に設定します）   Configure設定 Sinkの設定まで終わったら、パイプライン画面上部の「Configure」をクリックします。 「Pipeline config」の「Batch Interval」を60秒に変更（デフォルトは10秒）後、Saveします。   パイプラインのデプロイ、実行 画面上部の「Save」ボタンをクリックします。 Saveが完了したら、隣の「Deploy」ボタンをクリックします。 編集画面から遷移したら、デプロイ完了です。 ※注意点 リアルタイムパイプラインは、一度デプロイしたパイプラインは編集ができません。 そのため、設定値などを修正したい場合はコピーして新たに作り直し、再度デプロイする必要があります。（バッチパイプラインはデプロイ後も編集が可能です）   パイプラインを実行、データを投入してみる デプロイしたパイプラインを実行します。 画面上部の「Run」ボタンをクリックします。 ※実際に実行してみると、パイプラインが起動してデータをリアルタイムに受け付けるまではおよそ8分程度かかりました。   起動から8分程度経過し、「Status」が「Running」となっていたら、データ投入を開始します。 作成したPub/Subトピック内メッセージタブから「メッセージをパブリッシュ」をクリックします。 メッセージ本文に「1111 aaaa」と入力、「公開」ボタンをクリックします。 作成したBigQueryテーブルのプレビュータブに以下の通りにデータが格納されました！ パイプラインを見に行くと、各プラグインのIn/Outに流れたデータの数が表示されていました。   作成時の注意点 パイプライン構築にあたって、個人的に引っかかったポイントや注意点を以下に記載します。 権限周り インスタンス作成時に、Data FusionにDataprocサービスアカウントへの権限を付与しないと、パイプライン実行がエラーとなりました。また、IAM周りも適切に設定してあげないとリソース間でうまくデータが流れないようです。 各環境と使用リソースに合わせて設定する必要があります。   リアルタイムパイプラインはデプロイ後修正ができない 修正ができないので、都度値を変更して検証するには時間がかかりました。パイプライン内歯車マークから「Duplicate」をクリックするとパイプラインのコピーが出来上がるので、この方法で修正⇒再デプロイを実施する形となります。   Batch Intervalを10秒から60秒に変更しないとパイプラインがうまく動かない 本記事内「Configure設定」にて記載しましたが、Batch Intervalを変更しなければ本パイプラインはうまく処理が進みませんでした。 Configure設定 Sinkの設定まで終わったら、パイプライン画面上部の「Configure」をクリックします。 「Pipeline config」の「Batch Interval」を60秒に変更（デフォルトは10秒）後、Saveします。 Batch IntervalはBigQueryへの書き込み時間の間隔となりますが、デフォルトの10秒だと書き込みの間隔が短く過剰アクセスが発生していると考えられ、GCPサポートからはBatch Intervalを60秒以上に設定して検証するように推奨されました。 また、本項目を変更するのは デプロイ前 である必要があります。パイプラインデプロイ後は、画面上はBatch Intervalの変更をすることができますが、実際には設定が反映されずエラーとなってしまいました。 GCPサポートに問い合わせたところ、 リアルタイムパイプラインの内容は途中で編集ができず再作成と再デプロイが必要であり、エンジン側のパラメータ設定などについても再作成と再デプロイによって反映させる必要がある。 とのことで回答がありました。 なお、デプロイ後に同項目を編集してしまった場合は、実際に設定されている値と画面上の値の乖離が起きてしまいますが、実際に設定されている値については、パイプラインを実行した際のログ内以下項目にて確認ができます。 「 – INFO〜 Remember interval = 〜 ms」   Data Fusionのコスト Data Fusionは作成したインスタンスごとに課金がされるため、インスタンスを複数作成するとその分コストがかかります。 また、Data Fusionのインスタンスは停止再開ができないため、 一度作成したら削除するまで 課金され続ける点に注意が必要です。 インスタンスを削除すると作成していたパイプラインも同時に削除されてしまうため、インスタンスを削除する場合はパイプラインをJSON形式でエクスポートなどしておくと良いかもしれません。 詳しい料金は公式の料金ページをご確認ください。 料金  |  Cloud Data Fusion  |  Google Cloud   最後に 今回はPub/SubをトリガーとしたData Fusionのリアルタイムパイプラインを構築してみました。 今回作成したパイプラインを使用すれば、発生したデータをCloud Pub/Subに向けて流すように設定するだけで、リアルタイムにBigQueryにデータを格納することができ、データ活用に役立ちそうですね。 今回の構築で初めてGCPを触ったのですが、Data Fusionはコードを書かずにパイプラインを構築できるため非常に扱いやすかったです。 ただGCPの権限周りについては、サービスアカウントに権限を追加しないと他リソースとの連携ができない場面があり、リソース作成時には都度勉強が必要だと思いました。 皆さんもData Fusion使ってみてはいかがでしょうか。

こんにちは。2024新人の加藤です。 今回はAWS上のCloudFormationと構成管理ツールのAnsibleを使用し、その便利さに感銘を受けたため、具体的に何を行って、どのような部分に感銘を受けたかご紹介したいと思います。 Ansibleとは Ansibleとは、RedHat社が開発するシステム設定やソフトウェアの自動化を行う構成管理ツールです。 Ansibleにはコントロールノードと管理対象ノードが存在します。 コントロールノードに管理対象ノードのあるべき状態を記載した「Playbook」ファイルを作成し、「Inventory」ファイルに管理対象ノードの情報を記載します。「Inventory」と「Playbook」の内容は以下のようになっています。 Inventory リモートホストやグループを管理するファイル ファイル名は「hosts」 Playbook リモートホストの状態を定義するymlファイル Inventoryで管理されたグループやホスト単位で作成 ファイル名は「main.yml」 今回は、Ansibleを各EC2のUserDataでlocalhost実行するため、コントロールノードと管理対象ノードが同じになります。 また、Playbookファイルは「ロール」形式を取ることによって、効率的にファイル管理をすることができるようになります。ロールとは、Playbookファイルを複数に分割し、別のファイルとして実行・管理できる仕組みのことです。   構成概要 アプリケーションをEC2上にホストし、プライベートネットワーク環境のPCからそのEC2にアクセスしWebページが表示されるか確認します。EC2へのアプリケーションのホストは構成管理ツール（Ansible）を使用し、自動化します。 EC2にアクセスする際にはパブリックサブネットに配置したELBを経由してアクセスするものとし、HTTPSプロトコルを使用してアクセスします。   AWS CloudFormationで各リソースをIaC化し、ルートテンプレートから複数スタックを作成しています。 スタック構造は以下のようになっています。 Application_Stack：親スタック Network_Stack：ネットワークリソースを作成する子スタック（Subnet、Route） Application_quickstart_Stack：アプリケーション実行に必要なリソースを作成する子スタック（IAM、SecurityGroup、Route53、ACM、ELB、EC2） 各リソースの詳細内容 各リソースの詳細内容は以下のようになっています。 No. カテゴリ 項目 詳細 備考 1 アプリケーション Spring Boot WebアプリケーションはSpring Bootを使用して作成する ページ概要は以下の通りである 「検証用APトップページ」ボタンを実装する 「一覧」ボタンを実装する 「dummy」ボタンを実装する   2 Ansible Playbook 以下のAnsible構成図を基に作成する 各ロールの役割を記載する linux_common_config： yumリポジトリのアップデート（yumでインストールされたすべてのパッケージのアップデート） web_ui_config： Amazon Corretoのインストール S3からJarファイル取得 Jar起動 今回はAnsibleをローカルホストから実行するためは、インベントリファイルは作成しない 3 AWS IAM 以下の権限を付与する S3へのアクセス（ReadOnly） SystemsManagerへのアクセス（AmazonSSMManagedInstanceCore）   4 VPC サブネット：構成図を基に作成する ルートテーブル：作成したサブネットの関連付け、および  Gateway  へのルーティングを設定する InternetGateway、NatGatewayは既に作成されているものを使用する 5 SecurityGroup（ELB） プライベートネットワーク環境（netskopeのグローバルIP）からアクセスできる設定にする   6 SecurityGroup（EC2） ELBのみからアクセスできる設定にする   7 Route53 指定の共通ホストゾーンを利用し、サブドメインのホストゾーンを作成する 共通ホストゾーン：training.aidiv1.com サブドメインのホストゾーン：katou.training.aidiv1.com サブドメインのホストゾーンには以下を設定する Certificate Manager用レコード：CNAME ELB用レコード：Ａ 共通ホストゾーンのゾーン情報にサブドメインのNSレコード情報を登録する 8 ACM 東京リージョンに証明書を発行する（パブリック証明書をDNS検証にて発行）   9 ELB Load balancer typeは「Application」とする セキュリティ強化のため、アクセスログの有効化を実施する 10 EC2 インスタンスタイプは「t3.micro」とする AWS::CloudFormation::Init リソースで以下を実施する AnsibleのInstall S3に配置したAnsible PlaybookファイルをEC2にコピー Ansible Playbookファイルをlocalhost実行する UserDataで以下を実施する 最新のヘルパースクリプトをインストールする cfn-initを実行 AMIは既に作成されている共通AMIを使用する 11 S3 名前は「hrd-d0-s3b-katou」とする 2つの子スタックテンプレート(Network_Stack.yml、Application_quickstart_Stack)とAnsibleのPlaybookファイルを格納しておく     Ansible AWS::CloudFormation::Init リソースでAnsibleをEC2上で実行することにより、スタック作成時にアプリケーションが自動で実行されるようになります。また、AnsibleのPlaybookファイルはS3に配置しておき、AWS::CloudFormation::Init リソースでS3からEC2にPlaybookファイルをダウンロードします。 Playbookファイル # Playbookファイルのrolesを関連付け - hosts: localhost become: true connection: local roles: - linux_common_config - web_ui_config 「linux_common_config」ロールのタスクファイル # yumリポジトリのアップデート - name: Update all packages yum: name: '*' update_only: yes 「web_ui_config」ロールのタスクファイル # Java 17 Amazon Corretoをダウンロード - name: Install Java 17 Amazon Correto yum: name: java-17-amazon-corretto state: installed # JarファイルをS3バケットからローカルホストにダウンロード - name: Copy Jar file from AWS S3 Bucket to localhost command: "aws s3 cp s3://hrd-d0-s3b-katou/web-ui-teamG-katou-0.0.1-SNAPSHOT.jar /tmp/web_app/" # Jarファイルをローカルホストから実行 - name: Run command "java -jar" command: "java -jar /tmp/web_app/web-ui-teamG-katou-0.0.1-SNAPSHOT.jar"   AWS CloudFormation テンプレート 構成図と各リソースの詳細内容を基に作成したテンプレートが以下の3つです。 以下のルートテンプレート（Application_Stack）をCloudFormationでデプロイしてください。 子スタックはネスト構造化してあるので、ルートテンプレートを実行した段階で自動で生成されます。 Application_Stack AWSTemplateFormatVersion: 2010-09-09 Description: Root stack for 2024 Cloud Training Program - TeamG Kato Parameters: #TemplateNetworkのURLを記載 TemplateNetworkUrl: Description: Network template Object URL Type: String Default: "https://hrd-d0-s3b-katou.s3.ap-northeast-1.amazonaws.com/Network_Stack.yml" #TemplateApplicationQuickstartのURLを記載 TemplateApplicationQuickstartUrl: Description: Application Quickstart Template Object URL Type: String Default: "https://hrd-d0-s3b-katou.s3.ap-northeast-1.amazonaws.com/Application_quickstart_Stack.yml" #Tagsに使用するパラメータ SystemId: Description: System ID Type: String Default: "hrd" EnvironmentId: Description: Environment ID Type: String Default: "d0" DeveloperId: Description: Developer ID Type: String Default: "katou-y-test" #サブネット作成に使用するパラメータ VpcId: Type: String Description: VPC ID Default: "vpc-04ac6f2eb1c774c79" PublicSubnet1CidrBlock: Description : CIDR block for Public Subnet1 Type: String Default: "10.0.225.0/24" PublicSubnet2CidrBlock: Description : CIDR block for Public Subnet2 Type: String Default: "10.0.226.0/24" PrivateSubnet1CidrBlock: Description : CIDR block for Private Subnet1 Type: String Default: "10.0.227.0/24" #ルートテーブル作成・ルート追加・ルートテーブルとサブネットの関連付けに使用するパラメータ InternetGatewayId: Type: String Description: Internet Gateway ID Default: "igw-0b1320c68c6590e15" NatGatewayId: Type: String Description: Nat Gateway ID Default: "nat-0be241ae2ac812138" #EC2インスタンス作成に使用するパラメータ InstanceType: Description: EC2 Instance Type Type: String Default: "t3.micro" #ホストゾーン登録・証明書に使用するパラメータ SubDomain: Description: FQDN of the certificate Type: String Default: "katou.training.aidiv1.com" Resources: #Network_Stackが管理するリソースのスタック TemplateNetworkStack: Type: AWS::CloudFormation::Stack Properties: TemplateURL: !Ref TemplateNetworkUrl Parameters: SystemId: !Ref SystemId EnvironmentId: !Ref EnvironmentId DeveloperId: !Ref DeveloperId VpcId: !Ref VpcId CidrBlockForPublicSubnet1: !Ref PublicSubnet1CidrBlock CidrBlockForPublicSubnet2: !Ref PublicSubnet2CidrBlock CidrBlockForPrivateSubnet1: !Ref PrivateSubnet1CidrBlock InternetGatewayId: !Ref InternetGatewayId NatGatewayId: !Ref NatGatewayId #Application_quickstart_Stackが管理するリソースのスタック TemplateApplicationQuickstartStack: DependsOn: TemplateNetworkStack Type: AWS::CloudFormation::Stack Properties: TemplateURL: !Ref TemplateApplicationQuickstartUrl Parameters: SystemId: !Ref SystemId EnvironmentId: !Ref EnvironmentId DeveloperId: !Ref DeveloperId VpcId: !Ref VpcId PublicSubnet1Id: !GetAtt TemplateNetworkStack.Outputs.PublicSubnet1Id PublicSubnet2Id: !GetAtt TemplateNetworkStack.Outputs.PublicSubnet2Id PrivateSubnet1Id: !GetAtt TemplateNetworkStack.Outputs.PrivateSubnet1Id CidrBlockForPrivateSubnet1: !Ref PrivateSubnet1CidrBlock InstanceType: !Ref InstanceType SubDomain: !Ref SubDomain Network_Stack AWSTemplateFormatVersion: 2010-09-09 Description: Network stack for 2024 Cloud Training Program - TeamG Kato Resource - Subnet, Route Parameters: #Tagsに使用するパラメータ SystemId: Description: System ID Type: String EnvironmentId: Description: Environment ID Type: String DeveloperId: Description: Developer ID Type: String #サブネット作成に使用するパラメータ VpcId: Type: String Description: VPC ID CidrBlockForPublicSubnet1: Description : CIDR block for Public Subnet1 Type: String CidrBlockForPublicSubnet2: Description : CIDR block for Public Subnet2 Type: String CidrBlockForPrivateSubnet1: Description : CIDR block for Private Subnet1 Type: String #ルートテーブル作成・ルート追加・ルートテーブルとサブネットの関連付けに使用するパラメータ InternetGatewayId: Type: String Description: Internet Gateway ID NatGatewayId: Type: String Description: Nat Gateway ID Resources: #パブリックサブネット1の作成 PublicSubnet1: Type: AWS::EC2::Subnet Properties: VpcId: !Ref VpcId AvailabilityZone: !Select [ 0, !GetAZs '' ] CidrBlock: !Ref CidrBlockForPublicSubnet1 Tags: - Key: Name Value: !Sub ${SystemId}-${EnvironmentId}-sub-pub1-${DeveloperId} - Key: Cost Value: !Sub ${SystemId}-${EnvironmentId}-${DeveloperId} - Key: Env Value: !Sub ${SystemId}-${EnvironmentId} #パブリックサブネット2の作成 PublicSubnet2: Type: AWS::EC2::Subnet Properties: VpcId: !Ref VpcId AvailabilityZone: !Select [ 1, !GetAZs '' ] CidrBlock: !Ref CidrBlockForPublicSubnet2 Tags: - Key: Name Value: !Sub ${SystemId}-${EnvironmentId}-sub-pub2-${DeveloperId} - Key: Cost Value: !Sub ${SystemId}-${EnvironmentId}-${DeveloperId} - Key: Env Value: !Sub ${SystemId}-${EnvironmentId} #プライベートサブネット1の作成 PrivateSubnet1: Type: AWS::EC2::Subnet Properties: VpcId: !Ref VpcId AvailabilityZone: !Select [ 0, !GetAZs '' ] CidrBlock: !Ref CidrBlockForPrivateSubnet1 Tags: - Key: Name Value: !Sub ${SystemId}-${EnvironmentId}-sub-pri1-${DeveloperId} - Key: Cost Value: !Sub ${SystemId}-${EnvironmentId}-${DeveloperId} - Key: Env Value: !Sub ${SystemId}-${EnvironmentId} #ルートテーブルの作成 RouteTableForPublicSubnet1: Type: AWS::EC2::RouteTable Properties: VpcId: !Ref VpcId Tags: - Key: Name Value: !Sub ${SystemId}-${EnvironmentId}-rtb-pub1-${DeveloperId} - Key: Cost Value: !Sub ${SystemId}-${EnvironmentId}-${DeveloperId} - Key: Env Value: !Sub ${SystemId}-${EnvironmentId} RouteTableForPublicSubnet2: Type: AWS::EC2::RouteTable Properties: VpcId: !Ref VpcId Tags: - Key: Name Value: !Sub ${SystemId}-${EnvironmentId}-rtb-pub2-${DeveloperId} - Key: Cost Value: !Sub ${SystemId}-${EnvironmentId}-${DeveloperId} - Key: Env Value: !Sub ${SystemId}-${EnvironmentId} RouteTableForPrivateSubnet1: Type: AWS::EC2::RouteTable Properties: VpcId: !Ref VpcId Tags: - Key: Name Value: !Sub ${SystemId}-${EnvironmentId}-rtb-pri1-${DeveloperId} - Key: Cost Value: !Sub ${SystemId}-${EnvironmentId}-${DeveloperId} - Key: Env Value: !Sub ${SystemId}-${EnvironmentId} #ルートテーブルへのルート追加 InternetGatewayRouteForPublicSubnet1: Type: AWS::EC2::Route Properties: RouteTableId: !Ref RouteTableForPublicSubnet1 DestinationCidrBlock: 0.0.0.0/0 GatewayId: !Ref InternetGatewayId InternetGatewayRouteForPublicSubnet2: Type: AWS::EC2::Route Properties: RouteTableId: !Ref RouteTableForPublicSubnet2 DestinationCidrBlock: 0.0.0.0/0 GatewayId: !Ref InternetGatewayId NatGatewayRouteForPrivateSubnet1: Type: AWS::EC2::Route Properties: RouteTableId: !Ref RouteTableForPrivateSubnet1 DestinationCidrBlock: 0.0.0.0/0 GatewayId: !Ref NatGatewayId #ルートテーブルとサブネットの関連付け PublicSubnet1Association: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PublicSubnet1 RouteTableId: !Ref RouteTableForPublicSubnet1 PublicSubnet2Association: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PublicSubnet2 RouteTableId: !Ref RouteTableForPublicSubnet2 PrivateSubnet1Association: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PrivateSubnet1 RouteTableId: !Ref RouteTableForPrivateSubnet1 Outputs: PublicSubnet1Id: Description: Public Subnet 1 ID Value: !Ref PublicSubnet1 PublicSubnet2Id: Description: Public Subnet 2 ID Value: !Ref PublicSubnet2 PrivateSubnet1Id: Description: Private Subnet 1 ID Value: !Ref PrivateSubnet1 Application_quickstart_Stack AWSTemplateFormatVersion: 2010-09-09 Description: Application Quickstart Stack for 2024 Cloud Training Program - TeamG Kato Resource - IAM, SecurityGroup, Route53, ACM, ELB, EC2 Parameters: #Tagsに使用するパラメータ SystemId: Description: System ID Type: String EnvironmentId: Description: Environment ID Type: String DeveloperId: Description: Developer ID Type: String #各種ネットワーク設定パラメータ VpcId: Description: VPC ID Type: String PublicSubnet1Id: Description: Public Subnet 1 ID Type: String PublicSubnet2Id: Description: Public Subnet 2 ID Type: String PrivateSubnet1Id: Description: Private Subnet 1 ID Type: String CidrBlockForPrivateSubnet1: Description : CIDR block for Private Subnet1 Type: String #EC2インスタンス作成に使用するパラメータ InstanceType: Description: EC2 Instance Type Type: String #ホストゾーン登録・証明書に使用するパラメータ SubDomain: Description: FQDN of the certificate Type: String Resources: #IAMロールを作成 IAMRole: Type: AWS::IAM::Role Properties: RoleName: !Sub ${SystemId}-${EnvironmentId}-iam-ec2-${DeveloperId} #どのリソースに対してどんなアクションをするかを記載 AssumeRolePolicyDocument: Statement: - Effect: Allow Principal: Service: - ec2.amazonaws.com Action: - 'sts:AssumeRole' #アクセス権限ポリシーを記載 ManagedPolicyArns: - "arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess" - "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore" Tags: - Key: Name Value: !Sub ${SystemId}-${EnvironmentId}-iam-ec2-${DeveloperId} - Key: Cost Value: !Sub ${SystemId}-${EnvironmentId}-${DeveloperId} - Key: Env Value: !Sub ${SystemId}-${EnvironmentId} #インスタンスプロファイルの作成 InstanceProfile: Type: 'AWS::IAM::InstanceProfile' Properties: Path: '/' Roles: - !Ref IAMRole # IAMロールへの参照 #セキュリティグループ（ELB）の作成 SecurityGroupForELB: Type: AWS::EC2::SecurityGroup Properties: GroupName: !Sub ${SystemId}-${EnvironmentId}-sec-elb-${DeveloperId} GroupDescription: Security Group for ELB VpcId: !Ref VpcId Tags: - Key: Name Value: !Sub ${SystemId}-${EnvironmentId}-sec-elb-${DeveloperId} - Key: Cost Value: !Sub ${SystemId}-${EnvironmentId}-${DeveloperId} - Key: Env Value: !Sub ${SystemId}-${EnvironmentId} #インバウンドルール・アウトバンドルールを追加 #netskopeのグローバルIPアドレスからELBへのHTTPS通信 SecurityGroupIngress1HTTPSForELB: Type: AWS::EC2::SecurityGroupIngress Properties: GroupId: !Ref SecurityGroupForELB IpProtocol: tcp FromPort: 443 ToPort: 443 CidrIp: xxx.xxx.xxx.0/xx #netskopeのグローバルIPアドレスからELBへのHTTPS通信 SecurityGroupIngress2HTTPSForELB: Type: AWS::EC2::SecurityGroupIngress Properties: GroupId: !Ref SecurityGroupForELB IpProtocol: tcp FromPort: 443 ToPort: 443 CidrIp: xxx.xxx.xxx.0/xx #netskopeのグローバルIPアドレスからELBへのHTTPS通信 SecurityGroupIngress3HTTPSForELB: Type: AWS::EC2::SecurityGroupIngress Properties: GroupId: !Ref SecurityGroupForELB IpProtocol: tcp FromPort: 443 ToPort: 443 CidrIp: xxx.xxx.xxx.0/xx #プライベートサブネットからELBへの8080通信 SecurityGroupIngressCustomTCP8080ForELB: Type: AWS::EC2::SecurityGroupIngress Properties: GroupId: !Ref SecurityGroupForELB IpProtocol: tcp FromPort: 8080 ToPort: 8080 CidrIp: !Ref CidrBlockForPrivateSubnet1 #セキュリティグループ（EC2）の作成 SecurityGroupForEC2: Type: AWS::EC2::SecurityGroup Properties: GroupName: !Sub ${SystemId}-${EnvironmentId}-sec-ec2-${DeveloperId} GroupDescription: Security Group for EC2 VpcId: !Ref VpcId Tags: - Key: Name Value: !Sub ${SystemId}-${EnvironmentId}-sec-ec2-${DeveloperId} - Key: Cost Value: !Sub ${SystemId}-${EnvironmentId}-${DeveloperId} - Key: Env Value: !Sub ${SystemId}-${EnvironmentId} #ELBからEC2への8080通信 SecurityGroupIngressCustomTCP8080ForEC2: Type: AWS::EC2::SecurityGroupIngress Properties: GroupId: !Ref SecurityGroupForEC2 IpProtocol: tcp FromPort: 8080 ToPort: 8080 SourceSecurityGroupId: !Ref SecurityGroupForELB #EC2インスタンスの作成 EC2: Type: AWS::EC2::Instance #Metadataの記述 Metadata: AWS::CloudFormation::Init: configSets: Default: - InstallAnsible - CreateDirectory - Download - RunAnsible #Ansibleをインストールするためのデータ InstallAnsible: packages: yum: ansible: [] #各種ディレクトリを作成するための実行コマンドデータ CreateDirectory: commands: mkdirWebApp: command: "mkdir -p /tmp/web_app" mkdirAnsible: command: "mkdir -p /tmp/ansible" mkdirLinuxCommonConfig: command: "mkdir -p /tmp/ansible/roles/linux_common_config/tasks" mkdirWebUiConfig: command: "mkdir -p /tmp/ansible/roles/web_ui_config/tasks" #AnsibleのPlaybookをS3バケットからダウンロードするためのデータ Download: commands: downloadWebUiStartup: command: aws s3 cp s3://hrd-d0-s3b-katou/ansible/web_ui_startup.yml /tmp/ansible/ downloadLinuxCommonConfig: command: aws s3 cp s3://hrd-d0-s3b-katou/ansible/roles/linux_common_config/tasks/main.yml /tmp/ansible/roles/linux_common_config/tasks/ downloadWebUiConfig: command: aws s3 cp s3://hrd-d0-s3b-katou/ansible/roles/web_ui_config/tasks/main.yml /tmp/ansible/roles/web_ui_config/tasks/ #AnsibleにおけるPlaybookの実行コマンドデータ RunAnsible: commands: runWebUiStartup: command: "ansible-playbook -c local /tmp/ansible/web_ui_startup.yml" Properties: ImageId: ami-0cb4639ca5eb232fc InstanceType: !Ref InstanceType SubnetId: !Ref PrivateSubnet1Id SecurityGroupIds: - !Ref SecurityGroupForEC2 IamInstanceProfile: !Ref InstanceProfile Tags: - Key: Name Value: !Sub ${SystemId}-${EnvironmentId}-ec2-${DeveloperId} - Key: Cost Value: !Sub ${SystemId}-${EnvironmentId}-${DeveloperId} - Key: Env Value: !Sub ${SystemId}-${EnvironmentId} #UserDataの記述 UserData: Fn::Base64: !Sub | #!/bin/bash yum install -y aws-cfn-bootstrap /opt/aws/bin/cfn-init -v --stack ${AWS::StackName} --resource EC2 --configsets Default --region ${AWS::Region} #ELBの作成 ApplicationLoadBalancer: Type: AWS::ElasticLoadBalancingV2::LoadBalancer Properties: Name: !Sub ${SystemId}-${EnvironmentId}-elb-${DeveloperId} Subnets: - !Ref PublicSubnet1Id - !Ref PublicSubnet2Id SecurityGroups: - !Ref SecurityGroupForELB Scheme: internet-facing Type: application LoadBalancerAttributes: - Key: access_logs.s3.enabled Value: true - Key: access_logs.s3.bucket Value: lms-d0-s3-logcollection Tags: - Key: Name Value: !Sub ${SystemId}-${EnvironmentId}-elb-${DeveloperId} - Key: Cost Value: !Sub ${SystemId}-${EnvironmentId}-${DeveloperId} - Key: Env Value: !Sub ${SystemId}-${EnvironmentId} #ELBのリスナー設定 ListenerForELB: Type: AWS::ElasticLoadBalancingV2::Listener Properties: LoadBalancerArn: !Ref ApplicationLoadBalancer Port: 443 Protocol: HTTPS Certificates: - CertificateArn: !Ref Certificate DefaultActions: - Type: forward TargetGroupArn: !Ref TargetGroup #ターゲットグループ作成 TargetGroup: Type: AWS::ElasticLoadBalancingV2::TargetGroup Properties: VpcId: !Ref VpcId Name: !Sub ${SystemId}-${EnvironmentId}-trg-${DeveloperId} Protocol: HTTP Port: 8080 HealthCheckProtocol: HTTP HealthCheckPort: 8080 HealthCheckPath: "/actuator/health" HealthCheckTimeoutSeconds: 10 HealthCheckIntervalSeconds: 20 HealthyThresholdCount: 3 UnhealthyThresholdCount: 2 Targets: - Id: !Ref EC2 Port: 8080 TargetType: instance Tags: - Key: Name Value: !Sub ${SystemId}-${EnvironmentId}-trg-${DeveloperId} - Key: Cost Value: !Sub ${SystemId}-${EnvironmentId}-${DeveloperId} - Key: Env Value: !Sub ${SystemId}-${EnvironmentId} #Route53のホストゾーン作成 HostedZone: Type: AWS::Route53::HostedZone Properties: HostedZoneConfig: Comment: "Subdomain of training.aidiv1.com" Name: !Ref SubDomain HostedZoneTags: - Key: Name Value: !Sub ${SystemId}-${EnvironmentId}-r53-${DeveloperId} - Key: Cost Value: !Sub ${SystemId}-${EnvironmentId}-${DeveloperId} - Key: Env Value: !Sub ${SystemId}-${EnvironmentId} #ホストゾーンへのレコード登録 #ELBのAレコード登録 ARecordSetForELB: Type: AWS::Route53::RecordSet Properties: HostedZoneId: !Ref HostedZone Name: !Ref SubDomain Type: A AliasTarget: HostedZoneId: !GetAtt ApplicationLoadBalancer.CanonicalHostedZoneID DNSName: !GetAtt ApplicationLoadBalancer.DNSName #training.aidiv1.comへのNSレコード登録 NSRecordSetForParentDomain: Type: AWS::Route53::RecordSet Properties: HostedZoneId: Z037543234RUL8GGC5CBK Name: !Ref SubDomain Type: NS TTL: 300 ResourceRecords: !GetAtt HostedZone.NameServers #Certificate Manager Certificate: Type: AWS::CertificateManager::Certificate Properties: DomainName: !Ref SubDomain ValidationMethod: DNS DomainValidationOptions: - DomainName: !Ref SubDomain HostedZoneId: !Ref HostedZone Tags: - Key: Name Value: !Sub ${SystemId}-${EnvironmentId}-acm-${DeveloperId} - Key: Cost Value: !Sub ${SystemId}-${EnvironmentId}-${DeveloperId} - Key: Env Value: !Sub ${SystemId}-${EnvironmentId} 実行画面 CloudFormation上でルートテンプレート「Application_Stack」を実行します。 AWSマネジメントコンソール上でCloudFormationを検索し、「スタックの作成」を押下します。 ルートテンプレート「Application_Stack」をアップロードします。 適当なスタック名を入力し、下までスクロールし「次へ」を押下します。　　　　　　 下までスクロールし、二つのチェックボックスにチェックを入れ、「次へ」を押下します。 下までスクロールし、「送信」を押下するとルートテンプレートが実行されます。 実行されると親スタックが作成され、子スタックが二つ作成されます。リソースが全て作成されると以下の画面のようになります。 プライベートネットワーク環境のPCから「https://katou.training.aidiv1.com」にアクセスします。以下のような画面が表示されたらWebアプリケーションの自動実行が成功となります。   注意点 AnsibleとCloudFormationを使用した際に、個人的につまづいた点を共有します。 AnsibleをS3からEC2へダウンロードする際に、Ansibleのディレクトリ構造を保持したままPlaybookファイルをダウンロードしてください。ディレクトリ構造が保たれていないと、適切なロールのタスクが実行されません。 AnsibleのPlaybookファイルに「become: true」を記述していないと、権限がなくコマンドが実行されない場合があります。「become: true」は一時的にroot権限を与えるものです。 Spring Bootアプリケーションのリッスンポート番号は8080なので、私のように「HTTPプロトコルを使用するのでポート番号は80」と決めつけてしまうと痛い目をみます。 共通ホストゾーンのゾーン情報にサブドメインのNSレコード情報を登録しないと、共通ホストゾーンからのサブドメインの名前解決がうまくいきません。 Certificate Managerでサブドメインの証明書をリクエストする際に検証方法としてDNS検証を選んだ場合、CloudFormationではデフォルトで、サブドメインのホストゾーンにCNAMEゾーン情報が登録されます。   最後に 以前行ったハンズオンではAWSをマネジメントコンソール上から画面をポチポチしてインフラ構築をしていたので、一度リソースを削除してから同じインフラを構築しようとなるととても面倒でした。それがCloudFormationとAnsibleを利用することで何度でも同じインフラを構築することができ、なおかつ自動で行ってくれるので、一度コードを書いてしまえばとても楽にインフラを構築できることに感動いたしました。 次回の記事では案件で得たナレッジなどを共有できればと思います。

どうもSCSK齋藤です。 EC2のバックアップを取得する際に、アプリケーション整合性の観点から、EC2を停止してからバックアップを取得するユースケースは発生すると考えられます。 Lambdaなどを使って、それらの手順を自動化することはできますが、今回はSystems Manager Automation Runbookを用いてノーコードでその仕組みを作成してみました。 大まかな流れ Systems Manager Automation Runbookで、以下の流れを自動化するランブックを作成します。 全EC2をディスクライブ 全EC2を停止 AWS BackupのAPIを使用してバックアップの作成 全EC2を起動 今回のバックアップはAWS Backupを用いたいと思います。   今回解説しない箇所 今回、下記の箇所は詳しく解説致しません。 AWS Backupで必要なIAMロールの作成方法 バックアップテスト用のEC2インスタンスの作成方法 AWS Backupで用いるIAMロールについては、本手順で使うIAMロール（backup_role）の画面キャプチャをあらかじめ記載しておきます。 また、EC2をバックアップさせるテスト対象のインスタンスについても、２台用意して検証してみます。   やってみた それでは、早速作成していきましょう！ Runbookの作成 SystemsManagerのコンソール画面の左のメニューから、「オートメーション」をクリックし、「Create Automation Runbook」をクリックします。   そうすると、以下のようなステートマシン作成画面に遷移します。   全EC2のディスクライブの処理の追加 まず、ディスクライブの処理を追加します。 先ほどのRunbook作成画面の左側の検索欄で、「AWS API」を選択します。 検索欄で、Describeinstancesと検索し、EC2のDescribeinstancesが出てきたら、Runbook内にドラッグ＆ドロップします。 そのまま、画面右側のDescribeInstancesのメニューの中で、出力タブに切り替えます。 どのような値を次の処理に渡すかを定義するため、下記の設定を行います。 設定内容の解説は下記になります。 項目 設定値 説明 名前 InstanceIds 任意の名前を入力できるので、どのような値を出力するかを定義します。 今回は、DescribeInstancesでインスタンスIDのリストを出力するので、このような名前とします。 セレクター $.Reservations..Instances..InstanceId AutoMationRunbookでは、裏でboto3が使われているので、boto3のドキュメントのレスポンス構造の中から、取得したい項目を指定します。 Responseの中身については、 ここ を参照してください。 タイプ StringList 今回はインスタンスIDの集合体を取得したいので、String型のリストとします。   全EC2を停止する処理の追加 ディスクライブしたインスタンスのリストを元に、全EC2の停止を行います。 左側の検索欄で、「アクション」を選択し、ChangeInstanceStateを検索します。 出てきたものを、ドラッグ＆ドロップします。 まず、名前をわかりやすく変更します。 次にインプットを編集します。 下記の値を設定します。 項目 設定値 説明 Instance IDs DescribeInstances.InstanceIds DescribeInstancesでリスト化したインスタンスIDたちが渡されます。 Desired state stopped 停止を行いたいため、stoppedとします。 全EC2をバックアップする処理を追加 ディスクライブしたインスタンスのリスト元に、全EC2のバックアップを行います。 今回は、Loop処理を追加し、その中でインスタンス１つ１つのバックアップ処理を含める形とします。   Loop処理の追加 左側の検索欄で、アクションを指定し、ループを選択します。そのまま、ドラッグ＆ドロップで、StopInstancesの下につけます。 ステップ名を自由に設定できるので、わかりやすく「BackupLoop」と名付けます。   次に、右側のメニューのインプットを設定します。 ループタイプを今回はFor eachに選択します。 その後、イテレーターを選択しますが、前段のDescribeInstancesで出力した、InstanceIdsを選択します。   バックアップ処理の追加 ループ処理の中に、バックアップの処理を追加していきます。 左側の検索欄で、「AWS API」を選択し、StartBackupJobを検索します。 出てきたものを、ドラッグ＆ドロップします。 次に、インプットタブを選択し、バックアップの条件を入力していきます。 設定内容の解説は下記になります。 項目 設定値 説明 BackupVaultName Default Backupの保存コンテナであるバックアップVaultの名前を設定します。 今回は、デフォルトでアカウントに用意されているDefaultという名前のバックアップVaultを使用します。 IamRoleArn arn:aws:iam::{account_id}:role/backup_role AWSBackupが用いるIAMロールのARNを指定します。 本ブログでは、冒頭で述べたIAMロールを使用しています。 ResourceArn arn:aws:ec2:{region}:{account_id}:instance/{{ BackupLoop.CurrentIteratorValue }} バックアップ対象のリソースのARNを指定します。 今回はループ処理の中でインスタンス１つずつ処理をしていくため、EC2のARNの型を用意しておき、末尾の部分を{{ BackupLoop.CurrentIteratorValue }}とすることで、ここにインスタンスIDが入り、EC2のARNが完成する形とします。 ※上記表の{region}と{account_id}は、それぞれご自身の環境のリージョン名とアカウントIDに置き換えてください。   全EC2を起動する処理を追加 左側の検索欄で、「アクション」を選択し、ChangeInstanceStateを検索します。 出てきたものを、ドラッグ＆ドロップします。 ついでに名前も、StartInstancesに変更します。 StartInstancesのメニューで、インプットタブを選択します。 項目 設定値 説明 Instance IDs DescribeInstances.InstanceIds DescribeInstancesでリスト化したインスタンスIDたちが渡されます。 Desired state running 起動したいため、runningとします。   保存と実行 最後に、名前を保存します。 画面左上のペンマークから編集を行い、お好きな名前で保存します。 次に、右上の「ランブックを作成」を押下します。 下記のような画面が出ますが、特に指定せず、画面下のExecuteを押下します。 そうすると、早速Runbookが走ります。   実行画面に遷移後、しばらく時間が経過した後確認すると、正しく実行されたのを確認することができました！ AWSBackupのコンソール画面に遷移し、保存したVaultを確認してみますと２つのバックアップが保存されているのを確認できました！   改めてのポイント 今回のRunbookで意識したポイントとして、AutomationRunbookに組み込まれているアクションである「ChangeInstanceState」を使ったところです。 EC2の停止と起動の際にaws:executeAwsApiのStopInstancesや、RunInstancesといったAPIを使う選択肢もありました。 しかし、これらのAPIは、一斉にEC2を停止や起動だけして状態の追跡をしません。 そのため、EC2が停止し切らない状態で次の状態に遷移（バックアップを取得）してしまうため、整合性を確保するという観点から望ましくありません。ですが、AutomationRunbookに組み込まれているアクションである「ChangeInstanceState」を使うことで、状態の追跡まで行ってくれます。 これを用いることで、インスタンスが停止し切った段階で次のワークフローに進んでくれるので、整合性を確保する観点から望ましいものとなります。   まとめ 今回は、インスタンスを停止してバックアップを行う自動化を、ノーコードにて実施してみました。 今回作ったRunbookを、EventBridgeルールで定期的にキックするようにすることで、毎日のバックアップなども容易になるかと思いますので、組み合わせてみるといいと思います。

こんにちは、ひるたんぬです。 10月も中頃を過ぎ、（個人的には）過ごしやすい季節となってきました。もう秋…ですかね？ ところで、、なぜ「〇〇の秋」という言葉だけ数多く存在するのでしょうか？ 「〇〇の春」「〇〇の夏」「〇〇の冬」…なくはないですが、圧倒的に秋に関する用語が多いように感じます。 これについて明確な文献は見つけられなかったのですが、例えば「スポーツの秋」は1964年の東京五輪、「読書の秋」は中国の漢詩に由来するもの、「食欲の秋」は食べ物の旬の多くが秋にあるという説があるそうです。 さて、今回は技術的なお話とは少し逸れますが、私がある時からずーーっと気になっていた用語についてまとめようと思います。 今回の記事を執筆するにあたり、多くの記事や周りの方への聞き取りを実施いたしました。 聞き取りに対して、多くの方から回答やご意見をいただきました。この場を借りて御礼申し上げます。 本記事は、それらの結果を自分なりに解釈しまとめたものですので、正確性に欠ける箇所がある場合があります。 きっかけは… 弊社では先月より新人が各部署に配属され、部署ごとの研修が始まりました。 私はAWS研修のサポーターとして、新人のサポートや質問対応をしていました。 新人ならではの新鮮な視点からの質問に対して、（ときにネットを駆使しながら）なんとか対応していた私ですが、ある新人さんから次のような質問を受けました。 すみません、 「フルマネージド」と「サーバレス」って何が違うんですか？？ …確かに。 今まで各サービスの特徴や説明を見る中で、これらの表現は何度も見てきましたが、この2つの用語の使い方に対して何ら疑問を抱く機会はありませんでした。また、後日調べてみてもなかなか腑に落ちることができなかったので、この機会にまとめようと思い記事にしました。 それぞれの違いについて まずはじめに、個人的に至った結論を以下にまとめます。 「フルマネージド」と「サーバレス」はベン図にまとめると下図の関係になります。 前提として 「フルマネージド」だけど「サーバレス」でないサービスは存在しますが、「サーバレス」だけど「フルマネージド」でないサービスは存在しません。 つまり、「フルマネージド」を極めた先が「サーバレス」という形式になるのかなと思います。 言葉だけだと分かりづらい点も多いと思いますので、実際のケースを一つ挙げてみたいと思います。 AWSにおけるデータベース利用 AWSでは「データベースを扱いたい！」と思った際には用途や予算、目的に応じて適切なサービスを選定できるよう多くのサービスが提供されています。今回はこのユースケースを元にまとめてみようと思います。 【参考】Amazon EC2 公式サイトには、EC2について以下のような説明がされています。 事実上すべてのワークロードに対応する安全でサイズ変更が可能なコンピューティングキャパシティ 引用：AWS「 Amazon EC2 」 つまり、どんなことにも使える汎用的なサービスだよ！ということですね。 EC2はいわゆるIaaSのサービスです。サーバ筐体そのものなどのハードウェア管理はAWS側が担っているものの、OSやアプリケーションといったソフトウェアのレイヤーは利用者が責任を持って管理をする必要性があります。また、どれくらいの性能のインスタンスを採用するか（インスタンスタイプを選択するか）も利用者側の判断に委ねられています。 EC2上に任意のデータベースエンジンを導入することでデータベースのサーバとして運用することは可能です。コスト面においてはサーバ利用料金のみのため安価で済む傾向がありますが、パッチ適用や暗号化、スケーリング、モニタリングなどを自身で設定する必要があるため、運用上のコストは大きくなってしまいます。 フルマネージドサービス：Amazon RDS フルマネージドサービスのデータベースサービスの一つとして、Amazon RDSが挙げられます。 Amazon Relational Database Service (Amazon RDS) は、クラウド内でデータベースを簡単に設定、運用、スケールできるようにする マネージドサービス を集めたものです。（後略） 引用：AWS「 Amazon RDS 」 – 機能の説明 ここでは「マネージドサービス」と記載があります。一方で、Amazon RDSの特徴ページの一項目には、次のような記載があります。 フルマネージド のクラウドデータベースサービスとして、データベースのニーズを簡単に管理 引用：AWS「 Amazon RDS – 特徴 」 – 「デプロイ環境の選択」 Easily manage your database needs as a fully managed cloud database service 引用：AWS「 Amazon RDS – Features 」 – 「Choice of deployment environments」 英語のページについても確認しましたが、同じように表記が混ざっていました。 以上のことから、本記事では「マネージドサービス」と「フルマネージドサービス」は実質的には同一の意味を指し示していることとします。 ここで、マネジメントコンソールからRDSのデータベースを作成してみましょう。 代表的な項目は「エンジンのタイプ」と「インスタンスサイズ」の選択です。 Amzon RDSではEC2と異なり、OSの選択がなくなっております。これはOSレイヤーについては利用者は意識することがなくなった（AWSに管理を委任する）ことを意味しています。また、データベースのエンジンについても選択することで初期セットアップが実施されるため、利用者による作業は不要になっています。 RDSの一部のパッチ適用（データベースエンジンのメジャーアップグレード）については、互換性が損なわれる可能性があるため、手動で対応する必要があります。 参考： AWS ドキュメント「DB インスタンスのエンジンバージョンのアップグレード」 一方で、インスタンスサイズの指定などはまだ残っており、その点についてはEC2と同様に「これくらいの規模のサーバで動いているんだなぁ。。」となんとなく分かるようにはなっています。 サーバレス：Aurora Serverless・DynamoDB Aurora ServerlessはAmazon RDSのデータベースエンジンの一つであるAmazon Auroraにおけるオンデマンド自動スケーリング設定です。 また、DynamoDBについては以下のような説明がされています。 あらゆる規模で一桁ミリ秒のパフォーマンスを実現する、 サーバーレス NoSQL フルマネージド データベース 引用：AWS「 Amazon DynamoDB 」 上記の説明より、DynamoDBは「サーバレス」であり、「フルマネージド」サービスであることが分かります。 これらのサーバレスサービスを設定する場合、インスタンスタイプはどのようになっているのでしょうか？ 先程のAmazon RDSでAmazon Auoraを選択し、Serverlessオプションを選択してみましょう。 選択できる項目が一つに減りましたね。 これにより、サーバレスなサービスではOSレイヤーの管理に加え、キャパシティ管理もAWS側に委任することができます。 おわりに 今回は少々技術的な内容とは逸れてしまいましたが、個人的に気になっていた「フルマネージドサービス」と「サーバレス」の違いについて、理解を深めることができました。新人の方には、改めてこの場を借りて御礼申し上げます。 一方で、「マネージドサービス」と「フルマネージドサービス」については、本記事では同一のものとして取り扱いましたが、表記が異なるものが存在するのも事実です。これらに厳密には違いがあるよ、ということが分かる有識者の方がいらっしゃいましたら是非ご教示ください。。 参考サイト 今回の記事を執筆するにあたり、私が参考にしたサイトや有識者の皆様から教えていただきました記事を以下に列挙いたします。技術的な内容ではない（業界用語である）ため、参考サイトはAWSに限定しておりません。 サーバーレスとフルマネージド: その違いとは？ | Google Cloud 公式ブログ cloud.google.com 【AWS】マネージドサービスとサーバーレスの違い - Qiita 【AWS】マネージドサービスとサーバーレスの違いクラウドコンピューティングが進化する中で、Amazon Web Services（AWS）はさまざまなサービスを提供しています。その中でも特に注目さ… qiita.com

こんにちは、SCSK株式会社の小寺崇仁です。 Zabbix7.0からZabbixプロキシの冗長構成が可能になりました。 制約事項等ありますので、検証しながら考察したいと思います。 プロキシの冗長構成について サーバ＋プロキシの構成 プロキシの冗長構成をする場合、Zabbixプロキシを2台構築します。 ZabbixのWeb管理画面にて「プロキシーグループ」を作成し、2台のプロキシを同じグループに設定します。 プロキシーグループに冗長構成のパラメータがあり、「フェイルオーバーの期間」が設定できます。デフォルトは「1m」となります。 ホスト設定でのプロキシの指定 ホストの設定画面にて、「プロキシーグループ」を選択します。 監視を担うZabbixプロキシサーバは自動的にZabbixサーバで割り振られます。 ホストの設定画面の「割り当てられたプロキシ」に割り当てられたプロキシサーバが表示されます。 ポイント ・Zabbixサーバがプロキシの状態を監視し、監視対象がどのプロキシサーバで監視を行うかコントロールしています。 ・Zabbixプロキシ間でハートビートするのような冗長構成ではありませんでした。 ・Zabbixプロキシの代表IP切り替えるような冗長構成ではありませんでした。 ・Zabbixプロキシ側で冗長構成を行うための設定はありませんでした。   監視対象の構成について 監視対象側での注意事項をまとめます。 シンプルチェック Ping監視、ポート監視などは、2台のZabbixプロキシから監視対象に接続ができれば問題ないです。   Zabbixエージェント（パッシブ） zabbix_agentd.confもしくはzabbix_agent2.confに、2台のZabbixプロキシから接続ができるように設定をします。 vi /etc/zabbix/zabbix_agent2.conf Server=10.0.2.155,10.0.2.230 ※カンマ区切りでZabbixプロキシのアドレスを指定します。   Zabbixエージェント（アクティブ） zabbix_agent.confもしくはzabbix_agent2.confに、2台のZabbixプロキシに接続ができるように設定をします。 vi /etc/zabbix/zabbix_agent2.conf ServerActive=10.0.2.155;10.0.2.230 ※セミコロン区切りでZabbixプロキシのアドレスを指定します。カンマ区切りにすると2重でヒストリデータが作成されます。   SNMPトラップ Zabbix7.0では対応しておりません。Zabbixサーバに送信する必要があります。 切り替わることを想定して、2台のZabbixプロキシに同じ内容のSNMPTrapを送信すると、2重でヒストリーデータが作成されます。   Zabbixトラップ Senderコマンドでデータを送信する場合、Zabbixプロキシの指定を以下のconfigを指定するようにします。 config内の「ServerActive」に指定しているプロキシが使用されます。 zabbix_sender -c /etc/zabbix/zabbix_agent2.conf -s <ホスト名> -k <アイテムキー> -o 1234 ※「-z」オプションで各プロキシを指定すると、2重でヒストリーデータが作成されます。   実際にフェイルオーバーしてみた 検証内容 以下の内容で検証を行います。フェイルオーバーの期間はデフォルトの1mとします。 １．各アイテムタイプで10秒間隔の監視アイテムを作成します。 ２．監視を行っている側のプロキシのサービスを停止します。 ３．フェイルオーバー後にヒストリを確認し、何秒間のデータが欠損したか確認します。 予想では、1m(フェイルオーバーの期間) + 10s(監視間隔) = 70秒＋αのデータ欠損が発生する想定です。   アクティブプロキシの場合 アイテムタイプ 監視内容 最終取得時間 再開時間 欠損 シンプルチェック ping監視 18:43:23 18:44:53 90秒 Zabbixエージェント（パッシブ） CPU使用率 18:43:25 18:44:55 90秒 Zabbixエージェント（アクティブ） CPU使用率 18:43:26 18:44:49 93秒 Zabbixエージェント（アクティブ） ログ 18:43:29  18:43:29 なし 再開後、切り替え期間中に発生したログも受信 Zabbixトラップ ー 18:43:27 18:44:47 90秒   パッシブプロキシの場合 アイテムタイプ 監視内容 最終取得時間 再開時間 欠損 シンプルチェック ping監視 18:58:43 19:00:13 90秒 Zabbixエージェント（パッシブ） CPU使用率 18:58:45 19:00:05 80秒 Zabbixエージェント（アクティブ） CPU使用率 18:58:46 19:00:04 78秒 Zabbixエージェント（アクティブ） ログ 18:58:39 19:00:04 なし 再開後、切り替え期間中に発生したログも受信 Zabbixトラップ ー 18:58:49 19:00:09 80秒   考察 ・フェイルオーバー期間(60秒)を考慮すると、30秒程で切り替えができました。通常は5分間隔の監視が多いため、タイミングによっては1回監視に失敗する程度かと思います。 ・ログ監視は、欠損なく監視が継続できました。監視再開後に切り替え期間中に出力されたログもZabbixサーバに送信されてきます。 ・Zabbixトラップで送信した内容は欠損します。zabbix_senderコマンドの実行結果がエラーになるため、送信元で制御する必要があります。もしくは、ZabbixAPIに「history.push」 がバージョン7.0から追加されましたので、変更することも考えてもよいと思います。   非機能要件について バックアップ ・プロキシサーバのデータベースに格納されるデータは一時データであるため、DBのダンプの保存は不要です。 ・/etc/zabbixは以下にコンフィグファイルがあるため、設定変更時にバックアップが必要です。   プロキシの監視 ・Zabbixサーバから直接(プロキシを経由せずに)監視を行うのが良いと考えております。プロキシを経由すると「接続エラーやダウン」なのか「データの取得エラー」か判別しにくいためです。 ・Zabbixプロキシのテンプレートは「Remote Zabbix proxy health」がデフォルトで用意されています。使用時にはマクロの設定が必要です。   メンテンナンス ・マイナーバージョンアップの方法について、別途ブログ記事にする予定です。   拡張性 ・プロキシーグループにプロキシサーバを追加することで容易に拡張できます。 ・障害発生時に縮退運転した際でも問題がないよう、リソースを準備する必要があります。   セキュリティ ・Zabbixサーバ　⇔　Zabbixプロキシ　⇔　Zabbixエージェント間の通信は暗号化することが可能です。「PSK」「証明書」と選択が可能です。   HA構成で気になること スプリットブレインについて もし、Zabbixプロキシで監視設定の情報を保持しているため、障害の状況によっては、両系のプロキシで監視を行う可能性はあると思います。 別途発生するか検証してみたいと思います。発生した場合の影響としては、以下と考えてます。 ・2重で障害を検知する。両系で取得したデータが保存されるため。 ・プロキシで保持している設定がZabbixサーバと同期されれば復旧する   フェイルバックについて 障害が発生したプロキシを復旧するだけで、Zabbixサーバは復旧を自動的に認識します。 復旧後自動的に監視対象のホストを分散します。（自動的に割り当てられるので、任意のプロキシに移動することはできません）   フェイルオーバー、フェイルバックを頻繁に繰り返す可能性について マニュアルを確認したところ、頻繁に切り替わりが発生した場合、対象プロキシを切り離すなどの設定はありませんでした。   まとめ プロキシグループを作成することで、簡単に冗長構成を構築することができます。 また、検知後30秒程度で切り替わりができております。さらにログ監視では欠損なく監視ができております。 SNMPトラップの監視ができませんので、要件を確認してご利用いただければと思います。   最後に 弊社では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

こんにちは、2024年度入社の冨岡です。 どうやら私は12月まで研修を受けさせていただけるようです。弊社の教育の手厚さを日々感じながら研修に取り組んでおります。 現在はクラウド（AWS）研修に取り組んでいる中で 作業証跡 というものを初めて聞き、そして感動しました。 作業証跡で 成果を客観的に示せたり 、 自分の操作の証拠を残せたり 、 研修の復習ができたり と利点がたくさんありました。なぜいままで証跡残すことを意識していなかったのかと反省してます。 今回は作業証跡に関して、画面キャプチャソフトである WinShot をクラウド研修を元に紹介します。 作業証跡とは 作業証跡 とは、自分の 操作に不正がないかどうかを客観的に示すための記録 を指します。 研修ではAWSのサービスに入力するパラメータ等の設定画面をキャプチャして、指示に沿っていることを記録しています。他にはアプリが正しく挙動しているかのテストが成功している様子を証拠に残したりしています。 WinShotの紹介 みなさんはスクショをどのように撮りますか？おそらくWindowsキー+Shift+Sでのやり方をされている人が多いかと思われます。少ない枚数ならばこのやり方で良いと思います。しかし研修ではlesson1だけで 64枚 のスクショをを撮りました。この枚数分Windowsキー+Shift+S押してると大変で非効率です。そこでWinShotが活躍します。ちなみに私はOJTの指導員からWinShotを教えてもらいました。 WinShotのダウンロード方法 http://www.woodybells.com/winshot.html からWinShotのzipファイルをダウンロードします。 解凍後、Winshotのアプリケーションファイルをダブルクリックして起動します。 何も起こらないように感じて不安になりますが、右下のタスクアレイにアイコンが存在すれば起動完了です。 これでもう使えます。 WinShotの使い方 まず設定から始まります。 WinShot右クリックで環境設定します。 基本設定 タブで保存するフォルダの指定をします。 ホット・キー タブでスクショのキーを確認できます。 私は ビットマップで保存(アクティブウィンドウ ）を主に使っています。 Ctrl + Shift + F7 押すと撮影したスクショを 自動でフォルダの中に保存 されていきます。これがすごく便利で作業効率が高まりました。 デフォルトの設定で名前が連番で割り当てられます。   業務では保存ファイル名が指定される場合もあるようです。 そんなときは基本設定で 保存ファイル名を毎回指定する(E) のラジオボタンを選んでください。 同様にCtrl + Shift + F7 押すと、ファイル名を付ける画面が出て保存が可能です。 研修概要 研修は将来的にフルスタック人材となるために必要な基礎テクノロジの取得を目的にされているため、アプリ・インフラの両方を扱っています。 今回は全部で9個あるlessonの内、最初のlesson1を紹介します。 この構成図通りに作ってみようがlesson1です。最後にはAWS環境にDeployしたアプリが起動するか、ブラウザからアクセスできることをテストして終了です。 具体的に例を挙げると No.15 No.17 このようなEC2やJavaの要件に沿って構築を進めていく研修になっています。 lesson1で撮ったこと No.15の指示に通りに作成し、No.17に取り組む際に入力したコマンドの証跡を残しました。 おわりに WinShotはインフラエンジニアの間では割と有名で良く使われているフリーソフトらしいです。これで自分もインフラエンジニアとしての第一歩を踏み出したのだなと 感無量 です。 次回の記事に関してですが、1月からの案件ではAzureを使うと聞いているので、次はAzureについて書きたいです。もしくは社会人になってから資格勉強にはまってるので資格関連も考えています。

こんにちは。 最近、ServiceNowのAutomated Test Framework（ATF）を使用する機会があったので、その際に学んだことのご紹介となります。 本記事は執筆時点（2024年10月）の情報です。最新の情報は製品ドキュメントを参考にしてください。 ATFとは ATFはServiceNowのインスタンス上で自動テストを作成・実行することが可能なツールです。 新しい機能を開発、リリースした時、インスタンスアップグレード後のリグレッションテスト時などで使用できます。 ATFには以下のような特徴、メリットがあります。 マニュアルで行っていたテストを自動化することによる生産性向上（テスト実行のスケジューリングも可能！） ローコード・ノーコードでテストを作成できるため、高度な開発技術が不要 テスト中に作成されたデータや設定変更はテスト終了後にロールバックされるため、インスタンスがクリーンな状態に保たれる データ破損、パフォーマンス影響などを防ぐ為、ATFによる自動テスト実行は非本番環境で実施してください。   ATFのコンポーネント 代表的なコンポーネントをいくつか記載します。 Test 後述するTest Stepをグルーピングするものとなります。 テストを実行する最小の単位であり、テスト対象となる1つ1つ機能や業務フローごとにTestを作成していくイメージとなります。 Test Step/Step Configuration Step Configurationは、ユーザーに成り代わる、メニューにアクセスする、フォームを開く、などの単一のアクションになります。OOTBで多くのアクションが用意されています。 そしてTest Stepではこれらのアクションを使用して、テスト項目の動作確認をするための1つ1つのステップ詳細を定義していきます。 例えば「Impersonate」というユーザーに成り代わる動作を行うことができるStep Comfigurationを使用する場合、どのユーザーに成り代わるのかをTest Stepで指定します。 たくさんのStep ConfigurationがOOTBで用意されていますが、個人的によく使用したものをいくつか紹介します。 Create a User 特定のグループ、ロールを持ったユーザーを作成します。作成したユーザーでそのまま代理操作することも可能です。 各ペルソナの権限で動作確認したい場合などに使用します。 Open a New Form / Set Field Values / Submit a Form  ３つを一緒に使用することで、「フォームを開く」「フィールドに値を入力する」「フォームをサブミット」するという一連の動作を再現することができます。 Order Catalog Item カタログアイテムをオーダーすることができます。 Record Validation レコードのフィールドの値が特定の条件を満たしているかを検証します。 Business ruleやScheduled Jobによる処理、ユーザーの操作などにより、フィールドの値が想定通りに更新されているか確認できます。 Test Suite 複数のTestをグルーピングしたものとなります。 Test Suiteを実行することで、紐づく全てのTestが自動で実行されます。そのため、ペルソナごと、業務内容ごとなどの切り口でTestをTest Suiteに紐づけグループ化することで、管理しやすくなります。 また、Test Suite内で各Testの実行順序を定義したり、Test Suiteを自動で実行するためのスケジュール設定も可能です。   例：全体の構成は以下のようなイメージとなります。 Test Suite システム運用者の運用業務 Test ①問題レコードを起票する ②変更レコードを起票する ③インシデントレコードを起票する （Test③に対する）Test Step/Step Configuration ①システム運用者のアカウントに代理操作する ②インシデントフォームを開く ③各項目を入力する ④フォームをサブミットする   ATFを使ってみる 以前作成した「User Registration Request」を使用して、①カタログアイテムをオーダーする、②部門長が承認する、③ユーザーが自動で作成される、というプロセスをATFで自動テストしてみます。詳細は以下記事をご参照ください。 ServiceNowⓇのNow Assistを活用してカタログアイテム（申請フォーム）とフローを効率的に作成する ServiceNowのNow Assistの機能を活用して、申請書とフローを作成してみました。非常に効率的に作成することができたので、そのプロセスをご紹介します。 blog.usize-tech.com 2024.08.27   その際、成功・失敗時のATFの動作を確認するため、以下２パターンでATFを実行します。 成功パターン ロールを持たない一般ユーザーで「User Registration Request」を申請する。 失敗パターン 「User Registration Request」を申請できる権限を「 user_admin 」に制限する。 ロールを持たない一般ユーザーで操作しようとしたが、権限が足りず申請することができない。 テストの作成 Automated Test Framework (ATF) > Testメニューから新規にTestを作成します。 その後、「Add Test Step」をクリックし、Test Stepを追加していきます。 追加したTest Stepは以下の通りとなります。 各ステップで行っていることは以下の通りとなります。 ①Creat a User 「User Registration Request」をオーダーするユーザーを作成して代理操作する。 この時、ユーザーの所属部署を「IT」に設定する。（=承認はIT部門長に設定したユーザー宛てに依頼される） ②Open a Catalog Item カタログアイテム「User Registration Request」を開く。 ※操作しているユーザーの権限が不足している場合、エラーとなる。 ③Set Variable Value 「User Registration Request」の各項目を入力する。 ④Order Catalog Item 「User Registration Request」をオーダーする。 ⑤Record Query リクエストアイテムが作成されていることを確認する。 ⑥Record Query IT部門長宛てに承認レコードが作成されていることを確認する。 ⑦Impersonate IT部門長のユーザーアカウントに代理操作する。 ⑧Open an Existing Record 自分宛ての承認レコードを開く。 ⑨Click UI Action UIアクション「Approve」をクリックして承認する ⑩Record Query ユーザーテーブルをクエリし、申請通りにユーザーが作成されていることを確認する。   Test Stepを追加していく際、各Test Stepのアウトプットは後続のTest Stepで利用することができます。 ④⑤のステップを例に説明すると、、 ④のOrder Catalog Itemではアウトプットとして、「Request」レコードが作成されます。 そして、⑤ではRequest Itemテーブルをクエリしていますが、クエリ条件に前ステップ④のアウトプットを使用しています。 設定は、画面上でポチポチするだけで完了します。   各ステップの詳細な設定手順は省きますが、基本ローコード/ノーコードで操作できるため、簡単に作成することができました。 テストの実行 「Run Test」をクリックし、テストを実行します。 テスト実行中は、以下の画面のようにテストの進捗を確認することができます。 テストの実行が完了しました。 「Go to Result」をクリックします。 Test Resultの画面では、各Test Stepごとの実行結果が確認できます。 また、画面操作などクライアント側のテストを実行した場合は、自動で画面のスクリーンショットを取得して添付してくれます。   次にテストが失敗した場合の動作を確認していきます。 「User Registration Request」をオーダーできる権限を「user_admin」に設定したうえでテストを実行します。 結果を確認すると、Test Step②のOpen a Catalog Itemでテストが失敗しています。 最初のステップで作成したユーザーが何も権限を持っていなく、「User Registration Request」を開けない為、失敗になったことが分かります。   感想 ATFを活用することで、テストに要する時間を大幅に削減することができると感じました。 また、アップグレードや新規機能リリース時、意図せぬ変更が行われていた場合の既存機能への影響検知に役立ちます。 今回は基本機能の一部分を紹介しましたが、他にも便利機能が多く用意されているので、引き続き勉強してアウトプットしていきたいと思います。   ServiceNow ServiceNowは、企業の生産性向上や業務プロセス改善を支えるサービスマネジメントクラウドソリューションです。従業員満足度・顧客満足度の向上、業務効率化を強力に支援します。 www.scsk.jp

こんにちは、SCSKの茂木です。 前回は「HULFT× LifeKeeper」についてご紹介しました。 第9回　HULFT × LifeKeeperでミドルウェアの高可用性を実現！ ミドルウェアの高可用性ニーズの高まりと、HULFTにLifeKeeperを用いてHA構成を実現する方法をご紹介いたします。 blog.usize-tech.com 2024.07.30 今回はデータのリアルタイムレプリケーションを実現する DRBD（Distributed Replicated Block Device）とLifeKeeperの可能性について探っていきましょう！   DRBDの概要 DRBD（Distributed Replicated Block Device）は、Linux環境で動作する ネットワークベースのストレージレプリケーションソリューションです。 主に高可用性クラスタを構築するために利用され、データのリアルタイムミラーリングを実現します。 DRBDは、ブロックデバイスレベルでのデータ同期を行い、物理的に離れたサーバー間でデータを複製します。   データのリアルタイムミラーリングは魅力的ね DRBDの特徴 続いてDRBDの4つの特徴について確認してみましょう。 DRBDを使用することでどのようなことができるのか、詳しく解説します。 ※DRBD9：DRBDの最新バージョンです。様々な機能が追加されました。 リアルタイムレプリケーション データをプライマリノードからセカンダリノードにリアルタイムで同期し、障害時のデータ損失を防ぎます。 通常のTCP/IPネットワークを利用してストレージの複製を行うネットワークレプリケーションを採用しているため、 特別なハードウェアを必要とせず、Linux環境とネットワークがあればすぐに導入可能です。 DRBD9では、Infini-Bandなどの高速ネットワークを活用することで、パフォーマンスの高い冗長化ストレージを提供します。 シームレスなストレージ冗長化 ファイルシステムよりも低いレイヤーで動作し、レプリケーションされたストレージをブロックデバイスとして提供します。 このデバイスは通常のストレージと同様に使用可能で、アプリケーションはミラーリングを意識せずに動作します。 これにより、リアルタイムでのデータ複製を行いながら、すべてのアプリケーションをシームレスに運用できます。 柔軟な構成 DRBDのマルチノード構成は、複数のノード間でデータをリアルタイムに同期し、システムの可用性を大幅に向上させます。 この構成により、単一障害点を排除し、データの一貫性を維持しながら、スケーラブルな環境を実現します。 特に大規模システムでの高可用性と信頼性を確保するために効果的です。 DRBD9からはメッシュ状に相互のノードを接続し、最大32ノードまでのレプリケーションが可能になりました。 オープンソース DRBDはオープンソースソフトウェアとして提供されており、コミュニティによるサポートと継続的な開発が行われています。 これにより、ユーザーは自由にソースコードを利用・改変でき、コストを抑えつつ最新の技術を活用できます。   Disaster Recovery add-on DRBDの理解が深まったところで、いよいよDRBD×LifeKeeperのご紹介です。 2024年9月25日より「LifeKeeper for Linux ver.9.9.0」において、 災害対策のための新たなオプション機能「Disaster Recovery add-on」の提供が開始されました。 「Disaster Recovery add-on」を使用し、DRBDリソースの設定と制御を行うことで、 遠隔地の災害対策サイトへのリアルタイムデータレプリケーションとアプリケーションのフェイルオーバーを行うことが可能になりました。 ここではDRBDやDataKeeperの問題点に注目することで、 「Disaster Recovery add-on」を使用するメリットを確認しましょう。 DRBDの問題点 手動管理 フェイルオーバーやフェイルバックは手動で行う必要があります。管理者が介入してノードの切り替えを行います。 監視機能の制限 DRBDはコマンドラインツールを通じて基本的なステータス（例：接続状態、同期状態）を確認できますが、 リソース監視等の詳細な監視や自動アラート通知機能はありません。 DataKeeperの問題点 マルチターゲット構成 DataKeeperは3ノード以上のマルチターゲット構成をサポートしていません。 非同期レプリケーション 非同期レプリケーションを使用することは可能ですが、パフォーマン面に課題があります。 Disaster Recovery add-onの使用 自動高可用性管理 DRBDのデータレプリケーション機能に加え、LifeKeeperは自動フェイルオーバーとフェイルバックを提供します。 障害発生時に自動でノードを切り替えることでダウンタイムを最小限に抑え、運用負荷を軽減します。 監視機能の拡張 リソースの状態を継続的に監視し、問題が発生した際にアラートを発します。 マルチターゲット構成（3ノード） Disaster Recovery add-onでは任意の同期モードを組み合わせた3ノード構成が可能です。 物理的・地理的な配置や利用可能なネットワーク環境、トランザクションの種類と量、転送されるデータ量などに応じて、 最適な同期モードを選択できます。 まとめ DRBD はデータのレプリケーションに特化しており、手動での管理が必要です。 DataKeeper は同サイトでのレプリケーションを想定しているため、DR環境での利用に適していません。 Disaster Recovery add-on は、DRBDの機能を拡張し、システム全体の可用性を高めるための自動化と管理機能を提供します。   製品ページ SCSKでは、LifeKeeperの製品ページをご用意しております。 「LifeKeeper」で安定稼働を実現 ｜ SCSK株式会社 「LifeKeeper」は、システム障害時にあなたのビジネスを守るＨＡクラスターソフトウェアです。オンプレ環境だけでなく、パブリッククラウド環境での安定稼働の実現にも最適です。長年培ったSCSK独自のノウハウでお客様の課題解決に向け最適なご... www.scsk.jp   ご参考までに、提供価格を提示いたします。 1年間の使用権とサポートをセットとしてサブスク型オプション製品として提供されます。 ※標準価格は1ノードあたり。LifeKeeperのライセンスと保守は別途必要。 最後に 今回はDRBDとLifeKeeperの可能性についてご紹介しました。 次回は実際に検証を行う予定ですので、ご期待ください！

既存のAWSリソースを基にCloudFormationテンプレートを生成する「IaCジェネレータ」が2024年2月にリリースされました。 このツールによって、既存のリソース情報を簡単にコード化できるようになっています。 8月にアップデートされた情報と合わせて、使ってみた感想、ポイントをご紹介します。 最新の情報については、AWS 公式ドキュメントをご参照ください。 IaCジェネレータとは AWS IaCジェネレータは、既存のリソースを基にCloudFormationテンプレートを生成できるサービスです。 テンプレートはJSONとYAML形式で出力できます。 こちらはCloudformationの機能の一部として提供されているので、マネジメントコンソールの[Cloudformation]のサービス画面から利用が可能です。   使い方 既存のリソース情報をスキャンし、スキャンされたリソースの中からコード化したいリソースを選択することで、テンプレートが作成できます。 ▼Cloudformationテンプレート化の方法 　1.　マネコンのCloudFormationから[IaCジェネレーター]のメニューを選択する。 　2.　[新しいスキャンを開始]をクリックする。 　3.　[テンプレートの作成]からテンプレートの詳細を指定し、テンプレート化したいリソースを選択して[スキャンしたリソースを追加]に追加する。 ※リソースはリソース識別子(ID等)、リソースタイプ(AWS::EC2::Instance等)、タグのいずれかでフィルター可能。 　4.　選択したリソースに関連するリソース一覧がデフォルトでチェックされた状態で表示されるので、必要に応じて追加選択する。 　5.　[テンプレートの作成]でテンプレートを作成する。以下は作成されたテンプレート。 ▼テンプレートを用いたリソース作成の方法 　1.　CloudFormationの[スタックの作成]>[新しいリソースを使用]を選択する。 　2.　[テンプレートの指定]でテンプレートを選択しスタックを作成する。   ちなみに、8月のアップデートは以下2点でした。 スキャンした内容に関して[スキャンされたリソースの内訳]が追加されました。製品タイプごとにフィルタリングし、円グラフを使って視覚的に表示することができます。   作成したテンプレートの[テンプレートの定義]がAWS Application Composer（AWSのビジュアルツール）で表示されるようになりました。 これにより、視覚的にリソースを容易に理解することが可能です。   コスト テンプレート化は無料で利用可能です。 ※Cloudformationで作成したリソースには利用料金が発生します。   制約事項 クォータ制限については、以下の表のとおり通り制約がありました。 1 回のアカウントスキャンで処理できるリソースの最大数 100,000 1日あたりのスキャン数 (リソースが 10,000 未満のアカウントの場合) 3 1日あたりのスキャン数 (リソースが 10,000 以上のアカウントの場合) 1 アカウントあたりの同時に生成されるテンプレートの数 5 1回のテンプレート生成で同時にモデル化されるリソースの数 5 1つのテンプレートでモデル化できるリソースの合計数 500 生成されたテンプレートのアカウントあたりの最大数 1,000 追加で、 スキャンは30日間のみ有効なためそれ以降は利用できなくなる こと、 スキャン後に削除されたリソースに関してはテンプレート対象として選択できない 点に注意です。 また、 スキャンはアカウント内の全リソースに対しておこなわれる（特定のリソースのみのスキャンは不可である） ことから、リソース数が多い環境では時間に余裕をもってスキャン実施することをお勧めします。 公式情報によると「1,000リソースで10分程度かかる可能性がある」とのことで、実際に自分が検証で30,000近くのリソースがある環境でスキャンした際は50分程かかりました。   テンプレート作成時の注意点 IaCジェネレータでテンプレートを生成してみて、個人的に引っかかったポイントです。 テンプレート作成時のリソース検索は、「リソース識別子(ID等)、リソースタイプ(AWS::EC2::Instance等)、タグ」のいずれかでフィルター可能ですが、 検索文字列はいずれも完全一致の必要有り でした。またリソース名で検索は不可です。 テンプレート作成時に「関連リソース」としてテンプレート化するリソースがレコメンドされますが、レコメンドされるリソースの判断基準は不明のようです。 ※AWSサポートに問い合わせると「現在のところ公開している情報がなく、AWS 内部の仕組みのため案内は難しい」と回答有り テンプレート化したリソースの更新・削除ポリシーは デフォルトが”保持” になっています。 この設定により、Cloudformationのスタックを削除しても作成されたリソースは削除されず保持されます。 Cloudformationで一からテンプレートを作成する場合このポリシーは”削除”がデフォルトのため、仕様の違いに注意です。 EC2はテンプレート内で指定しているAMIが現在存在していない場合、テンプレートを使ってリソースを構築することはできません。 テンプレート内のリソース参照がハードコードされている場合、別のアカウントで同じリソースを作成しようとすると、そのアカウントの情報に合わせてテンプレートを修正する必要があります。 テンプレートには、AWSマネコンでは直接表示や設定ができないリソースタイプ（例: “AWS::EC2::EIPAssociation” や “AWS::Lambda::Version” など）が含まれることがあります。 リソースタイプは普段マネコンからリソース作成していると馴染みが薄いかもしれませんが、Cloudformationのユーザーズガイドにリソースタイプリファレンスとしてそれぞれの意味や構文などの説明が記載されているので参考にしてみてください。   また、Cloudformationの仕組みとして、以下はマネコン上で構築する際と異なるルールになりますので、Cloudformation初心者の方はお気を付けください。 リソースの設定内容によってはCloudformationテンプレートで設定できないものもあります。（リソース作成後マネコンから設定可能） テンプレートで構築するEC2はリソース定義するのみのため、内部のソフトウェアやデータ構成など中身は反映されません。 ユーザデータにスクリプトを書き込んでおくなど別途対応が必要になります。   活用できそうな場面 構築では、 同じ環境を複製したい場合、同等の環境を作成したい場合、アカウントをまたいでリソースを移行したい場合 に 運用では、 リソースを棚卸したい場合、リソースの依存関係を可視化したい場合、現状のリソースの設定状況を保管しておきたい場合（変更管理） に また、 BCP用、不要リソースの削除前のバックアップ にも活用できそうです。   みなさまも色々IaCジェネレータを触ってみて、活用方法をぜひ考えてみてください。

こんにちは。SCSKの上田です。 システム監視の重要度が高まってきた昨今、様々な監視ツールが存在しています。 今回は、 オープンソースのシステム監視ツール「 Zabbix 」 と、 AWSの「 Amazon CloudWatch （以下、CloudWatch）」 を比較してみました。 監視ツール選定のご参考になれば幸いです。 ZabbixとCloudWatchの概要 まずは、 Zabbix と CloudWatch 、それぞれの概要について説明します。 Zabbixについて Zabbixは、 エンタープライズ対応のオープンソース統合監視ツール です。 サービスやそれを支える ITシステム(サーバ、ネットワーク機器等)の状態を把握し、障害の予兆やサービスへ影響を及ぼす事象が発生した際に、システム管理者やオペレータに通知を行うことができます。 オープンソースのため無料で導入でき、数万デバイス規模のエンタープライズ環境でも多数の稼動実績を誇っています。 Zabbixの詳細情報については、下記リンクよりご確認ください。 Zabbix :: The Enterprise-Class Open Source Network Monitoring Solution ZabbixはITインフラストラクチャ・コンポーネントの可用性やパフォーマンスを監視するためのエンタープライス向けソフトウェアです。Zabbixはオープンソース・ソフトウェアとして開発されており、無料でダウンロードいただくことが可能です。 www.zabbix.com CloudWatchについて CloudWatchは、 AWS が提供するクラウドネイティブな監視サービス です。EC2、Lambda、S3といったAWSの各種サービスのパフォーマンスデータも収集・追跡し、AWS環境全体の監視ができます。 CloudWatchは、AWSコンソールから簡単に設定・利用できるため、導入の手間が少なく、初心者にも扱いやすいのが特徴です。また、監視対象のAWSサービスやメトリクス、アラート設定などを柔軟にカスタマイズできるため、大規模で複雑なシステムにも対応可能です。 CloudWatchの詳細情報については、下記リンクよりご確認ください。 Amazon CloudWatch（リソースとアプリケーションの監視と管理）| AWS Amazon CloudWatch は、AWS リソースと AWS で実行するアプリケーションのモニタリングサービスです。様々なメトリクスやログを収集・追跡することで、システム全体のリソース使用率、アプリケーションパフォーマンス、およびオペ... aws.amazon.com ZabbixとCloudWatchの比較 それでは、 Zabbix と CloudWatch を比較してみましょう。 比較表 ざっくり比較すると、以下のようになります。 比較項目 Zabbix CloudWatch 概要 オープンソースの監視ツール AWSのマネージド監視サービス コスト ソフトウェア自体は 無料 AWS上に構築する場合EC2料金、 サポート入るなら年間サポート料金 従量課金制 （監視項目数に応じた課金） 監視対象 クラウド・オンプレどちらも対応 サーバー、ネットワーク機器、アプリケーションなど、多岐にわたる AWSのリソース （EC2、S3、Lambdaなど） 監視項目 CPU、メモリ、ディスク、プロセス、ログ、SNMP監視など （一部監視にはエージェント導入必要） CPU、メモリ、ディスク、プロセス、ログなど （一部監視にはエージェント導入必要） 監視対象数 無制限（サーバのスペックに依存） 無制限 導入難易度 ある程度の技術知識が必要 AWSの知識があれば 比較的容易 サポート Zabbix Enterpriseサポート AWSの公式サポートとコミュニティ いくかの比較項目について、詳しく解説していきます。 コストについて Zabbixはオープンソースソフトウェアのため、ライセンス費用無料で監視を行うことが可能です。何台監視しても、どれだけ監視項目を増やしても、無料で使用することができます。 但し、AWS上に導入する場合はEC2の費用が発生するのと、サポートに加入する場合はサポート費用が発生します。 CloudWatchは従量課金制です。Cloudwatchのリソース監視には標準メトリクスとカスタムメトリクスの2種類があり、標準メトリクスであれば無料ですが、カスタムメトリクスの場合はメトリクスの数だけ料金が発生します。 簡単にコスト比較をしてみましょう。 （2024年10月時点でのコスト比較です） コスト Zabbix CloudWatch サーバ t3.smallを使用したとすると、 0.0272$ /h　→約20$ /月 – 監視対象 – 1サーバあたり10個カスタムメトリクスを利用したとすると、 0.30$/月 * 10 = 3.0$/月 →3.0$ /月・監視台数 合計 20$/月 3.0$ /月・監視台数 この結果から、 監視対象が7台を超えるとZabbixの方が安い ということになります。 但し、 EC2のスペック や カスタムメトリクスの数 によって料金が変動するため、一概にこのシミュレーションが正しいとは限りません。 あくまで参考値として捉えてください。 詳細なコストについては、AWS公式サイトをご覧ください。 料金 - Amazon CloudWatch | AWS Amazon CloudWatch は無料で始めることができ、また 、無料利用枠内でご利用いただけるアプリケーションも多数ご用意しています。このページでは Amazon CloudWatch に関する各種お見積もりや API 使用時のコスト... aws.amazon.com 監視対象、項目について Zabbixは、クラウド・オンプレ問わず、サーバやネットワーク機器、アプリケーションなど様々なリソースを監視することができます。監視項目も幅広く、既存のアイテムキーに加え、APIを作り込めば様々なデータを取得し監視することが可能です。 CloudWatchは、AWSのマネージドサービスというだけあり、AWS上のリソース監視に特化しており、他クラウドやオンプレミスの監視には不向きです。（CloudWatchでも作り込みによってはオンプレ環境の監視はできますが、設定が煩雑です） また、監視項目は、標準メトリクス（死活、CPUなど）は無料ですが、カスタムメトリクス（メモリ、ディスク、プロセス）については有料となっています。 導入難易度について Zabbixは、GUI操作で監視の設定が行えるのですが、柔軟性が高い反面設定が難しく、慣れるまでが大変です。例えば「CPU使用率を監視したい」と思っても、ホストの登録・アイテムの設定・トリガーの設定など手順が多く、アイテムキーの設定もマニュアルを読まないと分かりにくい部分があるため、慣れるまでが大変です CloudWatchは、GUIの直感的な操作で監視の設定ができるため、AWSに慣れている人なら比較的簡単に設定できると思います。 それぞれでAWS上に建てたEC2のCPU使用率を監視する方法を見比べてみましょう。 まずはZabbixからです。Zabbixのインストール、監視対象へのAgentのインストールは完了している前提とします。 Zabbixのインストールについては、以下の記事をご参照ください。 LinuxサーバーへのZabbixインストール手順 オープンソースの統合監視ツールである「Zabbix」を、Linuxサーバーへインストールする手順を紹介します。 blog.usize-tech.com 2024.02.13 ①WEBコンソールから、監視対象機器（ホスト）を登録する Zabbix設定手順① ②登録したホストにアイテムを設定する Zabbix設定手順② ③登録したホストにトリガーを設定する Zabbix設定手順③ 以上で設定は完了です。設定手順自体は少ないですが、アイテム設定の”アイテムキー”、トリガー設定の”トリガー条件式”の書き方は、様々な項目の監視や複雑な条件式が書ける反面、 慣れるまで難しい と思います。 より複雑な設定を行いたい場合、Zabbix公式ドキュメントを読んでいただくか、 ZabbixのEnterpriseサポートに加入いただくこと をお勧めいたします。詳細は弊社のZabbix特設ページをご覧ください。 SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします www.scsk.jp 続いて、CloudWatchの設定手順です。 ①CloudWatchのコンソールから、アラームを作成する CloudWatch設定手順① ②監視対象のメトリクスを選択する CloudWatch設定手順② ③閾値を設定する CloudWatch設定手順③ ④アクションを設定する（SNS通知、EC2へのアクションなどが設定できます） CloudWatch設定手順④ ⑤アラーム名を設定する CloudWatch設定手順⑤ 以上で設定は完了です。設定手順は多く見えますが、一連の流れで全ての設定が直感的に行えるため、Zabbixに比べて簡単に設定できると思います。 結局、どちらを選ぶべき？ ここまでの比較から、ZabbixとCloudWatchの強みと弱みをまとめます。 比較項目 Zabbix CloudWatch 強み ・柔軟な監視設定 ・広範囲な監視対象 ・コスト効率が高い ・豊富なAWSサービスとの連携 ・導入が容易 弱み ・導入・運用に技術知識が必要 ・サーバーのサイジングが必要 ・監視の対象がAWSに限られる ・高度な監視にはコストがかかる Zabbixは、 クラウド・オンプレ問わず様々な監視 ができ、 コストも抑えられます 。しかし、導入や運用には知識が必要です。 CloudWatchは、 AWS上のリソース監視を簡単に設定 することができます。しかし、AWS以外の監視には向いておらず、コストもかかってしまいます。 以上のことから、以下のように選択すると良いと思います。 マルチクラウドやオンプレミス環境で、コストを抑えたいなら、 Zabbix AWS環境で、手軽に監視をしたいなら、 CloudWatch   まとめ 今回は、 Zabbix と CloudWatch の比較を行ってみました。 それぞれメリット・デメリットがありますので、皆様の環境に合わせて、最適な監視ツールを選択してください。 弊社では、 Zabbixの導入もAWSの設計構築も行っています。 「Zabbixを使いたいけど、使い方が分からない・・・」 「結局どの監視ツールを使えばいいのか迷っている・・・」 などなど、監視についてお悩みの点がありましたら、是非弊社までお声がけください！ 最後まで読んでいただきまして、ありがとうございました。 弊社では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株式会社の小寺崇仁です。 Zabbixには定期レポート機能があります。今回は定期レポートの設定方法を紹介いたします。 定期レポートとは Zabbix5.4にて実装された、定期的にダッシュボードのスクリーンショットをPDF形式で通知する機能です。 以下のファイルが「application-pdf」というファイル名で通知されます。 設定方法 Chromeのインストール dnf install https://dl.google.com/linux/direct/google-chrome-stable_current_x86_64.rpm dnf install google-chrome-stable Zabbix-Web-Serviceのインストール＆設定 dnf install zabbix-web-service systemctl start zabbix-web-service vi /etc/zabbix/zabbix_server.conf StartReportWriters=1 WebServiceURL=http://localhost:10053/report 作業ディレクトリの作成 mkdir /var/lib/zabbix chown zabbix:zabbix /var/lib/zabbix/ Web管理画面のURLを設定 「管理」->「一般」->「その他」を開きます。 WebインターフェースURLにZabbixサーバのWeb管理画面のURLを指定します。 レポートの作成 「レポート」->「定期レポート」->「レポートの作成」を開きます。 名前 任意 ダッシュボード 任意 （レポートにしたいダッシュボード） 期間 前日、先週、先月、去年 (ダッシュボードに表示するデータの期間) 周期 毎日、毎週、毎月、毎年 （レポートを送信する間隔） 配信先 配信先ユーザ ※メディアタイプの設定が必要です。 通知 メールのメディアタイプを設定した場合、以下の様に通知されます。 最後に ★YouTubeに、SCSK Zabbixチャンネルを開設しました！★ https://www.youtube.com/channel/UC-_Jh3K46ZM610HUNtsArtQ/videos ★X（旧Twitter）に、SCSK Zabbixアカウントを開設しました！★ https://x.com/SCSK_Zabbix

こんにちは。SCSK株式会社の南です。 11/6 に、 【「Prisma Cloud」運用課題を解決、成功事例に学ぶ「CSPM」運用改善アプローチ ～未解決アラートへの対策など具体的な解決策を紹介～】 と題したPrismaCloudのセミナーを開催します。 本セミナーでは、Prisma Cloudの運用課題を解決したいと考えている方を対象に、運用改善のための具体的な手法と成功事例をご紹介します。 特に「なぜアラートの対応が進まないのか」に焦点を当てて解説してまいります。   セミナー概要 主催・協力 SCSK株式会社株式会社 オープンソース活用研究所 マジセミ株式会社 日時 2024-11-06（水）13:00 – 14:00 会場 Webセミナー ツールはZoomを使います。URLは直前にメールにてご連絡いたします。 対象 Prisma Cloudをご利用いただいており、運用に課題を抱えている方 Prisma Cloudにご興味ある方 参加費 無料   プログラム詳細とお申込みは、以下ページをご参照ください。 （SCSK） 「Prisma Cloud」運用課題を解決、成功事例に学ぶ「CSPM」運用改善アプローチ ～未解決アラートへの対策など具体的な解決策を紹介～ 2024-11-06（水）13:00 - 14:00 当お申込ページはSCSK株式会社経由の方向けのお申込みページです。 一般の方はこちらからお申し込みください。 本セミナーはWebセミナーです ツールはZoomを使います。URLは直前にメ... majisemi-security.doorkeeper.jp   最後に 弊社ではPrisma Cloud関連サービスを展開しています。以下ページもご参照ください。 ★パブリッククラウドのセキュリティ設定を監視し異常を速やかに検知する、Prisma Cloudを活用した「 マネージドCSPMサービス 」はこちら！ Smart One Cloud Security® パブリッククラウドのセキュリティ設定を診断/監視するマネージドCSPMサービスです。Palo Alto Networks社Prisma Cloud（CSPM機能）を使い易く、簡単に導入いただけます。 www.scsk.jp ★パブリッククラウドのセキュリティ設定に対する現状確認やリリース前診断が、お手軽に可能な「 スポット診断サービス 」はこちら！ マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 マルチクラウド環境のセキュリティ設定リスクを手軽に確認可能なスポット診断サービスです。独自の診断レポートが、運用上の設定ミスや設計不備、クラウド環境の仕様変更などで発生し得る問題を可視化し、セキュリティインシデントの早期発見に役立ちます。 www.scsk.jp

昨今のビジネス環境では、コスト削減やスケーラビリティの向上、リモートワークの促進など、多くの利点を提供するクラウドサービスの利用が急速に拡大しています。しかし、その一方で、 パブリッククラウド環境には特有のセキュリティリスクが存在 しているため、データ漏洩や不正アクセス、サイバー攻撃などの脅威から企業の重要な情報を守るためには、 クラウドセキュリティの強化が必要不可欠 となっています。 ここでは、「クラウドセキュリティ」 がどのようにあるべきか、そしてそれをどのように進めるべきかを、「 今やるべきクラウドセキュリティ対策とは？ 」と題して解説します。 パブリッククラウドにおける昨今のセキュリティリスク まず初めに、パブリッククラウドにおけるセキュリティリスクにはどのようなものがあるでしょうか。Cloud Security Alliance（CSA）により2022年に「 Top Threats to Cloud Computing ‒ Pandemic Eleven 」が公開されていますが、その すべてにおいて利用者側に責任が発生する 脅威 となっています。パブリッククラウド環境の機能追加や利用者側の用途拡大に伴い、これらセキュリティリスクの多様化は年々進んでいるため、組織はこれらの動向確認とその対処や対策が急務と言えます。 順位 脅威名 1 不十分なアイデンティティ、クレデンシャルおよびアクセスと鍵の管理、ならびに特権アカウント 2 セキュアでないインターフェースやAPI 3 設定ミスと不適切な変更管理 4 クラウドセキュリティのアーキテクチャと戦略の欠如 5 セキュアでないソフトウェア開発 6 セキュアではないサードパーティーのリソース 7 システムの脆弱性 8 予想外のクラウドデータ公開 9 サーバレスやコンテナワークロードの構成ミスやエクスプロイト 10 組織的な犯罪、 ハッカーとAPT 11 クラウドストレージデータ流出 【出典】CSA、Top Threats to Cloud Computing ‒ Pandemic Eleven 　       （日本語訳：CSA ジャパ ン「クラウドコンピューティングの重⼤脅威 パンデミックイレブン」）     　    https://www.cloudsecurityalliance.jp/site/wp-content/uploads/2022/11/top-threats-to-cloud-computing-pandemic-eleven-060622-en_us-ja.pdf   クラウドセキュリティ対策のあるべき姿 では、これらのセキュリティリスクに共通する対策は何でしょうか？ それは 「 発見 」 と 「 対応 」 そして、それらを 「 継続して確認すること 」 と考えます。 Gartner社は、サイバーセキュリティの新たなアプローチとして2022年に 継続的な脅威エクスポージャー管理（ CTEM ：Cloud Threat Exposure Management） を提唱し、これを2023年に続き2024年のサイバーセキュリティ トップ・トレンドの一つとして掲げています。 *1 *1 2024年2月27日　 Gartner 2024年のサイバーセキュリティのトップ・トレンドを発表       https://www.gartner.co.jp/ja/newsroom/press-releases/pr-20240227   CTEMとは？ では、CTEMとはどういったものでしょうか。 CTEMは、組織がサイバー攻撃を受ける可能性のあるリスクや脆弱性の状態（攻撃面）をIT資産全体で特定し、それを継続的に評価し、対応するためのフレームワークであり、これを導入することでサイバー攻撃によるリスクを大幅に軽減できるとされています。 「一度作ったらずっと安全」 というシステムはほとんど存在しないため、このような継続的管理は必然的だと言えます。 CTEMフレームワークは以下の5つのステップで構成されています。   No. Step 説明 1 範囲の設定 （Scoping） 保護すべき資産やシステムの範囲を決定します。 2 発見 （Discovery） 脆弱性や攻撃経路などのリスクを発見し評価します。 3 優先順位付け （Prioritization） 発見された脆弱性やリスクを優先順位付けし、修正の順序を決定します。 4 検証 （Validation） 対策の有効性を確認するために、シミュレーションやテストを行います。これにより、対策効果を事前に評価し、それが十分であるかを確認します。 5 動員 （Mobilization） 検証結果に基づき、組織のセキュリティ体制強化と対策を実施します。セキュリティ体制では、セキュリティ担当と運用担当との連携も必要となります。 1～3は診断フェーズとして、対象範囲の特定と、その範囲における問題の把握と優先順位付けを行います。 4、5は行動フェーズとして、対策の事前検証と、検証結果に問題がなければ対策を実施します。 これらを 定義した 「範囲の設定」毎に繰り返し実施 することで、組織におけるサイバーリスクの継続的な評価・対策を実現することができます。また、一連の動作すべてを単一ソリューションでまかなう必要はなく、環境に応じて手動運用とソリューションの組み合わせなどで実現することも有効な手段となります。 CTEMの具体的な指標としてGartner社は、2026年までにCTEMの考えに基づき継続的にセキュリティ投資を行っている組織について、セキュリティ侵害を3分の1まで減らせるようになるとみています。   【クラウドセキュリティ対策のあるべき姿】 CTEMを活用 して 脅威の発見と対応を継続的、効果的に管理 すること   パブリッククラウドを取り巻くセキュリティ対策 さて、クラウドセキュリティ対策のあるべき姿が理解できたところで、実際にパブリッククラウドで 実施すべきセキュリティ対策のソリューションや機能 に何があるかを見てみましょう。   まずは利用形態のご紹介ですが、パブリッククラウドは大きく分けて、IaaS、PaaS、SaaSのモデルに分類されます。 IaaS（Infrastructure as a Service）: インフラストラクチャをサービスとして提供するモデルで、ユーザーは仮想マシンやストレージ、ネットワークなどのリソースを必要に応じて利用できます。代表的なサービスには、Amazon Web Services（AWS）やMicrosoft Azure、Google Cloudがあります。 PaaS（Platform as a Service）: アプリケーション開発に必要なプラットフォームを提供するモデルで、開発者はインフラの管理を気にせず、アプリケーションの開発とデプロイに集中できます。例として、Google App EngineやMicrosoft Azure App Servicesがあります。 SaaS（Software as a Service）: ソフトウェアをサービスとして提供するモデルで、ユーザーはインターネットを通じてソフトウェアを利用でき、インストールやメンテナンスの手間が省けます。代表的なサービスには、Google WorkspaceやMicrosoft 365、Salesforceがあります。 これらのモデルごとに適した、主なセキュリティ対策としては以下のようなものがあります。   EASM (External Attack Surface Management) 外部攻撃対象領域（インターネットに公開されている入口）を管理し減少させるための取り組みで、管理されていない対象も洗い出します。組織の外部から見える脆弱性を特定し、それを解消することを目的としています。 CNAPP (Cloud Native Application Protection Platform) IaaS、PaaS領域に対応した、クラウドネイティブなアプリケーション保護を目的とし、設定ミスや脆弱性の管理、統一した設定などのガバナンス強化を行うためのセキュリティプラットフォームです。通常、マルチクラウドに対応します。 CSPM、CWPP、CIEM、IaCセキュリティ *2  が主な構成要素です。 SSPM (SaaS Security Posture Management) SaaS領域の適切なセキュリティ設定から逸脱した状態を検出し、データの保護を強化します。ソリューションによって対応可能なSaaS環境が異なります。 DSPM (Data Security Posture Management) データのセキュリティ態勢を包括的に管理します。重要データの検出を行ったり、データが保管・処理される全ての段階でセキュリティを確保し、データ漏洩や不正アクセスを防ぐことを目的としています。   パブリッククラウド環境においては、これらの異なる目的と役割を持つソリューションを活用し、 互いを補完しつつ全体のセキュリティを強化 することが重要となります。 *2  CSPM (Cloud Security Posture Management)：IaaS/PaaSのセキュリティ設定不備を監視し、リスクを可視化するソリューション 　　CWPP (Cloud Workload Protection Platform)：IaaS/PaaSのワークロードを監視し、脅威を検知するソリューション 　　CIEM (Cloud Infrastructure Entitlement Management)：IaaS/PaaSの権限侵害を検知し、セキュリティを強化するソリューション 　　IaCセキュリティ (Infrastructure as Codeセキュリティ)：コードの構成ミスやセキュリティリスクを検知するソリューション   今やるべき「クラウドセキュリティ」対策 ここまでで、パブリッククラウドにおける セキュリティ対策のあるべき姿 (CTEM) と セキュリティ対策のソリューションや機能 (EASM・CNAPP・SSPM・DSPM) の概要をお伝えしてきました。CTEMに基づいて、それぞれのセキュリティ対策を実施することで、安全・安心なクラウド環境を維持することが可能となります。理想はすべてのセキュリティ対策をあるべき姿で運用することですが、それらを一度に適用するのが困難であることは、言うまでもありません。   ここでは、 クラウドセキュリティ対策を効果的に進める ための流れについて、ベストプラクティスをご紹介します。   IaaS・PaaSの場合 IaaS・PaaS環境の場合は、下記の対策順で適用することが効率的と考えます。 環境によっては、既に導入済のソリューション・機能がある場合や、導入予定のサービスが複数機能を有していることから、適用順が変わる場合があるかもしれません。ここでの説明は、あくまでも効率よく進めるための参考として捉えて頂き、状況に応じて柔軟に対応頂ければと思います。   運用フレームワーク CTEM  ソリューション・機能 CNAPP (CSPM、CWPP、CIEM、IaCセキュリティ) 、EASM、DSPM 対策順 EASM → CSPM → IaCセキュリティ → DSPM → CIEM → CWPP １. EASMの適用 最初にEASMを適用します。最初に適用することによって、攻撃者にとっての「入口」を早期に閉じることができ、外部攻撃に対する脆弱性が減少します。基本的に企業が有するドメインやIPアドレスなどの情報から「入口」を発見するため、SaaS環境を利用中の場合は、同時に適用できる場合があります。（使用するソリューションに依存） ２. CSPMの適用 次にCSPMを適用します。基本的なセキュリティ設定やポリシーの監視を行い、この段階でインフラストラクチャにおけるセキュリティのベースラインを確立します。 ３. IaCセキュリティの適用 IaCを利用している場合は適用します。IaCセキュリティを導入することで、一貫したセキュリティ設定が自動的に適用され、構成のドリフト(設定と実態で差異が生じること)を防止します。CSPMと同様にこの時点でインフラストラクチャのセキュリティベースラインを確立します。 ４. DSPMの適用 CSPM/IaCセキュリティの次に適用する事で、通信経路などのインフラストラクチャに関する基本設定が整った後となるため、効果的なデータセキュリティ対策を行うことが可能となります。 ５. CIEMの適用 続いて、CIEMを適用します。DSPMによって新たな重要データの発見や、その管理が確立した後に適用することで、合理的かつ適切にデータのアクセス権限管理が可能となります。 ６. CWPPの適用 最後にCWPPを適用します。CWPPは、リアルタイムでマルウェアや攻撃からの防御を提供するため、他のセキュリティ対策が確立された後に導入することで、脆弱箇所が限定されるなど、ワークロードを効果的に総合的に保護できます。   SaaSの場合 SaaS環境の場合は、下記の対策順で適用することが効率的と考えます。 基本的な考え方はIaaS・PaaS環境と同様ですが、SaaS環境の方が必要な機能が狭まるため、対応するソリューションはシンプルな構成で済みます。   運用フレームワーク CTEM ソリューション・機能 SSPM、EASM、DSPM 対策順 EASM → SSPM → DSPM １. EASMの適用 最初にEASMを適用します。EASMによって外部からの脅威を迅速に特定することで、IaaS・PaaS環境と同様に、攻撃者にとっての「入口」を早期に閉じることができるため、外部攻撃に対する脆弱性の減少が行えます。こちらもIaaS・PaaS環境を利用中の場合は、同時に適用できる場合があります。（使用するソリューションに依存） ２. SSPMの適用 次にSSPMを適用します。SSPMによってSaaSアプリケーションのセキュリティ設定を確立し、内部リスクを管理します。この時点でクラウド環境全体のセキュリティベースラインを確立します。環境によっては、EASMより先にSSPMを実施した方がリスク低減が図れる場合があります。 ３. DSPMの適用 最後にDSPMを適用します。SaaS環境における内部・外部のセキュリティ対策が整備された後に、データの保護、分類、監視を行うことで、効果的にデータセキュリティ対策が行えます。   IaaS・PaaS環境、SaaS環境の何れの場合においても、どのリスクに重きを置くかによって適用順を見直すことは必要です。また、何れの対応においてもCTEMフレームワークに沿って運用することで、効果的かつ強固なセキュリティ対策を実現することが可能となります。   まとめ クラウドコンピューティングの普及に伴い、クラウドセキュリティの重要性が高まってる一方で、パブリッククラウドには数百にも及ぶ多くのサービスが存在しているため、それらの 設定すべてを人の手で確認することは非常に困難な状況 となっています。 しかも、攻撃者による「脆弱性の発見」から「攻撃」までにかかる時間は年々短縮されているため、組織側の確認・対応サイクルを短くすることも求められます。 このような背景から、 効率よく運用する ためには 専用のソリューションがオススメです。 当社では、IaaS・PaaS環境のセキュリティ対策に適した「 EASM 、 CSPM 、 IaCセキュリティ 、 DSPM 、 CIEM 、 CWPP 」を全て備えた Prisma Cloud を提供しています。また、CSPMに関しては、簡単導入・簡単診断が可能な下記のサービスもありますので、ご興味ある方は是非、お気軽にお問い合わせください。 パブリッククラウドのセキュリティ設定を監視し異常を速やかに検知する、Prisma Cloudを活用した「 マネージドCSPMサービス 」 はこちら！ Smart One Cloud Security® パブリッククラウドのセキュリティ設定を診断/監視するマネージドCSPMサービスです。Palo Alto Networks社Prisma Cloud（CSPM機能）を使い易く、簡単に導入いただけます。 www.scsk.jp パブリッククラウドのセキュリティ設定に対する現状確認やリリース前診断が、お手軽に可能な「 スポット診断サービス 」 はこちら！ マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 マルチクラウド環境のセキュリティ設定リスクを手軽に確認可能なスポット診断サービスです。独自の診断レポートが、運用上の設定ミスや設計不備、クラウド環境の仕様変更などで発生し得る問題を可視化し、セキュリティインシデントの早期発見に役立ちます。 www.scsk.jp

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で自動展開することで、設定漏れをなくし、手動で１つずつVMを作成するよりも作業時間を短縮することができます。  AzureはAWSと違い参考になる記事が少なく、経験年数の少ない自分は周りの優秀な先輩に不明点を聞きながら構築を行いました。 Microsoft公式ページにもBicepを使用したVMのIaC構築のやり方は記載がありますが、Azure初心者がこんな感じで構築を行ったというのが別のAzure初心者の方の参考に少しでもなればうれしいです。 はじめに 今回は以下の構成を実現します。 リ ソースグループ/ VNET/サブネットは手動で予め作成した上 で、同じOSイメージを使用した VM1[yabu-vm-1] と VM2[yabu-vm-2] をBicepファイルを使い、デプロイします。 OSはWindows11を使用し、グループポリシーや言語設定などがVM1とVM2にも引き継がれていることがゴールとなります。   １．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が学習を進め、ラフな自然言語でも読み解いてくれて、 上手くフィルタしてくれるようになるまで成長してくれるといいです。