Technology Topics by Brains

ブレインズテクノロジーの研究開発機関「未来工場」で働くエンジニアが、先端オープン技術、機械学習×データ分析(異常検知、予兆検知)に関する取組みをご紹介します。

圧縮時のcompression levelでの処理の違いが気になったので調べてみた

こんにちは。ブレインズテクノロジーの岩城です。

先日、データ圧縮時のオプションの一つの"compression level" (または圧縮レベル)の設定を検討する機会があったので、調べた内容をご紹介します。

本記事では特に、圧縮レベルの値の違いでの「速度や圧縮率の方向性」ではなく、「何が違ってその結果が得られたのか」を議論するための素材の提供に重点を置いています。

1. 本記事のゴール

本記事のゴールは以下の2つに設定しました。

  1. 圧縮レベルによる内部処理の違いを設定値として確認すること
  2. さらに調査を進めるための資料の整理

そのため、アルゴリズムの詳細な内容は対象としていません。

1.1. 圧縮レベル設定と検討のメリット

圧縮レベルは圧縮の速度と圧縮率のバランスを調整するパラメータです。

この値の検討により、可能な限りデータを圧縮したい場面や速度を重視したい場面など、目的に応じた設定ができるようになります。

1.2. 調査対象

今回の記事ではzlibを主な調査対象としました。 選定理由としては、zlibは情報が充実していたほか、pythonでよく使うshutilやjoblibでも利用されていることが挙げられます。

その他の方式として、lzmaなどいくつかのライブラリで部分的に参考になりそうな情報があったため、末尾にリンクを整理します。

2. 結論

まず結論です。 zlibではcompression levelごとに圧縮処理で使われるパラメータや関数が変わるようでした。 この情報が記載されていた資料のリンクと、ソースコードへのリンクを示しておきます。

Understanding zlib 3.3.4. Adaptive Serach Limit

ソースコード

また、分かりやすさのためソースコードの該当箇所を引用してご紹介します。

local const config configuration_table[10] = {
/*      good lazy nice chain */
/* 0 */ {0,    0,  0,    0, deflate_stored},  /* store only */
/* 1 */ {4,    4,  8,    4, deflate_fast}, /* max speed, no lazy matches */
/* 2 */ {4,    5, 16,    8, deflate_fast},
/* 3 */ {4,    6, 32,   32, deflate_fast},

/* 4 */ {4,    4, 16,   16, deflate_slow},  /* lazy matches */
/* 5 */ {8,   16, 32,   32, deflate_slow},
/* 6 */ {8,   16, 128, 128, deflate_slow},
/* 7 */ {8,   32, 128, 256, deflate_slow},
/* 8 */ {32, 128, 258, 1024, deflate_slow},
/* 9 */ {32, 258, 258, 4096, deflate_slow}}; /* max compression */

(https://github.com/madler/zlib/blob/master/deflate.cより引用。)

この部分はUnderstanding zlibにも記載がありますが、一次情報であることを考慮しソースコードを直接引用しました。

圧縮アルゴリズム等を勉強された方はご存知かとは思いますが、結局辞書的な表現に直すために過去の出現とのマッチングを行う必要があり、 その探索の際のパラメータのセットをいくつか準備している、ということのようです。

good, lazy, nice, chainはいずれも文字列のmatchに関するもので、chainのあとの*はdeflate(圧縮部分の処理)で使う関数です。

good, lazy, niceについてのコメントを簡単に整理すると以下の通りです。

  • good: match_lengthがこの値より大きいとlazy searchを減らす
  • lazy: match_lengthがこの値より大きいとlazy searchをしない
  • nice: この値よりも大きいmach lengthでは探索をやめる

lazy search (lazy match)は、ある長さNの一致が見つかった後で次の入力byteに対してより長い一致を探す処理のことのようです。 (参考: https://tools.ietf.org/html/rfc1951)

また、chainはmax_hash_chainとも呼ばれるもので、記号列一致の候補を探すときに使われます。

いずれのパラメータも値が大きいほどより長い一致記号列を探したり、より多くの圧縮表現作成に使用する情報をもつなど、圧縮率を高くする方向の役割をするようになります。

その他、zlib自体はlossless, つまり可逆圧縮であることも把握しておくと良いでしょう。

パラメータは分かったものの、パフォーマンスがどう変わるかはさすがに分からないので、あとは実験結果などを参考に妥当な値を使用するか、推奨値を使用するかなどの判断をすることになるかと思います。

なお、後述のjoblib.dump()ではcompressionをTrueとした場合はcompression levelを3としており、この値を"often a good compromise"、つまり良い妥協点としています。

3. zlibに関する参考資料

zlibに関して、今回の調査で最も参考になったサイトがこちらです。

Understanding zlib

zlibの原理やパラメータ、最近の研究などが簡潔かつ分かりやすくまとまっており、とても参考になりました。

また、もちろんですがzlib自体のホームページとgithubで公開されているソースコードも非常に参考になりました。

zlib Home Site

github/madler/zlib

アルゴリズムなども含めて詳細な内容が知りたい方は上記のリンクなどが有用かと思います。

補足資料

さて、ここまでで本記事の目的はほぼ達成しました。

ここからは関連しそうな周辺情報の整理と、少しだけzlibの中身を確認してみたいと思います。

A.1. zlib周辺情報の整理

A.1.1. 様々な圧縮ツール

圧縮ツールといっても様々な種類があります。 zilbも含めて後述のライブラリとも関わってくる代表的な手法から4つ紹介しておきます。

  • zlib
  • gzip
  • bz2
  • lzma

詳細は本記事のフォーカスではないため割愛します。

A.1.2. pickleと圧縮

pythonでデータを保存 (dump) するときにぱっと思い浮かぶのがpikcleだと思います。 pickleは公式でも記述がある通り、serializingとde-seriazilingが主な役割です。

つまり、python objectの構造をbyte streamに変換して保存する・読み出すのが役割です。

pickleは相対的に小さなbinaryでの表現にはしてくれるものの、圧縮は別で考える必要があります。

公式ではpickleしたデータに対して圧縮もできる、という形で言及されています。

https://docs.python.org/3/library/pickle.html

A.1.2.1. pickle.dump()の引数の"protocol"

pickle.dump()については、引数の"protocol"の設定を知っておくと後述のjoblibなど、別のところで役に立つかもしれません。

プロトコルはPython 3.8.5の時点では0から5のいずれかの整数で、番号によってserializeする方式が異なっています。

大きいほど新しくて、高速化や大きなオブジェクトのサイズへの対応が追加されているようです。

デフォルト値はPython 3.0以降は3、Python 3.8以降は4になっています。

https://docs.python.org/3/library/pickle.html#pickle-protocols

A.1.3. joblib

joblibはPythonでpipeline jobを扱うツールを提供するライブラリです。

本記事との関連要素として大きいのはjoblib.dumpです。 joblib.readthedocs.io

joblibではzlib, gzip, bz2, lzma, xzといった圧縮方式が選択可能ですが、特に重要なポイントは、圧縮のデフォルトがzlibであることです。

(参照: https://joblib.readthedocs.io/en/latest/persistence.html#persistence )

拡張子での指定およびパラメータでの指定をしなかった場合はzlibが使用されるため、知らないうちにお世話になっていたかもしれません。

A.1.4. shutil

pickleのcompressの記述は以下のページにリンクしています。

https://docs.python.org/3/library/archiving.html

ここでshutilのArchive operationが紹介されているように、shutilからも圧縮処理が可能です。

compression levelが指定できなさそうではありますが、圧縮手段の一つとしてのご紹介でした。

A.2. zlibの簡単な紹介

zlibについても簡単に記載したいと思います。

先ほどもご紹介した以下リンクを読めばおよそ知りたいことが得られるので、きちんと知りたい方は改めてこちらをお勧めします。

Understanding zlib

A.2.1. 代表的な情報

まずは大まかなポイントとなる情報を箇条書きで整理します。

  • 1995年に作られた。
  • 圧縮部分はJean-loup Gailly, 解凍部分はMark Adlerにより書かれた。
  • 圧縮にはdeflete method、解凍にはinflate methodが用いられる。
    • それぞれLZ77とハフマン符号化を使用。
  • deleteの文字列一致の探索では、Rabin-Karp algorithmのようなアルゴリズムも使用。
  • zlib Licenseというライセンス

A.2.2. パラメータ

続いて、少しだけパラメータの話です。ここでは圧縮のみを対象とします。

圧縮 (deflate)ではLZ77による圧縮とハフマン符号化を行います。

A.2.2.1. LZ77

圧縮レベルでのパフォーマンスの違いを決めるパラメータはこのLZ77関連です。

ここでは要素を極めて簡単にご紹介します。

詳しく知りたい方は、以下リンクの2章2項と3章部分を順番に読んでいただくのが理解の助けになると思います。本記事を書く上ではWikipediaも参考にしました。

https://www.euccas.me/zlib/#deflate_lz77 https://www.euccas.me/zlib/#zlib_implementation https://ja.wikipedia.org/wiki/LZ77

LZ77はsliding windowを用いて、新たに注目する記号列が過去の記号列の中にあったかどうか探索し、出現していた場合はlenght-distance pairと呼ばれる、文字列の長さと出現位置を示す記号での表現に置き換える手法です。

LZ77についてはポイントが大きく2つあります。

一つ目のポイントとしては、Sliding Windowを用意して、ファイルの部分文字列に対して過去の出現情報を辞書化する処理を行うことが挙げられます。

Sliding Windowは"search buffer"と"look-ahead buffer"の2つの部分から構成され、look-ahead bufferは新たに辞書化する対象文字列を、search bufferは過去の文字列を保持します。

二つ目のポイントはlength-distance pairで、これは(検索対象記号列からの距離、一致した文字列長さ、look-ahead bufferの最長一致長さの次の文字列)で表現されています。

文字で説明すると非常にわかりづらいので、以下の箇所をご確認いただくのが良いでしょうか。

https://www.euccas.me/zlib/#deflate_length_distance_pair

A.2.2.2. パフォーマンスとパラメータ

最後に、パラメータとパフォーマンスの話です。

defleteのパフォーマンスを決めるパラメータとして最も重要なのは、"一致文字列の探索をどこまでするか"になります。

(Sliding Windowのサイズも重要に思えますが、デフォルトが64KBであり、可変ではあるものの圧縮レベルのパラメータには含まれていません)

zlibの実装では最長一致を見つけるために、大きく以下の2つの処理をしています。

  1. 短い長さの文字列で一致候補を見つける
  2. 候補に対して一致を評価し、current longest matchを決める。

このプロセスで最長一致対象を見つけるか、事前に決めたlongest match limitを超える物を見つけるまで探索を行うことになっているとのことです。

さらに一つ目ではRabin-Karp Algorithmを元にしたアルゴリズムを使っていることのポイントになります。

Rabin-Karp Algorithmはrolling hashという手法を用いた文字列のhashを用いた文字列の一致を効率的に見つけることが可能なアルゴリズムです。

zlibでは部分文字列の一致評価を行うために、Hash Chainという構造を使用し、Rabin-Karp algorithmのように部分一致情報を効率よく活用します。

このhash_chainの最大長さを決めるのが、パラメータの一つのmax_chain_lengthになります。

A.2.2.3. ハフマン符号化

ハフマン符号化の方はwikipediaをはじめ様々な資料が出てくるので、そちらをご参照いただければ基本的には問題ないかと思います。

パフォーマンスに関連する要素も、zlibに関しては内部処理の中で一度dynamic Huffman treeを作ってstatic treeかdynamic treeを使うかを決めていることをおさえておけば大丈夫ではないでしょうか。

ハフマン符号 - Wikipedia https://www.euccas.me/zlib/#zlib_huffman_encoding

A.3. その他のツールとcompression level

あまり詳しくは確認できていませんが、zlib以外でもいくつかcompression levelの参考になりそうな資料があったので記載しておきます。

まとめ

この記事ではcompression levelの具体的に何が変わるかをzlibを題材に調査した結果をご紹介しました。

圧縮レベルについて調査をした際に、"compression level"や"圧縮レベル"で検索してみたものの情報が不十分だったり、パフォーマンスの方向性は示されていても、原理や設定値での違いがすぐには見つからず、手間取ってしまったことが今回記事を書くきっかけでした。

圧縮処理の際のパラメータや関数セットの違いということが確認でき、個人的には知りたいところまでは納得できたのですが、この記事にたどり着いた方にも十分な内容になっていれば幸いです。

今回は特に、知りたいことが検索してもなかなか出てこなかった背景もあり、リンク等も含めて皆様のお役に立つことを願っています。


ブレインズテクノロジーでは「共に成長できる仲間」を募集中です。
採用ページはこちら

参考資料

zlib関連

zlibに関わるpython関連

zlibのアルゴリズム関連

その他のツールとcompression level

Impulseを無料で体験できるImpulse Cloud

こんにちは、ブレインズテクノロジーの加藤です。

今回は、弊社の業務特化型機械学習ソリューション「Impulse」を無償でご体験いただける「Impulse Cloud」についてご紹介いたします。

Impulse Cloud とは

Impulse Cloudは、多様な機能があるImpulseをPlayground的に体験いただけるサービスです。
Impulseは6つの機能を備えておりますが、現在のImpulse Cloudでは「要因分析」のみご利用が可能です。(下図の赤枠部分)
他のサービスも順次追加していく予定ですので、よろしければユーザー登録いただき、Impulseを体験いただければと思います。

f:id:brains-tech:20200330185028p:plain
Impulse構成図:本記事では赤枠の要因分析についてご紹介

要因分析モジュール とは

工場の生産設備や建設現場の建設機器から発生した異常や、製品の不良に起因するパラメータを分析する機能を基本とし、他にも不良や異常の自動分類や発生メカニズムの可視化など、様々な角度から品質向上に貢献する機能を揃えています。
本機能は、実際にJFEエンジニアリング様などにご活用いただいています。 www.brains-tech.co.jp

Impulse Cloudへの登録

下記のURLから、Impulse Cloudのトップ画面に遷移します。
Impulse Cloud

初めてご利用の方は画面中央部の「はじめる」からログイン情報をご登録いただければ、ユーザー情報を記載したメールが届きますので、そちらからログインが可能となります。
すでに登録済の方は「ログイン」ボタンからログインが可能です。

Impulse Cloudの使い方

現段階では、ユーザーにてファイルをアップロードできない仕様になっています。下図の赤枠で囲われた部分が現在ご利用いただける機能です。 f:id:brains-tech:20200331162232p:plain

要因分析では下記の3機能があります。

  1. 分析:配置済のデータを対象に「分類」と「回帰」の2種類の分析を行います。
  2. 結果:分析した結果が様々な形式のグラフで可視化されます。
  3. ガイド:分析と結果の実行方法を動画形式で閲覧できます。

Impulse Cloudにご登録いただき、実際に各機能をご覧頂きたく思いますが、今回は「結果」でどのような情報を見ることができるか、一部をご紹介します。

分類

異常データと正常データの分類や、どのパラメータが異常に寄与する要因である可能性が高いかなどを可視化します。
その他にも、品質改善に向けた対策の意思決定をサポートするための機能を取り揃えております。

  • クラスタ分析:異常や不良が発生した要因の類似度を可視化します。本機能により、異常や不良の発生要因別に対策を講じることができます。

  • 不良要因分析:異常や不良の発生要因となるパラメータの上下により、異常や不良の発生がどの程度増減するかを分析・可視化します。

  • 良品・不良品ルールの書き下し機能:良品を得るための制御パラメータの範囲をIF-THEN-ELSE形式で出力することができ、改善業務に活かすことができます。

分類画面① f:id:brains-tech:20200401155454p:plain

分類画面② f:id:brains-tech:20200401155500p:plain

回帰

分析対象データを用いた回帰分析を行い、その結果を可視化します。 f:id:brains-tech:20200401165728p:plain

最後に

今回は、Impulse Cloudが現在提供している要因分析モジュールについて、簡単にご紹介をさせていただきました。その他のモジュールにつきましても、随時追加していく予定です。
ユーザー登録は無料ですので、是非とも一度お試しいただければ幸いです。

また、弊社では特に製造業における豊富なImpulseの導入経験をもとにした、機械学習事例をご紹介するオンラインセミナーを開催していますので、こちらもお気軽にお問合せいただければと思います。 info.brains-tech.co.jp

AWS re:Invent2019 Hands-on(Creating Models with Amazon SageMaker), Workshop(Machine Learning with Kubeflow on AWS) and Session(new SageMaker Ecosystem)

こんにちは、ブレインズテクノロジーの寺村です。

2019年12月にLas Vegasで開催されたAWS re:Invent2019に参加してきました。 今回がre:Invent初参加になります。今回は参加したSession等を中心に技術的な部分をまとめます。

Day 1 Mon.2 Hands-on Lab and Workshop

私は1日目の昼にHands-on LabとWorkshopに参加しました。

Hands-On Lab

Hands-On Labは、100以上のカタログの中から自分で好きなラボを選び、手順に従ってシナリオに沿って自分のペースで学習する形式です。

f:id:brains-tech:20200117130359j:plain
Hands-On Labの様子 01
f:id:brains-tech:20200117123236j:plain
Hands-On Labの様子 02

今回私は Amazon Sagemaker を用いてチャーン分析を行うためのモデルを作成するラボを選択しました。 Creating Models with Amazon SageMaker SageMakerでNotebookインスタンスを立ち上げ, 使用するデータから特徴量の選択、データの前処理、モデル作成までを2時間程度の時間で行うことができました。 データの取り込みからモデル作成までがSagemakerでほぼ完結するので(データはS3に配置)とても楽に機械学習のモデルを作ることができると実感しました。 また、手順がNotebook形式でうまくまとめられていて、トレーニング資料などの作成にとても参考になりました。実際にWeb上でCatalogを使ってみることができるので気になる方は是非使ってみてください!

qwiklab

Workshop

Workshopは、事前に用意されている課題を自分のPC上で解決するタイプのハンズオン形式のセッションです。 最初にWorkshopで使用するAWSサービスの概要と課題を進めるためのドキュメントを共有してもらいます。その後にドキュメントに書かれた手順に従って各自のPCで課題を進めます。質問等がある場合は周囲のAWSエンジニアに質問して進めていきます。およそ2,3時間でSessionは終了します。

f:id:brains-tech:20200117123656j:plain
Workshopの様子 01 OPN401-R - [REPEAT] Machine learning with Kubeflow on AWS
f:id:brains-tech:20200117130509j:plain
Workshopの様子 02 OPN401-R - [REPEAT] Machine learning with Kubeflow on AWS

今回私はAmazon EKS上でKubeflowを動かすWorkshopに参加しました(Machine learning with Kubeflow on AWS)。 KubeflowはGoogleが開発するオープンソースの機械学習プラットフォームです。Kubernetesのクラスター上で機械学習のワークフローを動かします。 Kubeflow Dashboardを立ち上げて、Jupyter notebookを起動します。

f:id:brains-tech:20200117124038p:plain
Kubeflow Dashboard上でJupyter notebookの起動

Jupyter notebook上でインタラクティブにモデルの作成やトレーニング、推論までを行うことができます。

今回はSample codeを使ってモデルのトレーニング、推論を行います。他にも Kubeflow fairing: Pythonを用いて機械学習モデルを構築、訓練、デプロイ Kubeflow Pipelines: Dockerコンテナ技術を用いて一連のML workflowをパッケージ化する などのKubeflow関連のツールを使いながら課題を進めました。

Kubernetesに関してほとんど触ったことはなかったですが、シナリオに沿って進めることができました。 このWorkshopの内容もweb上で確認することができます。

MACHINE LEARNING USING KUBEFLOW

Day 2-4 Mon. 3-Mon. 5 Keynotes and Sessions

私は2日目以降は朝にKeynotesを聞き、午後には今回のre:Inventで発表されたSageMaker関連のSessionを中心に回りました。

f:id:brains-tech:20200117124927j:plain
Keynotes 01
f:id:brains-tech:20200117125328j:plain
Keynotes 02
f:id:brains-tech:20200117125448j:plain
Keynotes 03

f:id:brains-tech:20200117130551j:plain
Session Amazon SageMaker Studio 01

f:id:brains-tech:20200117130818j:plain
Session Amazon SageMaker Studio 02

機械学習モデルの構築やパラメータ設定がより簡単にできそうです!

f:id:brains-tech:20200117130653j:plain
Session Amazon SageMaker Debugger

f:id:brains-tech:20200117130725j:plain
Session Amazon SageMaker Debugger 02

まとめ

今年のre:InventではAWSが今後MLやAIの分野に力を入れていこうとしている意思を強く感じました。今後は、SageMaker上で機械学習プラットフォームの構築や運用がどのくらいできるのか試してみたいです。

re:Invent 2019, Day 2: Keynote by Andy Jassy

On the second day of the re:Invent, AWS CEO Andy Jassy announced severals new products, here is a summary and my thoughts on the products and how they are going to change the business:

f:id:brains-tech:20200114125606j:plain
Keynote

Instances

This year they focus heavily on advertising the Niro System, the underlying platform that powers EC2 and several other services. With this system they said they can deliver instances faster to the customers at lower costs.
They also introduce some new instance types, including Inf1, powered by their own Inferential chips to address Machine Learning use cases. To be honest, I was very amazed, the market for CPUs has been very lively these days, Intel and AMD trading blows on the x86 market, every phone manufacturer (Apple, Samsung, Huawei) has been trying to manufacture their own CPUs. And now, there is a very new market, CPUs that are made for specific use cases, like the Amazon Inferential, optimized for that use case only instead of general purposes computing. This should be a competition that is very entertaining to watch.

Containers

A very big announcement: Amazon EKS on AWS Fargate. With already a lot of customers deploying their Kubernetes instances on AWS, now AWS has decided to equip their Elastic Kubernetes Service with Fargate. Since Fargate is a way people can manage containers instances without worrying about provisioning or managing servers, I guess a lot of customers would be very happy to use the service.
But I wouldn’t want to see AWS going completely monopoly on the container scene, I really hope competitors can catch up soon.

Databases

Lots of enhancements have been made to AWS databases offerings: Amazon S3 Access Points, Data Lake Export Query, Amazon Redshift RA3 Instances with Managed Storage, Advanced Query Accelerator for Amazon Redshift, UltraWarm for ElasticSearch. But what catched my attention the most was Amazon Managed Apache Cassandra Service.
A lot of companies like ourselves have been using Cassandra for business since it offers a very fast insertion speed compared to the other databases. With no equivalent on AWS, we kind of have to use DynamoDB instead, which results in two different data modeling, a chore to maintain. We would be very happy to see this new service released and with a reasonable pricing too, so that we can reduce the time it takes to migrate our on premises software to the cloud.

Machine Learning

Machine learning is heavily focused on the event this year, and AWS didn’t fail to impress.
The first “wow” is the Amazon SageMaker Studio. It is a web-based IDE for a complete machine learning workflow. Build, train, and deploy machine learning models can now be done in a single interface. Along with that several other services like SageMaker Notebooks, Experiments, Debugger, Model Monitor, Autopilot.
And they managed to surprise me even further with Amazon CodeGuru, a service that review codes not only in the sense of linting, finding syntactic errors, but also finding logical errors, expensive operations, concurrency issues, etc. If the thing can be just half as good as they said it was, it definitely would become a game changer.

Others

One more interesting announcement is Kendra, an internal enterprise search engine. This sounds like the direct competitor to our business Neuron. This led me to thinking, AWS is not an infrastructure company anymore, just like their parent company Amazon, they participate in every market now. What I wonder is, their motives on this move. Is AWS going to offer very domain specific applications and destroy smaller competitors completely, or they are going to build an ecosystem, where smaller businesses will use their application as the core, and offers additional services to the customers to make a profit. One thing I know for sure, our business Neuron will have to improve, significantly so that we can keep on being one of the best offerings on the market.

My only complain is, they should let the rock band perform a little more, instead of just verses of songs. I felt very bad for the band.

-- Cuong Nguyen, Software developer @ Brains Technology, Inc.

re:Invent 2019, Day 1: Building ML practices & Advanced DynamoDB patterns

Building ML practices to address the top four use cases

I woke up very early in the morning (as early as 2pm) so I came very early to the venue too. The room of the session is shared with other sessions, so there’s no loud speaker, just some headphones set up for people who couldn’t hear the speaker directly. This session is kind of an introductory to the ML stack offerings from AWS, though it didn’t provide much detail about how to implement things, the speakers did give you a brief idea of steps you need to take to address your machine learning problems (4 of which mentioned in this session: Recommendation engines, Forecasting, Computer vision, and Natural language processing).

f:id:brains-tech:20200114115851p:plain
AWS ML Stack
What I learned from this session is: as an AWS user, you should first take advantage of their very convenient offerings like Personalize, Forecast, Rekonition, Textract, etc. to address your problem. These options are very convenient because you don’t really need the data initially to create your first models. It’s better to have a mediocre model than nothing, so if your system is just at an initial state, those are very helpful. And then when you have your own data, you can either input them to the “easy buttons” solutions, or you can customize the process further using SageMaker, there will be lower level options for you to choose from: several algorithms which you can tweak to your liking. And there is a marketplace for pre built models for different use cases that you can browse and buy them to use if it satisfies you. And if every pre built solutions cannot satisfy your needs, you can go deep down to the programming levels, which you can use frameworks like Tensorflow, Pytorch, and interfaces like Keras, or Amazon’s Gluon to program your ML pipeline yourself.
Full event can be found here.
(Update, at the Keynote one day later, AWS just announced some services that can make the process much more convenient including a cloud based IDE for SageMaker, with multiple SageMaker related goodies)

Advanced Design Patterns for DynamoDB

This is a repeated session from 2018, but there were still a lot of them being held repeatedly this year, and with a lot of people attending those sessions too. I can understand the reason behind that. Everybody is using NoSQL for their workloads, but not very many of them (myself included) truly understand what it is and how to utilize the technology.
Speaker Rick Houlihan started the presentation by addressing the reason why NoSQL is taking over RDBMS: data gets bigger, storage gets cheaper and CPUs are still expensive, it is more appropriate to store unnormalized that is ready for fast querying than to store normalized data that needs heavy computing for queries.
NoSQL is a very different beast than traditional relational databases. Using NoSQL the same way as relational databases is wrong, and if you use the same data model it’s wrong. In this session, Mr. Houlihan introduced briefly about the data model of DynamoDB, and then some advanced design patterns such as:

  • Choosing partition key to optimize partitioning performance
  • Range queries using sort key
  • Heterogeneous collections of items
  • Indexing and access patterns

f:id:brains-tech:20200114115403p:plain
Advanced design patterns for DynamoDB

Full event can be found here

-- Cuong Nguyen, Software Developer @ Brains Technology, Inc.

AWS re:Invent 2019 Session - Building machine-learning infrastructure on Amazon EKS with Kubeflow

Impulseの開発をしている樋口です。

今回は表題のセッションについて少しまとめます。

モチベーション

セッションはEKSで機械学習基盤を構築するという題目でしたが、AWSにはAmazon SageMakerというEnd to Endの機械学習サービスがあります。 aws.amazon.com

なぜSageMakerを使わずにEKSを利用して個別に機械学習のインフラを作り上げるのか(しかも今回のre:Inventで相当のアップデートが発表されました)、理由は以下が紹介されていました。

  • Portability
  • Composability
  • Scalability

以下そのうち2つを詳しく書いておきます。(ScalabilityはSageMakerでも,,,というところはあるので)

Portability

オンプレミス環境でもプロダクトを動作させる事が求められる場合、クラウドサービスにロックインした形で実装を進めてしまうと、クラウドサービスが担っていてくれた部分を一部自分で実現しなくてはならなく、 同じロジックを違う手段で実装し直すということが発生する。 クラウド・オンプレミス両方で同じ手段を使い動作する事で最小限の手間でプロダクトをポータブルにすることができる。

Composability

現在Kubernetes界隈にはたくさんのOSSがあり、それらを組み合わせることにより様々な機能を実現することができる。コンテナ基盤として使えるので、追加の個別の要件にも対応しやすい。

機械学習基盤

機械学習基盤として、満たすべき要件は

  • Authentication/Authorizationのサポート
  • Notebookを使ったデータ分析者による分析
  • パイプラインの実行
  • 並列分散処理によるモデル構築
  • スケーラブルな推論
  • メトリクスの可視化
  • インフラレイヤーの抽象化

など多々ありますが、これらを満たすために手段としてkubeflowが紹介されていました。 f:id:mhigu:20191204123205j:plain www.kubeflow.org kubeflowの各機能詳細については、公式ドキュメントを参照してもらうとして確かにこれだけでも機械学習基盤として必要な要件は最低限満たせるかもしれません。

kubeflowのパイプラインではTensorFlow, scikit-learn, PyTorchのいずれの処理でもパイプラインの一つの要素として定義することができます。 f:id:mhigu:20191205022107j:plain

一つのライブラリに依存せず基盤を準備できるのは便利( ゚∀゚)・∵. グハッ!!

まぁ、kubeflowの裏ではargoというもっと抽象的なworkflow engineが動いているので、何でも実行できるのは不思議では無いですね。 github.com

また、kubeflowと一緒にhorovodというライブラリが紹介されていました。 github.com 一応スピーカいわく現在一番洗練された分散学習のフレームワークの一つらしいです。

事例

実際にEKSをベースにして、この様な基盤を組んだ企業の事例紹介がありました。

基本的には上記で紹介したkubeflowをベースに以下の様な構成で、 f:id:mhigu:20191204125352j:plain

追加でPrometheus/Grafanaを導入して以下項目の可視化も行っていたとのことでした。

  • cpu
  • memory
  • cluster state
  • job metrics
  • cost f:id:mhigu:20191204130206j:plain コストが見えてるのいいですね。

また、この企業ではEKSベースの機械学習基盤をグローバルに展開しており、それをどこからでも利用できるようにするために複数の機械学習基盤をまとめるREST APIを作ってユーザーにはREST API経由で実際のジョブの実行をさせる様にしていました。

f:id:mhigu:20191204130439j:plain

こうすることで複数の基盤をまとめる事ができたのに加えて、ユーザーが指定しなければならない項目をシンプルにできたとも言っていました。 (kubernetesの利用障壁に煩雑なyamlを書く作業があるが、REST APIにすることでその部分を隠蔽できる。wall of YAML 突破か,,,(ヾノ・∀・`)ムリムリ)

所感

このセッションを通じて話されていた事は弊社のプロダクトにも共通の部分が多くあり、実際に同じようなものを動かしている人の話を聞くとやる気が上がりますね。 見聞きした事は、今後またImpulseの開発に生かしていきます。

AWS re:Invent 2019 に行く

AWS re:Invent 2019

Impulseの開発をしている樋口です。

12/2(月) - 12/6(金)の間で開催されているAWS re:Inventに参加しています。 セッションでの興味深かった内容はまた別途書くとして、まずは雰囲気をお伝えします。

Las Vegas

こんな感じのホテルがあちこちに。 f:id:mhigu:20191203093453j:plain

とにかく中がひろいでかい豪華。 f:id:mhigu:20191203093542j:plain

自分たちの泊まったホテルはFlamingo Las Vegasというホテルですが、 goo.gl その中庭にはフラミンゴが。 f:id:mhigu:20191203093505j:plain

あと、写真は撮れないので無いですが、そこら中にカジノがあり自分はベガス到着から2日で$300ブラックジャックで失いました。。。 安いApple Watchが買える値段。ご利用は計画的に_| ̄|○ il||li

AWS re:Invent

会場

セッション前日から会場は人で賑わっていて、各々壁に落書きしたりビリヤードしたりとくつろいでいます。 f:id:mhigu:20191203100527j:plain サインアップを済ませるとSWAGがもらえます。今回もパーカーとウォーターボトル。 f:id:mhigu:20191203094751j:plain f:id:mhigu:20191203095209j:plain 他にもノベルティが至るところでもらえるようなので、お土産としてたくさん確保していきます。

セッション

因みにセッションの確保競争は年々盛り上がっているようで、殆どのセッションが予約開始日から埋まります。 写真の青いのが興味のあるセッションですが、全て埋まっていて取れません。 f:id:mhigu:20191203094755p:plain 一応当日枠もあるので、泥臭く並んで空いてたら入ろうと思います。

まとめ

  • まずはアメリカの規模を実感する
  • カジノは適度に楽しみましょう
  • セッション確保は仁義なき戦い

以上です。