IstioとAuth0でJWT認証付きAPIを5分でデプロイする

SREのたっち(@TatchNicolas)です。

JX通信社では、月に一度「WinSession」というリリースした機能や検証したリリースについて開発チーム全体へ発表する機会を設けています。今回は自分が前回社内に紹介した「パパッと便利APIを作って5分でお手軽＆セキュアにデプロイする」方法について書きます。

TL; DR;

• Istio/cert-manager/Auth0を使って、任意のコンテナを認証つきで5分でデプロイできる仕組みを作った
• 設定はアプリケーションごとに独立し、中央集権的なリポジトリに依存しない*1

きっかけ

プロダクト間で共通のAPIを認証付きでパパッと作りたいこと、よくありますよね？

でも、アプリケーションに毎回認証のための仕組みを組み込むのは骨が折れます。アプリケーションはあくまで、アプリケーションの関心ごとに集中させたい。すると、サイドカーコンテナを使って責務を分離するのが良さそうです。

そこで、少しでもその手間を小さくするための仕組みを作ってみよう、となりました。ちょうどPyCon JPの配信システムでGKEに慣れた人も増えてきたタイミングだったので、またGKE上に構築しようと考えました。

tech.jxpress.net

しかし前回と違って幾つか課題がありました。

課題と対策

1. あるアプリケーションの関心ごとがそのリポジトリの中で完結できない
   • JX通信社ではモノレポではなくマイクロサービス単位でレポジトリを切っている
   • 「気軽さ」を売りにしたいので中央集権的なリポジトリを作りたくない
   • Ingressだと多数のサービスへのトラフィックルールが1つのリソースのmanifestに列挙される
   • するとこの仕組み自体がよく使われるようになる程、Ingressリソースの記述が長くなってしまう
2. 新しいアプリケーションをデプロイするたびに証明書を作る 必要がある
   • <アプリケーション名のサブドメイン>.<会社のドメイン> みたいな形で割り振りたい
   • しかしGCPのマネージド証明書はワイルドカード非対応
   • 増えた証明書をIngressのAnnotationに列挙する必要があり、記述がまた大きくなる
3. きちんと認証をかけたいけど、アプリケーション本体と認証は分離したい
   • 基本的にはエンドユーザー向けというよりも内部で使うものたち
   • アプリケーションは自身の機能だけに集中したい

上記の3つの課題に対して、Istio/cert-manager/Auth0 の組み合わせた 「新しくリポジトリを作ったら、その中だけで必要なものが揃う」 ような仕組みで解決を試みました。

1. 個々のアプリケーションへのトラフィック制御はIstioのVirtualServiceに任せることで、アプリケーションごとのリポジトリでトラフィックの管理ができる
2. cert-managerを使ってワイルドカード証明書を利用する
   • アプリケーションが増えるたびに証明書を増やしたり、その設定を更新したりしなくて良い
   • IstioのGatewayリソースに三行書き足すだけで簡単
3. Auth0を使って手軽に認証をつける
   • こちらもIstioのRequestAuthentication/AuthorizationPolicyを使うことで簡単に組み込むことができます。
   • アプリケーション側の実装は何も変えなくてOK

今回の環境/前提

• クラスタ: v1.15.12-gke.2
• Istioおよびcert-managerはインストールされている前提とします
  • どちらもOperatorでインストールしました
  • GKEのアドオンのIstioは使っていません
• クラスタ外からのアクセスはistio-ingressgatewayのLoadBalancerで受けてます
• アプリケーションのデプロイ先のNamespaceでistio-autoinjectは有効化しておきます
• Auth0のsign upも完了していることとします

実際に作ってみる

(以下、本記事において「Application」「API」はAuth0上の概念、「Service」「Secrets」などはKubernetesリソース、「アプリケーション」は今回デプロイしたい対象としての一般名詞を指しています)

1. 全体で使うリソースの準備

各アプリケーションではなく、GKEクラスタ全体で使うリソースのリポジトリに置く想定のものから解説します。

cert-manager

apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
  name: clusterissuer
  labels:
    repo: platform
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: 'yourname@yourdomain'
    privateKeySecretRef:
      name: cm-secret
    solvers:
    - dns01:
        clouddns:
          # GCPプロジェクトを指定
          project: your-project

CloudDNSを使ったchallengeを行うには、cert-managerのPodがCloudDNSを操作する権限を持つ必要があります。今回は、Workload Identityを使って、cert-managerのServiceAccountに権限を付与する方法を取りました*2 。

apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
  name: wildcard
  namespace: istio-system
  labels:
    repo: platform
spec:
  # certificateリソースの名前じゃなくて、
  # このsecretNameをistioのGatewayで使う
  # https://istio.io/latest/docs/ops/integrations/certmanager/
  secretName: cm-secret
  issuerRef:
    name: clusterissuer
    kind: ClusterIssuer
  commonName: <your domain>
  dnsNames:
  - <your domain>
  - '*.<your domain>'

CertificateリソースのsecretNameで指定した名前で、cert-managerがKubernetesのSecretリソースを作成してくれます。このSecretリソースはあとでIstioのGatewayリソースから参照されます。

Istio

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: gateway-with-tls
  namespace: istio-system
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    tls:
      mode: SIMPLE
      credentialName: cm-secret
    hosts:
    - "*.<your domain>"

Gatewayリソースに、前述のCertificateリソースによって作られるSecret(cm-secret)を紐付けます。

apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
  name: require-auth0-jwt
spec:
  selector:
    matchLabels:
      require-auth0: enabled
  jwtRules:
  - issuer: https://<yourtenant>.auth0.com/
    jwksUri: https://<yourtenant>.auth0.com/.well-known/jwks.json

require-auth0: enabled なラベルを持ったPodへの通信には認証を必要とするような設定をします。但しこれだけではまだ設定不足で、 不正なjwtを弾くことはできても、そもそもAuthorizationヘッダが無いリクエストは素通りしてしまいます。また、そのJWTがどのアプリケーションのために発行されたのかのチェックもできません。その対策は、アプリケーション単位に行います。

2. アプリケーション固有のリソースを作る

続いて、個々のアプリケーションごとに作成するリソースをみてみましょう。新しいアプリケーションを生やしたくなったら、ここ以降の手順を繰り返せばOKです。お好きなコンテナを動かしてください。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample
  labels:
    app: sample
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sample
      require-auth0: enabled
  template:
    metadata:
      labels:
        app: sample
        require-auth0: enabled
    spec:
      containers:
      - name: app
        image: tatchnicolas/envecho:v0.3.2
        env:
        - name: ENVECHO_PORT
          value: "8765"
        - name: ENVECHO_MESSAGE
          value: "Hi! I am running as a `sample` service on GKE!"
        ports:
        - containerPort: 8765
---
apiVersion: v1
kind: Service
metadata:
  name: sample
  labels:
    app: sample
spec:
  type: ClusterIP
  selector:
    app: sample
    stage: current
  ports:
    - name: http
      protocol: TCP
      port: 8888
      targetPort: 8765

DeploymentとServiceは、require-auth0: enabled というラベルを指定している以外は特に変わったことはありません。そしてこのラベルが前述のRequestAuthenticationリソースのselectorと対応します。

Serviceが公開するポートは、一つしか無い場合はIstioがよしなにしてくれるので、何でもOKです。

続いて、トラフィック制御と認証を追加しましょう。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sample
  labels:
    app: sample
spec:
  gateways:
  - istio-system/gateway-with-tls
  hosts:
  - sample.<your domain>
  http:
  - route:
    - destination:
        host: sample.default.svc.cluster.local
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: sample-auth-policy
  labels:
    app: sample
spec:
  selector:
    matchLabels:
      app: sample
  action: ALLOW
  rules:
  - when:
    - key: request.auth.audiences
      values:
      # auth0のidentifierと一致させる
      - sample.<your domain>
  - from:
    - source:
        namespaces: ["prometheus"]
    to:
    - operation:
        methods: ["GET"]

sample.<your domain> というホスト名で来たリクエストを、前の手順で作ったServiceに紐づいたPodたちに回すようにVirtualService設定をします。

先ほど、RequestAuthenticationはまだ設定が不足していると書きましたが、足りない部分をここで補います。AuthorizationPolicyの spec.rules[0].when 以下の部分で、jwtのaudienceが正しいことを求めるようになります。また、AuthorizationPolicyを設定するとAuthorizationヘッダが無いリクエストもちゃんと弾いてステータスコード403を返すようになります。(あとで管理しやすいようにドメインと一致させましたが、特にその必要はありません。)

今回のテーマからは少し逸れますが、アプリケーションがPrometheusでinstrumentされていてる場合スクレイピングも弾かれてしまいますので、Prometheusサーバが prometheus というネームスペースにデプロイされていることを想定して、スクレイピングのリクエストは許可するような設定を参考として追加しました。

Kubernetes側の設定は以上です。

3. Auth0側にAPIを登録する

Auth0のコンソールにログインして、アプリケーションをAPIとして登録します。2. の手順の中でjwtのaudienceとして文字列が必要になります。

細かな手順は 公式の Register APIs を参照してください。注意すべき点はたった一つ、identifierの値を spec.rules[0].when 以下で指定した値(上記の例ではsample.<your domain>) とそろえるだけです。

APIを登録すると、対応するTest Applicationが作成されると同時に、API詳細画面のTestというタブからリクエストの方法が各種言語で見られるようになります。

4. 動作確認

Client、Auth0、istio-proxy付きPodの関係図

今回はcurlを使ってトークンを取得し、実際に立てたサービスへリクエストを試みます。 Applicationsの一覧に<API作成時の名前> (Test Application) というApplicationが作成されていますので、Client IDとClient Secretを使って次のように実際のアプリケーションへアクセスします。

# 上記の図の(1)
$ TOKEN=$(curl --request POST \
  --url https://jxpress.auth0.com/oauth/token \
  --header 'content-type: application/json' \
  --data '{"client_id":"xxxxxxxx","client_secret":"abcdefghijklmnopqrstuvwxyz","audience":"sample.<your domain>","grant_type":"client_credentials"}' | jq -rc '.access_token')
# 上記の図の(3)
$ curl -i -H "Authorization: Bearer $TOKEN"  https://sample.<your domain>
HTTP/2 200
date: Thu, 27 Aug 2020 03:18:21 GMT
content-length: 46
content-type: text/plain; charset=utf-8
x-envoy-upstream-service-time: 3
server: istio-envoy

Hi! I am running as a `sample` service on GKE!

TOKENが不正だったり、AuthorizationPolicyで指定したaudienceがJWTのaudience(=Auth0 APIのidentifier)が一致しない場合には403 Forbiddenが返ってきます。

Auth0の使い方について

今回は自動で作成されるTest Applicationを利用したので分かりにくいのですが、実際の運用では

• デプロイするAPIのConsumerごとにApplicationを作成
• そのApplicationに対してAPIの利用を許可する

という手順を踏むことになると思います。つまり、あるApplicationは複数のAPIに対する認可を得ることができ、またAPIも複数のアプリケーションに認可を与えることができます。

前述の例の audience の部分が使いたいAPIで設定したidentifierになり、ApplicationがAPIに対する権限を持っていなければAuth0からJWTが入手できないので、「どのApplicationがどのAPIを利用できるか」をAuth0で一元管理できるというわけですね。

たとえば、画像のアップロードを受け付ける foo というApplicationが、いい感じにリサイズや圧縮をしてくれる便利API hoge や画像に何が写っているかを判定する fuga というAPIを利用する場合、Application(foo) がAPI (hoge fuga) を叩けるようにAuth0のコンソール上でAuthorizeしてやる 必要があります。

詰まったところ/改善点

Istioがプロトコルを認識してくれない

今回の仕組みを作る途中、RequestAuthorization/AuthenticationPolicyを有効化すると upstream connect error or disconnect/reset before headers なエラーが出る現象にハマってしまいました。

本来IstioはデフォルトでHTTPおよびHTTP/2のプロトコルは自動で検出可能で、VirtualServiceは、spec.http.route[].destination の指しているServiceが公開しているポートが1つだけの場合、自動でそのポートへリクエストを回してくれます。*3 実際、認証をかけない状態ではきちんとリクエストは通っていました。

なので特に明示的に書かなくても大丈夫と思っていたのですが、Service側で spec.ports[].name に http を指定してやる必要がありました。(そういう仕様なのか意図せぬ挙動なのかまでは調べきれてません...)

VirtualServiceのトラフィック制御条件が散らばってしまう

これは当初の目標だった「アプリケーションごとのリポジトリでトラフィックの管理ができる」ことの裏返しなのですが、トラフィック制御のルールが複数のリポジトリに散らばってしまいます。

公式Docにもある通りVirtualServiceは一つのKubernetesリソースとして登録することも、複数のリソース分割して登録することもできます。今回はその機能を前向きに利用したのですが、そのデメリットとして、例えばホスト名をベースにトラフィック制御していると、たまたま条件がかぶっていたり矛盾していると期待した振る舞いをしてくれない可能性があります。

it will only have predictable behavior if there are no conflicting rules or order dependency between rules across fragments

以前書いた記事のように、Admission Webhookなどを使って、自前で条件被りのチェックを実装しても良いかもしれませんが、条件のパターンは多岐に渡りますし、「何を意図せぬ衝突とし、何を意図した衝突とするか」の判断も難しいので一筋縄では実装できなさそうです。

tech.jxpress.net

さいごに

本記事の元になった社内発表でも、ライブコーディング的にデモを行って5分でサンプルアプリをデプロイすることができました。少しでも皆さんの参考になれば幸いです。

*1:もちろん、Istioやcert-manager自体の管理をするリポジトリは用意しますが、「アプリケーションを追加するときに、基盤の事情は知らなくていい」がポイントです

*2:https://github.com/jetstack/cert-manager/issues/3009

*3:https://istio.io/latest/docs/ops/configuration/traffic-management/protocol-selection/#automatic-protocol-selection

PyCon JP 2020のTwitter実況システムをGKE上に作った話

SREのたっち(@TatchNicolas)です。

今年のPyCon JPはオンライン開催でした。JX通信社はSilverスポンサーとして協賛したほか、イベントをより盛り上げるために、参加者の反応をリアルタイムに配信に反映するシステムを開発・提供しました。

jxpress.net

アプリケーションはPythonで作られており、基盤としてGKEを採用しました。データ分析基盤や昨年の開発合宿等で社内向けのプロジェクトにKubernetesの採用した事例は過去にもあったのですが、今回はじめて社外向けのシステムに採用したので、その裏側について書いてみたいと思います。

できたもの

構成図

構成としては比較的シンプルだと思います。

基本的な処理はGKE上で行い、データの永続化はFirestoreを使っています。一部、ブラウザで動く運営向けフィード画面上の操作(いいね・リツイート)について、Firebaseを使った書き込みをトリガーとしてCloud Functionsを使って反映させています。

PyCon JP 2020 SNSリアルタイム配信システム 構成図

(一部リソースは省略しています)

設計のポイント

前提としては、

• 継続的に提供するサービスではなく、PyCon JP 2020が開催されている二日間のみ稼働すればよい
• Kubernetes採用の理由は「普通に作っても面白くない、今までと違うことにチャレンジしよう」
• 一方で、短期間 + 開発チームは普段の業務と並行してすすめるため、あまり欲張りはできない

以上から、 「今までよりちょっと便利」を感じてもらいつつも「今までと違いすぎない」 を目指して構成を考えました。

やってみて

Kubernetes投入のハードルは思った以上に低かった

もともとJX通信社ではECSを使い倒しているので、「これはECSでいうとXXみたいな何か」という説明で、Kubernetesに馴染みのないメンバーにもすんなり理解してもらえたと思います。毎週社内の有志でKubernetes勉強会を開催していたので予備知識としても全くのゼロからのスタートではなく、実践の場として良い機会を作れたなと思います。

社内輪読会、クリーンアーキテクチャの次は「Kubernetesで実践するクラウドネイティブDevOps」をやってみることになりました。k8s完全に理解する。https://t.co/oV7FUsDYlJ

— uemoto@JX通信社 Engineering Manager🐣🐥 (@jazzsasori) 2020年6月11日

(最近は本を読むより、それぞれが作りたいものを作ってもくもくする時間になりつつあります。)

永続化や認証はFirebaseを利用したので、複雑になりがちな部分をうまくマネージドに逃がせたことも導入の容易さに繋がったと思います。

port forward のおかげでローカル開発が捗った

今回のプロジェクトでは単にツイートを取得してくるだけでなく、不適切な書き込みをできるだけ除去するために幾つかの機械学習モデルをWeb API化して利用しています。

実際には構成図のcrawlerから利用されていて、収集したツイートをスコアリングしています。ローカルでのcrawler動作確認時にもツイートの内容を判定するためにモデルを叩きにいきたいのですが、そのためにモデルをダウンロードしたりdocker-composeなど用意して推論APIをローカルに立てるのも面倒です。さらに、手元のマシンのリソースも余分に消費してしまいます。

そこで kubectl port-forward <推論APIのService> <ローカルのポート>:<推論APIのポート> とlocalhostで使えるようにすることで、別途APIを立てることなくスムーズに開発ができるようになりました。

APIのURLは環境変数としてcrawlerに渡すようにしているので、切り替えも簡単に行えます。

これは普段のECSの開発では無かった体験なので、開発メンバーからも「こりゃ便利だ」と言ってもらえました。

Secretsのおかげで開発用のAPIキーを簡単に共有できた

Slack連携やTwitter APIの取得のために、いくつか秘匿情報としてPodに渡したいAPIキーがありました。コーディング時は前述の推論APIのURLと同様、実際にSlack/TwitterのAPIを叩きたいのですが、メンバーが自分でキーを用意するのはやはり面倒です。

こちらも検証および本番環境ではSecretsリソースを使って環境変数としてアプリケーションへ渡しているので、ローカルで使いたい場合は検証環境から各種キーを取得して環境変数へセットするワンライナーを用意することで、各メンバーがそれぞれキーを発行することなく利用でき、開発に集中することができました。

export SLACK_CHANNEL=$(kubectl get configmap crawler --template="{{.data.SLACK_CHANNEL}}")
export SLACK_TOKEN=$(kubectl get secret crawler --template="{{.data.SLACK_TOKEN}}"|base64 -D)

上記をそのままdirenvの .envrc に書いておけば、下準備はほとんど必要なく、pullしてきてすぐに開発を始められます。

まとめ

PyCon JPに限らず、様々なテックカンファレンスがオンラインで開催されている中で、JX通信社としてイベントを少しでも盛り上げるために貢献できたことはとても嬉しいです。

今回のPyCon向け配信システムに限らず、チーム全体での開発のスピードを上げるために、Kubernetesを使って社内のマイクロサービス基盤を改善していく取り組みも行っています。次回はもうすこしKubernetesのエコシステムを生かした仕組みづくりについて書いてみたいと思います。

アプリを利用しながらアプリの更新ができるin-app updates

Androidエンジニアの@sakebookです。 今まではストアに飛ばしたり、自前で用意したロジックやAPIで更新があるかを確認していました。しかしそんな時代はもう終わりました。Play Core Libraryを使えばアプリ内でアップデートが可能になります。

in-app updates

文字通りアプリ内でアプリのアップデートを行える機能です。アプリのアップデートといえば、知らない間に自動更新されていたり、ストアへ行って更新ボタンを押すなどがありましたが、それらのトリガーをアプリ内から任意のタイミングで引き起こすことが可能になったイメージです。

in-app updatesでは大きく分けて2つの方法がサポートされています。

フレキシブル(Flexible)

知らない間に自動更新

に相当するものです。ユーザにアプリを利用させつつ更新版アプリをDLし、DL完了したタイミングで再起動するメソッドを呼び出すことでアプリを再起動させられます。

アプリにとって必須とは言えないアップデート等の場合に有効です。

即時(Immediate)

ストアへ行って更新ボタンを押す

に相当するものです。更新版アプリをDLしている間はユーザにアプリのUIを触らせない形になります。DL完了後、画面に従いアプリは自動で再起動します。

アプリにとって必須なアップデート等の場合に有効です。

実装

詳細はドキュメントに任せます。

ざっくりいうと、アプデが可能かどうか確認し、可能であればFlexible or Immediateとしてアプデリクエストを送る流れです。

Flexibleの場合は、自動ではアプデ完了しないので、DLの進捗をモニタリングし、完了したら再起動を促すUIを表示するのが推奨されています。再起動自体はアプリをDL後、AppUpdateManager#completeUpdate()を呼び出すことで可能です。アプリがBGの状態で呼び出すとアップデートがサイレントインストールされます。

Immediateの場合は、全画面表示になりユーザのアプリの利用を阻害しますが、ユーザはキャンセルすることもできます。そのため、DLがキャンセルされた場合に途中から再開するべきか判定する処理があることが望ましいです。

どちらの場合でも、ユーザはキャンセル可能で、アップデートを強制させるものではないことに注意してください。

テスト

ロジックのテスト用にFakeAppUpdateManagerというクラスが用意されています。AppUpdateManagerと同様のinterfaceを持っています。状態を操作できることと、実際にDLやUIは表示させないこと以外は同じです。

初めての場合は実際にアプリがどんな挙動を取るのか確認したくなると思います。

そんなとき、Google Playの内部アプリ共有機能を使えば実際にin-app updatesを確認することも出来ます。

内部アプリ共有(internal app-sharing)

通常、ストアにあげるアプリにはVersionCodeをincrementしたりする必要がありますが、internal app-sharingを使えばincrementの制約を無視したり、許可リストによる配布が可能になります。

アプリをアップロードしてリンクを発行することで、認定テスターやリンクを知っている人のみDL可能にします。認定テスターとはメーリング リストに追加したテスターのことです。

注意点として、認定テスターはGooglePlayアプリの設定からバージョンを7回タップしてデベロッパー設定をしておく必要があります。設定をしていないと、発行したリンクを踏んでもDLできません。また、既存のアプリとは同じPackage Nameなので端末内で同居はできません。

認定テスターは発行したリンクを踏むことでストア内のinternal app-sharingのアプリページに遷移し、DLできるようになります。

in-app updatesは、GooglePlayアプリ上で更新があるかどうかでアプデ可能かを判定しています。internal app-sharingを使うと、既にストアに上がっているアプリとは別のアプリとして扱われます。

別のアプリとして扱われるというのは、更新判定が別という意味です。

例えばストアのアプリのVersion Codeが2で、internal app-sharingのアプリのVersion Codeを1にして、internal app-sharingのVersion Code1のアプリをインストールしていても更新判定は行われません。

internal app-sharingのアプリで、Version Codeが2以上ものを用意し、そのリンクを踏んで、GooglePlayアプリ上で更新があることを認識させてあげることで、アプデ可能判定フラグを建てることが出来ます。

• internal app-sharingのVersion Code 1のリンクを踏んでアプリをインストール
• internal app-sharingのVersion Code 2のリンクを踏んで「更新」ボタンが確認できたら更新をせずストアから離れる
• アプデ可能判定フラグが立つ
• internal app-sharingのVersion Code 1のアプリでin-app updatesの実装をしている画面を表示
• アプデ可能判定になりin-app updatesのフローに入る

つまり、既存のストアアプリとは別で、バージョン違いの内部アプリ共有のアプリを2つ用意することで既存のストアアプリに影響を与えることなく実際にin-app updatesの確認ができます。

任意の識別しやすい名前をつけることが出来ます。ニュースダイジェストではまだAndroid App Bundle(AAB)に対応していませんが、もちろんAABでも可能です。

例

ニュースダイジェストでは、Immediateの方式で実装しました。

ニュースダイジェストでは、ユーザ一人ひとりに対して返事を行うことは現状していません。しかしユーザからのフィードバックには目を通しています。

フィードバックの中には、アプリを最新版にしてもらえれば直っているものとか対応している機能があったりするのにと思うケースもちらほらあります。

そこで今回は、フィードバックを送る画面でin-app updatesを組み込むことにしました。そうすることで、現状送ろうとしていたフィードバックはアプデによって解決されるかもしれないことを示せるようにしました。

なので、FlexibleではなくてImmediateを選択しました。

もちろん内容によっては解決されないものもありますし、そもそもin-app updatesの仕組みを導入したバージョン以降でしか機能しないです。

今回のような例の実装であれば、1日あればできるので、気になった方は仕組みとしては入れておくと良いと思います。

きめ細やかな制御

今回は利用しませんでしたが、ストアに更新可能なアプリが配布されてから何日経過しているかという情報や、Google Play Developer APIと組み合わせることでアプリのバージョンごとにアップデートのpriorityの設定が可能です。

更新が頻繁であったり、FlexibleとImmediateを組み合わせたい場合などに有効だと思います。

まとめ

開発者としてはなるべく最新のアプリを使ってもらいたいです。そうすることがユーザにとってもメリットです。

適切に更新導線を組み込むことで、ユーザにストレスなく最新のアプリを提供できるようになります。

in-app updatesはその選択肢の一つになるでしょう。

参考

アプリ内アップデートをサポートする  |  Android デベロッパー  |  Android Developers

Support in-app updates  |  Android Developers

Internal app sharing | Google Play Console

Exploring in-app updates on Android | by Joe Birch | Google Developers Experts | Medium

Support In-App-Updates Implementation Example | by Rajan Maurya | Medium

AppUpdateInfo  |  Android デベロッパー  |  Android Developers

Firebase をフロントエンドから適切に隠蔽するための「Hooks Injection パターン」

取締役の小笠原(@yamitzky)です。

JX通信社では、React 製のフロントエンドでも Clean Architecture で設計するなど、なるべく特定のバックエンドに依存しない設計を心がけたりもするのですが、一方で Firebase をラップした react-firebase-hooks などの「便利な Hooks」を使って開発スピードを加速したい、という課題を持っていました。

そして先日、次の記事が話題になっていました。まさに「どう Firebase を隠蔽するか」と「どう Firebase を活用するか」を両立する悩みです。

blog.ojisan.io

結論を言うと「Hooks そのものを注入する」のが筋が良いのではないか と思っています。個人的に「Hooks Injection パターン」と名付けたこの方法をご紹介したいと思います。

今回の記事の完成形はソースコードを公開し、デモアプリやFirestore に依存しない Storybookも公開しています。

github.com

「便利な Hooks」とは

react-firebase-hooks や react-apollo などの、特定のバックエンドを手軽に使える Hooks ライブラリを、僕は勝手に「便利な Hooks」と呼んでいます。例えば react-firebase-hooks をつかうと、次のようなシンプルなコードを書くだけで、Firestore を扱えます。Firestore なので、もちろん変更はリアルタイム反映されます。

import React from 'react'

type Todo = { id: string; title: string }

// 記事一覧ページ
export const TodoList: React.FC = () => {
  const [todos, loading, error] = useCollectionData<Todo>(firebase.firestore().collection('todos'))
  if (error) {
    return <div>error!</div>
  }
  if (loading) {
    return <div>loading...</div>
  }
  return (
    <ul>
      {todos.map((todo) => <li key={todo.id}>{todo.title}</li>)}
    </ul>
  )
}

react-apollo も useQuery() を呼び出すだけで、任意の GraphQL のバックエンドを適切なライフサイクル*1で扱えます。この２つは似たような思想のライブラリと言えるでしょう。つまりここで言う「便利な Hooks」は「特定のバックエンドに密結合にする代わりに、めちゃくちゃ便利にバックエンドを使えるようになる Hooks」です。この手軽さは、Hooks のない時代には考えられないものでした。

コンポーネントと Hooks (バックエンド)を密結合にさせてしまうのは大変便利なのですが、密結合の弊害もあります。例えば「GraphQL や Firebase を捨てたい！」となったときに UI (コンポーネント)を書き換えないといけません。また、コンポーネントに副作用がある(通信が発生する等)と、テストしづらく、Storybook などにも載せづらい等、再利用性の低いコンポーネントになってしまっています。

疎結合にする方法はいくつかあるのでご紹介します。ただしここでは「react-firebase-hooks のような便利な Hooks を諦めない」という縛りを入れています。

疎結合にする方法１：Presentational Component と Container Component の分離

上記例の TodoList を疎結合にするだけであれば、なるべく外界(Firebase)との接点を限定的にする、という方針があるでしょう。いわゆる Presentational Component と Container Component の分離です。これは、Hooks が発明される前から(Redux の文脈とかでも)言われていた方法です。

// TodoListContainer.tsx ＝ Container Component
export const TodoListContainer: React.FC = () => {
  const [todos, loading, error] = useCollectionData<Todo>(firebase.firestore().collection('todos'))
  if (error) {
    return <div>error!</div>
  }
  if (loading) {
    return <div>loading...</div>
  }
  return <TodoList todos={todos} />
}

// TodoList.tsx ＝ Presentational Component
export const TodoList: React.FC<{ todos: Todo[] }> = ({ todos }) => {
  return (
    <ul>
      {todos.map((todo) => <li key={todo.id}>{todo.title}</li>)}
    </ul>
  )
}

これで TodoList は再利用性が高まり、テストしやすくなりました。今後 UI の責務は TodoList が担い、通信などの責務は Container Component の方に逃がすことができます。一方で Container Component の方は引き続き副作用を持ってテストしづらいまま です。

しかしこれは単純すぎる例です。実際のアプリケーションでは、Container Component が様々なデータ(認証や関連データetc...)を扱う必要があり、どんどんファットになっていきます。Presentational / Container Component の分離という方法は王道ではあるものの、Hooks のメリットがどんどん薄れてしまうような良くない手段である と考えています(あくまで個人的な意見です)。

疎結合にする方法２：クライアントを Injection する

Apollo のような「便利な Hooks」ライブラリでは、通信クライアントを注入することができます。次の例は、Apollo を使った場合のイメージです*2。

// App.tsx ＝ 一番上に存在する root component
export const App: React.FC = () => {
  const client = new ApolloClient(/* 略 */)
  return (
    <ApolloProvider client={client}>
      <Routes />
    </ApolloProvider>
  )
}

// TodoList.tsx
export const TodoList: React.FC = () => {
  const { loading, error, data: todos } = useQuery(QUERY)
  if (error) {
    return <div>error!</div>
  }
  if (loading) {
    return <div>loading...</div>
  }
  return (
    <ul>
      {todos.map((todo) => <li key={todo.id}>{todo.title}</li>)}
    </ul>
  )
}

TodoList の実装は何も変えていませんが、テストはしやすくなっています。テスト時や Storybook で TodoList を利用する際には、適当なモックのクライアントを注入できるので、副作用がコントロールできているのです。

react-firebase-hooks には直接的にはこの仕組みはありませんが、React の Context API と useContext を使えば実現できるでしょう。

// Context.ts
export const ClientContext = React.createContext()

// App.tsx
export const App: React.FC = () => {
  const client = firebase.firestore()
  return (
    <ClientContext.Provider value={client}>
      <Routes />
    </ClientContext.Provider>
  )
}

// hooks/todo.tsx
export const useTodos: { todos?: Todo[]; loading: boolean; error?: Error } {
  const client = useContext(ClientContext)
  const [todos, loading, error] = useCollectionData<Todo>(client.collection('todos'))
  return { todos, loading, error }
}

// TodoList.tsx
export const TodoList: React.FC = () => {
  const { todos, loading, error } = useTodos()
  if (error) {
    return <div>error!</div>
  }
  if (loading) {
    return <div>loading...</div>
  }
  return (
    <ul>
      {todos.map((todo) => <li key={todo.id}>{todo.title}</li>)}
    </ul>
  )
}

これで Firebase そのものに依存することなく、react-firebase-hooks を使うことができました。client を差し替えればテストもできそうです。また、useTodos() のようなカスタム Hooks を定義してみたことで、TodoList の実装もスッキリしてきました。

しかし useTodos() が Firebase のライブラリインターフェースそのものに依存 しています。UI 層が間接的にライブラリのインターフェースに引っ張られてしまっており、今回の場合はこの方法はナンセンスだと思います(※Context を通じて注入するパターン自体はいい方法です)*3。

疎結合にする方法３：Hooks 自体を Injection する

最後に紹介するのが、本記事の趣旨である「Hooks Injection パターン」です。

「方法２」は、UI から使う Hooks が Firebase のようなライブラリのインターフェースに引っ張られてしまっていることが問題でした。そこで、Hooks が使う Client を Injection するのではなく Hooks 自体を Injection すると、冗長さを減らしながらも、さらに疎結合にできているのではないか と思います。

// hooks/todo.ts
export type TodoHooks = {
  useTodos(): { todos?: Todo[]; loading: boolean; error?: Error }
}
export const TodoHooksContext = React.createContext<TodoHooks>()
export const useTodos: { todos?: Todo[]; loading: boolean; error?: Error } {
  return useContext(TodoHooksContext).useTodos()
}

// hooks/todo/firestore.ts
export const useTodos: { todos?: Todo[]; loading: boolean; error?: Error } {
  const [todos, loading, error] = useCollectionData<Todo>(firebase.firestore().collection('todos'))
  return { todos, loading, error }
}

// App.tsx
import { TodoHooksContext } from './hooks/todos'
import * as firestoreTodoHooks from './hooks/todos/firestore'

export const App: React.FC = () => {
  return (
    <TodoHooksContext.Provider value={firestoreTodoHooks}>
      <Routes />
    </TodoHooksContext.Provider>
  )
}

// TodoList.tsx
import { useTodos } from './hooks/todos'
export const TodoList: React.FC = () => {
  const { todos, loading, error } = useTodos()
  if (error) {
    return <div>error!</div>
  }
  if (loading) {
    return <div>loading...</div>
  }
  return (
    <ul>
      {todos.map((todo) => <li key={todo.id}>{todo.title}</li>)}
    </ul>
  )
}

TodoList.tsx は次の制約を満たしています。

• コンポーネントは Firestore に依存しておらず、Hooks の実装の詳細が何であるかを知らない
• コンポーネントからのカスタム Hooks の使い方が自然
• hooks/todo/firestore.ts のみが Firestore のライブラリのインターフェースに依存している
• 新たな class の定義などは不要で、カスタム Hooks を自然に実装すれば良い
• テストや Storybook での Hooks の実装が差し替え容易
• ちゃんと型安全

冗長になった部分として、Hooks のインターフェースを別に定義したり、Provider を通じて Injection していますが*4。

Firestore をやめる方法

疎結合にできたので、Firestore をやめて別のバックエンドを採用したい場合でも、差し替え容易です。

例えば、次のように実装を変えたファイルを作って、Context に渡すパッケージを変更するだけです。

// hooks/todo/rest-api.ts
export const useTodos: { todos?: Todo[]; loading: boolean; error?: Error } {
  const [todos, setTodos] = useState(null)
  useEffect(() => {
    axios.get('/todos').then(r => setTodos(r))
  }, [])
  return { todos, loading: /* 略 */, error: /* 略 */ }
}

認証

認証も同様に react-firebase-hooks を諦めずに疎結合にできます。同様に定義していけば、次のように認証することもできます。(あまり良いコンポーネント分割ではない例ですが)

// TodoList.tsx
import { useTodos } from './hooks/todos'
import { useAuth } from './hooks/auth'

export const TodoList: React.FC = () => {
  const { user } = useAuth()
  const { todos } = useTodos({ user }) // ユーザーの記事一覧を見る
  return (
    <div>
      <h1>{user.name} さんの記事一覧</h1>
      <ul>
        {todos.map((todo) => <li key={todo.id}>{todo.title}</li>)}
      </ul>
    </div>
  )
}

おわりに

今回は、Hooks 自体を Injection することで、react-firebase-hooks のような便利な Hooks を諦めず、UI と Firebase を疎結合にする、、、といった方法を紹介しました。

実務でも使っているパターンではあるのですが、最近思いついただけなので、色々と穴があるかもしれません。何かありましたら、ご指摘をいただけると嬉しいです。

また、JX通信社では React/TypeScript/Firestore などを使いながらプロダクト開発をする学生インターンを募集していますので、ぜひよろしくお願いいたします。

www.wantedly.com

*1:変なムダリクエストが発生しない、適切にキャッシュされる、などを指しています

*2:実際には本ブログのために動かしてるわけではないので、間違ってたらすみません

*3:あえて触れてないのですが、Firebase そのものではなく、それをラップしたクライアントを注入する方法の方がベターだと思います。しかし方法３の方が Hooks っぽい責務の分割になると思っています

*4:関数を増やしても Provider は一つで良いです。けど、意味的な単位でわけた方が良いと思います(hooks/user.ts、hooks/todo.ts、hooks/commment.ts など)))、疎結合にしたいのであれば流石に許容範囲でしょう。ただ、 ./hooks/todo.ts の中で useContext を通じて Hooks の実体を呼び出すコードが書かれているのはちょっと微妙だなと思っています((デコレータなど使えば回避策はありそうですが

データ基盤を支える技術 - ETLフレームワークの実践的な選び方・組み合わせ方

JX通信社シニア・エンジニア兼データ基盤担当大臣の@shinyorke（しんよーく）です.

最近やった「ちょっとした贅沢」は「休日, 自宅で🍺片手に野球を見ながらUberEatsで注文したランチを楽しむ」です. ⚾と飲食を提供してくださる皆さまに心から感謝しております🙏

JX通信社では,

• 機械学習を用いたプロダクト開発・施策
• プロダクト・サービスの改善に関する分析
• 日々のイベントをメトリクス化して可視化（いわゆるBI的なもの）

を円滑かつ効率よく行うため, 昨年からデータ基盤を整備・運用しており, 現在では社員のみならず（スーパー優秀な）インターンの皆さまと一緒に活用し, 成果を出し始めています.

ainow.ai

なぜデータ基盤が必要か?どういった事をしているのか?...は上記のインタビューに譲るとして, このエントリーでは「データ基盤を支える技術 - ETL編」と称しまして,

• Python製ETLをどうやって選ぶか?
• JX通信社におけるETLフレームワークの使い分け
• 小さく作って運用するETLならprefect最高やで！

というお話をさせてもらえればと思います.*1

TL;DR

• ETLフレームワークはどれも癖があって得意不得意も違うので, 一つに絞らず適材適所にやってこ.
• JX通信社では, 大きめのWorkflowを運用するのにAirflow（Cloud Composer）, 1〜複数個のコンテナで収まるバッチをprefectでやってます.
• 大きめWorkflow/小さいETL両方行ける（と思われる）prefectに期待する未来はあって良さそう

おしながき

対象読者

そこそこハイコンテクストな話題なので一応書きます.

• 規模の大小を問わず, 企業および何かしらの団体でデータ基盤構築・運用に携わっている方.
• AirflowやLuigi, kubeflowといったETLフレームワークを使った構築・運用をしたことがある方. SRE的なレイヤーが得意ならなお望ましい.
• ETLとかWorkflowとかDAGとかそのへんの単語を解説しなくても読める方.
• 「PythonicなETL話」なので, DigDag等, 別言語で実装・定義されたETLとの比較はしておりません.

Python製ツールの話メインですが言うほどPython出てこないです&統計・機械学習のアルゴリズム等は出てきませんのでそっち方面の知識は不要です.

PythonicなETLフレームワークの選び方

私の話で恐縮ですが, 過去のお仕事および個人プロジェクトでAirflowおよびLuigiを活用してきました.

• 個人のデータ基盤でAirflowを使った事例*2
• LuigiでWebサービスのバックエンド構築*3

上記以外にもJX通信社の仕事をはじめ結構色々とETLを構築・運用しましたが, ETLフレームワークの選び方として以下の3つが大事なのでは?と気が付きました.

• Workflow（複数のタスク処理）実行に必要なプロセス（コンテナ）の数）
• CPU・メモリの利用量が変動するか
• 開発のしやすさ

構築するETLの要件・規模（と開発者の好みなどなど）を上記の3つの視点で組み合わせるといい感じになります！というのがこの先のお話になります.

Workflow（複数のタスク処理）実行に必要なプロセス（コンテナ）の数

結論から言うと,

Dockerのコンテナ1個で処理が終わるか, それとも複数のコンテナ・プロセスで処理するかで採用するフレームワーク変わるやで！

ということです.

データ基盤のバックエンドのタスクは,

1. 欲しいデータを取ってくる「Extract」タスク
2. 前処理・クレンジング・集計etc...何かしらの変換を行う「Transform」タスク
3. DWH, ストレージなど必要としている所にデータを読み込む「Load」タスク

この3つの組み合わせで構成され*4, 大抵の場合「Extract -> Transform -> Load」の順で「Workflow」バッチを組むことになります.

これらの設計を進めると,

• 一つのDBテーブル, 一つのアプリケーションログを相手にする比較的小さいETL Workflow
• 複数のデータセット, 複雑な集計処理を伴うかつ, 別のWorkflowと依存する大きめのETL Workflow

に別れます. そして大抵の場合,

• 「小さいETL Workflow」は一つのアプリケーションで完結することが多い. 例えば「RDBにselectした結果をS3に保存」みたいな小さなタスクはEmbulkのプロセス一つ立てればそれで終わる.
• 「大きめのETL Workflow」は「AのWorkflowが終わったらBのWorkflowを」的な複雑な順序および障害発生時の冪等性を担保するような大掛かりな仕組みが必要となり, 仕組み的にもWorkflowが担うSLA的にもゴツい仕組みが必要.

となります.

小さいものはDockerコンテナ1個で収まるとかが多いですが, 大きいものはk8sクラスタ一個まるごと使う的な事が多く, ETLフレームワークもそれらによって得意不得意が異なるのでここのポイントは結構大きいんじゃないかなと思っています.

CPU・メモリの利用量が変動するか否か

Workflowが使うComputing Resources, 特にCPUとメモリの利用量が変動するか否かも大切なポイントとなります（機械学習系だとここにGPUも加わることになります）.

これも一言でいうと,

処理に必要なCPU・メモリが一定量ならDocker Containerもしくは関数系のサービスでやる, 変動するならフルマネージドなクラウドサービス使うとかしよう！

です.

「1日一回, マスターデータをS3にダンプする」「アプリケーションログを1時間に一度BigQueryに流す」みたいなタスクはCPU・メモリの利用量が安定することが多いので, コンテナで動かすアプリケーションで十分対応可能です.

が, 「複数のデータセットをかき集めてクラスタリングした後機械学習の予測とかやります」だと,

• データセットをかき集める, クラスタリングするときに多くのメモリが必要
• 機械学習の予測タスクってCPU頼り（もしくはここだけGPU使う）なのでは？
• その他の小さいタスクは分散するなり遅延処理するなりしたらさほどComputing Resourcesいらなさそう

とかあったりします. Resourcesに変動がある場合は,

• Airflowの「ECSOperator*5」「KubernetesPodOperator*6」など, 実行時にリソース指定ができる仕組みを使う
• kubeflowなど, k8s前提の流動的・弾力的にリソースが使える仕組みを使う
• Sparkとかの仕組みに乗れるものはAWS Glue/EMRやGCP Dataprocなどフルマネージドな分散処理サービスに乗っかる

などの工夫で切り抜ける必要があります（かつ, LuigiやEmbulkなどはこの手の仕組みがありません）.

開発のしやすさ（含む環境構築）

開発のしやすさもかなり大事です.

まず, ETLフレームワークはどれも癖があります&人それぞれ好みも別れます.*7

迷ったらやりやすいやつを選ぶのも大事な視点です.

比較表にしてみると...

というわけで, 上記の視点で比較表を作ってみました.

なお, あくまでも個人の感想です.

Framework	実行プロセス数	CPU・メモリ変動	開発しやすさ（shinyorke個人の感想）	備考
Airflow	複数コンテナ必要・Cloud Composerなどを使ってk8sで運用が推奨	k8sクラスタ内で割り当てたり他のサービス使ったりと優秀	DAGはPython書ければ誰でも書ける, 他は怪しい.	オンプレ・セルフホスティングは地獄ですのでオススメしません, Cloud ComposerもしくはどうしてもせるふでやるならhelmのAirflowテンプレを使うのがベスト.*8
Luigi	Docker Container一つで収まる	基本的に起動したコンテナ・マシンのリソースのみ	Python完全に理解した...レベルならかろうじて行けそう	軽量で良い仕組みですが少し癖がある&後述のprefectが良い後継なので今からやるならprefectがオススメ?
prefect	Docker Container一つでもk8sなどでもどっちでも	環境によって柔軟にできる（らしい）	メチャクチャやりやすい, Luigiの代替として優秀	Airflowの代替として使えるっぽいが試した事無いです
kubeflow	k8s	k8s内でいい感じにやれる	Pythonで書きやすそう（まだ書いたこと無い）	機械学習Workflowとしてすごく使えそう. データを移送する程度のETLとしては少々割高かも.

個人の感想が思いっきり入ってるので参考程度にしてもらえるとありがたいですが,

• 比較的SLAが要求されるWorkflowはAirflow
• 小さめのWorkflowはprefectやLuigi
• 機械学習目的でkubeflow

ぐらいに雑に考えると良さそうです.

JX通信社におけるETLの使い分け

JX通信社ではデータ基盤チーム・CTO室で試行錯誤や本番運用しながらのトライアルの結果,

• 全体的な大きめWorkflowはCloud Composer（Airflow）で管理
• 1コンテナで収まるタスクはprefectとLuigiを使う, Luigiは順次prefectに書き換え中
• DBのimport等小さいタスクはEmbulk
• ML Opsが必要なWorkflowはkubeflowの導入を前提に色々とお試し中

という感じで進めています.

全体像

現状の全体像はこちらです.

個別のタスクでLuigi, Prefect, Embulk, 全体管理でAirflow使ってます

アプリケーションログを扱うか, RDBMS/KVSを扱うかで仕組みがちょっと変わっていますが原則として,

• すべてAirflowのDAGから実行
• 個別のタスク（小さいWorkflow）はAWS ECSもしくはCloud ComposerのPodとしてクライアントアプリ（Python製のコードもしくはEmbulk）を実行
• 最後はBigQueryに投入, 中間データはS3/GCSに残す

という運用を行っています.

Airflow（Cloud Composer）

前述のとおり, Cloud Composerにすべてを任せています.

DAGで順番をコントロールしています

アプリケーション（AWS）側のタスクもAirflowのトリガーで実行（すべてECS Fargateのタスクとして実行）できるのでものすごく楽にできます.

GCPのタスクもCloud Composer内のnode pool上でPodを立てて実行しています.

また, DAGについてはビジネスロジックを原則書かない運用としているため, コードベースも比較的スッキリしています.

ちなみに, すべてのAirflowタスクがCloud Composerという訳ではなく, 一部セルフホスティングしているものもありますがこれは近々Cloud Composerに引っ越しする予定で進めています.

Luigi

アプリケーションログなど, ある程度のフィルター・クレンジングが必要（≒方言がある）モノはLuigi/prefect製のアプリケーションをECS Fargateのタスクとして実行し, ログを出力する仕組みとしています.

アプリケーションの方言が入るログは独自のETLでやってます

これは「Dockerのコンテナ1個で処理が終わる」レベルなので, Luigiみたいな小さいFrameworkが良さそうということでLuigiで開発しました.

luigi.readthedocs.io

Luigiは, Dockerコンテナ一つで動かすようなWorkflowや, 小規模な機械学習pipelineに用いることが多く, （前述の事例通り）私もよく使っていたので昨年までは愛用していました（が後述の理由によりprefectに移行中です）.

prefect（Luigiの後釜として）

Luigiは実績があって枯れているETL Frameworkではありますが,

• Workflowの定義・記法がやや独特. Luigiのクラス・インターフェースの定義に従って書かないといけない.
• 「前のタスクが途中か終わってるか」的な管理を時前で実装する必要がある. 具体的にはタスクの開始・終了をログファイルやDBの状態で判断するような書き方になるため, 運用（特に再実行とか）の際にハマりどころとなりやすい.

という欠点があります.

どうしたものか...と思案していたところ, 最近注目を浴びているprefectを使うとこの辺がシュッとなると気がついたので最近はprefectでの開発に切り替えています.

docs.prefect.io

Airflowの開発者が, Airflowの辛い所をいい感じにするぜ！というノリで開発したETL Frameworkで, クラウドサービスも存在します.

感覚的にはAirflow的な使い方・Luigiの替わり両方行けそうな感じで, JX通信社では今の所後者（Luigiでやれそうな軽いWorkflow）で使っています.

prefectは, Luigiと異なり,

• ETL/Workflowに必要な機能がいい感じにまとまっている. 並列実行・GUIなど面倒を見てくれる
• Workflowに必要なタスク・実装をdecoratorで定義できる
• Pythonの一般的なclass/methodの実装ができたら比較的シュッとできる

利点があり活用しています.

このエントリーだけでは説明がしきれないところもあるので, prefectの詳細については近日中に別記事で紹介いたします！*9

その他（Embulk, kubeflowほか）

RDBMSやDynamoDBなどを相手にするものは処理が決まってるためEmbulkを使っています.

また, 最近はML Opsまわりをもっと進めるため試験的にkubeflowも使ったりしています.

結び - 結局どれも癖がありますので長いおつきあいを

というわけでこのエントリーでは「ETLフレームワークの選び方・組み合わせ方」について色々と書きました.

が, これが最適解かと言われるとまだまだな気がしますし, この手の事例って意外と無いんですよね...

ご指摘や改善点などありましたらコメントや意見をいただけると嬉しいです :bow:

というのと, これだけは自信を持って言えるのですが,

ETLフレームワーク, 結局どれも癖がありますので長いおつきあいを前提にやってこうぜ！

どれも癖はありますが長所を活かす使い方をするとしっかりバリュー出ます.

色々と試し, 自学自習して改善しながらいい感じにやってくのがベストかなと思います.

最後までお読みいただきありがとうございました&次はprefect編で会いましょう.

*1:なお, 余談ですがこのネタ本当はPyCon JP 2020のCfPとして提出したモノの一部となります. 悔しいことに不採択になったので供養エントリーという意味合いも含んでおります（真顔）

*2:PyCon JP 2017の発表で, 日々発生する野球の試合データを収集・可視化する基盤のバックエンドとしてAirflowを使いました.

*3:私が当時在籍していたRettyでの事例で, アライアンス関係のバックエンドをLuigiでゼロから作った話です.

*4:Transformあたりは事実上なかったりする場合も無きにしもあらず（例えばExtractがSQLでデータを取ってくるとか）ですが, 最低でもExtractとLoadの2つはある認識でいます.

*5:特定のDocker ImageをAWS ECSのタスクとして実行する仕組みでFargateも使えるためかなり便利です. 後ほど触れますがJX通信社のデータ基盤でも活用しています.

*6:指定したk8sのクラスタ・node pool上のResourcesを使って処理を行う仕組みでこれもDocker imageを元に処理することになります.

*7:PythonのWeb Frameworkを思い出してみてください. Django, Flask, sanic, FastAPIどれも良いところ・癖がそれぞれあって好みが分かれることを. 他の言語も同じでしょう.

*8:いずれもk8s前提の運用となります.

*9:ホントはこの記事のメインコンテンツのつもりでしたが思ったより文量が増えたため別けることに