Taste of Tech Topics

Taste of Tech Topics

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

LambdaのSnapStartをSpring Cloud Functionで検証してみた

3歳の息子がきらきら星を歌っていたので、きらきら星変奏曲モーツァルト)を弾いたら、「それは違う」と否定されてしまった@phonypianistです。

AWS re:Invent 2022でLambdaのSnapStartが発表されました。サーバーレス界隈に衝撃が走っていますw
ということで、本ブログのアドベントカレンダー12/8の記事として、SnapStartを紹介します。

Lambda SnapStartとは

LambdaのInitフェーズに時間がかかる問題、いわゆるコールドスタート問題を解決するための機能です。

aws.amazon.com

Lambdaのライフサイクルは大まかには、「初期化 (Init)」「起動 (Invoke)」「シャットダウン (Shutdown)」の3つのフェーズに分かれています。

https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtime-environment.html#runtimes-lifecycle より引用

最初の呼び出し、もしくはしばらく時間が経過したりスケールアウトしたりする際に「初期化」が行われますが、この部分はプログラムを実行するための環境準備やライブラリ読み込みなど、通常重い処理が行われます。 とりわけ、JavaではJava VMの起動があり、PythonやNode.jsに比べると「初期化」フェーズに時間がかかります。

SnapStartでは、Lambdaが実行されたときの状態のスナップショットを取っておき、それを復元することで、「初期化」フェーズの高速化を行います。 これにより、JavaではJava VMの起動が省略され、圧倒的に速くLambdaを起動することができるようになります。

実際にどれくらい高速になるのか、起動に時間がかかるSpringアプリケーション(Spring Cloud Function)を使って試してみました。 また、スナップショットのサイズはLambdaのメモリサイズに依存すると思われるため、Lambdaのメモリサイズにも影響するか検証してみました。

検証の概要

Spring Cloud Functionで作ったエコー(送られてきた文字をそのまま返す)アプリケーションをLambda上で動かし、CloudShellからリクエストを送って性能を検証します。

SnapStart検証構成

コールドスタートを確実に発生させるために、アプリケーションではリクエストを受けたときに1秒スリープさせます。

準備

プロジェクトの生成

Spring Cloud Functionのコードを用意します。 Spring Initializrで依存関係に「Spring Cloud Function」を追加してプロジェクトを生成します。今回はMavenプロジェクトにしました。 注意点として、LambdaはJava 11しか対応していないため、最新のSpring Boot 3は選択できません。Spring Boot 2とJava 11を選択してください。

pom.xmlの修正

生成したプロジェクトにはAWS用のライブラリがないため、pom.xmlにspring-cloud-function-adapter-awsを追加します。

<dependency>
  <groupId>org.springframework.cloud</groupId>
  <artifactId>spring-cloud-function-adapter-aws</artifactId>
</dependency>

Spring Bootが生成するJARファイルはそのままではLambdaから呼び出せないため、maven-shade-pluginでJARファイルを生成するように設定します。

<build>
  <plugins>
    <plugin>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-maven-plugin</artifactId>
      <dependencies>
        <dependency>
          <groupId>org.springframework.boot.experimental</groupId>
          <artifactId>spring-boot-thin-layout</artifactId>
          <version>1.0.28.RELEASE</version>
        </dependency>
      </dependencies>
    </plugin>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-shade-plugin</artifactId>
      <dependencies>
        <dependency>
          <groupId>org.springframework.boot</groupId>
          <artifactId>spring-boot-maven-plugin</artifactId>
          <version>3.0.0</version>
        </dependency>
      </dependencies>
      <configuration>
        <createDependencyReducedPom>false</createDependencyReducedPom>
        <shadedArtifactAttached>true</shadedArtifactAttached>
        <shadedClassifierName>aws</shadedClassifierName>
        <transformers>
          <transformer implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
            <resource>META-INF/spring.handlers</resource>
          </transformer>
          <transformer implementation="org.springframework.boot.maven.PropertiesMergingResourceTransformer">
            <resource>META-INF/spring.factories</resource>
          </transformer>
          <transformer implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
            <resource>META-INF/spring.schemas</resource>
          </transformer>
        </transformers>
      </configuration>
    </plugin>
  </plugins>
</build>

これにより、 mvn clean package を実行することで、Lambdaで設定可能な snapstartdemo-0.0.1-SNAPSHOT-aws.jar ファイルが生成できます。

Javaコードの実装

簡易的に実装します。 メインクラスに echo メソッドを実装し、1秒待つ処理を追加します。

@SpringBootApplication
public class SnapStartDemoApplication {

    public static void main(String[] args) {
        SpringApplication.run(LambdademoApplication.class, args);
    }

    @Bean
    public Function<Flux<String>, Flux<String>> echo() {
        return flux -> flux.doOnNext(this::sleep);
    }

    private void sleep(String text) {
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            // Do nothing.
        }
    }

}

serverless.yml

今回はServerless Frameworkでデプロイします。 512MB/1024MB/2048MB/4096MBの4種類のメモリサイズ×SnapStartのON/OFFの組み合わせで計8個のLambda関数を作成します。 アプリケーションはすべて同じとします。

SnapStartを有効にするために、resources.extensionsでSnapStartのApplyOnに PublishedVersions を指定します。

また、SnapStartはLambdaのバージョン指定での実行が必要です。Serverless FrameworkのデフォルトではAPI Gatewayから呼ばれるLambdaのバージョンは $LATEST になり、SnapStartのオプションを有効にしていてもSnapStartが機能しません。そのため、serverless-plugin-canary-deploymentsプラグインを用いて、API GatewayからLambdaを呼び出す際にLambdaバージョンが指定されるようにします。

service: snapstartdemo

provider:
  name: aws
  stage: dev
  region: ap-northeast-1
  runtime: java11
  timeout: 15
  logRetentionInDays: 7
  iamRoleStatements:
    - Effect: Allow
      Action:
        - codedeploy:*
      Resource:
        - '*'

package:
  # mvn clean packageで生成される、AWS用のjarファイルを指定する
  artifact: target/snapstartdemo-0.0.1-SNAPSHOT-aws.jar

functions:

  # これ以降は、SnapStart有効/無効の順番に、メモリサイズが異なるLambda関数を定義する
  # SnapStart有効/無効の設定は、下のresourcesに定義する

  SpringCloudFunction512MBSnapStartEnabled:
    handler: org.springframework.cloud.function.adapter.aws.FunctionInvoker::handleRequest
    memorySize: 512
    events:
      - http:
          method: get
          path: /snapstart/512/enabled
    deploymentSettings:
      type: AllAtOnce
      alias: Live

  SpringCloudFunction512MBSnapStartDisabled:
    handler: org.springframework.cloud.function.adapter.aws.FunctionInvoker::handleRequest
    memorySize: 512
    events:
      - http:
          method: get
          path: /snapstart/512/disabled
    deploymentSettings:
      type: AllAtOnce
      alias: Live

  SpringCloudFunction1024MBSnapStartEnabled:
    handler: org.springframework.cloud.function.adapter.aws.FunctionInvoker::handleRequest
    memorySize: 1024
    events:
      - http:
          method: get
          path: /snapstart/1024/enabled
    deploymentSettings:
      type: AllAtOnce
      alias: Live

  SpringCloudFunction1024MBSnapStartDisabled:
    handler: org.springframework.cloud.function.adapter.aws.FunctionInvoker::handleRequest
    memorySize: 1024
    events:
      - http:
          method: get
          path: /snapstart/1024/disabled
    deploymentSettings:
      type: AllAtOnce
      alias: Live

  SpringCloudFunction2048MBSnapStartEnabled:
    handler: org.springframework.cloud.function.adapter.aws.FunctionInvoker::handleRequest
    memorySize: 2048
    events:
      - http:
          method: get
          path: /snapstart/2048/enabled
    deploymentSettings:
      type: AllAtOnce
      alias: Live

  SpringCloudFunction2048MBSnapStartDisabled:
    handler: org.springframework.cloud.function.adapter.aws.FunctionInvoker::handleRequest
    memorySize: 2048
    events:
      - http:
          method: get
          path: /snapstart/2048/disabled
    deploymentSettings:
      type: AllAtOnce
      alias: Live

  SpringCloudFunction4096MBSnapStartEnabled:
    handler: org.springframework.cloud.function.adapter.aws.FunctionInvoker::handleRequest
    memorySize: 4096
    events:
      - http:
          method: get
          path: /snapstart/4096/enabled
    deploymentSettings:
      type: AllAtOnce
      alias: Live

  SpringCloudFunction4096MBSnapStartDisabled:
    handler: org.springframework.cloud.function.adapter.aws.FunctionInvoker::handleRequest
    memorySize: 4096
    events:
      - http:
          method: get
          path: /snapstart/4096/disabled
    deploymentSettings:
      type: AllAtOnce
      alias: Live

resources:
  - extensions:
      # SnapStartを有効にする設定を行う(デフォルトは無効)
      SpringCloudFunction512MBSnapStartEnabledLambdaFunction:
        Properties:
          SnapStart:
            ApplyOn: PublishedVersions
      SpringCloudFunction1024MBSnapStartEnabledLambdaFunction:
        Properties:
          SnapStart:
            ApplyOn: PublishedVersions
      SpringCloudFunction2048MBSnapStartEnabledLambdaFunction:
        Properties:
          SnapStart:
            ApplyOn: PublishedVersions
      SpringCloudFunction4096MBSnapStartEnabledLambdaFunction:
        Properties:
          SnapStart:
            ApplyOn: PublishedVersions

plugins:
  # Lambdaのバージョンを設定するためのプラグインを指定する
  - serverless-plugin-canary-deployments

デプロイ

deployコマンドでデプロイします。

serverless deploy

検証方法

クラスメソッドさんの以下の記事でまとまっていますので、こちらを参考にさせていただきました。 CloudShellから、API Gatewayに対して ab コマンドで100並列でリクエストを送ります。

dev.classmethod.jp

検証結果

Lambdaに割り当てたメモリサイズ毎に、SnapStartの無効/有効時のコールドスタートにかかった時間は、以下のようになりました。

メモリサイズ毎のコールドスタートにかかった時間(最小/最大/平均)
 SnapStart無効SnapStart有効
メモリサイズ最小最大平均最小最大平均
512MB4278.455049.414737.08195.01416.18285.83
1024MB4534.515200.474764.89267.76398.31326.71
2048MB3721.234659.764161.39203.59813.66321.07
4196MB3084.843607.293222.51212.74768.53353.76
メモリサイズ毎のコールドスタートにかかった時間(パーセンタイル)
 SnapStart無効SnapStart有効
メモリサイズp50p90p99p50p90p99
512MB4717.684881.765049.41283.59359.71416.18
1024MB4745.574906.425200.47321.88373.49398.31
2048MB4132.394345.264659.76345.51406.48813.66
4196MB3213.913354.723607.29354.87424.72768.53

90パーセンタイル値をグラフにすると、以下のようになりました。

割り当てメモリ毎のコールドスタート時間

どのメモリサイズでも、SnapStart有効の場合はSnapStart無効の場合に比べて約10倍も時間が短縮しています。

なお、Lambdaのメモリサイズを大きくすればするほど、SnapStartなしでの起動時間は短くなっていますが、SnapStart有効の場合はわずかに長くなっています。これはおそらく、スナップショットのサイズがメモリサイズに依存して大きくなっているものと思われますが、気にするほどではなさそうです。

まとめ

SnapStartを有効にすることで、JavaのLambdaコールドスタートの時間を大幅に短縮することができました。 今後はLambda関数をJavaで実装する、という選択もありかと思います。

ただ、X-Rayが使用できない、512MBより大きなエフェメラルストレージが使用できない等の制限があるため、注意が必要。 加えて、LambdaではJava 11(Amazon Corretto 11)しか選択できないのが残念なところ。 早くJava 17に対応してもらえないかなー。

では。

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

YAMALEX が第3回 AI 王に参加しました

アクロクエスアドベントカレンダー 12月7日 の記事です。

こんにちは、機械学習チーム YAMALEX メンバの駿です。

この度、東北大学理化学研究所が主催する「 AI 王~クイズ AI 日本一決定戦~第3回コンペティション」(以下、AI王)に YAMALEX として参加しました。
初めて参加するコンペで、結果としては入賞できませんでしたが、今回は参加した感想をお伝えします。

技術的な詳細はこちらのスライドにまとまっているので、併せてごらんください。

speakerdeck.com

YAMALEX とは

YAMALEX とは2022年夏に Acro 社内で発足した、 会社の未来の技術を創る、データサイエンスチーム です。
Kaggle Grandmaster の山本を中心に、若手のデータサイエンティスト5人がメンバーです。

最先端技術の調査、実証を通し、会社としてのデータ分析事業の方向性を示すと同時に先端を切り開くデータサイエンティストになることを目指して活動しています。

YAMALEX についてもっと知りたい方はこちらの記事もご覧ください。

コンペ最終日の YAMALEX メンバ MTG

AI 王とは

AI王とは、日本の質問応答研究を推進させることを目的として、クイズ問題を題材とした質疑応答データセットを用いて、より正確に答えを出すことができるモデルを作成するコンペティションです。

AI王 ロゴ

2020年の第1回から毎年行われており、今回が第3回となります。

第1回は20個の選択肢の中からクイズの回答を選択するものでしたが、第2回からは自由回答になっていて、 回を重ねるごとに難易度が上がっています。
そんな中、 YAMALEX として AI 王となるため、挑戦を決めました。

参加のモチベーション

  1. QA の経験を積みたい

    QA システム自体は、チームメンバがほぼ扱ったことが無かったので このコンペを知った際に、チャレンジしたくなった(今回、初参加です)。

  2. 日本語の NLP コンペに参加したい

    Kaggle などには参加したことはあるが、問題のほとんどが英語の文章なので 日本のコンペにチームとして出たかった。

  3. チームでまとまってコンペに参加してみたい

    YAMALEX チームはまだ個人参加はあれど、チームでコンペに取り組んだ ことがなかったので、チームで取り組んでみたかった。

スケジュール

時期
概要
内容
ある10月末頃 AI 王へのチャレンジが始動する とあるチームメンバが唐突に本格的に AI 王をやりたいと発言したところから、私たち YAMALEX チーム5人の挑戦は始まりました。
~11月7日 作戦を立てる 既存ベンチマークの動作確認と昨年度のソリューションを読んで作戦を立てて、分担を決めました。
役割は、 Retriever ( BPR/DPR ) / FiD /外部データセット取得で、3人、1人、1人ほどです。
Retriever が最もやることが多かったのでその部分に人を多めに担当してもらうようになりました。
~11月14日頃 チーム毎に作業を進める チームに分かれて以下に取り組んでいました。
QA に取り組んだメンバがいないため勘所が分からないこともあり、一つ一つ、影響のあるパラメータや手法を考えて確認をしていました。
  • 外部データセットの取得・実験
  • モデルのパラメータチューニング作業
  • 機械学習モデルとは別に Elasticsearch を使ったテキスト検索を Retriever に導入
11月18日頃 外部データを追加する 計算時間が膨大になる Wikipedia のデータを新たに追加する解法を取り入れました。
Dev/Test 間の LB での相関が取れなくなり思うようにスコアが伸びず、頭を抱えるようになったのはこの頃です。
リーダーボード
締切直前
アンサンブルを導入する 複数のモデルを計算する時間が厳しい中、シンプルな Voting を行うアンサンブルを試みました。
アンサンブルのバリエーションもいくつかあると思いますが、この部分は詰め切れませんでした。
最終提出は LB 最高スコアに届きませんが、このアンサンブルした結果にしています。
Dev/Test で相関が取れていないことから問題傾向によるブレがあると予測し、安定した結果を出すためにシンプルな Voting を行うアンサンブルが妥当だといった判断です。
11月23日 リーダーボード提出締切 テストデータでのスコアの確認、他チームの進捗確認がこれ以降できなくなる。
リーダーボード
締切後
Dockerfileを作成する リーダーボードへの提出が締め切られ、システムの最終提出のみとなってからは、 Dockerfile の作成に追われていました。
提出のために不要なファイルを消すなど試行錯誤をしていました。
11月26日 システム最終提出締切 本当に最後の締め切り。ここで提出した Docker イメージを使って未知の問題を解き、スコアと順位が確定する。

感想

  1. チームとして話し合いながら進めるのが楽しい!

    私はあまり NLP が得意ではないのですが、モデル改良に向けてチームでの話し合いに参加しました。

    その中で、クイズを見ながら「こういう問題にはこういうアプローチをしたい」や「これができると精度上がらないですか」 などの意見を出して、できそう/できなそうを議論することができました。

    人がクイズを答えるときにやっていることと同様にやろうとすると、 複数モデルを用意して、問題文から適切なモデルを選択しないといけず、 複雑かつ巨大になってしまうことなども分かり、興味深かったです。
    例:ですが問題は「ですが」の前と後の対比をできるモデルがあれば強いが、他の問題に対しては全く使い物にならない。

    締め切りまじかになると、普段の生活では味わえない、ひりひり感を会話から感じる事ができました。

  2. NLP 分野の知識が広がった!

    AI 王では主催者がベースラインのモデルを提供しており、初心者でも環境があれば動かせる状態から始めることができました。

    また、ベースラインを動かして各機能の入出力や中のコードを見ることで、 QA タスクのアプローチを知ることができました。
    一つのやり方を学ぶことができたため、別の機会に別のモデルを見たときには、 今回のモデルと比較することで、どんなことをやっているかが分かりやすくなると思います。

  3. スコアが上がっていくのを見るのが楽しい!

    これはコンペティションなら言わずもがなですね。

    下の図はリーダーボードスコア(LB Score)といって、提出回数ごとに、AIによる質疑応答のスコアの遷移を表しています。
    当社のデータだけを示していますが、コンペ開催中は、リーダーボードに各チームの暫定スコアと順位が表示されており、 上の人のスコアに徐々に近づいて追い抜いていく、逆に追い越されるなど、 他チームとの駆け引きも面白いポイントでした。

    今回コンペのYAMALEXチームスコアの遷移

まとめ

今回は AI 王に参加した感想を書いてみました。

残念ながら、初参加で入賞!とはいきませんでしたが、確実に YAMALEX チームとしての強さとチームワークは上がったと思います。 この経験を糧に次の挑戦をしていきます。

開催していただいた運営の方々、ありがとうございました!

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

Elastic Stack Advent Calendar 2022(2022年のElastic Search Platformを振り返る)

こんにちは、アクロクエストテクノロジー株式会社でElastic Stackのコンサルティング業務を担当している吉岡です。
本記事は、Elastic Stack (Elasticsearch) Advent Calendar 2022 の5日目の内容になります。

■Elastic Stackリリース概要

  • Elastic Stack Version 7.17.0リリース(2022年2月)
  • Elastic Stack Version 8.0.0リリース(2022年2月)
  • Elastic Stack Version 8.1.0リリース(2022年3月)
  • Elastic Stack Version 8.2.0リリース(2022年5月)
  • Elastic Stack Version 8.3.0リリース(2022年6月)
  • Elastic Stack Version 8.4.0リリース(2022年8月)
  • Elastic Stack Version 8.5.0リリース(2022年11月)


2022年1月時点での最新バージョンはVer.7.16.2、2022年12月5日時点での最新版はVer.8.5.2です。
待ちに待ったVer.8のリリースです。Ver.7.0.0がリリースされたのが2019年4月ですので、約3年振りのメジャーバージョンアップ!Ver.8.0.0リリース後、マイナーバージョンが5回上がっていますが、マイナーチェンジとは思えない多くの機能が盛り込まれています。

本ブログでは、Enterprise Search、Observablility、Elastic Security、3つのソリューションのコアとなる「Elastic Search Platform」の進化について紹介していきます。

■Elastic Search Platformとは

Elasticsearch、Kibana、Logstash、Beatsとう主要プロダクト群を以前はElastic Stackと呼んでいましたが、Ver.8.0あたりからElasticsearch、Kibana、Integrations(Logstash/Beats/Elastic Agent)という分け方になり、総称が「Elastic Search Platform」となりました。Elastic Stackと同様の意味に捉えてもらえればと思います。

Elastic Search Platformをまとめるとこのような感じです。

Elastic Search Platform

■Ver.7.17.0における進化ポイント

パフォーマンスの向上

  • インデックス設定の重複排除
    • Ver.7.16以前では、インデックスのSetting/Mapping情報は各インデックスに紐づいていたため、Setting/Mappingが全く同一だとしても、重複した情報全てをヒープに保持する非効率な仕様でした。特に、日/週/月などの単位でインデックスを集約する時系列データでは、インデックスが増加するほど、Setting/Mapping重複によるヒープ逼迫の影響が大きくなります。
    • Ver.7.17.0では、複数のインデックスに使用される同一のSetting/Mappingが1セットに削減されます。Elastic社の公式発表によると、Auditbeatのインデックスが10,000個あるとき、7.16以前ではヒープを約500MB消費するのに対して、Ver.7.17.0ではヒープ使用量が1MB(約500分の1)になるそうです。ノード間通信の量も削減されるため、クラスタのパフォーマンス向上につながります。

■Ver.8.0.0~Ver.8.5.0における進化ポイント

パフォーマンスの向上

  • インデックスサイズ
    • 圧縮率向上によりインデックスサイズが縮小(8.0.0)
    • 時系列メトリック データに最適な「時系列データ ストリーム (TSDS) 機能」がリリース。インデックスサイズを約30%削減(8.5.0)
  • ストレージサイズ
    • Doc value only field:ストレージサイズを20%以上削減(8.1.0)
  • インデクシング性能
    • ジオポイントのインデクシング性能が10~15%高速化(8.0.0)
    • Doc value only field:インデクシング性能を20%以上向上(8.1.0)
  • 検索性能
  • ヒープ使用量
    • リソース使用量を大幅に削減、データノードが保持可能なインデックス数が増加(8.3.0)

Ver.8.0.0以降、インデックスサイズ/ヒープ/ストレージの効率化に関する機能強化が多く、結果としてVer.7.Xと8.3以降で、10倍以上のシャードを保持できるようになっています。ぜひVer.8.3以降を使いましょう。

可視化/Kibana UI

  • Discover
    • フィールド統計機能が追加(8.0.0)
    • フィールド統計機能ジオデータに対応(8.2.0)
  • Lens
    • Gauge, Waffle, Mosaicが追加(8.1.0)
    • 新しいメトリックが追加(Tech Preview)(8.4.0)
    • 簡単にChoropleth Maps を作成可能に(8.2.0)
    • Annotation機能が追加(8.2.0)
    • クエリベースのAnnotation機能が追加(8.5.0)
  • Maps
    • Shapeファイルのアップロード機能を追加(8.1.0)
    • GeoServer不要でカスタムマップを利用可能に(8.1.0)
  • Dashboard
    • コントロール専用エリアが追加(8.3.0)
    • タイムスライダー機能が追加(8.5.0)
  • その他
    • フリートパッケージマネージャーから機械学習モデルやSecurityパッケージがインストール可能に(8.0.0)

Discoverが機能強化で使いやすくなりました。最初にフィールドの統計分析からデータ傾向を掴み、KQLを使ってドキュメント抽出/調査、その後必要に応じて異常値検知用のアラートを作成。このようなデータの基礎調査作業がDashboardを作ることなく可能です。

Search/ML/NLP

  • Search
    • 近似最近傍(ANN)検索機能(8.0.0)
  • ML管理機能
    • 機械学習モデル管理画面が追加(8.1.0)
    • 機械学習モデルをスペース単位で管理可能に(8.2.0)
    • 機械学習モデルのテスト画面が追加(8.2.0)
  • NLP
    • PyTorchモデルのインポートが可能に(8.0.0)
    • Fill-mask、固有表現抽出、テキスト分類、Embeddingに対応(8.0.0)
    • 質問応答(Question-Answering)に対応(8.3.0)

PyTorchモデルのインポートが可能になったことで、Elasticsearch単体で様々なデータ分析ができるようになりました。今後も様々なNLPタスクがサポートされるはずです。非常に楽しみですね。

ちなみに、現時点でのElasticsearchにおけるNLPの変遷をまとめると以下のようになります。

NLPの変遷

ログ分析/監視

  • Kibana Alert
    • スヌーズ機能が追加(8.2.0)
    • Discoverからアラートルールを作成可能に(8.3.0)
  • データのエンリッチ
    • Lookup Runtime Fieldのサポート(8.2.0)
    • クエリのタイミングでデータ結合が可能(リアルタイムエンリッチ)
    • Enrich Processorとルックアップデータ更新に対する追従が容易
  • AIOps
    • ログパターン解析機能が追加(8.5.0)
    • Log Rate Spike原因調査機能が追加(8.5.0)

これまで、Elasticsearch上でデータのエンリッチを行うにはEnrich Processorの一択でした。Enrich Processorはルックアップ先が固定の場合は向いていますが、頻繁にルックアップデータが更新されるようなユースケースでは、再ルックアップ(Update by Query + Pipeline指定)が必要で使い勝手が良くありません。その課題を解決するのが、Ver.8.2.0でリリースされたLookup Runtime Fieldです。Lookup Runtime Fieldはクエリタイムジョインなので、常に最新のルックアップデータをエンリッチ可能です。柔軟な可視化を行うのに非常に便利です。

まとめ

2022年のElastic Search Platformを振り返って、特徴的な機能強化/新機能をピックアップしてみましたが、その中でも、NLP関連の進化が個人的に興味深いですね。Ver.8.0以降、BERTなどのPyTorch機械学習モデルをElasticsearchでダイレクトに使用したり、モデルを使った推論をElasticsearch内でネイティブに実行することができるようになり、データのエンリッチや検索の幅が大きく広がっています。来年も目が離せませんね。

Elastic Stack

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

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

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

【データ分析】
Kaggle Grandmasterと一緒に働きたエンジニアWanted! - Acroquest Technology株式会社のデータサイエンティストの採用 - Wantedlywww.wantedly.com

Amazon EventBridge Schedulerの使いどころを整理してみた

Amazon/楽天ブラックフライデーで例年通り散財した、@kojiisdです。
今回、光学30倍ズーム、という謳い文句に惹かれて、10年ぶりくらいにパナソニックのコンデジを買ってしまいました。
これから写真を撮るのが楽しみになりそうです(^^
みなさんは散財しましたか?

さて、アクロクエストでは、エンジニアたちが仕事の中で気になっていたことを調査・検討・検証した際に、
その内容を社内勉強会でフィードバックしています。
今月は12月ということで、そのような調べたことを、アドベントカレンダーとしてブログに公開していくことにしました~!

初日はタイトルにもあるとおり、「Amazon EventBridge Schedulerの使いどころを整理してみた」です。

Amazon EventBridge Schedulerとは

AWSでイベント/スケジュールドリブンな処理の管理、というとAmazon EventBridgeが代表的ですが、先日、スケジュール機能に特化したAmazon EventBridge Schedulerが発表されました。
スケジュールベースのイベントトリガ管理を行う場合、従来のEventBridgeでは、Rulesという機能を使ってcronやrateを使用しつつ処理実行のタイミングを指定していましたが、以下のような制約がありました。


1. UTCベースのスケジュール指定が必要(誤ってJSTのつもりで時刻を設定してしまって、失敗した苦い経験ないですか?私はあります)
2. 実行できる機能は20程度のAWSサービスのみ


これらのスケジュール指定方法、実行サービスの幅などが広がったのがEventBridge Schedulerになります。



EventBridge Rulesとの比較は主に以下のようになっています。(抜粋)

Amazon EventBridge Scheduler Amazon EventBridge Rules
スケジュール上限 アカウント毎に100万 アカウント内リージョン毎に300
イベント実行スループット 秒間1,000トランザクション 秒間5トランザクション
指定可能なターゲット AWS SDKを使用した270以上のサービスと6,000以上のAPI 20以上のターゲット
時刻指定方法とタイムゾーン at(), cron(), rate()に対応
すべてのタイムゾーンとDST(サマータイム)に対応
cron(), rate()に対応
タイムゾーンUTCのみ、DSTはサポート外
1回限りのスケジュール 指定可能 指定不可
ウィンドウ時間を指定した設定 指定可能 指定不可

参考:Introducing Amazon EventBridge Scheduler | AWS Compute Blog


これを見ただけでも、より細かなスケジュール設定が可能になった、ということがわかりますね。


ちなみに従来のEventBridge Rulesでも、スケジュールベースのイベント作成はできますが、現在AWSコンソールにアクセスすると、下図のようにEventBridge Schedulerへの遷移を促されるので、今後スケジュールドリブンなトリガ管理はEventBridge Scheduler、イベントドリブンなトリガ管理はEventBridge Rules、と棲み分けがされていくかもしれないですね。

EventBridge Rulesでスケジュールドリブンイベント作成をしようとすると、EventBridge Schedulerに移動を促される

また、特に今回、大きな機能追加になりそうなものは以下かな、と感じました。

EventBridge Schedulerの特長的な機能追加

詳細を挙げればキリがないですが、私として気になった大きな機能追加は主に以下の3点ですね。

1. ウィンドウ時間(フレックスタイムウィンドウ)の指定が可能になった

予定した起動時刻に対して、指定した時間内の任意のタイミングに処理を起動させることが可能になりました。
これにより、同時刻に大量の処理が発生してしまいAWSのクォータ(制限)に引っかかりにくくすることができるようになりました。
例:12:00起動に設定してフレックスタイムウィンドウを15分と指定すると、12:00 - 12:15の間のどこかで実行されることになります。

2. 1回限りのスケジュールの指定が可能になった

今までのEventBridgeでは、基本的に「定期処理」または「イベントドリブンな処理」での指定が必要でした。
今回のリリースで、単発の実行のみを行う設定が可能になりました。(EventBridge Rulesでも1回限りの指定をするような小技はありますが、Rulesのスケジュールドリブンなイベント管理はあくまで「定期実行」が考え方のベースになっています。)
これにより、1度のみ実行すれば十分、というようなユースケースに対応することができるようになりました。

3. 直接AWSサービスのAPIコールをすることが可能になった

従来のEventBridge Rulesでは、どんなにシンプルな処理であっても、AWSサービスのAPIを呼び出すためにはLambdaを一度経由するなど、ワンクッションを置く必要がありました。
例:指定した時刻に、定期的に決まったDynamoDBのレコードのある値を書き換える。

EventBridge Schedulerでは、6000以上ものAWSサービスのAPIが直接コールできるようになったので、今までAPIを呼ぶためだけにLambdaを準備していたようなユースケースに対して、開発が不要になりました。

EventBridge Schedulerの使いどころを整理してみた

これらの機能追加を踏まえて、今回のサービスリリースで、どんなことが可能になりそうか、整理してみました。

1. 毎日、運用中のサービスの状態チェックを行う
2. 「1回限りの実行」を使用し、夜間のデータ移行処理を実行する
3. 短期間で、大量の処理を分散させて終わらせる
4. 業務時間外のEC2サーバーへのアクセスを制御する

1. 毎日、運用中のサービスの状態チェックを行う

運用しているサービスの状態チェックは、定期的に行っていると思います。このような定期的な処理は、従来のEventBridge Rulesでも指定可能でしたが、もちろんEventBridge Schedulerでも実現が可能です。EventBridge Schedulerでは、実行タイミングの指定時に、タイムゾーンの指定が可能になっているので、毎回UTCに変換した時刻を考える必要もなくなります。(従来のEventBridge Rulesでは、時刻指定の際にはUTCタイムゾーンが固定で指定されていました。)

タイムゾーンをPSTで指定した場合の実行時刻サンプル


2. 「1回限りの実行」を使用し、夜間のデータ移行処理を実行する

サービスの更改などによるデータ移行が必要になった場合、基本的にサービスに影響を出さないように、夜間に実施するケースが多いですが、EventBridge Schedulerで1回限りの実行イベントを定義すれば、夜間の指定した時間帯にデータ移行処理を実行することが可能になります。

深夜3時(日本時間)に1回限りの実行を行う


3. 短期間で、大量の処理を分散させて終わらせる

例えばLambdaで実施される処理を大量に並列で実行し、短期間で結果を得たい、というユースケースの場合、分割の粒度や実行タイミング、並列度を考えながら、Step Functionsを組むことがあると思います。

大量の処理を並列に実施するワークフロー


この場合、前処理のLambdaはどうしても実装が必要になってしまいますし、メイン処理も同時タイミングでの実行はサービスへの負荷が上がってしまい、サービスの運用に影響を出す恐れがあるため、実行タイミングにばらつきを発生させるよう、Step Functionsの設定で並列度を調整したり、場合によってはメイン処理のLambdaにWait処理を入れることがあると思います。

このようなユースケースの場合、フレックスタイムウィンドウを使って処理を分散させることが可能になります。

定期的なスケジュールの選択の上で、フレックスタイムウィンドウを「1時間」に設定すれば、指定した「毎日1時(JST)~2時」の間のいずれかで実行するイベントの作成が可能になり、ばらつきを制御する苦労から解放されます。

フレックスタイムウィンドウを利用した処理のばらつきの実現


4. 業務時間外のEC2サーバーへのアクセスを制御する

たとえばEC2サーバーで運用している社内サービスが以下の要件で稼働しているとします。
1. 業務時間中は、Webアクセスはすべて受け付ける。
2. 業務時間外は、メンテナンス用のIPアドレス以外からのアクセスを遮断する。

このような場合、今まではLambdaによりEC2のセキュリティグループを定期的に変更する処理の実装が必要でした。EventBridge Schedulerを利用すると、EC2のModifyInstanceAttribute API直接コールするように設定することで、Lambdaの実装なしに要件を満たすことが可能となります。

特定のAPIをEventBridge Schedulerから直接コールすることが可能

まとめ

今回、Amazon EventBridge Schedulerの用途について整理をしてみました。スケジュールドリブンなイベント管理の機能強化により、
さらに効率的にサービスの開発や運用ができそうですね。私もより深く調べて、活用していきたいと思います。


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


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


www.wantedly.com



ElasticON Tokyo 2022 最速レポート

この記事は Elastic Stack (Elasticsearch) Advent Calendar 1日目の記事です。

こんにちは、@shin0higuchiです😊

昨日11/30(水)に、ElasticON Tokyo 2022 が開催されました。
今年は2019年以来、3年振りのオフライン開催で、私もウェスティンホテル東京の現地に行って参加してきました。

午前中は基調講演やゲストスピーカー落合陽一氏の講演などが、
午後は2並列でテクニカルセッションとユーザ事例のセッションがありました。

私はテクニカルセッションを中心に聴講していましたが、
今年はクラウドベンダー各社との連携が強まった点が印象的で、GoogleMicrosoftAWSのそれぞれから発表がありました。

今回参加した中でも特に印象的だったセッションは「サーバーレスアーキテクチャへの道」という発表です。
Elasticsearch社のプリンシパルソリューションアーキテクト古久保さんによる発表で、Elasticsearchのアーキテクチャの変遷と今後の展望について話されました。

このブログでは、このセッションについて詳しく紹介します。

「サーバーレスアーキテクチャへの道」

概要

セッションの動画等は公開されていませんが、下記のブログが元ネタとなっています。
www.elastic.co

ブログでは現在のアーキテクチャと、今後のアーキテクチャの2つに分けて違いが説明されていますが、セッションの中ではさらに細分化して4つに分けて説明されました。

  • Act-one:Elasticsearch初期のアーキテクチャ (シャード分割)
  • Act-two:現在のアーキテクチャ(Data Tierを用いた時系列データ管理)
  • Act-three:ステートレス
  • Act-four:サーバレス/フルマネージド


こちらが、ブログで説明されている画像ですが、Existing ArchtectureがAct-two、New ArchitectureがAct-threeに相当することになります。

https://www.elastic.co/jp/blog/stateless-your-new-state-of-find-with-elasticsearchより

話の趣旨としては、現在のAct-twoからAct-threeを目指して移行中で、更に先の将来はAct-fourを目指したいということでした。

Act-two (Existing Architecture )の特徴/課題

Act-twoでは、いわゆるHot-Warm Architectureとも言われるように、データの鮮度に応じてノード間を移動させ、新しいデータ程良いスペックのマシンに載せることで従来よりもコストを抑えつつパフォーマンスを維持することができていました。さらに最近ではレプリカをオブジェクトストレージに配置する Searchable Snapshot 機能も公開されています。
しかし、課題として下記の点が挙げられます。

  • レプリカを保持するためストレージコストがかかる
  • ノード間のデータ移動が頻繁に発生し、また、移動に時間がかかる
  • 検索とインデクシングが同じリソースを共有するので、互いの性能に影響する
Act-three (New Architecture)の特徴

Act-twoの課題を改善すべく、新たに「ステートレス」な構造が提唱されています。
ポイントとしては、データ投入と検索を分離することで、リソースをより効率化できる点です。

書き込み時には、書き込み用のノードがオブジェクトストレージに書き込み、検索時には検索用のノードがオブジェクトストレージから読み込む。こうすることでAct-twoで挙がっていた課題が悉く解消される形になります。現行のアーキテクチャでは、データ投入と検索がCPUリソースなどを食い合うので、必要スペックの正確な見積もりが困難でしたが、その辺りも解消される形になりそうです。

オブジェクトストレージからの検索になったことで検索速度の低下が懸念されることと思いますが、キャッシュを上手く使うことで速度を改善しているとの説明でした。初回の検索が遅くなってしまう等はあるかと思うので、場合によってはSearch Tier側の暖機運転が必要になるかもしれませんが、その辺りはElastic社としても検討中かと思いますので今後の情報が楽しみです。

# Act-fourのフルマネージドはもう少し先の話になると思いますので、ここでは割愛します

まとめ

Elasticsearchを触って8年近くになりますが、時代に合わせて日々変わって来ているのを感じます。
特にクラウド連携や、アーキテクチャの変化など、当初のコンセプトから切り替わるダイナミックな変更もありました。
今後の動向から目が離せません。

今回の記事は以上となります、最後までお読みいただきありがとうございました。


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

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

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

新しいデータ基盤アーキテクチャである「データレイクハウス」について調べてみた

最近ソーダストリームを買い、炭酸水を飲むのにはまってます。機械学習エンジニアの@yktm31です。

以前に「AWS Lake Formationでデータレイク体験!」という記事を書いてみて、データ基盤アーキテクチャに興味が湧いてきました。

データレイクハウスは、「データウェアハウス」と「データレイク」を統合したようなアーキテクチャで、 2020年にDatabricks社により提唱され、新しいデータ基盤アーキテクチャとして注目されているようです。

www.databricks.com

そこで今回、「データレイクハウス」について調べてみたことをまとめてみたいと思います。

なぜデータレイクハウスが注目されているのか?

データ基盤アーキテクチャは、以下のような変遷をたどっていて、データレイクハウスが最新のアーキテクチャという流れのようです。 それぞれの登場時期、利用用途を以下にまとめて見ました。

アーキテクチャ 登場時期 利用用途
データウェアハウス 1980年代 ビジネス意思決定のためのデータ分析 (BI)
データレイク 2000年代 非構造化データを使う機械学習 (ML)
データレイクハウス 2020年 BIとMLの両立

最新のデータ基盤アーキテクチャであるデータレイクハウスの必要性を理解するために、 まず、データウェアハウスとデータレイクそれぞれの特徴・課題を見ていきたいと思います。

データウェアハウスの特徴・課題

データウェアハウスのアーキテクチャ

データウェアハウスは、ビジネス意思決定のためにデータを一つの場所に集約・保管し、分析に利用するためのデータ基盤アーキテクチャで、1980年代に考案されたそうです。 (私が生まれたのは1997年なので、生まれる前からこうしたデータ基盤アーキテクチャが考えられていたのは驚きでした。) 例えば、「Amazon Redshift」はデータウェアハウスを提供しているサービスとして有名だと思います。

データウェアハウスの特徴として、以下のような点が挙げられていることが多かったです。

  • 複数のソースから取得したデータにETL処理を施し、構造化データを蓄積する。
  • スキーマが決まっていて、トランザクションもサポートされることでデータ一貫性が担保されている。
  • 権限管理が行え、データへのアクセスコントロールが効く。

しかし反面、ビジネスで扱うデータの多様化により、データウェアハウスだけでは新たなニーズに応えられなくなっていったそうです。 とくに、非構造化データを使う機械学習の発展に、データウェアハウスのスキーマが決まっているという点が大きな制約となったようです。

データレイクの特徴・課題

データレイク + データウェアハウスのアーキテクチャ

画像やテキストなど非構造化データの分析という新たなニーズに合わせ、データレイクというデータ基盤アーキテクチャが2000年代に入り誕生したそうです。

例えば、「Amazon S3」や「Azure Data Lake Storage」といったクラウドストレージシステムと周辺サービスを組わせるとデータレイクとなります。

データレイクの特徴として、以下のような点がよく挙げられています。

  • 未加工のデータが格納され、主にデータ分析や機械学習で利用されることが多い。
  • データの形式に制限がなく、テキストデータやセンサーデータ、画像、テキストなど、構造化データ以外のデータも格納できる。

他方、以下の2点がリスク・課題としてもよく挙がります。

  • データレイクはトランザクションはサポートされないためデータ品質が保証されない。
  • 自由にデータが配置できる反面、本当に必要なデータが見つかりづらくなる、データスワンプとなるリスクがある。

トランザクションがサポートされないというデータレイクの欠点を補う必要がある場合は、データレイクとデータウェアハウスを併用するようです。

データレイクのデータを直接扱うだけでなく、ETL処理を施しデータウェアハウスにデータを登録することで、トランザクションを実現する試みです。 しかしその方式では、データ一貫性を保つのが難しいなど、デメリットも残っている現状のようです。

ここまでで、データウェアハウス、データレイクの比較をまとめてみました。

特徴 データウェアハウス データレイク
扱えるデータ形式 構造化データのみ、加工・整形済みデータ 構造化データ、半構造化データ、非構造化データ、生データ
代表的な利用用途 BI (過去データの分析) ML (将来予測)
データ一貫性 ×
データの自由度 ×
コスト データ保持・構築ともにコストがかかる データサイズに対して比較的安価
主な利用者 ビジネスアナリスト データサイエンティスト

データレイクハウスの特徴

データレイクハウスが登場したのは、データウェアハウス・データレイクそれぞれの特徴を活かしつつ、 課題をうまく解決するためでした。

まず、データレイクハウスはどのような特徴を持ち、既存の課題をどう解決したのかをまとめてみたいと思います。

  • ACID トランザクションサポート
  • データレイクの問題点として、トランザクションサポートが無いことで、データ一貫性が保てないことがありました。 その原因の一つとして、トランザクションがサポートされていないという点がありました。 データレイクハウスでは、データレイクをメタデータを扱うレイヤーを重ねることで、 データレイク内のデータを直接扱うのではなく、メタデータを操作する事で扱っていきます。 この機構により、ACIDトランザクションを実現し、データ一貫性の欠如という課題を克服できたようです。
  • データのアクセス権限管理
  • データウェアハウスでは実現でき、データレイクでは実現できなかった、データのアクセス制御を行えます。 テーブル単位のみならず、列/行単位でのきめ細やかな権限管理をサポートします。
  • parquetなどのオープンなファイルフォーマットを利用
  • Apache Parquet, Delta Lake, Apache Hudiなどのオープンソースのデータフォーマットを利用することで、データアクセスの方法を標準化できるというメリットがあるようです。
  • 安価なストレージ
  • データレイクのメリットとして、様々なデータ形式を、安価なストレージで扱えるという点がありました。 データレイクハウスでは、データレイクのこの良い面を受け継いでいます。
  • BI・データ分析・機械学習をサポート
  • データレイクハウスでは、BIはデータウェアハウス、機械学習はデータレイク、という区別なくデータを扱うことができるようになります。

    データレイクハウスのアーキテクチャ

    ここからは、データレイクハウスのアーキテクチャについて具体的に見ていきます。 データレイクハウスのアーキテクチャは、概ね以下のようなレイヤー構造からなっているようです。

  • Data Ingestion Layer
  • Storage Layerにデータを取り込む役割を担う。
  • Storage Layer
  • 高い耐久性とスケーラビリティを持ち、コストの安いデータ保管を担う。構造化/非構造化データを格納する。 データの加工度に応じて、データ格納のレイヤーを分ける、メダリオンアーキテクチャ(※1)を採用するケースが多い。
  • Metadata Layer
  • Storage Layerに存在するデータのメタデータを扱う役割を担う。 データカタログを作成したり、トランザクション・権限管理を実現する。Catalog Layerと表現されることもある。
  • Processing Layer
  • データ分析や機械学習などで利用可能な形にするための、データの検証・変換を担う。
  • Data Consumption Layer
  • SQLやBI、機械学習など、データを利用する層。Serve Layerと表現されることもある。

    データレイクハウスアーキテクチャ

    ※1 メダリオンアーキテクチャ

    メダリオンアーキテクチャとは、データレイクのデータ配置を、データの質によって3つのレイヤーに分けるアーキテクチャということらしいです。 3つのレイヤーはそれぞれ、Bronze、Silver、Goldとなっています。

  • Bronze Layer
  • あらゆるデータソースからデータを取り込み、未加工の生データを配置。
  • Silver Layer
  • Bronze Layerのデータから、ジョイン、フィルターなどの処理を施し、マスターテーブルなどのクレンジングされた中間データを配置。
  • Gold Layer
  • レポート作成などに必要なレベルで集約されたデータを配置。プロジェクトのユースケースごとに専用のデータベースとなり、データマートとも呼ばれる。

    メダリオンアーキテクチャ

    Azure

    Azureでドキュメントで提示されているデータレイクハウスアーキテクチャを見ていきます。

    https://learn.microsoft.com/ja-jp/azure/architecture/example-scenario/data/synapse-exploratory-data-analytics

    Azureのこのレファレンスアーキテクチャのポイントを3つ挙げてみました。

    • Azure Synapse Analyticsを中心としたアーキテクチャ
    • Azure Synapse サーバーレス SQL プールとPowerBIによるデータ可視化
    • Azure Machine Learningを利用した機械学習利用

    Azure Synapse Analyticsを中心としたアーキテクチャ

    Azure Synapse Analyticsとは、データウェアハウス・ビッグデータ解析を統合したデータ分析プラットフォームです。 Azure Synapse Analyticsを利用することで、SQL / Apache Sparkによるデータ分析が用意に実現できるようになります。

    Azure Synapse サーバーレス SQL プールとPowerBIによるデータ可視化

    Azure Synapse サーバーレス SQL プールを利用し、Azure Data Lake Storageに保存されたParquetファイルに対し、 SQLベースでデータ探索を行い、Power BIに結果を可視化します。

    Power BIとSynapseを連携する際、Power BI Linked Serviceで直接連携することも可能ですが、 その方式では、ワークスペースが1つのみに制限されてしまいます。 そのため、サーバーレス SQL プールを利用することが一つのポイントになります。

    Azure Machine Learningを利用した機械学習利用

    Azure Machine Learningを利用し、推論した結果をデータレイクに保存し、PowerBIで可視化することが出来ます。 学習するデータの取得、整形のためにはAzure Synapse サーバーレス Apache Spark プールが利用できます。 Azure Machine Learningによる推論結果は、データレイク中のゴールドレイヤーに保存されることになります。

    参考

    learn.microsoft.com

    Azure Databricksを利用した代替案

    ここまで、Azure Synapse Analyticsを利用したデータレイクハウスアーキテクチャを見てきましたが、 代替アーキテクチャとして、Azure Databricksを利用する方法もあるようです。

    Azure Databricksは、SQL / ML / データ分析をするためのプラットフォームです。 Azure Databricksを利用したデータレイクハウスのアーキテクチャは以下のドキュメントが参考になりそうでした。 learn.microsoft.com

    AWS

    次に、AWSにおけるデータレイクハウスのアーキテクチャを見ていきます。ここでは、AWS Big Data Blogで提示されているアーキテクチャを参考にしていきます。

    https://aws.amazon.com/jp/blogs/big-data/build-a-lake-house-architecture-on-aws/

    AWSのこのレファレンスアーキテクチャのポイントをまとめると、以下のような点が分かりました。

    • メタデータレイヤーとして、AWS Lake Formationを利用
    • Amazon S3Amazon Redshiftのネイティブな連携
    • Amazon Athena / Amazon QuickSight / Amazon SageMakerなどのサービスから、統一されたインターフェースでデータ利用できる

    メタデータレイヤーとして、AWS Lake Formationを利用

    AWS Lake Formationは、データの行/列レベルの権限管理や、ACIDトランザクションを提供しています。 Amazon S3Amazon Redshiftに格納されているデータ本体と、メタデータをレイヤーとして分離することで、スキーマオンリードを実現します。

    データレイク単体では、データのスキーマが変更されても、変更を検知することは難しいです。 そのため、読み込むデータがどのようなスキーマか確認することが必要になり、このスキーマオンリードの考え方が重要になってくるようです。

    また、データレイクは、データのスキーマが変わることが考えられますが、 AWS Glueを通じて、中央データカタログは更新されていくので、変更に追従できるということのようです。

    Amazon S3Amazon Redshiftのネイティブな連携

    データをBIで利用する場合、整理された構造化データが分析パフォーマンスの上で重要になります。他方、機械学習では非構造化データを扱うことになります。

    例えば、大量の履歴データがデータレイク(Amazon S3)に保管され、BIでの分析対象分のデータは、データウェアハウス(Amazon Redshift)にAmazon Redshift Spectrumを通じて展開、 そして、逆にデータウェアハウス(Amazon Redshift)で不要になったデータは、データレイク(S3)にオフロードするという使い方ができるらしいです。 データウェアハウス(Amazon Redshift)からデータレイク(Amazon S3)にオフロードされたデータも同じクエリでアクセスすることができるようです。

    Amazon Athena / Amazon QuickSight / Amazon SageMakerなどのサービスから、統一されたインターフェースでデータ利用できる

    以下のようなサービスから、データレイクハウスのデータを扱うことができます。

    サービス 用途
    Amazon Athena SQL
    Amazon QuickSight BI
    Amazon SageMaker ML
    Amazon Redshift Spectrum データ分析

    まとめ

    機械学習ビッグデータ系のプロジェクトをやっているとき、データをどうやって管理する?という課題がよく出てくる実感があります。 今回見てきたデータレイクハウスは、ぜひデータ管理アーキテクチャの設計に活かしていきたいと感じました。

    ただ、データレイクハウスは、自前で0から構築するとなると、かなり大変そうな印象を受けました。 なので、クラウドサービスで簡単に構築できそうなところは、有難いなと思いました。

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

    Elastic Cloudの紹介 ~Elastic Cloud上に簡単デプロイ編~

    こんにちは、Elastic認定資格3種(※)を保持しているノムラです。
    ※Elastic社の公式認定資格(Elastic Certified Engineer / Elastic Certified Analyst / Elastic Certified Observability Engineer)

    皆さんはElastic Stackを構築するにあたってElastic Cloudを利用されたことはあるでしょうか?
    Elastic Cloudは、Elastic社が提供しているSaaSサービスです。クラウドプロバイダはGCPAWS、Azureをサポートしています。
    最新バージョンのクラスタ構築や、既存クラスタのバージョンアップを数クリックで実施できるため、導入がお手軽です。

    本記事では、Elastic Cloudの無料トライアルを利用して、Elastic Stackをデプロイする手順を紹介します。

    目次は以下です。

    前提

    本記事では、Elastic Stackである

    • Elasticsearch
    • Kibana
    • Logstash

    については、説明をいたしません。各プロダクトの詳細は公式ホームページをご参照ください。
    www.elastic.co

    アカウントを作成する

    Elastic Cloudは2週間の無料トライアルが利用可能です。
    方法はメールアドレスを登録するのみです。


    Elasticクラスタをデプロイする

    デプロイメント名、クラウドプロバイダ等を設定する

    以下を設定します

    1. デプロイメント名(任意の文字列でOK)
    2. クラウドプロバイダ(今回はAWSを選択)
    3. リージョン(今回はOhioを選択。Tokyoリージョンも選択可能です)
    4. ハードウェアタイプ(Storage Optimizedを選択。詳細はこちら
    5. Elastic Stackバージョン(最新を選びましょう)

    入力後、「Create deployment」を押下することで、Elastic Stackの構築が開始されます。

    さっそく利用!

    数分で構築が完了し、デプロイされたKibanaの画面に遷移します

    標準で付属のサンプルデータ/ダッシュボードをKibanaから1クリックでインストールしてみました。

    数クリックするだけで構築が完了し、利用可能になりました。
    ここまで5分程度です。お手軽ですね!

    まとめ

    Elastic Cloudを利用することで、非常に簡単にElastic Stackが構築可能です。

    追記

    またElasticCloudではセキュリティ設定として、ユーザ認証に加えて、Private Link接続やIPフィルタリングが可能です。
    次回以降で紹介したいと思います。お楽しみに。

    それでは。

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

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

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

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