Taste of Tech Topics

Taste of Tech Topics

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

AWS Lake Formationでデータレイク体験! #3 きめ細かな権限管理

機械学習アプリケーションエンジニアの@yktmです。

AWSで構築するデータレイクがテーマの本連載、今回は第3回目、最終回です。 前回は、AWS Lake Formationで構築したデータレイクとAmazon Athenaの連携を確認しました。今回は、Lake Formationの権限管理で、Athenaからのクエリにアクセスコントロールをかける部分を試していきます。

データレイクにはとにかくどんなデータも格納される、ということは誰がどのデータにアクセスできるか管理する必要がでてきます。 Lake Formationを使うと、データレイクにおけるアクセスコントロールを、要件に合わせ細かく設定することができます。

実際に権限管理を試してみると、確かに細かく権限管理できることが実感できました。他方、Lake Formationにおける権限管理の考え方が複雑なため、自分にとっては難しい部分もありました。 本記事では、実際に試してわかった、権限管理の具体的な設定方法、および権限管理の考え方をまとめてみたいと思います。

構成図

1. Lake Formationの権限管理

最初に、Lake Formationで、どのような権限管理ができるのか、簡単に見ていきます。

第1回の記事で書いたように、データレイクでは、事業・業務横断的にデータを管理するケースがあるかと思います。 データの中には、個人情報、業務上の秘匿情報など、自由にアクセスされたくないデータも混在していることも考えられます。 そのようなデータは、漏洩した際のリスクがあり、データレイク利用者すべてにアクセスを許可するのは非常にリスクが高くなります。

AWS Lake Formationは、データレイクに柔軟にきめ細かな「権限管理」を付与できることが特徴の一つです。

AWS Lake Formationは、

  • データベース、テーブルレベルのアクセス管理
  • 列、行、または行・列組み合わせによるセルレベルのアクセス管理

を提供しています。

例を通して、整理してみたいと思います。
「顧客マスタテーブル」と「販売実績テーブル」が存在し、セールスとアナリストがいる事業所を仮定します。

アナリストに、個々の顧客個人情報を見せないように、テーブルからデータを参照すること自体を禁止します。
また、販売時にサードパーティーの決済システムを利用していたとして、決済時に発行されるIDも必要ないでしょう。不要な列は、列レベルで参照を禁止します。
セールスには、担当地域の顧客情報は参照できても、それ以外の個人情報は参照させたくない。とすれば、担当販売地域のデータにのみアクセス可能にできます。

上記ケースのアクセスコントロール例を図示してみます。

アクセスコントロールの例

本記事では、テーブルレベルのアクセスコントロール、および列レベルのアクセスコントロールまでを扱っていきます。

2. 構築時のポイント

具体的な設定方法に移る前に、権限管理する際のポイントをまとめてみたいと思います。

ポイントは(1) IAM権限範囲(2) ペルソナ(3) 権限管理方式の3つあります。 それぞれ簡単に見ていきます。

(1) IAM権限範囲

Lake Formationは、データソースへのアクセスコントロールを行います。同様に、IAMもアクセスコントロールを実現するために利用されます。 したがって、それぞれ権限を細かく設定するか、粗く設定するか、組み合わせを考慮することが必要になります。

基本シナリオは、以下の2通りです。

方法 Lake Formation IAM
方法1(デフォルト) アクセスコントロールしない きめ細かにアクセスコントロールする
方法2(推奨) きめ細かにアクセスコントロールする 粗くアクセスコントロールする

このうち、AWSの推奨は「方法2」になります。 「方法1」は、IAM、S3バケットポリシーなど、複数のサービスにまたがり、複雑に権限管理する必要があります。その上、リソースの変更、追加時、全設定を見直す必要が出てきてしまいます。

ゆえに、「方法2」が推奨されています。しかし、Lake Formationのデフォルト設定は「方法1」になっています。
これは、AWS Glue データカタログの既存動作との互換性を保つためのようです。 したがって、Lake Formationの設定で、「方法2」に切り替える必要があります。 具体的な切り替え方法は後述します。

ここでの話は、以下のドキュメントにより詳細が書かれています。 docs.aws.amazon.com

(2) ペルソナ

どの属性のユーザに何のIAMポリシーを付与するか、その類型のことを、AWS Lake Formation ペルソナと呼びます。

例えば、データレイクの管理者や、データアナリスト、などです。 それぞれに、どの程度の権限を付与するか事前に設計することが重要になります。

以下、AWSが提案しているペルソナの例です。 docs.aws.amazon.com

(3) 権限管理方式

Lake Formationは2つの権限管理方式を提供しています。

名前付きリソースアクセスコントロールは、「ユーザAは、テーブルXにアクセス可能である」のように、ユーザごとに設定する権限管理方式です。
TBACは、「開発者タグを持つユーザは、テーブルXにアクセス可能である」のように、タグ付けによる権限管理方式です。

推奨されているのは、TBACです。理由は2つあります。

  • TBACでは管理する権限の数が、名前付きリソースメソッドよりも少なく済む
  • TBACでは、データソースに1つタグを付与し、各ユーザに対応するタグを付与すればよいです。
    つまり、「ユーザの数 + 管理対象データソース数」のみ管理するだけになります。
    他方、名前付きリソースアクセスコントロールでは、「ユーザの数 x 管理対象データソース数」となります。
  • TBACは、名前付きリソースメソッドよりもスケーラブル
  • リソースが増えた場合、名前付きリソースメソッドでは、全ユーザに対し新たに権限付与が必要になります。他方、TBACでは、リソースにタグを付与するだけで済みます。

    TBACに関するドキュメントは、以下になります。 docs.aws.amazon.com

    3. 権限管理してみる

    ここまで、権限管理に関する考え方を見てきました。ここからは、実際にLake Formationで権限管理していきたいと思います。

    まず、権限付与されていない状態でのクエリ実行を試します。権限管理されていない状態では、どのテーブルにもアクセスできない状態となります。

    次に、テーブルレベルのアクセスコントロールをかけていきます。この時、許可されたテーブルからデータを取得できるようになります。

    最後に、列レベルのアクセスコントロールを試していきたいと思います。許可された列のみ参照できるようにしていきます。

    権限付与されていない場合

    1回目の記事で作成した「データアナリスト」のIAMユーザでログインします。 Athenaコンソールを開き、salesテーブルからデータ取得するクエリを発行してみます。

    以下に添付するキャプチャは、クエリ発行の結果です。 ここから、①テーブルの候補が出てこないこと、②SELECT文の結果データを取得できていないことがわかります。

    権限付与されていないときのアクセスコントロール

    まずは、権限付与されていなければ、アクセスできないことがわかりました。

    権限管理用のタグ作成 (LF-Tag作成)

    「LF-Tag」とは、Lake Formationのタグベース権限管理で利用するタグのことです。 このタグをテーブルや列に付与することで、同じタグを持つユーザのみアクセスできる、といった具合にアクセスコントロールを実現することができます。

    タグベースでの権限管理方式については、権限管理方式で触れました。本記事では、LF-Tagを利用して、権限管理していきます。

    以下、roleというキーに対し、「leader」と「analyst」という2つの値をもつLF-Tagを作成していきます。

    「Add LF-Tag」を押下します。

    「key」と「value」に値を入れ、「Add LF-Tag」を押下します。

    LF-Tag作成後、一覧に作成したタグが表示されます。

    続いて、「データアナリスト」のIAMユーザに、「role=analyst」のタグを付与します。

    「Permissions」 > 「Data lake permissions」 > 「Grant」を選択し、権限付与画面に移動して以下のように設定します。

    テーブルレベルのアクセスコントロール

    続いて、許可されたテーブルにのみアクセスできることを確認していきます。 まず、「データレイク管理者」のIAMユーザで、Lake Formationコンソールを開きます。

    データベースへのアクセス権限付与

    少なくともデータベースに対してDESCRIBEを実行できなければ、テーブルの一覧も取得できません。したがって最初に、データベース自体へのアクセス権限を付与します。

    「Permissions」 > 「Data lake permissions」 > 「Grant」を選択し、権限付与画面に移動して以下のように設定します。

    この段階で、データアナリストはAthenaからデータベースを参照できるようになり、テーブルは参照できない状態になります。

    テーブルにLF-Tagを付与

    次に、roleがanalystのユーザに許可するテーブルを設定します。 「Data catalog」>「Table」から、アクセス許可するテーブルを選択し、「Actions」>「Edit LF-tags」からLF-tags編集画面に移動します。

    「role」タグの値を「analyst」に設定します。

    Athenaから権限設定結果を確認

    タグの設定が完了すると、データアナリストはAthenaからsalesテーブルを参照できるようになります。SELECT文を実行した結果が以下です。

    列レベルのアクセスコントロール

    ここまで、テーブルレベルでアクセスコントロールできることは確認できました。 次に、より細かなコントロールの例として、例レベルのアクセスコントロールをかけていきたいと思います。

    テーブルレベルのアクセスコントロールと同様に、LF-Tagを使って、列レベルのアクセスコントロールを設定していきます。

    テーブルの権限を「leader」に変更。

    「Tables」 > 「テーブル名」 > 「Edit schema」を選択します。

    アクセス許可する列に「analyst」のタグを付与

    analystが参照可能とする列を選択し、「Edit tags」を選択します。

    roleをanalystに変更し、「Save」します。

    Athenaから権限設定結果を確認

    列単位での設定は以上になります。データアナリストIAMユーザでログインし、Athenaコンソールを開くと、指定した列のみが参照できるようになっています。 SELECT文でも、許可された列のみが参照できるようになっています。

    5. 最後に

    AWS Lake Formationを試してみて、LF-Tagを使った設定はかなり簡単で、柔軟に設定できるなと感じました。

    ただ、気を付けておきたい点として、権限を付与、制限する要素それぞれの、「役割・作用」の理解が重要なのだと思いました。

    データレイクにおいて、過剰なアクセスコントロールは使い勝手を著しく損ない、「データスワンプ」になってしまうと言われています。 過剰な権限管理を避けながらも、スケーラブルかつ、安全にアクセスコントロールを設計するのは、エンジニアとしての力量が試されるな、と感じます。

    ここまで全三回に渡りLake Formationを使ったデータレイク構築を試してみた感想として、 Lake Formationは難しい部分はあれど、Lake Formationなしで同じことはしたくない、と感じました。

    ユーザごとの権限管理にせよ、テーブル・列レベルのアクセスコントロールにせよ、Lake Formationなしで構築することは技術的には可能と思います。 しかし、Lake Formationを使う方が簡単にかつ一元的に管理できるのは間違いなく、 Lake Formationの謳い文句である、「安全なデータレイクを数日で簡単にセットアップできる」も、その通りだった、と感じました。

    本連載では、Lake Formationの基本的な使い方と、権限管理に注目してきましたが、AWS Lake Formationには魅力的な機能がまだまだ備わっています。 例えば、行、セルレベルの権限管理、Governed Tableが提供するACID トランザクションのサポートなどです。

    今後、AWS Lake Formationの他の機能も試していければと思います。

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

    AWS Lake Formationでデータレイク体験! #2 Athenaで簡単データ連携

    機械学習アプリケーションエンジニアの@yktmです。

    AWSで構築するデータレイクがテーマの連載、今回は第2回目です。 前回は、AWS Lake Formationの概要と基本となるデータレイクの構築を確認しました。今回は、Amazon Athenaを利用し、前回構築したデータレイクから実際にクエリでデータを取得する部分を試していきます。

    AthenaはS3からSQLで簡単にデータを取得できることが特徴のサービスですが、実際使うと本当に手軽に扱うことができました。 その一方、気を付けておきたいポイントも分かったので、その点を踏まえ、まとめていきたいと思います。

    本記事で扱うのは、赤枠部分です。

    構成図

    1. Athenaとは

    まずはAthenaについて、その概要を見ていきます。

    Athenaは、SQLで、S3内のデータを集計・分析できるサービスです。

    Athenaの特徴は、主に以下4点です。

  • サーバレスで、インフラの管理、設定は不要
  • ソフトウェアの更新や、インフラのスケーリングは自動で行われるため、考える必要はないです。純粋にデータをどう取得、加工するかに集中できます。
  • ハイパフォーマンス
  • 高速にS3からデータを取得、操作できるようにパフォーマンスが最適化されています。クエリの並列実行も自動で行われるため、大規模なデータも、クエリ結果が短時間で取得できます。
  • AWSサービスとの統合、連携
  • Athenaは、AWS Glueと統合されており、Glueのクロール機能やETL機能と組み合わせることができます。また、フェデレーティッド SQLを利用すれば、DynamoDB、Redshift、CloudWatchなど複数のデータソースに対し分析することができます。
  • 機械学習の利用
  • Athena SQL クエリで SageMaker 機械学習モデルを呼び出すことができます。機械学習の推論により、異常検知や予測などの分析が可能になります。

    2. 利用方法

    ここからは、実際にAthenaを利用して、前回構築したデータレイクからデータを取得していきます。 前回の記事で作成した、「データレイク管理者」のIAMユーザで操作していきます。

    (1) クエリ結果保存用バケット作成

    Athenaからクエリを発行すると、その結果は自動的にS3に保存されます。 まずは、クエリ結果保存用のバケットをS3に作成しておきます。

    次にAthenaコンソールを開き、「設定」 > 「管理」から、「クエリ結果の設定」で、クエリ結果の保存先バケットを指定します。

    (2) SELECT文でデータ取得する。

    Athenaのクエリエディターを開くと、前回の記事で作成したテーブルの一覧が表示されていることが確認できます。

    なお、今回は前回の記事でGlueで作成したテーブルにクエリを発行しています。S3にcsvファイルを配置しただけでは、Athenaから参照できないのでご注意ください。

    続いて、SELECT文でsalesテーブルのデータを取得してみます。

    SELECT * FROM "sales" WHERE shop_id = 25 LIMIT 10; をクエリとして入力し、「実行」を押すとクエリ結果が表示されます。

    LIKE句なども、もちろん利用可能です。

    2014年のデータのみに絞り込む場合、SELECT * FROM "sales" WHERE date LIKE '%.2014' LIMIT 10;というクエリで取得できます。

    以下のドキュメントで、クエリに関して詳細に説明されています。

    docs.aws.amazon.com

    3. Athenaを利用する上での注意点

    Athenaは、簡単にS3上のデータを分析することができますが、他方、意図しない超過課金が発生するリスクもあります。データを大量に読み込ませないために、最低限気を付けておきたいポイントを簡単にまとめていきます。

    ワークグループによる制限

    Athenaには、「ワークグループ」という機能があります。

    このワークグループを利用することで、クエリ実行時のスキャンの最大量を設定できます。 スキャン最大量を超えるクエリが実行された場合、クエリはキャンセルされます。

    検証時など、意図しない大量データスキャンを避けるためにも、この設定をしておくことで安心できると思います。 ワークグループ作成時、もしくはワークグループの編集画面より、制限を設定できます。

    ワークグループは、スキャンの最大量制限のほかにも、

    • クエリを実行できるユーザーを管理
    • ワークグループ毎のメトリクス取得
    • ワークグループ毎のコスト管理

    にも利用できます。

    読み込みカラムの指定

    SELECT文でクエリを発行する際、読み込み対象のカラムを明示的に指定することが推奨されています。 特に、大量のカラムがあるテーブルや、文字列ベースのカラムが多い場合に有効なアプローチです。

    Parquet または ORC を利用する。

    AthenaはCSV、TSV、JSONなどのデータ形式のほか、Apache ParquetやLogstash、CloudTrailなどの形式をサポートしています。(サポートしているデータ形式)

    この中でも、Parquet・ORCを利用することが、よいとされています。 Parquetは、Hadoopで利用される列指向のデータ形式です。ORCは、Hiveで利用される列指向のデータ形式です。
    これらのデータ形式を利用するメリットは、2つあります。
    一つは、parquet形式にすることで、単純にデータ量を圧縮できることが挙げられます。 一例として、1TBのCSVファイルも、parquet形式にすることで、130 GBまで削減することができるとされています。

    databricks.com

    データ量を削減できることで、S3の利用コストを削減することができます。

    二つ目の理由として、列指向形式に変換することで、クエリ実行時のスキャンデータ量の削減が期待できる点が挙げられます。 列指向形式のデータにすることで、必要な列のみが選択的に読み込まれ、不要なデータのスキャンを避けることができるため、 コスト削減、パフォーマンス向上に寄与します。

    参考資料

    本記事では、よく使いそうなものに絞って、ベストプラクティス、チューニング方法を挙げてみました。 より詳しい最適化、チューニング方法は、以下のAWSが出している資料に載っています。

    aws.amazon.com

    www.slideshare.net

    4. コスト

    Athenaで発生する料金は「クエリ」に対して発生します。

    クエリ実行時のスキャンデータ量 1TBにつき、5USDが発生します。(リージョンによって、5USD以上の料金になります。)

    上記に加え、S3、Glue、Lambda、Sage Makerなど他サービスを利用する場合、それぞれの料金体系に応じた料金が発生します。 特にS3については、Athenaクエリ結果をS3に保存するため、転送量、リージョンには気を付けておきたい所かと思います。

    5. まとめ

    Athenaを利用するのは初めてでしたが、簡単にSQLでS3のデータを取得、分析できる点は便利だと感じました。

    データ分析をするとき、pythonでPandasを利用することが多いと思います。しかし、Pandasはパッケージとしてのサイズが大きく、サーバレス案件でAWS Lambda xPandasの組み合わせを採用すると、Lambdaのデプロイパッケージに関するサービスクォーターに達しないように意識する必要が出てきます。

    Lambda Layerに載せきれないといった時の代替手段として、Athenaを利用する手もあるんじゃないかなと思いました。 また、数百MB ~ 数GB程度の小~中規模程度のデータの検証、分析であれば、AWSコンソール上で手軽にクエリを実行できる点も魅力だと思います。

    他方、数十GB~数TB級の大規模データを分析する際は、綿密にチューニングしないと、コストとパフォーマンスの面で負担がかかってしまう点は注意が必要だと思いました。

    本記事では、Athena を使って、Lake Formationで構築したデータレイクからデータを取得するところまでを試してみました。 次の記事で、Lake Formationの権限管理で、Athenaからのクエリをアクセスコントロールしていきます。

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

    AWS Lake Formationでデータレイク体験! #1 何がうれしいのか?

    機械学習アプリケーションエンジニアの@yktmです。

    最近、実際の仕事でも、データレイクに関する話を耳にするようになってきました。私自身、あまり経験がない分野だったので、「安全なデータレイクを数日で簡単にセットアップできる」という、うたい文句にひかれて、今回、AWS Lake Formation + Athena による、簡易なデータレイク構築を試してみました。 実際に構築をしてみたところ、つまづいたポイントなどもいくつかあり、特にIAMの扱いや権限の考え方などは重要だと感じました。そこで、実際に構築してみた流れや、つまづいたポイントなどを中心に、記事にまとめていきたいと思います。

    ひとつの記事では、まとまらない量になってしまったので、3回にわたって連載していきます。

    各記事で取り扱うテーマは次の通りです。

    3回の記事を通して、以下の構成で構築していきます。 本記事では、赤枠部分の構築をしていきます。

    構成図

    初回の本記事では、データレイク、およびLake Formationの概要と、Lake Formationの基本的な構築を実施していきます。

    1. データレイクとは

    データレイクとは、様々な形式、かつ、大規模なデータを保存し、一元管理するための仕組みです。 同様に、大量のデータを保存・管理する仕組みとして、従来からデータウェアハウスがありましたが、以下のような違いがあります。

    特徴 データウェアハウス データレイク
    データタイプ 構造化データ すべての構造化・非構造化データ
    データ 分析用に加工したデータ 加工前データ
    分析用途 BI / データビジュアライゼーション 機械学習 / 予測分析
    関連AWSサービス Amazon RedShift S3, Lake Formation

    aws.amazon.com

    2. Lake Formationでできること

    Lake Formationの特徴は以下の3点です。

  • 簡易でスピーディな構築
  • データレイクを構築する際、ストレージの準備、データ取り込み方法、データ整形、セキュリティ、分析、モニタリング、監査など、横断的に検討することがあります。
    そのため、データレイクを一から構築するとなると、それぞれの技術要素に深い理解が求められ、数か月単位で時間・コストが必要とも言われています。Lake Formationでは、そうした障壁なく、短時間でデータレイクを構築することが可能です。
  • きめ細かな権限管理
  • データレイクを利用する際、データのサイロ化が起きないように、事業・業務横断的に、データを管理するケースがあります。
    その際、個人情報などは許可された役割の人にのみアクセス可能にする等の対応が必要になります。Lake Formationでは、データソースレベルだけでなく、行・列レベルできめ細かに権限設定できます。
  • データ取り込みの自動化
  • ブループリントと呼ばれるテンプレートにより、データベースやログのデータの取り込みが容易に設定できます。

    3. データレイク構築

    ここからは、実際にLake Formationでデータレイクを構築していきたいと思います。以下の流れで、データレイクを構築していきます。

    (1) データ準備

    利用データのダウンロード

    本記事では、AI・データサイエンスのコンペティションであるKaggleで公開されているデータを利用します。

    www.kaggle.com

    利用するファイルと、データの内容は、以下のようになっています。

    ファイル名 説明
    sales_train.csv 2013年1月から2015年10月までの日別販売トランザクションデータ
    items.csv 商品名のマスタデータ
    item_categories.csv 商品カテゴリのマスタデータ
    shops.csv 店舗情報のマスタデータ

    S3へのデータアップロード

    取得したCSVファイルを、S3にアップロードします。

    sales_train.csvをsales.csvにリネームし、以下のディレクトリ構成でS3にアップロードします。

    /
    ├ sales/
    |  └ sales.csv/
    ├ items/
    |  └ items.csv/
    ├ item_categories/
    |  └ item_categories.csv/
    └ shops/
        └ shops.csv/

    (2) IAMユーザの準備

    IAM管理者

    こちらは、Lake Formationにおける、ペルソナの考えに従い、AdministratorAccess権限を持つユーザを想定しています。 AdministratorAccess権限は、ルートユーザ同等の権限となるので、扱いには注意が必要です。

    docs.aws.amazon.com

    ワークフロー用ロール

    まず、Lake Formationがデータ自動収集するための、Workflow用にロールを作成していきます。 このWorkflowで収集されたデータは、データカタログという形で整理され、Athenaなどの分析ツールから参照するために使われます。

    この機構はAWS Glueに依拠するもので、実際Lake Formationの裏ではAWS Glueが動きます。

    こちらのロールは、公式ドキュメントに沿って、設定します。 ロールの名前は「LakeFormationWorkflowRole」とします。

    docs.aws.amazon.com

    ここで注意が必要な点として、S3バケットへのアクセス権限を付与する必要があるケースがあるということです。 なぜならば、AWSGlueServiceRoleには、特定のprefixを持つ、S3バケットへのアクセスのみ許可されているためです。

    S3バケットを読み取る権限がないと、Glueでテーブル作成時に以下のようなエラーが発生します。

    今回はインラインポリシーでバケットを読み取る権限を付与します。

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "s3:GetObject"
                ],
                "Resource": [
                    "arn:aws:s3:::{BUCKET_NAME}",
                    "arn:aws:s3:::{BUCKET_NAME}/*"
                ]
            }
        ]
    }

    データレイク管理者

    データレイク管理者は、AWSLakeFormationDataAdmin の権限が必須です。
    次の権限は、オプションとなります。

    • AWSGlueConsoleFullAccess
    • CloudWatchLogsReadOnlyAccess
    • AWSLakeFormationCrossAccountManager

    本記事では、オプションの権限も付与しておきます。

    次に、「datalake-admin-servicelinkrole-create」という名前で、インラインポリシーとしてサービスリンクロール作成権限と、ロール作成権限を付与します。

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "iam:CreateServiceLinkedRole",
                    "iam:PutRolePolicy"
                ],
                "Resource": "*"
            }
        ]
    }

    後述する、Data lake locationsの設定で、AWSServiceRoleForLakeFormationDataAccessというLake FormationのサービスリンクロールをIAMユーザに付与することになります。(ドキュメント)

    iam:CreateServiceLinkedRoleiam:PutRolePolicyが付与されていないと、以下のような権限エラーが発生します。

    最後に、データレイク管理者がWorkflowを利用するため、Pass Roleをインラインポリシーとして付与します。

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Sid": "PassRolePermissions",
                "Effect": "Allow",
                "Action": [
                    "iam:PassRole"
                ],
                "Resource": [
                    "arn:aws:iam::<account_id>:role/LakeFormationWorkflowRole"
                ]
            }
        ]
    }

    最終的に付与した権限はこちらです。

    データレイク管理者のIAM

    ここでは、簡単に記載するため、FullAccessのポリシーを利用していますが、実際には要件に応じて適切な権限に絞ってください。

    データアナリスト

    データアナリスト向けには、Amazon Athena クエリを実行する権限(ここでは、AmazonAthenaFullAccess)を付与します。

    注意が必要な点として、Athenaクエリを実行する際、クエリの結果を保存するS3への書き込み権限が必要になります。 S3への書き込み権限がないままAthenaクエリを実行すると、以下のようなエラーが発生します。

    S3への書き込み権限不足によるエラー

    なので、インラインポリシーでAthena クエリ結果保存用S3への書き込み権限を付与します。
    次のドキュメントを参考に、権限を付与していきます。
    Athena クエリの実行時の「Access Denied (アクセスが拒否されました) 」エラーを解決する

    本記事では、「write-athena-query-result」という名前で、以下のインラインポリシーを付与します。

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "s3:GetBucketLocation",
                    "s3:GetObject",
                    "s3:ListBucket",
                    "s3:ListBucketMultipartUploads",
                    "s3:AbortMultipartUpload",
                    "s3:PutObject",
                    "s3:ListMultipartUploadParts"
                ],
                "Resource": [
                    "arn:aws:s3:::{BUCKET_NAME}",
                    "arn:aws:s3:::{BUCKET_NAME}/*"
                ]
            }
        ]
    }

    データアナリストに付与するIAMは、最終的にこうなりました。

    データアナリスト向けのIAM

    プロジェクトリーダー

    データアナリストよりは広い権限を持ち、データレイク管理者よりは狭い権限を持つユーザを想定して作成します。

    以下のようなポリシーを付与します。

    プロジェクトリーダー向けのIAM

    また、このユーザは、データレイク管理者としては設定せずにおきます。

    (3) Lake Formation構築

    データレイク管理者登録

    ここでの作業は、「IAM管理者 (AdministratorAccessを持つユーザ)」で行います。 前述したように、AdministratorAccess権限はルートユーザ同等の権限となるので、扱いには注意が必要です。

    先ほど作成した、データレイク管理IAMユーザをLake Formation上で、管理者として設定します。

    作成したデータレイク管理IAMユーザをLake Formation上で、データレイク管理者として割り当てます。 Lake Formationを初めて開くと、以下のようなダイアログが出てくるので、 「Add other AWS users or roles」を選択し、データレイク管理者とするIAMユーザを選択します。

    データレイク管理者を設定

    データレイク管理者設定は、「AdministratorAccess 」の権限を持つユーザによって実施可能です。 しかし、次の2つの権限を付与すれば、「AdministratorAccess 」の権限を持つユーザ以外でも、データレイク管理者設定可能です。

    • lakeformation:GetDataLakeSettings
    • lakeformation:PutDataLakeSettings

    ここでポイントになるのは、Lake Formationでは、「暗黙的なアクセス許可」が存在することです。 例えば、「AdministratorAccess 」は、「lakeformation:GetDataLakeSettings」と 「lakeformation:PutDataLakeSettings」の権限が暗黙的に付与されています。

    このほかにも、データレイク管理者・データベース作成者・テーブル作成者にも、それぞれ暗黙的なアクセス許可が付与されています。データレイク構築時、この点を押さえておくことは重要になりそうです。

    docs.aws.amazon.com

    尚、データレイク管理者IAMユーザでログインし、データレイク管理者に自身を追加しようとすると、権限エラーが発生します。最初、「AWSLakeFormationDataAdmin」を付与したIAMユーザで、自身をデータレイク管理者に設定しようとしたところ、User: arn:aws:iam::xxxx:user/admin is not authorized to perform: lakeformation:PutDataLakeSettings with an explicit denyのエラーが発生しました。

    また、注記として、「IAM管理ユーザ (AdministratorAccess AWS 管理ポリシーを持つユーザ) をデータレイク管理者に選択しないことを推奨します。」と公式ドキュメントに記載されています。

    データカタログ設定

    ここでの作業は、IAM管理者で実施します。

    前述のとおり、Lake Formationは、デフォルトでは、「IAMによるアクセスコントロール」のみが適用されるようになっています。 つまり、Lake Formation上での権限管理は、反映されない設定がデフォルトになっているということです。

    これは、Lake FormationはAWS Glueに依拠しており、既存のAWS Glueの挙動との互換性を取るためとされています。

    しかし、Lake Formationでは、「Lake Formation のアクセス許可」によりきめ細かなアクセスコントロールを取ることが推奨されています。 Lake Formationのアクセス許可を有効化するために、「Data catalog settings」から、IAMによるアクセスコントロールのみ適用される設定を変更します。

    データカタログに対する権限管理にLake Formation設定が反映されるように変更する。

    この設定に関して、Classmethod様が詳細に解説しています。 AWS Lake Formationにおけるデータカタログ設定の意味について | DevelopersIO

    データカタログ権限設定

    ここでの作業は、データレイク管理者で実施します。

    Athenaからクエリで参照するための、データカタログの設定をしていきます。 データカタログとは、平たく言えばデータレイク保存されているデータを、分析するために整理されたものです。

    前提として、Lake Formationは、AWS Glueがバックエンドとして動くため、クローラ、ETLなど、Glue の機能をもとにしています。 データカタログの作り方等は、AWS Glue寄りの話題となるので、本記記事での説明は割愛します。

    docs.aws.amazon.com

    S3パスの登録

    Lake Formationコンソールから、「Register and ingest」> 「Data lake locations」>「Register location」を選びます。 次に、データレイクに登録するS3 Pathを指定し、「Register location」を押下します。 ここでの操作が意味するのは、「Data lake locations」で設定されたS3バケットは、Lake Formationの権限管理配下に入ったということです。

    ここで、データレイク管理者にサービスリンクロール作成権限、ポリシー作成権限がないと、以下のようにエラーが発生します。

    権限不足による、S3パス登録の失敗

    データベース作成

    続いて、データベースを作成します。

    データベース・テーブル権限設定

    続いて、データベース・テーブルの権限設定に移ります。

    今回、Glueを利用してテーブルを作成するので、LakeFormationWorkflowRoleがテーブル作成できるように権限付与します。

    データロケーション登録

    「Permissions」>「Data locations」>「Grant」を選びます。 今回は、クロスアカウントではなく、同一アカウントの操作なので、「My account」 「IAM users and roles」で、ワークフロー用ロール(LakeFormationWorkflowRole)を指定します。

    ここでの操作が意味するのは、指定されたS3パスに対し、指定されたユーザ・ロールがデータベース作成権限を得たということです。

    一つ前で設定した、「Data lake locations」と「Data locations」の考え方がややこしいと感じました。
    「Data lake locations」と「Data locations」が、各IAMユーザにどのように作用するか、まとめてみます。

    バケットA、Bという二つのS3バケットが存在するとし、IAMユーザは本記事で作成している3つです。

  • データレイク管理者
  • AWSLakeFormationDataAdmin権限を持ち、かつデータレイク管理者に登録されている
  • プロジェクトリーダー(PL)
  • AWSLakeFormationDataAdmin権限を持っているが、データレイク管理者に登録されていない
  • データアナリスト(アナリスト)
  • Athenaへのアクセス権限のみ保持

    尚、AWSLakeFormationDataAdmin権限は、glue:CreateDatabaseポリシーを保持するため、データベース作成は可能です。 また、データレイク管理者は暗黙的にデータベース作成権限を持つので、すべての条件でデータベース作成可能です。

    Data lake locations Data locations バケットAデータベース作成 バケットBデータベース作成
    バケットA 指定なし データレイク管理者 データレイク管理者、PL
    バケットA バケットAへの権限をPLに付与 データレイク管理者、PL データレイク管理者、PL
    指定なし バケットAへの権限をPLに付与
    →データレイク管理下でないので、設定不可
    データレイク管理者、PL データレイク管理者、PL
    バケットB バケットBへの権限をアナリストに付与 データレイク管理者、PL データレイク管理者、※アナリスト

    上記から、「Data lake locations」で指定されたS3バケットに対して、Data locationsで権限付与されていなければ、AWSLakeFormationDataAdmin権限を持っていてもデータベース作成ができないことがわかります。 つまり、Lake Formationの権限管理配下にあるS3バケットに対して、Lake Formationによる権限付与がなければ操作できないということがわかります。 また、Lake Formationの権限管理配下にないS3バケットに対し、AWSLakeFormationDataAdminを持っていれば、データベース作成できることがわかります。

    ※の部分では、アナリストによるデータベース作成はできますが、 「Unknown error」が発生します。 アナリストのペルソナとして、データベース作成は役割の範囲外となると思います。 ここでは、敢えて権限付与したときの挙動を確かめましたが、通常の運用では役割の分割、設計を行うべきかと思います。

    データベース権限付与

    続いて、データベースに対して、LakeFormationWorkflowRoleがテーブル作成できるように権限付与します。

    「Data catalog」 > 「Tables」 > 「テーブル名」 > 「Action」 > 「Grant」を選択し、「Create Table」権限を付与します。

    データカタログ作成

    データカタログ(テーブル)は、Lake FormationのBlueprintやGlueの クローラを使い自動で作成する方法と、 コンソールから手動で作成する方法があります。

    本記事では、AWS Glueの クローラを利用して、テーブルを作成していきます。 本記事では、Glue自体は詳しく触れません。以下のキャプチャのように設定し、クローラを作成していきます。

    クローラを実行すると、テーブルが作成されます。

    今回は取り扱いませんが、クロスアカウントで利用する場合、S3のACL設定が必要になる場合もあります。

    Glueクローラーで、テーブル作成時にS3から403エラーが返ってきた場合、以下のドキュメントからトラブルシューティング方法を参照できます。

    aws.amazon.com

    4. まとめ

    以上で、Lake Formationを使った、ベースとなるデータレイクの作成は完了です。個人的には、S3やGlueとの連携部分で発生する、IAM権限設定が最初の難関でした。次に、「Data lake locations」と「Data locations」周りの考え方を理解するのに時間がかかりました。
    次回、Athenaを利用し、作成したデータレイクからデータ取得ができるかどうかを見ていきます。

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

    Amazon CloudWatch RUM で Angular アプリのパフォーマンスモニタリングをやってみた

    はじめに

    こんにちは。フロントエンドエンジニアのmiuraです。

    本記事では、2021年12月のAWS re:Inventで発表されたAmazon CloudWatch RUMを、
    AngularのWEBアプリケーションで実際に利用してみて、使い勝手を確認してみたいと思います。

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

    Amazon CloudWatch RUMとは

    概要

    Amazon CloudWatch RUMは、WEBアプリケーションのパフォーマンスやエラーなどをモニタリングすることができるサービスです。
    例えば、ECサイトに組み込むことで、ユーザーがどの端末やブラウザからアクセスしており、コンテンツの表示速度がどのくらいかなどを簡単にモニタリングすることができ、WEBアプリケーションの改善に役立たせることができます。

    f:id:acro-miura:20220228001413p:plain

    特徴

    Amazon CloudWatch RUMでは、以下の4つをモニタリングすることができます。

    • パフォーマンス
      • WEBアプリケーションのパフォーマンス指標である4つの値が収集され、確認することができます。
        • 時刻別の平均ロード時間
        • 最大コンテンツの描画(LCP)
        • 最初の入力遅延(FID)
        • 累積レイアウトシフト(CLS)
    • エラーとセッション
      • HTTPエラーやJavaScript内の想定外のエラーを一覧で確認することができます。
    • ブラウザとデバイス
      • ブラウザやデバイス、国ごとに平均ロード時間やエラー数などを確認することができます。
    • ユーザージャーニー
      • ユーザーが、WEBアプリケーション内のどのページからアクセスして、どのページに遷移したかを確認することができます。

    そして、これらのモニタリングをお手軽に設定できることが、Amazon CloudWatch RUMの最大の特徴になります。

    料金

    Amazon CloudWatch RUMの料金は「イベント」を単位として、100,000 イベントあたり $1の課金が発生します。
    ページの遷移やエラーをそれぞれ1イベントとして計算されるため、JavaScriptや画像などのコンテンツサイズは料金には影響しません。

    Amazon CloudWatch RUMを使ったモニタリング

    それでは実際に、Amazon CloudWatch RUMを設定し、いかに手軽にWEBアプリケーションのモニタリングをできるかを見ていきたいと思います。

    前提

    今回は、以下の前提をもとに手順を示します。
    1. AWSアカウントを持っている。
    2. Node.js v14.15.5以上がインストールされている。

    Amazon CloudWatch RUMの新規追加

    AWSコンソールで、Amazon CloudWatchを開きます。左のサイドメニューより「アプリケーションのモニタリング > RUM」を選択します。
    「アプリケーションモニターを追加」を押下し、アプリケーションモニターの追加画面を開きます。
    f:id:acro-miura:20220227213834p:plain

    アプリケーションモニターの追加画面では、
     ①アプリケーションモニター名
     ②アプリケーションドメイン
    を設定します。
    ②のアプリケーションドメインには、WEBアプリケーションにアクセスできるドメインを設定します。今回はローカルで動作確認できるように「localhost」を指定します。
    上記の①②以外のオプションは、今回、デフォルト設定のままにします。
    画面下部の「アプリケーションモニターを追加」を押下し、追加を完了します。

    f:id:acro-miura:20220227213940p:plain
    f:id:acro-miura:20220227214011p:plain

    アプリケーションモニターが追加されると、WEBアプリケーションに組み込むコードスニペットが表示されます。
    クリップボードにコピー」を押下して、メモに残しておきます。
    ※一度閉じた後でもアプリケーションモニターの設定画面から確認できます。

    f:id:acro-miura:20220227214313p:plain

    WEBアプリケーションへの組み込み

    今回、JavaScriptフレームワークであるAngularを用いたWEBアプリケーションに組み込んでみます。

    まずは、Angular CLIをインストールします。

    npm install -g @angular/cli

    Angular CLIを使って、初期プロジェクトを作成します。

    ng new my-angular-web-app

    初期プロジェクトの作成が完了すると、指定したプロジェクト名(例:my-angular-web-app)のフォルダが作成されるので、そのフォルダを開きます。
    そのフォルダ内にある「src/index.html」を編集するため開きます。
    「head」タグ内の最後に、Amazon CloudWatch RUMを追加したときに取得したコードスニペットを貼り付けて保存します。

    <!DOCTYPE html>
    <html lang="en">
      <head>
        <meta charset="utf-8" />
        <title>MyAngularWebApp</title>
        <base href="/" />
        <meta name="viewport" content="width=device-width, initial-scale=1" />
        <link rel="icon" type="image/x-icon" href="favicon.ico" />
    
        <!-- こちらにコードスニペットを貼り付ける -->
      </head>
      <body>
        <app-root></app-root>
      </body>
    </html>
    

    ここまでで、すでにモニタリングできる準備は整いました。
    しかし、Angularの場合、想定外のエラーをキャッチしてAmazon CloudWatch RUMに送信するために、追加で実装が必要でした。
    「src/app」フォルダ配下に「utils」フォルダを作成し、その中で以下のコードで「cwr-error-handler.ts」を作成します。

    import { ErrorHandler } from '@angular/core';
    
    declare function cwr(operation: string, payload: any): void;
    
    export class CwrErrorHandler implements ErrorHandler {
      handleError(error: any) {
        console.error(error);
        cwr('recordError', error);
      }
    }
    

    「app.module.ts」を開き、「providers」に「ErrorHandler」を追加します。

    import { ErrorHandler, NgModule } from '@angular/core';
    import { BrowserModule } from '@angular/platform-browser';
    
    import { AppRoutingModule } from './app-routing.module';
    import { AppComponent } from './app.component';
    import { CwrErrorHandler } from './utils/cwr-error-handler';
    
    @NgModule({
      declarations: [AppComponent],
      imports: [BrowserModule, AppRoutingModule],
      providers: [
        {
          provide: ErrorHandler,
          useClass: CwrErrorHandler,
        },
      ],
      bootstrap: [AppComponent],
    })
    export class AppModule {}
    

    以上で、WEBアプリケーションへの組み込みが完了しました。
    以下のコマンドでWEBアプリケーションを起動し、http://localhost:4200を開きます。

    npm start

    WEBアプリケーションを開いた時点でAmazon CloudWatch RUM(https://dataplane.rum.<リージョン>.amazonaws.com)への送信が開始されます。
    そして、画面遷移やエラーが発生する度にその情報が送信され、Amazon CloudWatch RUM上に表示されます。

    f:id:acro-miura:20220227224600p:plain

    パフォーマンスの確認

    数回WEBアプリケーションの表示を行うと、Amazon CloudWatch RUM上にログが蓄積し、ウェブバイタルやユーザージャーニーなどにグラフが表示されます。
    ウェブバイタルの場合、グラフには「Positive」「Tolerable」「Frustrating」という3つのしきい値があらかじめ設けられています。
    それぞれ「Positive」ならパフォーマンスが良く、「Tolerable」なら許容できる程度のパフォーマンスがあり、「Frustrating」ならユーザーがイライラするほどパフォーマンスが悪いことを示しています。

    例えば、下図の場合、「最大コンテンツの描画」では、計6回のアクセスのうち5回は「Positive」で、1回は「Frustrating」であったことが、時系列で確認できます。
    もし今後「Frustrating」が多くなった場合は、パフォーマンス改善が必要ということになります。

    f:id:acro-miura:20220307225723p:plain

    また、Amazon CloudWatch RUMでは、WEBアプリケーションが複数ページある場合、それぞれのページを指定して表示することができるため、どのページで改善が必要なのかを確認することもできます。

    f:id:acro-miura:20220307231825p:plain

    使用感

    使いやすい点

    • お手軽にWEBアプリケーションのモニタリングを始められる
      • Amazon CloudWatch RUMの最大の特徴として記載したが、基本的にindex.htmlにコーススニペットを追加するだけで、モニタリングを始めることができるのは良いと思いました。

    注意が必要な点

    • JavaScriptフレームワークによっては追加の実装が必要になる
      • AngularなどJavaScriptフレームワークによっては、想定外のエラーを内部でキャッチしてしまうため、今回のような追加の実装が必要になります。
    • 問題を検知して自動で通知してくれる機能がない
      • Amazon CloudWatch RUMは、AWSコンソール上で状況を確認することを前提のサービスのため、メール通知といった機能は自身にはありません。
      • Amazon CloudWatchのアラーム機能を駆使することで閾値による通知を設定することは可能のようです。
    • ユーザージャーニーにて、動的に変わるURLを同じページとみなすためには、追加の実装が必要になる
      • 表示するページは同じだが、中身の値を変化させる場合、「/users/<ユーザーID>」のようにURLを動的に変えることがあります。
      • この動的に変わるURLを同じページとみなしたい場合は、aws-rum-web/cdn_angular.md at main · aws-observability/aws-rum-web · GitHubのように、追加で実装をする必要があります。

    さいごに

    以上で、Amazon CloudWatch RUMを使ったモニタリングは完了です。

    とにかくお手軽にWEBアプリケーションのモニタリングを始めたい、という人におすすめできるサービスだと思いました。
    また、X-Rayと一緒に活用することで、よりWEBアプリケーションの運用に役立ちそうです。

    それでは。

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

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

     
    少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
    サーバーレスでサービス開発を行いたいクラウドエンジニア募集! - Acroquest Technology株式会社のシステムエンジニアの採用 - Wantedlywww.wantedly.com

    Amazon QuickSightで異常検出してみた

    こんにちは、エンジニアの駿です。

    最近AcroではWordleが流行っており、親の仕事の都合で中学3年間をアメリカで過ごし英語が得意を売りにしている身としては2回くらいで当てたいと思っているところ。
    ですが、なかなかうまくいきません。。。

    普段、サーバーレスでの開発をしており、私自身は、QuickSightの利用はまだ経験が浅いのですが、BIで異常検知もできる、ということで、どのようなことができるのか、試してみました。

    f:id:acrosyoshioka:20220308111445p:plain:w25:h25 Amazon QuickSightとは

    Amazon QuickSightAWSが提供する可視化用のツールで、 各種AWSサービス、サードパーティクラウド、オンプレのデータに接続し可視化できるだけでなく、 機械学習の統合、Qを用いた自然言語の質問を使ったクエリなど、必要な情報を簡単に手に入れることができます。

    QuickSightの機械学習機能、ML Insightsには3つの主要機能があります。

    1. 異常検出

      機械学習を用いて、時系列データを分析し、異常を検出します。
      また、異常につながった主な要因の特定、Eメールでのアラートなどを行うことができます。

    2. 予測

      機械学習を用いて、時系列データの予測を行います。
      追加の設定不要で、季節性や欠損値など複雑なシナリオにも自動で対応します。

    3. 自動説明文生成

      最大/最小をはじめとするデータの内容を、自動でわかりやすい説明文として表示することができます。
      必要な情報を得るためにチャートや表を調べる必要がなくなり、また、組織内でデータの理解を共有することができます。

    下の画像は公式のQuickSight紹介ページに載っているIoTデバイスの情報を可視化したデモダッシュボードです。
    可視化するだけでも必要な情報を一目で見られるようにできて、さらにML Insightsを使うことで異常検出と予測の情報を付け加えることができる、と考えると、非常に強力なツールになりそうです。

    f:id:acrosyoshioka:20220223182521p:plain
    公式のIoTデモ(https://d2lzvqq4w5ulk4.cloudfront.net/?dashboardName=iot

    異常検出してみる

    今回は、周期性のある時系列データと複数の要素を含む時系列データを使って、QuickSightの異常検出を実際に試してみます。

    f:id:acrosyoshioka:20220306031949p:plain
    周期性のある時系列データ

    f:id:acrosyoshioka:20220306032015p:plain
    複数の要素を含む時系列データ

    周期性のある時系列データ

    QuickSightのML Insightsを使って異常検出をするためには大きく3つのステップが必要です。 (1) QuickSightにサインアップする、 (2) データをアップロードする、そして最後に (3) ビジュアル/インサイトを追加します。

    まずは周期性のある時系列データで各ステップを説明します。

    (1) QuickSightにサインアップする

    AWS ConsoleからQuickSightを初めて開くとき、サインアップを求められます。 ダイアログに従ってサインアップを行ってください。

    なお、Editionを選択するダイアログでは、「Enterprise」を選択してください。 「Standard」を選択してしまうと、ML Insightsの機能が利用できません。

    (2) データをアップロードする

    QuickSightコンソール右上の「新しい分析」>「新しいデータセット」の順にクリックして、データをアップロードします。

    今回は single-anomalydata.csv という名前のファイルを用意しました。 中身は下記の様にセンサーID、日時、値が約10分起きに記録されたシンプルな物になっています。

    id timestamp value
    sensor01 2018-11-28 00:00:00 151.87
    sensor01 2018-11-28 00:09:56 157.66

    「ファイルのアップロード」をクリックし、ファイル選択ダイアログで single-anomalydata.csv を選択すると、プレビューが表示されるので、「次へ」をクリックしデータセット作成を完了します。

    「設定の編集とデータの準備」を使うと、別のCSVとの結合やフィルタ、列の削除などが行えます。 今回は編集せずにそのまま扱います。

    f:id:acrosyoshioka:20220223180617p:plain
    ファイルプレビュー

    (3) ビジュアル/インサイトを追加

    ファイルをアップロードし、データセットを作成した後は、ビジュアルを追加して可視化を行います。

    左上の「+追加」>「ビジュアルを追加」を選択し、可視化する要素として「timestamp」と「value」を選択します。
    この時、それぞれの要素をクリックするだけで、QuickSightが自動でtimestampをx軸、valueをy軸に設定してくれます。
    デフォルトだとtimestampの集計間隔は「日」になっていますが、今回は10分間隔のデータを扱うため、集計間隔を「分」に変更します。
    また、y軸の値の集計方法は「合計」「平均」「最大/最小」などから選択することができます。 データに応じて適した集計方法を選択してください。
    可視化した結果を図に示します。 今回用意したデータには2018/12/19 7:30前後に異常なデータがあることが分かりました。

    次にインサイトの異常検出を使って、この異常を検出できるか試してみます。

    f:id:acrosyoshioka:20220223180742p:plain
    ビジュアル/インサイトの追加
    f:id:acrosyoshioka:20220223180747p:plain
    周期性のあるデータ可視化

    今度は「インサイトを追加」を選択し、表示されるプルダウンから「異常値検出(ML駆動型インサイト)」を選択します。
    続いてビジュアルと同様に「timestamp」と「value」を選択します。 集計間隔と集計方法もビジュアルと同じ設定を行います。
    「今すぐ始める」ボタンが現れるため、それをクリックし、異常検出の設定を行います。
    「異常検出をセットアップ」画面で異常検出の設定を行うことができます。 今回はすべてデフォルトのままでよいので、右上の「保存」を選択します。
    次に「今すぐ実行」ボタンが表示されるので、クリックします。 「異常値の分析中…」と表示されたら、解析が終わるのを待ちます。

    5分ほど待つと異常検出の結果が表示されます。
    2018/12/19 05:03に異常が見つかったようです。
    「異常の探索」を選択し、詳細を見てみます。

    f:id:acrosyoshioka:20220223180721p:plain
    異常発見

    ビジュアルを作成して、目視で確認できた7:30前後の異常が確かに検出できていました。
    普段であれば、正常データを機械学習モデルに学習させて、そのモデルを使って異常検出をしていたところ、QuickSightのML Insightsを使えば画面をポチポチするだけでカンタンにできてしまいました。

    f:id:acrosyoshioka:20220223180744p:plain
    以上詳細

    複数の要素がある時系列データ

    次に要素の多いデータでもML Insightsを試してみました。

    先ほどのデータセットでは値を1つしか使いませんでしたが、今度は、気温、湿度など5つの要素を持つデータを準備しました。 こちらのKaggleのデータセットを元にしています。
    表の様に5つの要素を縦持ちにしたセンサーデータです。 また、値は各要素毎に値が0-1の範囲に収まるように正規化してあります。

    Time SensorType Value
    2021-06-15 18:21:46 Temperature 0.314
    2021-06-15 18:21:46 Humidity 0.386
    2021-06-15 18:21:46 Air Quality 0.0
    2021-06-15 18:21:46 Light 0.380
    2021-06-15 18:21:46 Loudness 0.161

    Time列がUnix時間となっており、このままだとQuickSightが日時と認識してくれないため、「設定の編集とデータの準備」で計算フィールドを追加し、Unix時間から日時文字列への変換を行いました(epochDate({Time}))。

    可視化した結果がこちらです。

    f:id:acrosyoshioka:20220223180733p:plain
    複数要素可視化

    また、時間にTime、値にValue、カテゴリにSensorTypeを設定して異常検出を実施したところ、下記のように各要素で異常が発生した箇所を見つけることができました。 線が紺色になっている部分が、異常が検出された部分です。また、異常の開始時刻は紺色の点で示されています。

    f:id:acrosyoshioka:20220306033118p:plain
    Temperature
    f:id:acrosyoshioka:20220306033120p:plain
    Humidity
    f:id:acrosyoshioka:20220306033122p:plain
    Light

    下の様に、各要素で異常が発生した日時をまとめて確認することもできるため、同時期に他にどのような異常が発生しているのかを一度に確認することができます。

    f:id:acrosyoshioka:20220223180730p:plain
    Multiple

    ただし、上記の様に各要素毎に異常がある部分を検出することはできましたが、要素間の異常検出は現状できないようです。

    例えば可視化した図を見ると、TemperatureとLightに相関があり、TemperatureとHumidityに負の相関があることが分かりますが、 この相関が崩れた時に異常と判定する、といったことはできません。
    あくまで一度に異常を検出できる時系列データはひとつだけの様です。

    f:id:acrosyoshioka:20220223180735p:plain
    2つ設定できない

    同様に、Temperatureに異常があったときに、どの要素がその異常に最も寄与しているかを産出させることもできません。
    QuickSightの異常検出には「上位の寄与要因」といって、異常の背後にある主要な要因を見つける機能があるのですが(「異常検出をセットアップ」で設定可能)、 この機能はカテゴリデータのみに対応しており、時系列データは扱えません。
    この寄与要因はチュートリアルやサンプルを見る限り、「会社の売り上げが大きく下がったときに、どの地域の売り上げがよくなかったのか、どの分野の売り上げがよくなかったのか」といった要因を調べるための物の様でした。

    このような相関分析ができるようになると、活用の幅がさらに広がりそうです。

    料金

    ML Insightsを用いるには、評価されたメトリクス数に応じて料金がかかります。

    評価されたメトリクス 料金/1,000 評価されたメトリクス
    1~1,000,000 $0.5
    1,000,001~10,000,000 $0.25
    10,000,001~100,000,000 $0.1
    >100,000,000 $0.05

    評価されたメトリクス数は、メトリック数x評価回数を元に計算されます。 評価方法などはQuickSight料金計算ツールの例を参考にしてください。

    If you set up one alert to run hourly, that would bill as 24 metrics per day (or 720 metrics per month).
    If you set up an Anomaly Detection job to watch “sales”, and then added break-downs by region (four regions) and product category (let’s assume 10 categories),
    that could be up to 55 metrics (1 sales + 4 regions + 10 categories + 4*10 region-categories, depending on if you choose to run it for all combinations of the data).
    If you ran that anomaly job daily, you’d expect to run 1.65 per thousand metrics (55 * 30 = 1,650) per month.
    

    それ以外に、ユーザーごとの料金として、Enterprise Edition だと、Authorユーザー(ダッシュボードの作成者)で$24/月、Readerユーザー(ダッシュボードの閲覧者)で最大$5/月の料金がかかります。

    今回は評価されたメトリクスが1,000に満たないため、Authorユーザの料金と合わせて、$24.5ほどでQuickSightとML Insightsを利用することができました。
    上の例のように55のメトリクスを一日一回異常検出に使用したとすると、ひと月に異常検出にかかる料金は$1弱になる計算なので、非常に安く利用できると思います。

    注意点

    形式

    いくつか、ML Insightsの異常検出を利用するにあたって注意が必要な箇所がありました。

    1. 解析されるデータは時系列データである必要がある。

      時折、時系列データでも日時ではなく、インデックスが振ってある物がありますが、 インデックスが日時カラムと認識されないため、QuickSightが時系列データとして扱ってくれません。
      また、日時カラムが文字列ではなくUnix時間になっている場合は、上で紹介したように、データ読み込み時に変換する必要があります。

    2. 横持ちより縦持ちの方が扱いやすい。

      カラムに各要素の値を持つ横持ちのデータも、要素毎に行が分かれている縦持ちに変換することで、カラム名をカテゴリとして活用できるようになります。

      横持ちのデータも分析はできますが、複数の要素がある時系列データで示したようにまとめて異常検出をすることや、 ML Insightsの機能の一つである、「上位の寄与要因」の分析ができない、といったデメリットがあります。

      縦持ちデータの例

      日時 センサ種類
      2021-06-15 18:21:46 温度 20.5
      2021-06-15 18:21:46 湿度 30.5
      2021-06-16 18:21:46 温度 21.5
      2021-06-16 18:21:46 湿度 28.5

      横持データの例

      日時 温度 湿度
      2021-06-15 18:21:46 20.5 30.5
      2021-06-16 18:21:46 21.5 28.5

    データ量

    異常検出を実行する前に要件を確認してください。

    • 少なくとも1つの日付ディメンションが必要
    • 異常検出のトレーニングに最低15のデータポイントが必要

    などの要件があります。

    まとめ

    今回はAmazon QuickSightのML Insightsを使って異常検出をしてみました。

    低コストで簡単に異常検出を行うことができ、びっくりしました。
    1つ目に紹介した、周期性のある時系列データを用いた内容を実施するのに30分ほどしかかかりませんでした。

    これだけ簡単にできるのは、学習データの準備など煩わしいことをしなくても、 ML Insightsが教師なし学習をしてくれるからで、専門知識がない人でも適用できると思われました。

    また、現状、相関分析まではできないようですが、複数の系列データを一度に分析できるのも、実用的だと感じました。

    是非皆さんも一度試してみてください。

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

    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