Taste of Tech Topics

Taste of Tech Topics

Acroquest Technology株式会社のエンジニアが書く技術ブログ

AWS CodeBuildでKarateを動かし、E2E/UIテストを自動化しよう

こんにちは、DevOpsエンジニアとして活動している横山です。

以前、本ブログ内で「KarateのDockerイメージを使用して、UIテストを自動化してみた - Taste of Tech Topics」を紹介しました。
今回は、E2Eテストを行う「Karate」をAWS上で実行し、テストを自動化する方法を紹介します。

クラウド上でKarateを実行することで、次のメリットが生まれます。

  • チーム全体でテスト結果を共有でき、修正が行いやすくなる
  • Gitへのプッシュをトリガーにテストを実行でき、問題に早く気づけるようになる

また、今回CodeBuildの実行環境として、AWSにより管理されているマネージド型Dockerイメージではなく、
カスタムDockerイメージを使用しましたが、その際の注意点も合わせて紹介します。

概要

本記事では、以下の内容について説明を行います。

  • AWS CodeBuildを用いたKarateの実行
  • Kareteのレポートを確認できるようにS3にアップロード
  • CodeBuildの実行環境としてカスタムDockerイメージを使用する際の注意点

Karate実行結果として以下のような結果がチーム全体で見られるようになります。
f:id:acro-yokoyama:20220225214142p:plain:w800
f:id:acro-yokoyama:20220225214152p:plain:w800

前提

Karateの詳細については、以下を参照ください。
qiita.com

全体構成

f:id:acro-yokoyama:20220213232615p:plain:w500

パイプラインの構築・実行

設定内容の流れとしては以下のようになります。

  1. buildspec.yml、Karateソースコードの準備
  2. CodeBuildの設定
  3. サービスロールの設定
  4. CodeBuild実行
  5. 結果確認

それでは、詳細です。

1. buildspec.yml、Karateソースコードの準備
以下のようなディレクトリ構成でKarate実行に必要なファイルをAWS CodeCommitにプッシュします。

karate-sample
├─ buildspec.yml  ・・・CodeBuildの定義ファイル
└─ src
    └─ test
        └─ ui
            └─ karate-git.feature  ・・・UIテストのシナリオファイル

buildspec.ymlの内容は以下になります。

version: 0.2
env:
  variables:
    # レポート配置用に作成したバケット名を指定
    REPORT_S3_BUCKET: karate-sample-bucket
phases:
  pre_build:
    commands:
      # 元のDockerイメージのENTRYPOINTで実行される想定だった処理を実行
      - echo Start Chrome
      - nohup /entrypoint.sh & # ★1
      # Karate実行ファイルをダウンロード
      - echo Download karate.jar
      - mkdir -p lib
      - curl -L -o ./lib/karate.jar https://github.com/karatelabs/karate/releases/download/v${KARATE_VERSION}/karate-${KARATE_VERSION}.jar
      # S3へのアップロードのために、AWS CLIをインストール
      - echo Install AWS CLI ...
      - curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
      - unzip awscliv2.zip
      - ./aws/install --bin-dir /usr/local/bin --install-dir /usr/local/aws-cli --update
  build:
    commands:
      # MavenによるKarateテスト実行
      - echo Karate Test...
      - java -jar lib/karate.jar -f cucumber:json src/test
  post_build:
    commands:
      # S3にレポートをアップロード
      - echo Uploading Karate results...
      - aws s3 sync ./target/karate-reports s3://${REPORT_S3_BUCKET}/karate/karate-reports --no-progress --delete

<注意点>
CodeBuildの環境イメージとして、AWSのマネージド型イメージではなく、カスタムイメージを使用する際、ENTRYPOINTはオーバーライドされるようです。
CodeBuild のDocker サンプル - AWS CodeBuild
今回利用する「ptrthomas/karate-chrome」イメージでは、ENTRYPOINTの処理にてKarate UI実行のために必要なプロセスを実行するため、そのままではKarate UIが実行できません。
そのため、本来ENTRYPOINTで実行したかった処理を、buildspec.ymlのpre_buildで実行するように記述しています。
(buildspec.ymlの★1の部分)

Karateのコードの詳細は割愛しますが、以下のコメントに書いたテストケースを実行します。

  • karate-sample/src/test/ui/karate-git.feature
Feature: GitHubのファイル確認

Background:
  # driver設定
  * configure driver = { type: 'chrome', start:false, headless: true, addOptions: ['--window-size=1920,1080']}

  # UI操作開始
  Given driver 'https://github.com/karatelabs/karate'
  * screenshot()

Scenario: land on the karate github page, and search for a file

  # 「Go to file」をクリックしてファイル一覧に遷移する
  When click('{a}Go to file')
  Then waitForUrl('karate/find/master')

  # 検索エリアに「karate-logo.png」を入力する
  And waitForEnabled("input[name=query]").input('karate-logo.png')
  * delay(500)
  * screenshot()
  
  # 1件以上ヒットすることを検証する
  Then assert locateAll("ul#tree-browser li[role=presentation]") > '#[1]'

2. CodeBuildの設定

AWSコンソールのCodeBuild画面から、「ビルドプロジェクトを作成する」をクリックし、以下のように設定して作成します。
(デフォルトから変更する箇所のみ記載しています。)

<注意点>
実行環境として指定するDockerイメージが、DockerHubなどの公開されているイメージの場合、CodeBuildでのダウンロード制限に引っかかる場合があります。
その場合は、以下を参考にするか、ECRにイメージをプッシュし、ECRから取得(プル)する設定にすることで対処可能です。
CodeBuild の「イメージ設定のプルエラー: toomanyrequests」エラーを解決する

①CodeBuildのビルドプロジェクト名を入力(任意)
f:id:acro-yokoyama:20220212165226p:plain:w650

②テストコードをプッシュしたリポジトリを指定
f:id:acro-yokoyama:20220212165239p:plain:w650

③CodeBuild上でのKarate実行環境のDockerイメージ、実行時に利用する環境変数、CodeBuildに適用するロールを設定
f:id:acro-yokoyama:20220212165246p:plain:w650
f:id:acro-yokoyama:20220213230959p:plain:w650
f:id:acro-yokoyama:20220212165302p:plain:w650

④CodeBuildで使用するbuildspecファイルを指定
f:id:acro-yokoyama:20220212165312p:plain:w650

⑤CloudWatch Logsへのログ出力設定を指定
f:id:acro-yokoyama:20220212174946p:plain:w650

3. サービスロールの設定

作成されたサービスロールに対し、以下のポリシーを追加します。

  • s3:ListBucket
  • s3:PutObject
  • s3:DeleteObject

※リソースは、レポート配置用のバケットを指定

4. CodeBuild実行
作成したCodeBuildのプロジェクトを開き、「ビルドを開始」から実行できます。

5. 結果確認

CodeBuildでビルドを実行すると、Karateテスト実行後に、レポートファイルがS3の指定のバケットにアップロードされます。
Karateレポート出力用のバケットの中の、以下のファイルをブラウザで開くことで、キャプチャも含めたレポートを確認することができます。

  • karate/karate-reports/karate-summary.html

f:id:acro-yokoyama:20220225214142p:plain:w800
f:id:acro-yokoyama:20220225214152p:plain:w800

まとめ

今回は、AWS CodeBuildを用いたUIテストを含んだKarate実行と、S3へのレポートファイルのアップロードについて説明しました。
これにより以下のようなメリットが得られます。

  • Karateを利用することで、ユースケースを意識したシナリオテストを実施しやすい
  • E2Eテストを自動化することで、リグレッションテストの手間を大幅に削減でき、変更の影響の検知を素早く行える
  • 画面キャプチャもレポートに組み込むことができ、テストの結果やエラーの内容をすぐに確認可能

チームの中で、テスト実行を継続して実行することで、
リリースサイクルが高速化する中でも、品質向上につながると思いますので、参考にしていただけたらと思います。

それでは。

Acroquest Technologyでは、キャリア採用を行っています。

  • ディープラーニング等を使った自然言語/画像/音声/動画解析の研究開発
  • Elasticsearch等を使ったデータ収集/分析/可視化
  • マイクロサービス、DevOps、最新のOSSを利用する開発プロジェクト
  • 書籍・雑誌等の執筆や、社内外での技術の発信・共有によるエンジニアとしての成長

 
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
www.wantedly.com
www.wantedly.com

AWS MLOps Workload Orchestrator で機械学習モデルのデプロイ/検証の自動化を体感してみた


こんにちは、DevOpsチームの@buzz_tkcです。
最近枕を「ヒツジのいらない枕」に買い換えました。2020年にクラウドファンディングで話題になっていた時から、キャッチーなネーミングと興味がそそられるフォルムが気になっていたはいたのですが、やっと重い腰を上げて買い換えました。弾力があり高さのある枕が好みの自分にとてもフィットしており、おかげさまで睡眠が捗っております。

さて、今回は AWSが公開している「MLOps Workload Orchestrator」を、試してみたいと思います。

機械学習プロジェクトにおいて、以下のような課題に直面したことがある人は多いのではないでしょうか?

  • 学習リソース不足
    • GPUマシンが足りず、並列実験ができない、、、
  • ローカルで検証したモデルを本番環境へ適用するのに時間がかかる
    • デプロイの自動化が大変、、、
  • 実験が再現できず、品質保証ができない
    • 何個か前の精度が良かった学習の再現が難しい、、、

そのような際に、MLOpsのプラクティスが有効とされていますが、自分も機械学習エンジニアではないため、何をどのようにすれば良いのか、イメージを持てていなかった部分があるので、「MLOps Workload Orchestrator」を試してみて、理解を深めていきたいと思います。

MLOps とは?

MLOpsとは、「機械学習チーム(Machine Learning)/開発チーム(Developers)」と「運用チーム(Operations)」がお互いに協調し合うことで、機械学習モデルの実装から運用までのライフサイクルを円滑に進めるための管理体制(機械学習基盤)を築くこと、またはその概念全体を指します。まさにDevOpsの機械学習版ですね。(MLOps = ML + Dev + Ops

Wikipediaにも、DevOpsの概念がベースとなって、MLOpsが生まれたと書かれていますね。

ソフトウェア開発ライフサイクル全体におけるワークロードの管理は、従来からDevOpsの概念があった。機械学習プロジェクトにDevOpsを適用した場合、モデルトレーニング等を含むのCI/CDのプロセス管理やデータサイエンティストとデータエンジニアの職種の役割分担など多数の機械学習特有の課題を考慮する必要が生まれた。その結果DevOpsをベースに機械学習プロジェクトに合理化された手法がMLOpsとして概念化された。

MLOPs Wikipedia


機械学習で精度の高いモデルを作るためには、多くの時間を試行錯誤に費やしモデルを育てていく必要があります。しかし実際には、動作環境の構築、システム全体の開発など、モデル作成以外でもやるべきことが多く、モデル作成に時間を多く割けないことが多いです。MLOpsを実践し、機械学習ワークフローの自動化・効率化を進めていくことで、良いモデルを育てるというコアな部分に、多くの時間を費やすことができるようになります。


AWS MLOps Workload Orchestrator とは?

MLOps Workload Orchestrator」は、AWS機械学習サービスとサードパーティーサービスの機械学習パイプラインを管理するためのフレームワークで、機械学習モデルの運用向けにアーキテクチャのベストプラクティスを合理化および強制するのに役立ちます。

具体的には、このサンプルテンプレートを使用し、トレーニング済みのモデル(自分で用意する)をデプロイすることで 、モデルのデプロイや運用/監視を簡単に実現することができます。モデルのデプロイや運用/監視を自動化することで、モデルの検証や更新のサイクルを高速に回すことができ、プロジェクト全体の俊敏性と効率を上げることができます。
aws.amazon.com

AWS MLOps Workload Orchestrator を使ってみる

このサンプルテンプレートでは、同アカウントへのデプロイと、マルチアカウントへのデプロイと大きく二種類対応しています。今回は同アカウントへのデプロイを扱います。アーキテクチャは以下になります。

やることとしては、以下の3つです。

  1. CloudFormationテンプレートを実行してスタックを作成
    • 通知用のメールアドレスを入力するだけでスタックを作成できます。
  2. パイプラインをプロビジョニングして機械学習モデルをデプロイ
    • パラメータを指定して、APIを実行する or Code Commitのルート直下にmlops-config.jsonをコミットすることで、パラメータによって指定されたCloudFormationが実行されます。その後、ワークフローに応じたCode Pipelineが作成・実行され、必要なリソースの作成と、モデルのデプロイが行われます。
  3. モニタリング用パイプラインのプロビジョニング
    • 2.の実行が完了し、機械学習モデルがエンドポイントにデプロイされている状態で、実行する必要があります。


学習(モデルの作成)自体はスコープ外なので、事前準備として、学習済みモデルが必要です。今回は、AWSが公開している公式サンプルを実行して用意しました。

1. CloudFormationテンプレートを実行してスタックを作成

CloudFormationのManagement Consoleに移動し、CloudFormationテンプレートから、「mlops-workloadorchestrator-single-account-framework.template」を選択します。
以下のパラメータの中から、必須項目の通知用メールアドレスを入力して、スタックを作成します。

この段階で、赤枠の部分が作成されます。

2. パイプラインをプロビジョニングして機械学習モデルをデプロイ

続いて、機械学習モデルデプロイのワークフローを実行します。Code Commitのレポジトリルート直下にmlops-config.jsonをコミットするか、APIにリクエストを送ることで、ワークフローを実行できます。今回はAPIへのリクエストを試してみます。

先程実行したCloudFormationで「/provisionpipeline」と「/pipelinestatus」二つのエンドポイントが作成されているので、「/provisionpipeline」に対して、学習済みモデルをエンドポイントにデプロイするためのリクエストを投げます。「/pipelinestatus」は「/provisionpipeline」実行後、パイプラインのステータス確認用として使用できます。

EndPoint:/provisionpipeline
Method:POST
Body:

{
"pipeline_type" : "byom_realtime_builtin", # Sage Makerが用意しているビルトインアルゴリズムを使用してのリアルタイム推論を行うパイプラインをプロビジョニング
 "model_framework": "xgboost", # モデル作成時に使用したフレームワーク
 "model_framework_version": "1", # フレームワークのバージョン 
 "model_name": "my-model-name", # Amazon SageMaker modelや、エンドポイント作成時に使用されるモデル名
 "model_artifact_location": "path/to/model.tar.gz", # 事前に学習し、S3に格納しておいたモデルパス
 "data_capture_location": "<bucket-name>/<prefix>", # エンドポイントへの推論結果のデータキャプチャを保管S3へのパス
 "inference_instance": "ml.m5.large", # エンドポイントで使用するインスタンスタイプを指定
 "endpoint_name": "custom-endpoint-name" # エンドポイント名を指定
}

「byom_realtime_builtin」用のパイプラインがプロビジョニングされ、エンドポイントが立ち上がり、推論を行うことができるようになりました。簡単に推論を行える環境が用意できるので、非常に便利ですね!

3. モニタリング用パイプラインのプロビジョニング

さきほど作成したエンドポイントのモニタリングを行うワークフローを実行し、モニタリング用のパイプラインをプロビジョニングします。エンドポイントにデプロイされたモデルに対し、ベースとなるデータセットを実行し、実際に飛んできている推論データとの統計情報を可視化することで、モデルがビジネスゴールを満たしているかどうかの指標を得ることができます。

EndPoint:/provisionpipeline
Method:POST
Body:

{
 "pipeline_type" : "byom_data_quality_monitor", # 推論やテストデータの評価を行うパイプラインをプロビジョニング
 "model_name": ""my-model-name"", # モデル名(リソース作成時に命名として使用されます)
 "endpoint_name": "xgb-churn-prediction-endpoint", # 評価対象のエンドポイント名
 "baseline_data": "path/to/data_with_header.csv", # S3に格納してある評価用データ(ヘッダー付きcsvファイル)へのパス
 "baseline_job_output_location": "<bucket-name>/<prefix>", # モデルデータ評価を行うジョブ結果を格納するS3へのパス
 "data_capture_location": "<bucket-name>/<prefix>", # エンドポイントへの推論結果のデータキャプチャを保管S3へのパス
 "monitoring_output_location": "<bucket-name>/<prefix>", # モニタリング結果のアウトプットを格納するS3へのパス
 "schedule_expression": "cron(0 * ? * * *)", # 評価ジョブ実行タイミングのスケジューリング
 "instance_type": "ml.m5.large", # 評価ジョブ実行で起動するインスタンスタイプ
 "instance_volume_size": "20", # 評価ジョブ実行で使用するボリュームサイズ
 "baseline_max_runtime_seconds": "3300", # 評価ジョブの起動時間上限
 "monitor_max_runtime_seconds": "3300" # モニタリングジョブの起動時間上限
} 

モニタリングの結果を確認します。 Sagemaker Studio左メニューから SageMaker resourcesを選択 >プルダウンからエンドポイントを選択 >エンドポイント名をダブルクリック >Monitoring job historyタブを選択 >「issue found」をダブルクリックして下さい。


続いて、「View Amazon SageMaker notebook」リンクをクリック > 「Import notebook」ボタンをクリックすることで、モニタリング結果を可視化してくれるnotebookが実行できるようになりました。

notebookを実行することで、モニタリング結果の可視化を行うことができました。グラフのところで、collectedが推論で飛んできているデータで、baselineが事前にベースとして用意していたデータです。データの差分や、偏り、傾向等が、感覚ではなく視覚的に確認できるのは嬉しいですね!

利用してみての所感

AWS MLOps Workload Orchestrator」を利用してきましたが、学習したモデルを簡単にデプロイできたり、状態を可視化できたりと非常に便利でした。特に、モニタリングのワークフローでは、データセットやモデルの統計情報を可視化することで、モデルがビジネスゴールを満たしているかを確認することが容易にできるので、効果的にモデルを育てていくというライフサイクルを回すことができそうだと感じました。

後は、一般的なMLOPsだと、

  • モデルの精度を評価(テスト)して、承認者が精度で問題ないことを確認した後、当該モデルをデプロイする
  • 継続的にモデルの精度劣化等をモニタリングして、必要であれば再学習を行う

ということもよくやるみたいですね。

どこまで自動化・効率化していくのかは、プロジェクトの目的や規模などによって変わるとは思いますが、今回学んだことを活かして、自分達の組織やプロジェクトに合ったMLOPsというものを考えていきたいと思います。

それでは。

Acroquest Technologyでは、キャリア採用を行っています。

  • ディープラーニング等を使った自然言語/画像/音声/動画解析の研究開発
  • Elasticsearch等を使ったデータ収集/分析/可視化
  • マイクロサービス、DevOps、最新のOSSを利用する開発プロジェクト
  • 書籍・雑誌等の執筆や、社内外での技術の発信・共有によるエンジニアとしての成長

 
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
Kaggle Grandmasterと話したいエンジニアWanted! - Acroquest Technology株式会社のデータサイエンティストの採用 - Wantedlywww.wantedly.com

Kaggleで開催された「Sartorius - Cell Instance Segmentation」でゴールドメダルを獲得しました

皆さんこんにちは。
@tereka114です。

昨年の年末までKaggleで開催された「Sartorius - Cell Instance Segmentation」に取り組み、4位を獲得しました。
本記事では、簡単にそのサマリを掲載します。

コンペティション概要

画像の中から、脳の試験細胞を見分けるコンペティションです。
具体的には細胞を個別にSegmentationする所謂、Instance Segmentationを行うコンペティションです。
Detectionは物体の領域に矩形を付けるものになりますが、Instance SegmentationはDetectionした上で、矩形の中の前景を抽出します。

投薬の反応によって、神経病(アルツハイマーなど)の病気に対する創薬に役立てるようですが、この確認に非常に手間がかかっているそうです。
そのため、セルのInstance Segmentationを試み、反応を自動的に判断するのに役立つコンペが開催されました。

www.kaggle.com

細胞のサンプルは次の通りです。

f:id:tereka:20220129215210j:plain:w720
コンペティションで扱う細胞画像のサンプル

※本可視化には次のNotebookの画像を利用させていただいています。
Sartorius Cell Instance Segmentation - EDA | Kaggle

このコンペティションに参加した理由は次の通りです。

  • 最近、Instance Segmentationのコンペティションは開催されておらず、興味があったこと。
  • 外部データや正確なラベルがないSemi-Supervised Learning用のデータセットが配布されており、データに工夫の余地が多くあり、面白そうだと思ったこと

今回のコンペティションで難しいポイントは次の通りです。

1. 細胞の数
Detection/Instance Segmentationの論文の多くで利用されているCOCOのデータセットの1画像中最も多いオブジェクト数は92です。
しかし、今回の細胞データでは細胞の種類(astro, shsy5h, cort)によって異なりますが、最大700をも超えるオブジェクト数が存在します。
そのため、COCOのデータで最適化されたモデルでは不十分で、多くの物体を検出するには、パラメータの一部を修正する必要がありました。

2. データセット
このコンペでは、Kaggleで外部データであるLive CellとSemi-supervised learningで利用するデータセットが用意されていることが特徴的です。
LiveCellはコンペティションで提供されているものがshsy5hと呼ばれる細胞の種類以外は別のものではありますが、Segmentationのアノテーションがされています。
また、Semi-Supervised learningの画像には、細胞の種類は提供されていますが、マスク情報は存在しないため、そのまま利用できません。

ソリューション

全体の流れ

チーム全体の詳細はこちらに記載しています。
www.kaggle.com

f:id:tereka:20220129201318p:plain:w720
ソリューションの全体図

全体の流れは次の通りです。

  • Instance Segmentitonで得られた結果に基づいて、細胞全体の画像を分類する。(単純に分類されたセルの多いものを採用)
  • 分類した細胞ごとに別々のInstance Segmentationのモデルを用いる。
  • 細胞ごとにアンサンブルやSegmentation Modelを用いたPost Process、Fix Overlap処理を行う。

※図中のshsy5y, astro, cortは細胞名由来の名称

Fix Overlapは、本コンペティションでは、提出形式としてセルのマスクの重複を許容していないため、その対応の処理です。
(細胞Aと細胞Bで同じPixelを指定できないので、片方にする必要がある。)
また、細胞に関して後処理に違いがあるのは、各処理を適用した際にCV/LBを見て精度が上がったものと下がったものがあり、その違いが後処理の内容に反映されています。

モデル作成

Classification/セルのマスク取得にはInstance Segmentationのモデルを作成しました。
具体的には次の手順を踏んでいます。

  • モデルはCBNetV2 + CascadeRCNNやResNeXt101+Hybrid Task Cascadeを利用
  • それぞれの細胞ごとにモデルとハイパーパラメータ群をチューニング
  • Semi-Supervised Learningのデータに学習済のモデルでラベルを付与(後述)
  • 事前学習として、Live Cellを学習した後、Semi Supervised Learningのデータで再学習(後述)

CBNetV2 + CascadeMaskRCNN(CRNN)とResNeXt101 + Hybrid Task Cascade(HTC)を用いたのは、最終的に精度が良かったためです。
他にもDetectors + HTC、ResNet50 + HTC、さらにはSwin Transformer + CRNNなど様々なモデルを試していましたが、アンサンブルなどに利用しても精度向上に貢献しませんでした。

チーム全体の実装はDetection/Instance Segmentationのフレームワークmmdetectionを利用しました。
設定のみで様々なアルゴリズムの利用ができる&学習済モデルが多いので、個人的にもYoloX/YoloV5を利用しないときにはmmdetectionをよく利用します。

今回は、COCOでSoTAを達成した物体検出の方式であるCBNetV2を利用したかったため、まだ実装されていない既存のmmdetectionに対してCBNetV2が追加されたリポジトリを用いました。

github.com

ハイパーパラメータ群のチューニング

mmdetectionは様々なモデルのconfigと学習済モデルが配布されています。
SoTAの計測がCOCOである論文がほとんどであるため、mmdetectionの物体検出パラメータはCOCOに最適化されています。
しかし、COCOとはデータセットの傾向が大きく異なるため、ハイパーパラメータを今回のデータセットに向けて大きく変更すると精度が向上しました。
具体的には、次のパラメータを変更して実行していました。
COCOと比較して、オブジェクト数が多いので、NMSでフィルタリングする数をCOCOよりも緩めると、精度向上します。

rpn_proposal.nms_pre=4000,
rpn_proposal.nms_post=4000,
rpn_proposal.max_per_img=4000

anchor_generator.ratios=[0.25, 0.5, 1.0, 2.0, 4.0]

外部&追加データの検討

先にも簡単に書きましたが、外部データであるLiveCellと追加データとしてSemi-Supervised Learningを行うためのデータが配布されていました。
これらのデータを有効に利用すると精度向上する可能性がありました。

Semi-Supervised Learningのデータは細胞の種類が記載されたCSVがありますが、マスクのアノテーションは存在していません。
学習にこのデータを利用する方法としていくつかありますが、チームでは学習モデルから予測した結果であるPseudo Labelingをすることで、学習に使えるようにしました。

1. LiveCell + Trainingデータを用いて学習したモデルを利用して、Semi-Supervised Learningを推論し、アノテーションする。
2. LiveCellで事前学習したモデルに対して、Semi-Supervised Learningのアノテーションした画像を学習する。
3. 最後にTrainingのデータでFinetuneする。

2で作成されたラベルはノイズが含まれているので、その影響を修正する役割として3を実行しました。
Semi-Supervised LearningとTrainingのデータを同時に学習させた場合と比較して、2,3のステップを踏むほうが精度が向上します。

最後に

Instance Segmentationは検討する内容も多く、コンペ終了後に他チームの共有されたソリューションを振り返ると様々な問題の解き方がありました。
これをうまく業務にも応用していきたいと考えています。

Acroquest Technologyでは、キャリア採用を行っています。


  • ディープラーニング等を使った自然言語/画像/音声/動画解析の研究開発
  • Elasticsearch等を使ったデータ収集/分析/可視化
  • マイクロサービス、DevOps、最新のOSSを利用する開発プロジェクト
  • 書籍・雑誌等の執筆や、社内外での技術の発信・共有によるエンジニアとしての成長

 
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。

Kaggle Grandmasterと話したいエンジニアWanted! - Acroquest Technology株式会社のデータサイエンティストの求人 - Wantedlywww.wantedly.com

AWSでお手軽時系列データの異常検知 ~Lookout for Metricsを試してみた~

はじめに

機械学習アプリケーションエンジニアの@yktmです。
本記事では、2020年12月のAWS re:Inventでアナウンスされ、2021年3月にGAとなった、
Amazon Lookout for Metricsを、実際に利用してみて、使い勝手を確認してみたいと思います。

Amazon Lookout for Metricsの特徴、実際の使い方をお伝えできればと思います。

Amazon Lookout for Metricsとは

概要

Amazon Lookout for Metricsは、機械学習を使った時系列データ分析を、機械学習の知識なしに簡単に始められるサービスです。

例えば、ECサイトトラフィックに発生した異常な外れ値を検知し、アラートを出す、という仕組みを簡単に構築することができます。

特徴

Lookout for Metricsの大きな特徴は、3つあります。

  • 機械学習による分析
  • Lookout for Metricsは機械学習に基づく分析を、機械学習の知識なしに使える点が最大の特徴です。
  • 柔軟なデータ連携
  • 分析対象とするデータは、S3、RDSなどのAWS関連サービスのほかに、
    SalesforceGoogle Analytics、Zendeskなどからシームレスに接続できます。
  • アラートのカスタマイズ性
  • Amazon SNSAWS Lambdaはもちろん、Slack、Datadog、WebHookなどに対しても、
    カスタマイズしたアラートを送信することができます。

    分析としては、複数のパラメーターの関連を見た異常検知や、複数項目を同時に異常検知することも可能な点が嬉しい点です。
    例えば、地域と時間帯から店舗収益の異常を検知したり、アクセス数と収益を同時に異常検知する、といったことができます。

    Amazon Lookout for Metricsを使った分析

    次に、Lookout for Metricsを使い、いかに手軽に分析できるかを見ていきたいと思います。

    検証データセット

    利用するデータセットは、AWS公式Githubで提供されているE-Commerceのサンプルデータを利用していきます。 zipファイルダウンロード・解凍し、backtest/input.csvが利用するファイルです。

    CSVの中身は、プラットフォームと利用国ごとの、閲覧数・収益を1時間おきに記録した履歴データになります。 期間は、2021/01/01から2021/09/30までです。

    カラムは以下の5つとなっています。

    カラム名 説明
    platform 利用デバイスと利用媒体 (pc_web, mobile_web, mobile_appの3パターン)
    marketplace 利用国 (us, uk, de, fr, es, it, jpの7パターン)
    timestamp タイムスタンプ
    views 閲覧数
    revenue 収益

    このデータから、閲覧数と収益の異常を見つけ、どのプラットフォーム・利用国で、何時に異常が発生したかを分析していきたいと思います。

    設定手順

    以下の順に設定していきます。
    1. Detector(分析器)の作成
    2. データセットを作成 / Detectorの有効化
    3. 分析結果の確認
    4. アラート設定

    1. Detector(分析器)を作成

    AWS コンソールで、Amazon Lookout for Metricsを開きます。 Create Detectorを押下し、分析器の作成画面を開きます。

    f:id:yktm31:20210930064417p:plain:w700

    分析器の作成画面では、
    ①分析器の名前
    ②分析のインターバル
    を設定します。

    分析のインターバルとは、分析の細かさを示します。 ここでは、1 hourを指定しています。
    1 dayにすれば1日単位で粗く分析でき、10 minuteにすれば10分単位の細かい分析が可能になります。
    後述しますが、与えられたデータを学習用とテスト用に分けて検証するBacktestモードでは、interval x 285(1dayなら285日分)のデータが必要になる点は注意が必要です。 分析のインターバルによって、利用料金が変動することはありません。(コストについては記事後半で解説しています。)

    f:id:yktm31:20210923172703p:plain:w700

    設定が完了したら、「Create」を押します。

    2. データセットを作成 / Detectorの有効化

    続いて、データセットを作成します。ここで設定するのは、2つの項目です。
    ① 分析対象のデータソース
    ② 分析対象のフィールド

    まず始めに、「Add a dataset」からデータセット作成画面を開きます。

    f:id:yktm31:20210923173346p:plain:w700

    データセット作成画面は、以下のようになっています。

    f:id:yktm31:20211115000438p:plain:w700 f:id:yktm31:20211128111651p:plain:w700 f:id:yktm31:20211115000528p:plain:w700

    設定が必要な項目は、
    ①データセットの名前
    ②分析対象データソースの指定
    ③分析対象データソースのフォーマット設定
    ④認証情報
    です。

    ここでは、Amazon S3上のCSVファイルを分析対象データソースとしています。

    また、分析のモードが2つ選択できます。 モードの違いによる、コストのかかり方に違いはありません。

    モード 説明 用途
    Backtest 指定したデータを学習用と検証用に分割して検証を行う。
    古い70%が学習に利用され、最新の残り30%をバックテストで利用(※interval x 285 のデータが必要になる。)
    検証
    Continuous 新しく取り込まれるデータを利用し、推論精度を向上させていく。 運用

    続いて、分析対象のフィールドを設定します。

    f:id:yktm31:20211114235934p:plain:w700

    「Measure」で指定するのは、異常を検知する対象のフィールドです。 「Demensions」で指定するのは、Measureをどのフィールドでカテゴライズするか、というものです。 例えば、プラットフォーム毎の閲覧数を見たい場合、「Measure」に「views(閲覧数)」を、「Demensions」に「platform(利用デバイス/利用媒体 )」を指定します。

    最後にTimestamp情報がどういった形式で表されているかを指定します。

    「Next」を押すと、設定情報確認画面が出てきます。

    「Save and active」を押すと、データセットが作成され、分析が始まります。

    f:id:yktm31:20210923175757p:plain:w700

    3. 分析結果の確認

    「View annomalies」から異常を確認してみましょう。

    f:id:yktm31:20210923180648p:plain:w700

    発生した異常は、以下のようにリストで表示されます。

    このリストは、どのメトリクスに、何時に異常が発生したかのリストです。 「Severity score」でソートすれば、異常度の大きさで並び替えできます す。「Time detected」でソートすれば、異常が発生した時間でソートできます。

    f:id:yktm31:20211128021445p:plain:w700

    そのうちの一つを開くと、以下のような画面になります。

    f:id:yktm31:20211128015108p:plain:w700

    Anomaly overviewを見ると、2021/09/04 00:00(GMT時間)に発生した異常の詳細であることがわかります。

    続いて、Dimension valuesを確認します。 Dimension valuesは、検知した異常に対し、どのDimensionの影響が大きかを表しています。

    ここでは、以下のような影響度になっています。

    Dimension Dimensionの値 影響度
    Marketplace De(ドイツ) 71%
    Marketplace Uk(イギリス) 28%
    Platform Mobile_web 100%

    ここから、Marketplaceが「De(ドイツ)」Platformが「Mobile_web」のrevenue(収益)に、より大きな異常が出ていることが読み取れます。

    Metric graphsには、それぞれの異常箇所がグラフとして表示されます。
    まず、9/3の21:00 ~ 9/4の1:00の間(赤枠部分)で異常が検知されていることが確認できます。 「De(ドイツ)のMobile_web」と、「Uk(イギリス)のMobile_web」を比較すると、確かに、「De(ドイツ)のMobile_web」の収益が0になっており、異常度が大きいと言えそうです。

    もし、異常と検知された部分が、予想の範囲内である場合、「Is this relevant?」(緑枠部分)でラベル付けしてアルゴリズムにフィードバックすることで、異常検知の精度を向上させることが可能です。

    4. アラート設定

    最後に、アラートを設定しましょう。 設定項目は、
    ①アラート名
    閾値(threshold)
    ③アラートチャンネル
    です。

    f:id:yktm31:20210923181010p:plain:w700

    アラートチャンネルは、Amazon SNSの他に、AWS Lambda、Skack、Webhooksなどが選択できます。

    使用感

    以上で、Lookout for Metricsを使った分析は完了です。使用感として、使いやすい点と注意点をまとめてみます。

    使いやすい点

  • Lookout for Metrics が、複数のアルゴリズムから適切なものを自動で選択してくれる
  • アルゴリズムを意識することなく使えるので、機械学習の知識・経験がない人にとっても使いやすいと思いました。
  • 異常のデータがなくても異常を検出できる
  • 教師なし学習という方法で異常データなしで分析を開始でき、データの準備が楽なところは嬉しいですね。
  • 誤判定を、アルゴリズムに簡単にフィードバックできる
  • 検知した異常を簡単に再ラベリングでき、アルゴリズムを再学習できるところは、運用しながら精度を向上できる、嬉しい部分だと感じました。

    注意が必要な点

  • 全体の傾向が見れない
  • 例えば、過去1ヶ月に起きた異常を、まとめて一つのグラフに表示する、という使い方はできないようです。今回のデータでは、異常発生から遡って約72時間分のデータのみ見ることができました。
  • 複数のMesureの異常を同時に見ることができない
  • 複数の分析軸(=Dimension)から異常を分析できることに対し、複数の分析対象(=Mesure)を同時に比較することはできないようです。
  • 設定の変更が柔軟にできない
  • 分析の時間単位(Interval)や、Measure/Dimensionを後から変更できない点は、注意が必要だと思いました。設定を変更するためには、新たに分析器を1から作成する必要があるため、とにかくランダムにパラメータを変えるという使い方は避けた方がよいと思いました。

    コスト

    ここまで、分析が簡単にできることは分かりましたが、実際使うとなると、利用コストが気になるところかと思います。

    Lookout for Metricsは従量課金制で、メトリクスと呼ばれる単位で課金が発生します。

    メトリクスは、Measureの数 × Demensionsがもつユニークな値の数から算出されます。 例えば、1時間あたりのオンライン注文数、1日あたりのウェブサイト訪問数などが例として挙げられています。

    したがって、ユニークな値を大量に持つ可能性があるフィールドを「Demensions」に設定すると、メトリクスが大きくなり料金が肥大化することに繋がります。 この点は注意が必要です。



    ここで、今回実施した分析を例にコスト試算してみたいと思います。

    まず、「Measure」には、views(閲覧数)とrevenues(収益)を指定したので、Measureの数は2です。

    続いて、「Demensions」には、platform(利用デバイス)とmarketplace(利用国)を指定しました。 それぞれのユニーク値は以下のようになっています。

    カラム名 ユニーク値 カウント
    platform pc_web, mobile_web, mobile_app 3
    marketplace us, uk, de, fr, es, it, jp 7

    上記より、Demensionsには3 x 7 = 21個のユニーク値が存在します。

    つまり、Measureの数 × Demensionsがもつユニークな値の数という式に当てはめると、 2 Measure × 21 Demensions = 42メトリクス となります。

    以下の料金表に基づき、最初の1000メトリクスでは 42 * 0.75USD = 31.5USD(約3500円) が1ヶ月ごとに課金される計算になります。

    f:id:yktm31:20211001072831p:plain:w700
    (出典: 料金 - Amazon Lookout for Metrics | AWS)

    請求ダッシュボードを見ても、計算通りの課金が発生していました。

    メトリクスごとの課金となるため、BacktestモードとContinuousモードでの課金体系に差分はありません。 1ヶ月動かし続けても、1時間だけ動かしても、料金は変わらない点は注意が必要です。
    また、検出された異常の保持、閲覧による課金は発生しません。 他方、Amazon SNS によるカスタムアラートや AWS Lambda を利用したカスタムアクションには別途課金が発生します。

    コスト試算には、AWS公式Githubで提供されているJupyter Notebookを利用できます。

    さいごに

    以上で、Lookout for Metricsを使った分析は完了です。

    時系列データの異常を検知したいけど、難しいことはしたくない、というニーズに応えるサービスだと思いました。 機械学習を利用した時系列分析が、ここまで簡単に利用できるのは、Lookout for Metricsの魅力ですね。

    今回は深く触れませんでしたが、データ連携の容易さやアラートのカスタマイズ性も、実運用するにあたり重要になってくるポイントかと思います。

    Acroquest Technologyでは、キャリア採用を行っています。
    • ディープラーニング等を使った自然言語/画像/音声/動画解析の研究開発
    • Elasticsearch等を使ったデータ収集/分析/可視化
    • マイクロサービス、DevOps、最新のOSSを利用する開発プロジェクト
    • 書籍・雑誌等の執筆や、社内外での技術の発信・共有によるエンジニアとしての成長
      少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。 www.wantedly.com

    KarateのDockerイメージを使用して、UIテストを自動化してみた


    こんにちは、DevOpsチームの@buzz_tkcです。
    最近、数分のあいだに複数の筋トレとインターバルを繰り返し、高い脂肪燃焼効果が得られると注目を集めている、「HIIT(High-intensity interval training)」トレーニングにハマっています。

    数分のトレーニングですが、かなり効果があるので、運動不足でお困りの方に、おススメです。


    さて、今回もKarateに関する記事です。Karateに関する記事も、増えてきました。


    テスト自動化も、準備ができた後は良いのですが、テスト自動化の環境を作ること自体、なんだかんだいって手間がかかりますよね。
    Karateでは、Dockerコンテナの形式でUIテストを実行できる環境が提供されているようなので、今回はそれを利用して、Webアプリのテストの自動化を行ってみたいと思います!


    f:id:buzz_tkc:20211002192627p:plain

    Karateとは?

    Karateは、REST-API/GraphQL/WebSocket/負荷テスト/E2Eテストなどに対する統合テスト自動化フレームワークです。
    Gherkin形式の自然言語に近い内容でテストをわかりやすく作成することができます。


    こちらの@takanorigさんのQiita記事に詳しく書いてあります。
    qiita.com


    個人的に感じているメリットとしては、

    • シナリオベースのテストが簡単にかける
    • 学習コストが低い
    • REST-API、GraphQL、WebSocketや、負荷テスト、UIテストと幅広く対応できる

    といったところです。

    Karate+Dockerを利用したUIテスト

    テストシナリオの準備

    今回は、KarateのGitHubで公開されているUIテストのサンプルをコンテナ上から実行します。

    構成は以下になります。google.featureが、実行するシナリオです。

    .
    ├── pom.xml
    ├── src
    │   └── test
    │       └── java
    │           ├── logback-test.xml
    │           └── web
    │               ├── GoogleRunner.java
    │               └── ★google.feature

    karate-chrome コンテナの起動

    まず初めにカレントディレクトリを、コンテナ上の/src配下にマウントする形で、Karateコンテナを起動します。

    docker run -itd --name karate-chrome -p 9222:9222 --rm -p 5900:5900 -e KARATE_SOCAT_START=true --cap-add=SYS_ADMIN -v "$PWD":/src ptrthomas/karate-chrome


    起動したコンテナの特徴は、以下になります。

    • VNC(Virtual Network Computing)サーバーを起動し、 5900ポートを公開し、Chromeにアクセスできる。
    • Chrome DevToolsには、9222ポートでアクセスできる。
    • テストの録画記録は、 /tmp/karate.mp4に保存される。
    • テスト終了後、テストの録画記録が埋め込まれたHTMLレポートが確認できる。


    それでは、VNCにて起動したChromeにアクセスしてみます。

    open vnc://localhost:5900


    Windowが立ち上がり、パスワードを求められるので、「karate」と入力し、サインインします。
    f:id:buzz_tkc:20210924005824p:plain


    すると、コンテナ起動したChromeブラウザが、確認できます。
    f:id:buzz_tkc:20210929003057p:plain


    今回は使用しませんが、localhost:9222にアクセスすることで、VNCにて起動したChromeブラウザのDeveloper Toolを確認することができます。
    f:id:buzz_tkc:20210924010918p:plain


    テストシナリオの実行

    Karateコンテナの起動に成功したので、google.featureをコンテナ上から、実行してみたいと思います。
    ただ、そのままのソースコードでは、デフォルトのPC上にある、Chromeドライバーを使用して起動してしまいます。(Windowsで言うと、C:\Program Files\Google\Chrome\Application\chrome.exe)


    今回は、コンテナ起動したChrome上で動くようにするため、google.featureのBackground(シナリオが実行前に呼び出される前処理)に、デフォルトのChromeドライバを呼び出さないよう、start:falseを追加してあげます。
    その他に、ログ出力、UIテスト実行をブラウザで録画するための設定も追加しておきましょう。

    Background:
       * configure driver = { type: 'chrome', start: false, showDriverLog: true, beforeStart: 'supervisorctl start ffmpeg', afterStop: 'supervisorctl stop ffmpeg', videoFile: '/tmp/karate.mp4'}
    


    google.featureシナリオの内容自体は、GitHubにアクセスして、ログインの失敗を行った後、Googleのトップページから、"karate dsl"と検索し、GitHubのKarateのレポジトリにアクセスするという、シンプルな内容になっています。

    Feature: web-browser automation
    
    Background:
       * configure driver = { type: 'chrome', start: false, showDriverLog: true, beforeStart: 'supervisorctl start ffmpeg', afterStop: 'supervisorctl stop ffmpeg', videoFile: '/tmp/karate.mp4'}
    
    
    Scenario: try to login to github
        and then do a google search
    
      Given driver 'https://github.com/login'
        And input('#login_field', 'dummy')
        And input('#password', 'world')
      When submit().click("input[name=commit]")
      Then match html('.flash-error') contains 'Incorrect username or password.'
      
      Given driver 'https://google.com'
        And input("input[name=q]", 'karate dsl')
      When submit().click("input[name=btnI]")
      Then waitForUrl('https://github.com/karatelabs/karate')
    


    これで設定は完了です。
    それでは、Karateコンテナからgoogle.featureを実行してみましょう。

    docker exec -it -w /src karate-chrome mvn clean test -Dtest=web.GoogleRunner


    VNCにて起動したChrome上で、UIテストが動き始めました!
    f:id:buzz_tkc:20211003102519g:plain

    テスト実行結果の確認

    出力されたレポートを確認してみましょう。
    target/karate-reports/src.demo.web.google.htmlを開きます。
    UIテストの動画付きのレポートが確認できます。
    エビデンスとして、テストのキャプチャを取る必要もなくなるので、これはとても嬉しいですね。
    f:id:buzz_tkc:20211003122127g:plain

    Chromeヘッドレスモードでの追加検証

    今までは、ヘッドフルモード(GUIがあるブラウザ)での動作確認を行いましたが、追加で、ヘッドレスモード(GUIがないブラウザ)での検証を行いたいと思います。ヘッドレスモードでの起動ができれば、CI/CD パイプラインの自動テストに組み込むことができます。

    設定自体は簡単で、Backgroundにheadlessオプションを指定してheadless: true 、起動をするだけ。

    configure driver = { type: 'chrome',start:false, headless: true }
    

    ・・・・のはずですが、ヘッドフルモードで実行した場合と、挙動は変わらず、VNC上で起動されたブラウザで、テストが実行され、テストの録画も実行されていました。

    実際にパイプライン(GitLab CI)に組み込んでみたところ、自動テストが実行できたので、headlessオプションの値に関係なく、CI/CDパイプラインにも組み込んで、自動化できそうです。

    まとめ

    KarateのDockerイメージを使って、コンテナ起動したChrome、Karateで、簡単にUIテストを実施することができました。
    コンテナを使うメリットとして、自分以外の他の開発メンバの環境でも同様に動かせる、ということがあると思います。

    先日、Java 17がリリースされましたが、テスト自動化を行う上で環境のバージョンの統一は重要ですよね。
    これで、バージョンの不整合で、自分以外の他の人の環境で動かない、、、なんてことも無くなりそうです。
    また、コンテナ実行とすることで、パイプラインにも簡単に組み込めたので、今後パイプライン構築の幅も広がりそうです。

    それでは。

    顧客のビジネスをインフラから加速するエンジニア募集! - Acroquest Technology株式会社のインフラエンジニアの求人 - Wantedlywww.wantedly.com

    ICCVでGoogle Landmark Retrieval 2021の解法を発表しました

    皆さんこんにちは
    @tereka114です。急に寒くなってきました。

    先週は一週間、自宅からICCVに参加しており、今年は自分もWorkshopで発表しました。
    そこで、発表したWorkshopの説明と簡単にICCVの傾向を紹介したいと思います。

    ICCV2021とは

    ICCVはコンピュータビジョンの国際学会で、正式名称は「International Conference on Computer Vision」です。
    今年も1600本ほどのポスターが公開される大きな学会で、10月11日から10月17日まで開催されていました。
    Workshop/Turtorialは11,16,17、本会議が12-15です。

    公式サイトのリンクです。
    iccv2021.thecvf.com

    今年はWorkshopで発表させてもらうことになりましたので、その話を主に書いておきます。

    Instance-Level Recognition Workshop(ILR)

    Kaggleで毎年開催されているGoogle Landmark Retrieval 2021のコンペティションにて
    5位に入賞したため、を「ILR2021」にて紹介してきました。

    www.kaggle.com

    このWorkshopでは、インスタンスレベル(富士山など)での識別や検索を議論しており、特に製品や目標物、芸術に関するものが対象となっています。
    Google LandmarkのコンテンツはこのWorkshopの中で毎年発表されており、今年で4回目となりました。
    そのGoogle Landmarkの一部門にRetrieval Trackがあります。

    Retrieval Trackは世界中の地図からの目印(例:自由の女神)となる画像のクエリデータが与えられ、
    同じ目印となる画像を別のデータセット群から検索する問題です。

    f:id:tereka:20211020221059p:plain:w700
    Landmark Retrievalの解法発表

    私達のチームの解法はEfficientNetV2と距離学習で用いられるArcFaceを利用しました。
    そのArcFaceを学習し、中間のベクトル表現を獲得したものを用いて近傍を計算しました。
    最後にノイズとなる画像を削る「Bridged Confidence」と呼ばれる後処理を提案し、スコアを伸ばしました。

    解法の詳細は次のYoutubeの14分あたりから御覧ください。(英語です)

    www.youtube.com

    ICCV2021の傾向

    セッションも時間の許す限りチェックしました。
    今年、特筆するものとして、Transformerを利用した提案手法が増えていました。
    もともとTransformerはNLPで利用されていたアーキテクチャですが、Visual Transformerの発表以降、画像でもTransformerの熱が上がっていることが伺えます。

    今年ICCVのベストペーパーもTransformerベースのアーキテクチャSwin Transformer: Hierarchical Vision Transformer Using Shifted Windows」でした。

    大きなポイントはVisual Transformerと比較して、固定となるパッチサイズではなく、スケーリングや平行移動への対応のために、
    徐々にパッチサイズを小さくする(CNNのPooling処理に近い)ようなこと行ってます。

    このSwin TransformerはPyTorchのtimmライブラリから簡単に扱うことができ、先述のGoogle Landmarkのコンペティションでもトップチームが利用していました。

    github.com

    最後に

    Transformerを利用したものが整理されて公開される時期が来たと感じました。
    従来の画像のDeepLearningといえばCNN一強の時代が続いていましたが、Transformerが少しずつ取って代わっているような流れになってきています。
    Transformer+CNNも組み合わせたり、Transformerをより画像向けにしたりするなど、改善できるところもまだまだある感じました。
    これからのアーキテクチャの進化がどのようになるか非常に楽しみです!

    Acroquest Technologyでは、キャリア採用を行っています。


    • ディープラーニング等を使った自然言語/画像/音声/動画解析の研究開発
    • Elasticsearch等を使ったデータ収集/分析/可視化
    • マイクロサービス、DevOps、最新のOSSを利用する開発プロジェクト
    • 書籍・雑誌等の執筆や、社内外での技術の発信・共有によるエンジニアとしての成長

     
    少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。

    Kaggle Grandmasterと話したいエンジニアWanted! - Acroquest Technology株式会社のデータサイエンティストの求人 - Wantedlywww.wantedly.com

    ElasticON Global 2021 最速レポート2

    こんにちは。Elastic認定エンジニアのノムラです。

    今回の記事は以下の続きになります。
    acro-engineer.hatenablog.com


    Opening Keynoteの後、Keynoteで紹介された各ソリューションについて、詳細説明のセッションがありました。
    そのセッションについてそれぞれ紹介します。

    1.Elastic Observability: Unified, actionable, frictionless

    Observabilityの発表では、Logs, Metrics, Insights それぞれに関して現在取り組んでいる内容の説明の後、
    ad hoc analysis & machine learning」というデモがありしました。
    アプリケーションがバックエンドに使っているDBの種別などに基づいて絞込みをおこなったり、ログメッセージをカテゴライズできるようになるという話は興味深かったです。

    f:id:acro-engineer:20211007061535p:plain:w500

    また、最近機能追加された Prometheus や OpenTelemetry への対応についても説明がありました。
    f:id:acro-engineer:20211007062440p:plain:w500
    f:id:acro-engineer:20211007062646p:plain:w500

    OpenTelemetryなどの標準的な規格に対応することで、Observabilityのバックエンドとして、より汎用的にElastic Stack を利用可能になりましたね。

    2.Elastic Security: Limitless XDR. Unbounded security

    この発表では、

    • バージョン7.14でリリースされた Limitless XDR
    • Cmdとbuild.security がElasticに加わった話
    • 今後おこなわれるクラウドセキュリティの強化について

    といった内容が中心に話されました。

    2019年にEndgameを買収し、XDR (eXtended Detection and Reactions)に力を入れていており、そこがさらに強化されてきたような形です。その結果、エンドポイントでセキュリティ脅威を検出し、さらにそこへの対処までをおこなうことが可能になっています。

    f:id:acro-engineer:20211007063609p:plain:w500

    Limitless XDRは、SIEM・Endpoint Security・Cloud Security からなります。
    今回は、今後導入される予定の Cloud Securityに関する話が特に印象的でした。
    f:id:acro-engineer:20211007070430p:plain:w500


    Endpoint Securityに関しては、発表の中で簡単なデモがありました。
    組み込みの検出ルールによって脅威を発見してアラート、ホストをネットワークから切り離すところまでKibana上で完結しています。
    f:id:acro-engineer:20211007064603p:plain:w500

    また、Elastic AgentがOSQueryに対応したことで、
    脅威の検出後に各エンドポイントでOSQueryを実行した結果を収集し、Kibanaで確認できるようになりました。素早く問題の特定をするのに役立ちますね。

    さて、目玉となるCloud Securityについてですが、Elasticが今年8月に買収をおこなった2社から、
    CmdのCSOである Jake King 氏と、build.securityのCEOであるAmit Kanfer 氏による発表+デモがありました。
    Cmd社はeBPFを活用したクラウドにおける Runtime Securityを得意としており、build.securityは OPA(Open Policy Agent)によってクラウドインフラを管理するような内容に強みがあります。
    これらの2社を取りこむことによって、セキュリティ基盤としてのElastic Stack がクラウドインフラに対しても大きな力を発揮できるようになるだろうと感じました。

    f:id:acro-engineer:20211007070212p:plain:w500
    f:id:acro-engineer:20211007070118p:plain:w500

    この2社がElasticにジョインしたことについては、Elasticからブログ記事が出ていますので是非ご一読ください。
    www.elastic.co

    www.elastic.co

    セキュリティの基盤として大きな躍進を遂げているというのが特に印象的でした。今後の動きも目が離せなさそうです。

    3.Elastic Enterprise Search: Solve with speed, scale, and relevance, out of the box

    Enterprise Searchでは以下のキャプチャのように、文書検索について手動/自動両方の調整機能がかなり開発されてきました。
    その各機能の紹介とデモが主な内容でした。
    f:id:acro_nomura:20211006225444p:plain:w500

    その中で個人的には、Keynoteで紹介されたWeb Crowler以外ではRuntime Fieldを活用する、という話が面白かったです。
    f:id:acro_nomura:20211006223343p:plain:w500

    Runtime FieldはElasticStack7.11で登場した機能です。ひとまずデータをElasticsearchにインデキシングしておいて必要な時にRuntime Fieldを生成して Enterprise Searchで検索可能にする、という考え方のようです。
    Runtime Fieldの再インデキシングが不要であるという利点を活かしているのが良いですね。

    また機械学習を利用した検索機能の強化も非常に面白そうな内容でした。
    f:id:acro_nomura:20211006224148p:plain:w500

    これからは登録したドキュメントから学習して、自動で似た意味の単語や文章を判断してくれるようになる可能性がある、と思うと辞書整備の手間も減り非常に便利そうです。

    まとめ

    今年のKeynoteと各サービスのセッションから以下を感じました。
    クラウド利用により世界中でサービスを簡単に展開可能となった
    ・Elastic Stackを活用することで簡易にあらゆるサービス/アプリケーションのデータを集め、横断的に検索・分析することができるようになった

    実際にElasticStackを触り続けている身として、年々ElasticStackがより簡単に高度な検索/分析ができるようになっていると思います。
    これからもどんどん強力になるElastic Stackを使いこなしていきたいです。

    それでは。

    Acroquest Technologyでは、キャリア採用を行っています。

    • ディープラーニング等を使った自然言語/画像/音声/動画解析の研究開発
    • Elasticsearch等を使ったデータ収集/分析/可視化
    • マイクロサービス、DevOps、最新のOSSを利用する開発プロジェクト
    • 書籍・雑誌等の執筆や、社内外での技術の発信・共有によるエンジニアとしての成長

     
    少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。

    世界初のElastic認定エンジニアと一緒に働きたい人Wanted! - Acroquest Technology株式会社のデータサイエンティストの求人 - Wantedlywww.wantedly.com