オーストラリアで勉強してきたMLデザイナーの口語自由詩

主に、データ分析・機械学習・ベイズ・統計について自由に書く。

Kubernetes Meetup Tokyo #22 レポート

kubernetes k8s EKS ECS AWS kubectl

以下のイベントに行ってきたので簡単にレポート書きます。

k8sjp.connpass.com

twitterでみんないろいろつぶやいているので、k8sjpのハッシュタグを見るのもいいかも(｀・ω・´)

twitter.com

内容

LT前の懇親会でのご飯(｀・ω・´)

f:id:yukinagae:20190828233424j:plain
ご飯

LTではなぜか分割キーボードと遊舎工房の宣伝が(´∀｀*)

f:id:yukinagae:20190828233427j:plain
分割キーボード

ここから本題。

AWS EKSを用いた開発環境の構築 by SmartNews

TODO: スライド資料へのリンクを後ではります。

  • SmartNewsってUSにもあるらしい(｀・ω・´)

サービス概要

  • ニュース配信
  • 広告配信

どちらも

システム概要

  • モノリスからマイクロサービス化
    • もちろん完璧ではない
    • 古い業務システム部分が残ってたりする

組織体制

k8sでやりたかったこと

  • 開発者が環境を簡単につくれる
    • GitHubにブランチをPushするだけ
  • その環境にユニークなURLでアクセスできる
    • それぞれendpointが用意される

k8sでやっていること

  • featureブランチ毎にLBで振り分ける
    • feature-a.smartnews.xxx -> feature-aのSVC + Deployment
    • feature-b.smartnews.xxx -> feature-bのSVC + Deployment
    • feature-b.smartnews.xxx -> feature-cのSVC + Deployment

インフラ部分の構成

  • Terraform
  • k8s
    • ALB Ingress Controller
    • Nginx
    • Monitoring: Datadog

アプリケーション部分の構成

  • k8s
    • Service
    • Deployment
    • ConfigMap

tips

  • annotationでdeploy-timestampをつけることで、必ずapplyされるようにしてる。これ必要なんかな(´∀｀*)
  • EKS環境はbranchが削除されるとともに削除されるように1日1回ジョブを走らせている
    • branchを消し忘れると消えない（※mergeした時に消したほうがいいよね、とか）

これから

  • Staging/Production環境へのk8s導入
    • スケールアウトの速度を改善したい: 例）号外をうつときはスピード重視
    • サービスメッシュの導入: 検討するらしい。サービス間連携とか楽になるのでは？

Q&A

  • 質問: 「ECSを使わずにEKSを使わなかった理由は？」
    • 回答: 「本番環境でECS使ったりもしてるが、色々な背景で今回はEKSを使っている」
    • 感想: なんとなく既存のECSがいろいろな事情（技術的・政治的？）で使いづらかったので、（技術検証も含めて）今回はEKSを採用した、ということかな(｀・ω・´)

はてなでのKubernetes利用の取組みとこれから by はてな

speakerdeck.com

  • Mackerel / SRE

  • ドッグフーディング

    • コンテナ運用してみる
    • Mackerelのエージェントの動作確認
  • インフラ管理コストの削減 <- わかる
    • 複雑なサーバプロビジョニングの管理からの脱却

なぜk8s？

選択肢

  • 自前？
  • マネージド？

自前にした

  • EKSにJapanリージョンがなかった
  • AWS以外ではネットワークのオーバーヘッドが大きく運用が難しい

技術的な話

課題

  • 高い学習コスト
    • そもそもk8sは複雑
    • 運用が属人化してしまう
  • 膨大なエコシステム
    • 運用にあったサービスやツールを選ぶのは大変
  • クラスタのアップデートへの対応
    • マイナーリリースは3ヶ月毎に実施され、3リリースブランチがサポートされる
    • リリースに追従する必要がある
    • アップデートに失敗すると困る。クラスタのBlue/Greenしたいよね
  • 運用リリース不足
    • メンバーの退職・異動
    • クラスタが放置気味に。。。汗
  • クラスタアップデートに失敗
    • 脆弱性への対応の遅れ
    • 運用リソース不足
    • etc

撤退

撤退の話できるの本当にすごいしありがたい。 こういうしくじり話を自分もしていきたい気持ち(´∀｀*)

  • 本番環境
    • 並行稼動していたので切り替えるだけでOKだった
  • ステージング環境
    • VMで全て再構成

経験やノウハウはたまった

これからの取組み

  • k8s != コンテナによるシステム運用の実現を優先させる
  • 社内で運用ノウハウのあるECSへ移行する
  • 最終的にEKSへ移行
    • マネージドで運用負荷の削減
    • 最悪EKSで失敗してもECS（コンテナ）によるシステム運用は担保

まとめ

  • 構築 != 運用
  • クラスタ運用を見据えた体制を整えることが大事
  • スモールスタート・並行運用・撤退可能な設計を心がける

紹介スライド・記事

PayPay での Kubernetes 活用事例 by PayPay

TODO: スライド資料へのリンクを後ではります。

技術スタック

  • kafka
  • Aurora
  • datadog
  • new relic

k8s事例

  • 2018/12/04: 100億円あげちゃうキャンペーン
  • 2019/02/12: 第二弾100億円キャンペーン

問題

  • アクセスの急増！
  • Core機能のAPIに予想以上のアクセス集中が。。。汗
    • Service/Deploymentのmanifestを複製してしのぐ
  • パフォーマンス・チューニングの前にボトルネックの調査
    • Docker imageにNewRelicを入れる？
  • アプリケーション間の認証のサービスに負荷が集中
    • Service/Deploymentのmanifestを複製してしのぐ（2回目！）

今後やりたいこと

Kafka on Kubernetes

  • アプリケーション用途
  • ログ収集用途: ログをロストしないために間にkafkaをかませている
    • [各アプリケーション] -> [kafka] -> [Logstash] -> [Elasticsearch]

Canary Release

  • 少しづつリリースしたいよね
  • 既存のデプロイフローも改善したいよね

既存のデプロイフロー

  1. アプリ修正
  2. Jenkinsでbuild & publish
  3. k8sのmanifestを修正
  4. devへのdeploy

新しいデプロイフロー

  • githubを見れば環境の状態がわかるようにしたい
    • secretは除く
  • 本番リリースは一部の権限を持つ人に限定したい

2ブランチ

  • master: 開発・ステージング環境用
  • production: 本番環境用

検証は終わったので、これからサービス展開準備中らしい(｀・ω・´)

技術スタック

メトリックスみたいよね

  • datadogに rollout-pod-template-hash ラベルの値を送信する（※環境変数として埋め込む）
    • この値でフィルターしてメトリックスを見る
    • 本当はdocker imageのtagが取得できればよかった

LT x 5

順不同

speakerdeck.com

speakerdeck.com

speakerdeck.com

speakerdeck.com

おまけ

  • 会社の同僚がKuberentes実践ガイド（サイン本）当たってました。うらやま(´∀｀*)

Kubernetes実践ガイド クラウドネイティブアプリケーションを支える技術 (impress top gear)

Kubernetes実践ガイド クラウドネイティブアプリケーションを支える技術 (impress top gear)

Terraform Getting Startedをやってみた

terraform aws

Terraform Getting Startedをやってみた

Terraformの Getting Started をやったメモ。

What is Terraform?

Terraform is a tool for building, changing, and versioning infrastructure safely and efficiently. Terraform can manage existing and popular service providers as well as custom in-house solutions.

The key features:

  • Infrastructure as Code: インフラをコードとして定義
  • Execution Plans: 実行計画の作成
  • Resource Graph: リソースグラフによる依存の管理。平行処理による効率的なインフラ構築が可能
  • Change Automation: （自動）変更管理。最小の手動制御で変更を設定することが可能

Use Cases

  • Heroku App Setup
    • Herokuのセットアップ
  • Multi-Tier Applications
    • マルチレイヤーのアーキテクチャのセットアップ（例: Database -> Routing -> Caching -> API）
    • 依存性を確認して自動的に構築（例: Databaseを構築してからAPIを構築するなど）
  • Self-Service Clusters
    • 中央集権的にインフラを管理する
  • Software Demos
    • デモ
  • Disposable Environments
    • 複数の同一環境を構築・メンテ可能（例: テスト、検証、QA etc）
  • Software Defined Networking
    • Software Defined Networking (SDN) の構築
  • Resource Schedulers
    • リソースの動的配備（例: Docker, Hadoop, Spark etc）
  • Multi-Cloud Deployment

Getting Started

see: Installing Terraform | Terraform - HashiCorp Learn

Download Terraform

see: Download Terraform - Terraform by HashiCorp

$ cd /var/tmp
$ wget https://releases.hashicorp.com/terraform/0.12.2/terraform_0.12.2_darwin_amd64.zip
$ unzip terraform_0.12.2_darwin_amd64.zip
$ rm -f terraform_0.12.2_darwin_amd64.zip
$ ls -l terraform
-rwxrwxr-x  1 yuki  staff  54228088  6 13 05:12 terraform

Move terraform to PATH directory

$ cd /var/tmp
$ mv terraform /usr/local/bin
$ which terraform
/usr/local/bin/terraform
$ terraform version
Terraform v0.12.2

Initialization

see: Build Infrastructure | Terraform - HashiCorp Learn

provider "aws" {
  profile = "default"
  region  = "us-east-1"
}

resource "aws_instance" "example" {
  ami           = "ami-2757f631"
  instance_type = "t2.micro"
}
$ terraform init

Initializing the backend...

Initializing provider plugins...
- Checking for available provider plugins...
- Downloading plugin for provider "aws" (terraform-providers/aws) 2.15.0...

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.

* provider.aws: version = "~> 2.15"

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Apply Changes

see: Build Infrastructure | Terraform - HashiCorp Learn

$ terraform apply

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # aws_instance.example will be created
  + resource "aws_instance" "example" {
    （中略）
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: [yesを入力]

インスタンスの現在のステートを確認

$ terraform show
# aws_instance.example:
resource "aws_instance" "example" {
    （中略）
}

Change Infrastructure

see: Change Infrastructure | Terraform - HashiCorp Learn

resource部分を以下に書き換える

resource "aws_instance" "example" {
  ami           = "ami-b374d5a5"
  instance_type = "t2.micro"
}

変更を適用

$ terraform apply
aws_instance.example: Refreshing state... [id=i-xxxxxxxxxxxxxx]

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
-/+ destroy and then create replacement

Terraform will perform the following actions:

  # aws_instance.example must be replaced
-/+ resource "aws_instance" "example" {
      ~ ami                          = "ami-2757f631" -> "ami-b374d5a5" # forces 
    （中略）
    }

Plan: 1 to add, 0 to change, 1 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: [yesを入力]

consoleを確認すると、最初に作成したインスタンスがterminatedされ、新しいインスタンスが起動されていることがわかる（※ ami の変更のため、変更というよりはインスタンスの削除・新規作成になっている）

f:id:yukinagae:20190729232439p:plain

Destroy Infrastructure

see: Destroy Infrastructure | Terraform - HashiCorp Learn

$ terraform destroy
aws_instance.example: Refreshing state... [id=i-xxxxxxxxx]

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  - destroy

Terraform will perform the following actions:

  # aws_instance.example will be destroyed
  - resource "aws_instance" "example" {
      - ami                          = "ami-b374d5a5" -> null
    （中略）
    }

Plan: 0 to add, 0 to change, 1 to destroy.

Do you really want to destroy all resources?
  Terraform will destroy all your managed infrastructure, as shown above.
  There is no undo. Only 'yes' will be accepted to confirm.

  Enter a value: [yesを入力]

- ami = "ami-b374d5a5" -> null とあるように、ami をnullに設定するのと同義みたいです。

console上でみてもterminatedされていますね。

f:id:yukinagae:20190729232416p:plain

Resources

SA Night行ったのでレポートするぜ

event report ml sa solutions architect aws

↓ この勉強会に参加したので、簡単ながらレポートします。

connpass.com

第一回開催なのか(｀・ω・´)

TL;DR

  • SA Nightとは？
    • SAのお仕事を紹介するイベント
  • SAとは？
  • SAのお仕事とは？（※主に）
    • お客さんと一緒にビジネスを作り上げる
    • お客さんの課題解決にフォーカスする
      • ◯ 顧客が本当にほしかったものを考える
      • ✕ イケてる技術を使う
    • お客さんをハッピーにさせる、信頼される
    • お客様がやりたいこと != お客様にとって必要なこと
  • AWS Loftはおしゃれ(´∀｀*)

外観

f:id:yukinagae:20190425084246j:plain

おしゃれなデバイスが置いてありますね。

f:id:yukinagae:20190425084333j:plain

ユニコーンがいる(´∀｀*)

f:id:yukinagae:20190425084326j:plain

SA（Solutions Architect）Night

目的・背景

  • SAの魅力を知ってもらいたい！

本日のSA Nightのトピック

  • SAのお仕事ってどんな感じかを伝えたい

IoTシステムはどう作られるか - ソラコムでのSAミッション

  • スライド: 後日アップロードされ次第追加。 スライド追加の連絡をtwitterでしていただいたので以下追記しました(｀・ω・´)

www.slideshare.net

アジェンダ

  • SA/PS（Professional Service）のお仕事@ソラコム
  • SA/PSの魅力
  • SA/PSマインド

SA/PSとは？

ソラコムでは以下のような職種があり、スピーカーは両方やっているらしい(｀・ω・´)

  • Solutions Architect
  • Professional Service
    • コンサルとして、お客様と一緒に要件定義〜実装をする

IoT サービスを形作る要素

仕事の進め方

  1. アーキテクチャ設計
  2. 処理方式設計
  3. 要件整理

↓

  • プロトタイプ実装
  • PoC
  • プロダクション実装サポート

加えて以下もSAのお仕事

  • サービスのFBを現場からもらう <- 重要そう(´∀｀*)
  • FBや要望を素早いサイクルでやる

魅力

  • IoTは技術範囲が広い
  • 現状ノウハウが少ない

IoTはテクノロジーの総合格闘技

↑ わかる

IoTサービスの問題あるある

プロトコルによって消費電力の大小が異なるよね

  • UDP: 消費電力は少ない、データは簡単に欠損する
  • TCP: 消費電力が多い、データをちゃんと送信してくれる

クラウドサービスをどう組み合わせるかもSAの腕の見せどころ

例えば、セキュリティ・双方向性などを考慮して以下サービスをどう選定するか(｀・ω・´)

  • SORACOM Beam
  • SORACOM Funnel
  • SORACOM Kryption

魅力

マインド

  • Customer Centric: 顧客満足が一番（※ホスピタリティの爆弾）
  • Technical Credibility: 顧客からの技術面の信頼度

ソラコムの発表についての感想

  • ソラコムのSAはホスピタティ意識が高い（＝お客さんにどう価値を提供するか）
  • ソラコムはただソリューションをコンサルしてるのかと思ったら、ガリガリ構築・開発してる（※これもお客さんに価値を提供するため）
  • IoTでのSAは技術的にもチャレンジングで面白そう
  • IoT周りは必要な技術スタックが広い（Webは当然のこと、ハードウェア周りの知識も必要）

これからSAになる人に向けたアドバイス

  • スライド:

speakerdeck.com

SAとしてのお仕事

  • 「さいきょうのモデル」から特徴量ベクトルが出てくる

↓ ここからSAのお仕事@ルミノソ

  • numpyを使う仕事
  • BIツールでダッシュボードを作成
  • データサイエンティストのコード整備
  • etc

SAの仕事

  • ◯ 課題解決
  • ✕ 技術を使う

お客様がやりたいこと != お客様にとって必要なこと

  • 手を動かす != やってみた
  • 情報収集: 投資を惜しまない
  • 自動化

自分の身を守るために議事録は書こう(´∀｀*)

ルミノソの発表についての感想

  • SAとしてというより、エンジニアとして分かりみの多い内容だった
    • お客様がやりたいこと != お客様にとって必要なこと <- わかる
    • 手を動かす != やってみた <- わかる
  • SA == 顧客の課題解決のために（技術含め）なんでもやる人

機械学習ソリューションアーキテクトの面白さ

  • スライド:

speakerdeck.com

余談

AWSでのSAとは？

  • Trusted Partner: 顧客・営業から信頼される
  • Technical Though Leadership: 社内外の先進テクノロジーの発信
  • Platform Improvement: AWSサービスの進化・活用に貢献

Machine Learning SAのお仕事

そもそもML specialist SAとは？

ポイント

Undifferentiated Heavy Lifting（差別化できないけど重労働なこと） はやらない！

参照: エンジニアの為のAWS実践講座

クラウドでの機械学習のポイント

  • ビジネス価値にフォーカス
  • データの流れを整理
  • 自分だけで頑張らない

頼れるもの

AWS ML SA

  • いろんな課題にチャレンジできる
  • スタートアップからエンタープライズまで
  • お客様と一緒にMLビジネスを作れる

AWSの発表についての感想

  • 様々な分野のスペシャリストがいてうらやましい（個人的な感想です）
    • 機械学習、セキュリティ、ネットワーク、もろもろ
  • Undifferentiated Heavy Lifting（差別化できないけど重労働なこと） というのがAWS内ではよく使うワードらしい
  • 「自分だけでがんばらない」「社内外のリソースをうまく使う」というのが印象的

トレジャーデータにおけるSolution Architectのチャレンジ

SA@Treasure Data

  • 顧客のビジネス課題を自社のテクノロジー（+α）を使って解決
    • 1人のSAから基本的に1つの案件を回す
  • プリセールスから実装まで
  • Sales / Support / Engineering まで幅広く連携

三位一体のメンバーで顧客のビジネスを推進する

  • Customer Success
  • Solutions Engineer（＝SA）
  • Support Engineer

顧客との連携

顧客の声を「そのまま」ではなく「正しく」伝える = ちゃんと課題や背景、文脈を考慮して伝言ゲームするの大事

日頃気をつけていること

  • 得意分野の把握・理解
    • 自分
    • 同僚
    • プロダクト
  • 社内の最新情報のキャッチアップ
    • プロダクトロードマップ
    • slackは全部読むｗ
  • 成果の可視化
    • slackでのプレゼンスｗ
    • 定期的な課題共有
    • オフラインでの相談
  • 知識や思考をwikiにdump
    • 脳内のdump時間を確保する
  • 技術のキャッチアップ
    • 顧客の課題にフォーカスした技術 != やりたい駆動の技術
    • 自分で手を動かす時間の確保
  • 自分の技術が顧客のビジネスに貢献できること

Treasure Dataの発表についての感想

  • SA@Treasure Dataの場合、プリセールスから実装までを1人のSAが行うのスゴイ
  • 顧客のために必要であれば技術を使って実装したり、このあたりはSA@ソラコムと近い
  • 顧客の声を「そのまま」ではなく「正しく」伝える <- これ他のスピーカーも話してる内容だなー(´∀｀*)
  • 日頃気をつけていることとして、社内の情報のキャッチアップという観点が面白い
    • それだけ社内のスピード感が早いのかも(｀・ω・´)

英語記事の翻訳 - ”Bayesian Analysis with Python - 第二版（オズワルド・マーティン）“ への序文（2019）

MCMC python stan ディープラーニング ベイズ 機械学習 統計モデリング

TL;DR

最近出版された「Bayesian Analysis with Python - Second Edition」への序文をPyMC3のコア開発者であるThomas Wieckiがブログ記事で書いていたので翻訳してみました. 「Pythonによるベイズ統計モデリング: PyMCでのデータ分析実践ガイド」という訳書がすでに出版済みですが, こちらは第一版なので少し内容が異なるので注意が必要です. 具体的には最新の第二版では arviz による可視化などが含まれていたりします.

できるだけ直訳ではなく, 自然な日本語になるように言い換えたり, 言葉足らずだと感じた箇所にはあえて言葉を増やしたりしてます.

そんなに長くない記事なのですぐ翻訳できると思ってたんですが, 結局1時間かかってしまいました汗.

本文 - My foreword to "Bayesian Analysis with Python, 2nd Edition" by Osvaldo Martin

オズワルドが彼の新しい著書への序文を私に頼んできた時, 誇らしさや興奮した気持ちとともに少し怖さもあったが, 自然に受け入れることにした. これから, 私にとって確率プログラミングがどれだけ魅力的であるか出来るだけ伝えてみよう. オズワルドの素晴らしい本は, 見つけうる限りの中で最新の情報を提供しており, 確率プログラミングを学び始めるよい手がかりになるでしょう. さあ, この本を手に取ってみてください.

もしこれ以上にこの本を読む動機が必要な人には:

「確率プログラミング」はプログラミングのコードによってベイズ統計モデルを柔軟に構築するためのフレームワークです. 一度モデルを構築してしまえば, そのモデルとは独立に動作する強力な推論アルゴリズムによって, モデルをデータに適応（fit）させることができます. 柔軟なモデルと自動推論の仕組みは, 研究者が新しい統計モデルをすばやく構築・分析・改善するための強力なツールを提供します. 以前のベイジアンモデルの手法では, 推論アルゴリズムは通常は特定の一つのモデルに対してのみ機能しました. このアプローチはモデルを定式化して推論スキームを構築するために高い数学的スキルを必要とするのみならず, モデルを変更して再度推論するという改善の反復サイクルをかなり遅くしていました. 確率プログラミングは多くの人に統計モデリングを活用してもらえるための必要な数学的理解のハードルを下げ, 新規モデルを構築するための時間を効率化することによってデータから独自の考察を得ることを可能にするでしょう.

確率プログラミングのアイディはそんなに新しいものではありません. 最初にBUGSという確率プログラミング言語が1989年にリリースされました. この第一世代の確率プログラミング言語は, うまくデータに適合するモデルは非常に限られ推論の処理も遅く, あまり実用的なものではありませでした. 昨今ではより大規模で複雑な問題を解決するために, 学術の領域やGoogle, Microsoft, Amazon, Facebook, Uberなどの企業で使用されている多数の確率的プログラミング言語があります. 何が変わったのでしょうか? 確率プログラミングを単なるおもちゃから複雑で大規模な問題を解決できる強力なエンジンへと変えた重要な要素は, 従来のサンプリングアルゴリズムより数段強力なハミルトンモンテカルロサンプリング（HMC）の出現でした. もともとは1987年に考案されましたが, StanとPyMC3という最近の確率プログラミングシステムがこのサンプリング手法を幅広く利用可能なものにしました.

この本は確率プログラミングという非常に強力で柔軟なツールへの実用的な入門書です. この本を読むことで, 複雑な分析問題をどのように考え解決するかというあなたの思考に大きな影響を与えるでしょう. PyMC3のコア開発者であるオズワルド以上にこの本を書くに適した人は少ないでしょう. 彼には複雑なトピックを簡単に消化できるように細分化するという貴重な才能を持っています. 困難な経験を通して得られた彼の深く実用的な理解が読者を最も効率的なルートに導くことでしょう. また, 実行可能な可視化やコード例を通して, 理論的基礎を直感的に理解する手助けにつながります.

読者の皆様, この本を手に入れたことにも感謝します. 正直なところ, これは決して速くて簡単な方法ではありません. 現在および将来のすべての分析問題を解決するための技術としてディープラーニング（深層学習）を宣伝している時代には, 特定の目的のためにカスタムモデルを構築するより慎重で慎重なアプローチはそれほど魅力的ではないかもしれません. しかし, 他の方法ではほとんど解決できない問題を解決することができるのです.

ディープラーニング（深層学習）が非常に刺激的なテクニックであることは言うまでもありません. 実際, 確率プロギグラミング自体は古典的な統計モデルに成約されていません. 現在の機械学習の文献を読むと, ベイズ統計が次世代のディープニューラルネットワークを表現し理解するための強力なフレームワークとして浮上していることがわかります. この本は, このように難しい分析問題を解決するためのスキルのみならず, AI（人工知能）開発という人文科学の最前線の特等席に座る手助けをするでしょう. Enjoy!

Thomas Wiecki

参考資料

英語記事のサマリ - UberのAIラボが #Pyro という深層学習+ベイズのライブラリを発表（2017）

edward pymc4 pyro pytorch python tensorflow probability ベイズ 機械学習 統計モデリング 確率

UberのAIラボがPyroという深層学習+ベイズのPythonライブラリを発表したブログ記事をサマリ翻訳してみた.

2017年11月の記事で若干古いが, 他にPyMC4やTFP（Tensorflow Probability）などのライブラリがある現状, Pyroがどのようなポジショニングをしているか確認する目的.

注）正確な翻訳ではなくあくまでも記事の翻訳サマリなので, 個人的に重要でないと判断した部分は省略したり, 原文がわかりづらい部分は意図的に言葉を付け加えたり補足したりしてます(｀・ω・´)（ぺこり）

TL;DR

  • UberのAIラボが Pyroという深層学習+ベイズのPythonライブラリを発表した
  • 確率モデリングによりデータの不確実性を推論し, 専門家の知識をAIシステムに活用することができる
  • 4つのコンセプトがある
    • 汎用性
    • 拡張性
    • 最小限
    • 柔軟性
  • 既存の確率プログラミング言語の枠組みに加え, guide という概念を取り入れている

内容

はじめに

Uberのやりたいことはユーザに信頼性のある移動手段を提供することで, そのためには毎回の予測と最適化を容易に行う必要がある.

用途としては主に以下の通り.

  • 乗り手とドライバーとのマッチングをする
  • 最適なルートのレコメンドする
  • 賢いライドシェアの組合せを見つける
  • 次世代の自動運転車を開発する

これらの課題を解決していく試みの中で, UberのAIラボがOSSとして Pyro を発表した. Pyroはモダンな深層学習とベイズ統計モデリングの手法を統合したツール.

なぜPyro？

  • なぜ確率モデリングが必要？
    • 教師なし学習および半教師つき学習のモデルと予測の不確実性を正しく捉え, 専門家の前提知識をAIシステムに組み込むため.
  • なぜ確率プログラムが必要？
    • 複雑なモデルを構築するための明確で高レベルかつ完全なツールが必要なため.
  • なぜ深層確率モデルが必要？
    • データから生成過程を学び, どのように推論するか知識を具体化するため.
  • なぜ最適化による推論が必要？
    • 大量データにもスケールして対応できるよう, モダンな最適化と変分推論を活用するため.

以下は詳細.

確率やそれを用いたモデルによって不確実性を推論し, それによりデータから「何がどれだけわかっているか？」「何がどれだけわからないか？」を理解することができる. 加えて, その業界の専門家の前提知識をそのAIシステムに組み込むことができる.

確率モデルの実装はめんどうでバグりやすいので, 「確率プログラミング言語（Probability Programming Language）」というものが必要になる. これを用いることで確率モデルの実装に伴う決定論的な計算（例: 1+1=2 など）と乱数生成（例: 正規分布から値をサンプリングする）を自然に組み合わせることができる.

Pyroはそれらを可能にし, かつ既存の確率プログラミング言語の問題点であるスケーラビリティの低さを解消しつつ, 深層学習の手法も取り入れている. 重要な概念としては 第二のモデル（guide） を導入しており, これは Helmholtz machine のアイディアである. 通常の確率モデル（第一のモデル）はデータの生成過程表し, guide（第二のモデル）はデータを潜在変数への変換の生成過程を表している.

注) ↑ このあたりは説明不足っぽいので, 別の資料を参考にしたい(｀・ω・´)

もちろん正確なguideを実装するのは不可能なので, そのかわりに 変分 の手法を用いて最適化問題を解くことでguideをモデルの事後分布に近づけるようにする. この最適化は 自動微分 で行われるため, 勾配計算などを自動で効率的に計算してくれる. このあたりは PyTorch というPyroのバックエンドのライブラリによって行われる.

Pyroのデザインコンセプト

  • 汎用性: 汎用的なPythonコードでループや再帰, および乱数生成や推論ができること
  • 拡張性: 少しのオーバーヘッドで大量データにスケーラブルに対応できる（最適化やミニバッチ, 近似推論などを用いて）
  • 最小限: 内部的に, 組合せ可能な抽象的なコードで実装されている（Pytorchや他ライブラリに処理を委譲している）
  • 柔軟性: 高レベルな抽象的なAPIを提供しつつ, より複雑な推論やモデルが必要であればカスタムすることもできる

これらのコンセプトを実現しようとすると, 実際には相反している項目があるため実現が難しい. 例えば汎用性を上げるとスケーラビリティを担保するのが難しくなり, 最小の抽象化を実現しようとすると応用的なカスタマイズが難しくなり拡張性が下がる.

これらの問題を解決するためにWebPPLやEdwardなどの他の確率プログラミング言語のさまざまなテクニックを拝借してきた.

  • 組み合わせ可能なハンドラーによるコントロールフローと計算処理の分離:
    • Poutine（Pyro Coroutine）
    • Trace
    • Replay
    • Condition

今後の課題

参考資料

英語記事のサマリ - PyMC開発者のThomas Wieckiさんにインタビューした記事

MCMC edward pymc4 pyro r stan theano ベイズ データ分析 統計モデリング 確率

気分転換にベイズや確率プログラミングに関する英語記事や論文の翻訳サマリをさっくり書いていく予定.

第一回目はPyMC3の開発者のインタビュー記事.

TL;DR

PyMC3の開発者であり, かつQuantopian という投資会社で働いている Thomas Wiecki へのインタビュー記事の英語サマリ.

補足: Quantopian はクラウドソース型の投資会社で投資アルゴリズムを開発・支援している

内容

注意) 重要でなさそうな質問や回答は省略している.

確率プログラミング（Probabilistic Programming）とは？

確率プログラミングはベイズ統計モデリングをプログラミング言語のコードで表現するというパラダイムのこと. 例えばA_Bテストでモデルをコーディングして推論することで, “x%の確率でバージョンAのCVRの方がバージョンBより高い” と推論結果の分布から示すことができる. このA_Bテストの例は単純な例だが, 実際にはもっと複雑なモデルもありえる. 何かの問題を解決しようとする時, 何らかの事前情報や構造（階層構造など）があるため, それをモデルに組み込むことができる. 確率プログラミングはそれらのプロセスを支援するためのツールの一つ.

PyMCとは？

PyMC3は確率プログラミングのフレームワークの一つ. 特徴としてはPythonで記述することが可能であったり, 最先端の推論アルゴリズムを実装していることが挙げられる. また, コミュニティが活発であることも特徴の一つ.

PyMCはなぜ作られたの？ 他プロジェクトのEdwardやStanとの違いは？

PyMC3はもともとMCMCアルゴリズムの上位である次世代のHMC（ハミルトンモンテカルロ）アルゴリズムを実装することも目的に作られた. HMCを実装するには勾配計算が必要だったため, そのためにTheanoが採用された.

StanはC++で書かれておりカスタムDSLでモデルを記述する必要がある. 一方, PyMC3の場合には単にPythonで記述することができ, DSLを覚える必要がない.

Edwardはtensorflow上に構築されておりPyMC3と近い. Edwardは特に変分ベイズやスケーラビリティ, 深層生成モデルに注力している（注: Tensorflow Probabilityに統合されたのでもうアクティブではない）.

役割分担のまとめ

  • ML研究者で深層学習や変分ベイズがやりたい: Tensorflow Probability
  • 統計知識があるRユーザ: Stan
  • Pythonが好きなデータサイエンティスト: PyMC3

PyMCが実際に使われている例は？

主にアカデミックなさまざまな領域で使われており論文は200にのぼる. 企業のよくある例だとA/Bテストやサプライチェーン最適化など.

PyMCは深層学習の手法と連携していくことは可能？

PyMC4になるとバックエンドがTensorflow Probabilityになるからそうなるかもね.

金融分野で変分ベイズ vs MCMCを使用するトレードオフは？

変分ベイズは速いけどその分精度が落ちるから金融分野ではMCMCがおすすめ.

QuantopianではPyMC3はどのように用いられているか？

色々なところで使ってるけど, 主にポートフォリオ・ウェイティング（portfolio weighting）だね.

注) 金融周りがよくわからないのでちょっと省略

確率や統計を学ぶのにおすすめの書籍やeラーニングは？

書籍

eラーニング

参考資料

2019年の抱負: ベイジアンとしてやること・やらないことを宣言する(˘ω˘)ｽﾔｧ

pyro pymc4 python ベイズ 統計モデリング tensorflow tensorflow probability pytorch

目標ややりたいことは書き留めたり人に宣言した方がいいらしいので、改めてまとめてみた。

TL;DR

一言でいうと ベイズ x python x 金融 の3つに関連することだけやっていくつもり(｀・ω・´)

基本方針として Focus（選択と集中） にこだわって、 やること も決めつつ やらないこと も書いた。 自分の性格や今までの経験上、いろいろな技術をつまみ食いして時間を無駄に費やす癖があるので汗。

やること（MUST）

  • ベイズ統計モデリングについて書いていく
  • ベイズに関する英語の論文や記事をサマる
  • kaggleにベイズ勢として参加したい(｀・ω・´)
  • python極める
  • pytorchに魂売る（ベイズ統計モデリングのライブラリとしてpyroを使っていく）
  • 他のIDEに浮気しない（neovim + jupyterのみ）
  • 金融周りに詳しくなる。できればシステム作りたい。
    • スモールビジネスでちゃりんちゃりんしたい

やってもいいこと（COULD）

  • 可視化する方法や技をもっと知る（matplotlibやseabornを使いこなす）
  • Rで書かれた本も多いため、理解する目的で必要であればRも継続して学習していく
  • クラウド周り（GCP/AWS）の知識は本業でも副業でも必要になるので、仕事で必要になり次第知識を深める

やらないこと（WON'T）

  • 他のプログラミング言語に浮気して時間を浪費しない（NO go/rust/julia/clojure）
  • 代替ライブラリを無意味に比較・検証しない（NOT tensorflow/tensorflow probability）
  • 無意味にIDEを試したり設定にこだわったりしない（NO emacs/vscode）

補足

↓ もともとはtensorflowをやっていこうかと思っていたが、tensorflowやTFP（tensorflow probability）の開発が進んでないとか、そもそも書きづらいとか色々考えて早々にpytorch/pyroに乗り換えることにした(｀・ω・´)