Taste of Tech Topics

Taste of Tech Topics

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

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

    ElasticON Global 2021 最速レポート

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

    最初に個人的な話で恐縮ですが、今週「Elastic認定オブザバビリティエンジニア」の資格を取得したので、
    以下3つの認定資格をコンプリートしました!
    ・Elastic認定エンジニア
    ・Elastic認定アナリスト
    ・Elastic認定オブザバビリティエンジニア

    さて、本題です。
    現在Elastic最大のイベントである、「ElasticON Global 2021」が 10/05~10/07で開催中です。
    今年も去年に引き続きオンラインでの開催で、多くのセッションがあり盛り上がっています!

    f:id:acro_nomura:20211006114948p:plain:w500

    アジェンダ

    全部で、100近いセッションがあります。
    3日間の開催ですが、後半2日間は各地域のタイムゾーンに合わせて同一内容を再配信する形式になっています。

    セッションの一覧は下記のURLから確認することができます。
    www.elastic.co

    今回は、Keynoteについて簡単に内容をご紹介します。

    ElasticON Global Opening Keynote: Solving for innovation

    Elastic社CPOであるAshutosh Kulkarni氏、Microsoft社のScott Guthrie氏、そしてElastic社CEOであるShay Banon氏による発表でした。

    f:id:acro-shiroi:20211007001849p:plain:w500

    Keynoteでは大きく以下について、話がありました。
    ①Azure等のクラウドプロバイダーとの連携について
    ②Observability、Enterprise Search、Securityの各ソリューションについて

    Azure等のクラウドプロバイダーとの連携について

    Elastic社は去年から今年にかけて、各クラウドプロバイダーと連携を強化しています。
    現在では5つのクラウドプロバイダーを利用でき、リージョン数も40を超えています。
    f:id:acro_nomura:20211006120703p:plain:w500

    またクラウド上で非常に簡易にElasticStackを構築することが可能です。
    今回のKeynoteではAzure上に構築するデモが紹介されていましたが、構築完了までほんの数クリックです。
    f:id:acro_nomura:20211006124359p:plain:w500

    仮想ネットワークとElastic Cloud を直接繋ぐPrivateLinkが利用可能となったほか、最新版である7.15では通信コストが以前から50%~70%抑えられるようになっているそうです。
    f:id:acro_nomura:20211006131429p:plain:w500

    Observability、Enterprise Search、Securityの各ソリューションについて

    次に各ソリューションについて最新版ではどのようなことが可能なのか紹介がありました。

    その中でもEnterprise SearchのWeb Crowlerは一押しの便利機能です。
    デモでは画面から簡単にElastic社のブログをクロール/インデキシングして検索可能とするデモを紹介。
    f:id:acro_nomura:20211006214538p:plain:w500

    また以下のスライドの通り、Enterprise Searchでは様々なサービスのメッセージやファイルをインデキシングして検索可能です。
    企業内検索を簡易に実現できるのは嬉しいですね。
    f:id:acro_nomura:20211006214010p:plain:w500

    Securityでは Limitless XDR として、エンドポイント検知や対処が強化されました。
    特にクラウドセキュリティは注目すべき部分だと思います。
    Elastic Stackという単一のプラットフォームで「SIEM」「エンドポイントセキュリティ」「XDR」の機能をフル活用できるのは
    非常に魅力的だと感じました。
    f:id:acro_nomura:20211007003807p:plain:w500

    次の記事ではKeynote以外のセッションについて紹介予定です。お楽しみに!

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

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

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

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

    GraphQL APIをKarateで自動試験する

    こんにちは、QAの@kareyama_rです。
    最近お花のサブスクを始めました🌹
    リモートワークで家にいる時間が長いので、部屋に季節の彩りが添えられて嬉しいです。

    ソフトウェア開発において、自動試験・テスト自動化の話題はよく聞くようになりましたが、ユニットテストとE2Eテストが主体になっているように感じます。
    当社では、ユニットテストとE2Eテストの間に来るインテグレーションテストとして、API試験の自動化も積極的に取り組んでいますが、E2Eテストより運用コストを抑えられるので、より対象範囲を拡大して導入していきたいと考えています。
    そこで今回は、GraphQL で実装されたAPIを、テスト自動化フレームワークの Karate で検証してみました。

    はじめに

    最初に、知らない方のために、簡単に今回の対象について紹介します。

    GraphQL とは

    GraphQL はWeb APIのための仕様で、リクエスト時に利用されるクエリ言語と、クエリを実行するサーバ側のランタイムから成ります。
    APIから提供されるエンドポイントは1つだけで、リクエストクエリで取得するデータフィールドを指定できます。
    フロントエンドとしては、REST-APIと比べて、少ないリクエストで必要なデータが取得できるメリットがあります。感覚的には、フロントエンドから利用できるSQLのような印象です。

    https://graphql.org/

    Karate とは

    Karate はE2Eテストや負荷テストを含むテスト自動化フレームワークであり、特にAPIテストに使いやすい機能が多く揃っています。
    REST-APIのテストでよく利用されていますが、WebSocket や GraphQL のテストも可能です。
    GraphQLのようにリクエスト内容によってレスポンス形式が変わるAPIでも、柔軟に試験を行うことができます。

    https://intuit.github.io/karate/

    GitLab の GraphQL API の確認

    今回は、試験対象として、GitLabが提供しているGraphQL APIを利用します。
    GitLabのチケット(Issue)の操作を、GraphQL APIから実行してみます。以下の内容です。

    • 一覧取得(Query): チケット一覧取得
    • 1件取得(Query): チケット詳細の取得
    • 更新(Mutation): チケットステータスの更新

    API Docはこちら

    予めテスト用にGitLabで`graphql-test`というプロジェクトを用意し、適当なIssueを作成してあります。
    f:id:acro-engineer:20210913003346p:plain

    GitLabが用意しているGraphiQL explorerを使い、クエリを実行してみます。

    チケット一覧取得

    プロジェクトを指定し、Issueの数とID・タイトルを取得します。

      query {
        project(fullPath: "sandbox17/graphql-test") {
          name
          issuesEnabled
          issues {
            count
            nodes {
              iid
              title
            }
          }
        }
      }
    

    3件のテストデータが取得できました。

    {
      "data": {
        "project": {
          "name": "graphql-test",
          "issuesEnabled": true,
          "issues": {
            "count": 3,
            "nodes": [
              {
                "iid": "3",
                "title": "issue3"
              },
              {
                "iid": "2",
                "title": "issue2"
              },
              {
                "iid": "1",
                "title": "Issue1"
              }
            ]
          }
        }
      }
    }
    
    チケット詳細の取得

    プロジェクトとチケットIDを指定します。
    チケットIDはvariablesとして定義し、値を自由に変えられるようにしています。

    query ($iid: String!) {
      project(fullPath: "sandbox17/graphql-test") {
        issue(iid: $iid) {
          iid
          title
          state
          author {
            name
          }
          description
          labels {
            nodes {
              title
            }
          }
          dueDate
        }
      }
    }
    
    {
      "iid": "2"
    }
    

    タイトルやステータス、本文、ラベル、期日が取得できました。

    {
      "data": {
        "project": {
          "issue": {
            "iid": "2",
            "title": "issue2",
            "state": "opened",
            "author": {
              "name": "kaya"
            },
            "description": "Issue2の本文です",
            "labels": {
              "nodes": [
                {
                  "title": "Label02"
                }
              ]
            },
            "dueDate": "2021-09-30"
          }
        }
      }
    }
    
    チケットステータスの更新

    mutationでIssueをクローズします。

    mutation {
      updateIssue(input: {projectPath: "sandbox17/graphql-test", iid: "3", stateEvent: CLOSE}) {
        errors
        issue {
          iid
          state
        }
      }
    }
    
    {
        "data": {
            "updateIssue": {
                "errors": [],
                "issue": {
                    "iid": "3",
                    "state": "closed"
                }
            }
        }
    }
    

    Karate を利用した GraphQL のテスト

    先ほどまでで実行した GitLab の GraphQL API の内容を、Karateを利用して、クエリの実行・レスポンス内容を行ってみます。
    Karateプロジェクトの作成方法は、公式ドキュメントを参照してください。

    まず1つ目のクエリ、「チケット一覧取得」を実行し、3件のチケットが取得できることを検証します。
    Karateプロジェクトにquery_issues.featureというファイルを作成し、以下の内容を記載します。

    Feature: GitLabのチケット(Issue)を取得する
    
    Background:
      * url 'https://gitlab.com/'
    
    Scenario: チケット一覧取得
      * text query = 
      """
      query {
        project(fullPath: "sandbox17/graphql-test") {
          name
          issuesEnabled
          issues {
            count
            nodes {
              iid
              title
            }
          }
        }
      }
      """
      Given path '/api/graphql'
      And request { query: '#(query)' } #リクエストボディを設定
      And header Accept = 'application/json' 
      When method post  #リクエストをPOST
      Then status 200  #レスポンスステータスが200であることを確認
      And match response.data.project.issues.count == 3  #チケットが3件あることを確認
      * print response
    

    Karateはリクエストボディを定義する際、多くの場合defというキーワードを使いますが、GraphQLのクエリを渡すとJSON形式として解釈されてしまいます。
    そのためGraphQLのクエリは、textというキーワードで宣言します。

    実行すると、このようなレポートが出力されました。
    f:id:acro-engineer:20210915222914j:plain
    KarateでGraphiQL explorerと同じリクエストが実行され、レスポンスに対する検証もできました。


    次に、「チケット詳細の取得」についても検証します。
    今度はクエリを別ファイルに保存して読み込むようにしています。
    .graphqlファイルで渡すと、defキーワードでも自動的にGraphQLのリクエストとして扱ってくれるようです(優秀!)

    また、variablesを定義して、queryと一緒にリクエストボディとして渡します。

    検証内容は「ステータスが"opened"であること」「ラベルに"Label02"が含まれていること」に変更します。
    レスポンスデータのネストは、".."で表記を省略できます。

    Scenario: チケット詳細取得
      Given def query = read('issue_detail.graphql')
      And path '/api/graphql'
      And def variables = { iid: "2" }
      And request { query: '#(query)', variables: '#(variables)' }
      And header Accept = 'application/json'
      When method post
      Then status 200
      And match response..state == ['opened']
      And match response..labels.nodes.[*] contains {title: Label02}
      * print response
    

    実行すると、このようになりました。
    f:id:acro-engineer:20210915225409j:plain

    最後に、「チケットステータスの更新」を行います。
    更新時のレスポンスでも結果を取得できますが、更新後に再度チケット詳細をクエリして、ステータスがCLOSEになっているか確認するシナリオを組んでみます。

    Feature: GitLabのチケット(Issue)を更新する
    
    Background:
      * url 'https://gitlab.com/'
    
    Scenario: チケットステータス更新
      * text query = 
      """
        mutation {
            updateIssue(input: {projectPath: "sandbox17/graphql-test", iid: "3", stateEvent: CLOSE }) {
                errors
                issue {
                iid
                state
                }
            }
        }
      """
      Given path '/api/graphql'
      And request { query: '#(query)' }
      And header Accept = 'application/json'
      And header Authorization = 'Bearer <アクセストークン>'
      When method post
      Then status 200
      * print response
    
      # 更新結果を検証
      Given def query = read('issue_detail.graphql')
      And path '/api/graphql'
      And def variables = { iid: "3" }
      And request { query: '#(query)', variables: '#(variables)' }
      And header Accept = 'application/json'
      When method post
      Then status 200
      And match response..state == ['closed']
      * print response
    

    チケット情報を取得するクエリを別ファイルにしたことで、使い回しができます。
    結果のレポートはこのようになりました。
    f:id:acro-engineer:20210916005503j:plain

    まとめ

    Karateを使って、GraphQLのAPIも簡単に実行・検証できました。
    特にGraph QLに対してKarateでテストする際、以下の機能がサポートされているのがありがたかったです。

    • QueryとMutationの実行
    • Variablesの受け渡し
    • .graphqlファイルの読み込み

    GraphQLはリクエスト時に自由に取得フィールドを指定できる分、レスポンス形式も流動的になりますが、Karateであれば必要な箇所のみ取り出して柔軟な検証を行えます。
    また、GraphQLのレスポンスは階層が深くなりがちですが、Karateならすっきりと書くことができました。

    ぜひAPIテストを自動テストの1つとして取り入れてみて下さい。
    それでは。


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

    ACM SIGIR 2021 に参加してきました

    こんにちは、@shin0higuchiです😊
    7/11~7/16に、情報検索のカンファレンスである ACM SIGIR 2021 がオンライン開催されました。
    私も参加してきたので、概要や特に興味深かったセッションについてブログを書きます。

    1. 概要

    1. SIGIRとは

    ACM(コンピュータ分野全般を対象とする国際学会)が主催するカンファレンスで、毎年一回開催されます。
    ACMは毎年数多くのカンファレンスを主催しており、SIGIRは Special Interest Group on Information Retrieval の略で、毎年情報検索に関する様々な研究成果が寄せられます。

    2. 今年のSIGIR

    昨年のSIGIRは中国の西安で開催され、リモートでの参加が可能という形となっていましたが、
    今年は完全オンラインということで、Underline / Zoom / Gather.Town などを駆使した催しとなっていました。
    オンラインではありましたが、約1000人(46か国)が参加したようです。

    Gather.Townは私自身初めて利用したのですが、
    ポスターセッションなどもストレスなく回ることができてとても良いプラットフォームだと感じました。
    仮想空間上を自由に歩き回ることができ、近くの人と会話したり、ポスターや企業ブースを回ったりと、かなり自由度が高かったです。
    (~25人のスペースなら無料で作れるようなので、遊んでみるのも面白いかもしれません)
    gather.town


    f:id:shin0higuchi:20210722151229p:plain:w700
    f:id:shin0higuchi:20210722151340p:plain:w700

    Underlineでのセッション視聴も使いやすく快適でした。(オープニングセッションの様子)
    f:id:shin0higuchi:20210723052055p:plain:w800
     
    学会全体での論文傾向などはオープニングセッションで紹介されていました。
    short paper なども含めると1410ものサブミッションがあり、382本が Accept されたそうです。
    https://waseda.app.box.com/v/sigir2021opening

    セッションのカテゴリは以下の通りで、
    私は主に「Recommendation」、「Searching and ranking」、「Question answering」などを中心に聞いていました。
    f:id:shin0higuchi:20210723050957p:plain:w800

    3. 昨年との傾向比較

    今年のトピック一覧を見てみると、「Content recommendation, analysis and classification」「Search and ranking」などが多いことがわかります。
    f:id:shin0higuchi:20210724100324p:plain:w800

    ちなみに、昨年のAccepted Papersのトピック分布はこちらです。昨年は圧倒的にRecommendationが多かったですが、この分野は引き続き研究が盛んであることがわかりますね。
    f:id:shin0higuchi:20210724095622p:plain:w800

    2. 興味深かったセッション

    1. Reinforcement Learning from Reformulations in Conversational Question Answering over Knowledge Graphs (Magdalena Kaiser, Rishiraj Saha Roy, Gerhard Weikum)


    Question Answering(以下QA)で、会話を通して強化学習するというトピック。

    良い質問応答のシステムを作るためには、良い応答と悪い応答を適切に判断して学習させる必要があります。
    システム側は常に「良い応答」だと思って応答を出力するので、良し悪しの判断は原則外部(質問者)からフィードバックされることが必要です。
    一般的に、会話で期待通りの答えが返ってこない時、自分の質問を言い換えることがあると思いますが、
    QAのシステム側から見れば、ユーザーが言い換え(Reformulation) を行った場合は、適切な回答ではなかったと考えることができます。


    f:id:shin0higuchi:20210723045026p:plain:w800

    この研究では、入力される発話が「新たなインテント」「言い換え」のどちらであるのかを推論し、
    言い換えであった場合は reward = -1、新たなインテントであった場合は reward = 1 とすることで、回答を生成する強化学習モデルにフィードバックすることが提案されています。
    インテント」というのは、目的・意図といった意味で、ここではユーザーが「何を訊きたいか」を意味します。
    つまり、訊きたいことに対する適切な回答が得られた場合は次の質問(=新たなインテント)、得られなかった場合は言い換えをするという仮説に基づいた考えです。

    Reformulationの判定にはファインチューニングされた BERTモデルを利用しているそうです。
    モデル全体のアーキテクチャは下図のようになっています。
    f:id:shin0higuchi:20210723044352p:plain:w800


    コードはこちらで公開されています。
    github.com

    QAは個人的にかなり興味のある分野だったのでためになりました。

    2. Personalized News Recommendation with Knowledge-aware News Interactions (Tao Qi, Yongfeng Huang, Chuhan Wu, Fangzhao Wu)

    ニュースのレコメンデーションに関するトピックでした。ニュースをレコメンドする際には、

    • ユーザーの関心
    • 推薦候補記事同士の関連性

    を紐づけることでユーザーごとに適切な記事を推薦する必要があります。

    一般的に、上記をそれぞれ別個のモデルで学習し、組み合わせる手法が多いのですが、
    ユーザーの関心(≒クリックや検索の傾向)と、推薦候補の記事傾向を別々に学習すると、適切なマッチングが難しいという問題があります。
    この研究ではこれらを統合的に学習することで、精度を改善する手法が提案されています。

    f:id:shin0higuchi:20210723045456p:plain:w800
      
    論文はこちら:arxiv.org

    3. Meaningful Answer Generation of E-Commerce Question-Answering (Shen Gao)

    E-Commerceにおける質問応答システムに関する発表でした。
    「この商品は辛いですか?」といったような、商品に関する質問に対して応答を自動生成するシステムがテーマです。
    応答は基本的にユーザーのレビューをもとに生成するのですが、中には間違った情報が含まれていたり、レビュアー間で観点が異なっていたりという問題があります。(たとえば、ほとんどの人が「辛くない」と言っている中で、ひとりだけ「とても辛い」とレビューしている場合など)
    データソースに誤った情報や関係のない情報が混ざっている場合に、それに引っ張られず適切な応答を返すのは難しいだけに、勉強になりました。

    f:id:shin0higuchi:20210724141119p:plain:w800

    この研究では、レビューを事前にクラスタリングし、それぞれについて回答を推論してから統合する形を取っています。
    f:id:shin0higuchi:20210724142535p:plain:w800

    また、クラスタ毎の推論部分は以下のような構成を取っており、これによって少数派の間違った情報から影響を受けにくくなるようです。
    f:id:shin0higuchi:20210724145333p:plain:w800




    4. その他

    今回のAwardは以下の通りでした

    • Best Short Paper: Contextualized Offline Relevance Weighting for Efficient and Effective Neural Retrieval by Xuanang Chen, Ben He, Kai Hui, Yiran Wang, Le Sun and Yingfei Sun
    • Best Student Paper: Dynamic Modality Interaction Modeling for Image-Text Retrieval by Leigang Qu, Meng Liu, Jianlong Wu, Zan Gao and Liqiang Nie
    • Best Paper: Computationally Efficient Optimization of Plackett-Luce Ranking Models for Relevance and Fairness by Harrie Oosterhuis
    • SIGIR Test of Time Award: Exploiting geographical influence for collaborative point-of-interest recommendation by Mao Ye, Peifeng Yin, Wang-Chien Lee, Dik-Lun Lee, SIGIR 2011

    興味のあるかたは是非読んでみてください。

    3. 最後に

    上記で挙げた以外にも、沢山の面白いセッションがあり、非常に良い刺激を貰えた一週間でした。
    運営の皆様、発表者の皆様お疲れさまでした。

    以上となります。お読みいただきありがとうございました。



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


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

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