データ分析者たちのコードレビュー #とは - 散らかったJupyter notebookを片付けるかどうするか問題を考える

JX通信社シニアエンジニアの@shinyorkeです.

最近はチームの朝会でよく着ているTシャツにツッコミを受けてます.*1

JX通信社では, いい感じにデータを整備・運用しているデータ基盤を駆使して,

• BI（Business Intelligence）文脈でのデータ分析・可視化. ダッシュボード作ったり.
• 機械学習的なアプローチを使ったR&Dと機能開発（分類タスクなど）

といった業務・タスクを社員・インターン問わず行っています.

データ分析でSQLを書いたり, 「新しいアルゴリズム試すやで！」的なノリでPythonのコードをゴリゴリ書く・動かして結果を見て振り返ってまた臨む...って楽しいですよね.

チームの皆さんも, もちろん私もモチベーション高くやってるわけですが！？

あれ, notebookどこ行ったんや...🤔

よくありますよねー（震え）

自分もチームメイトも, 前のめりになって分析なり機械学習なりをやればやるほど, notebookはどこかに溜まっていき, 「そういえば前にやったnotebookどこだったっけ?🤔」ってなります.

これはきっと私（弊社）に限らずあるあるな問題だと思います.

また, 分析業務や機械学習的なR&Dなどをたくさんやればやるほど,

ワイのコード, 大丈夫だろうか（震え）

と心配になります.

このエントリーでは, 散らかったJupyter notebookを片付けるの諦めたもっとカッコよくいい感じにナレッジをシェアしながら分析したい私が,

• JX通信社のデータ分析環境の今とこれから, を紹介しつつ
• 結局, 分析屋さんのコードレビューとnotebookの管理って何のためにするんだったっけ?

というお話をいい感じにまとめて書きたいと思います.

TL;DR

• モブプログラミング的なノリでレビューするとノウハウの共有・お互いを知る意味でも最高なのでオススメ（オンラインでイケる）.
• notebookの管理で神経と労力を使うのもいいけど「諦める」のも一つの手.

おしながき

JX通信社のデータ分析環境と作業スタイル

早速コードレビューの話をする...前に, JX通信社における

• データ分析ってどういう環境でしてるの?
• 現状の問題点

の話をサクッと整理しました.

なお, このエントリーの続きみたいな話です.

tech.jxpress.net

現在の環境

社員・インターンがデータ分析に使っている環境は, 以前のエントリーに触れたとおり, BigQueryを中心に回っています.

現状のデータ分析環境あれこれ（要約）

（一部のデータ*2を除き）大抵のデータはBigQueryのテーブルとして存在するので,

• 単にデータを見たいだけ（≒SQLで事足りる）ならBigQueryのコンソール・Redashを使う
• 機械学習や統計でちょっと凝ったことをする（≒コードを書かないと難しいタスク）ならColabを使う*3
• ダッシュボード・レポート等の最終成果物をDataPortal, Redashで行う

といった感じで活用しています（+他のツール・サービスもよく使います*4）.

ちなみに手段（ツール・サービスなど）の選択は原則として各人（社員のみならずインターンも対象）に任されています（メンターとしても必ずその話をしています*5）.

なお, データの抽出・変換・出力, いわゆるETLについてはAirflow, prefect（一部Luigi）でWorkflowを組み立てて行っています.

ETLの詳細は以前のエントリーをご覧いただけると幸いです（本筋と離れるためこのエントリーでは特に触れません）.

現状の課題とやりたいこと

ビッグデータ・データサイエンスのエコシステムの組み合わせでいい感じに分析したり成果出したりと一見すると順風満帆に見えるこの仕組ですが, 課題とやりたいことがいくつか存在します.

• 現状の課題
  • notebookが散らかる. コード管理やシェアが各人に任されているため, チームの資産としての活用が難しい*6.
  • 分析コード・SQLのレビューが各人任せになっている. プロダクトのコードみたいなMerge Request(Pull Request)をベースとしたチーム作業にはなっていない.*7
  • アドホックなデータ分析・取得の依頼が増えた時の管理. できる人が限られている為ボトルネックになりがち.
• やりたいこと
  • データマートの整備. 現状は「データレイクの生ログをいい感じにBigQueryにしました」的なデータを扱うことが多いためそれなりに難易度が高い*8.
  • ある程度の分析・可視化（select文の結果をピボットしてグラフ描く的な）をデータサイエンス・エンジニアな人以外にも開放. つまり民主化.

「やりたいこと」の話は後日機会あれば紹介ということで一旦さておいて.

データ分析に関わってるメンバー特に若い人やインターン達にとって不安要素になるかもしれない「コードレビュー」「notebookの管理」は無視できない問題です.

コードレビューとnotebook管理をいい感じにする

「コードレビュー」「notebookの管理」という課題に対して, 会社全体としてどうしていくか?...という問いについてはまだ答えが出ていないのですが.

私（@shinyorke）のチーム*9では,

• notebookやSQLをモブプログラミング形式で作ったりレビューをしたりする
• notebook, SQLはあくまで「中間成果物」と捉え, 敢えて管理を放棄する

という方策でやっています.

モブプログラミングの積極活用

モブプログラミングいいですよね

「チームで一つになってISSUEと向き合う」でお馴染みのモブプログラミングですが, これをデータ分析チームとして積極活用しています.

実際は対面じゃなくて, Zoomで一つの画面をシェアしながらやってます（みんなリモートしてる*10ので）

モブプログラミングのお題は「インターン生が書いたnotebook/SQLのレビュー」「メンターのshinyorkeがまとめたレポートのレビュー」などその日によって異なりますが大切なのは,

インターンや若い人が時折レビュアーに回る

ようなローテーションを回すようにしています.

私の場合, プログラミングそのものやシステム的・ビジネス的なスキル・知見は若い人よりありますが, 数学・統計・機械学習的なアプローチは現役で学んでいる学生さんの方が上だったりするケースも多々あるので「私もたまには見てもらう側に回る」ようにしています.

若い人やインターンの場合は「プログラミング・SQLの定石」「きれいなコードの書き方」「Pythonの便利ライブラリ」などが勉強になるケースが多いみたいです. つい先日は「コード・SQLをフォーマットして書くのが何故大事か？」という話題で30分くらい時間が溶けました*11.

この方式はそれなりに労力を使いますが, 成果物の最終チェックが進むだけでなく「関わった人の知見・スキルのシェア・勉強がはかどる」「個々人のノウハウがチームに還元される」のと何よりも楽しいので今後も継続していく感じになると思います.

notebookはあくまで「中間成果物」

そして 「散らかったnotebook」問題ですがこれについては,

すっぱり諦める

というお気持ちでやっています.

というのも,

• notebookはあくまでもアドホックな「らくがき帳」「試行錯誤するためのサンドボックス」である*12
• 「よっしゃこれはイケるぞ！」ってなった段階でちゃんとしたプロダクトのコード（テストコードを含める）に落とし込むべき
• （notebookでdiffをとるソリューションはいくつかある*13とはいえ）神経質にdiffを気にするぐらいなら最初から管理そのものを放棄したほうが良い.

これらの定義・信念を考えると「わざわざ管理する方にもっていくのはまだ先でいいかな...」ってなります.

もちろん, 安易に消されたりやってくれた方が退職したりするとそれはそれで困ってしまうので,

• 可能な限り社内限定でシェアする. 少なくともメンターの手元には残す.
• 「もしかするとプロダクトコードになるかも」なスニペットはgitに残す

ぐらいはしています.

結び - レビューとメンタリングで大切なこと

というわけで,

分析者のコードレビューには「モブプログラミング」を, notebookの管理は「諦め」が肝心

という話を紹介させてもらいました.

もちろんこの両方が絶対的な答えじゃないです, もっといい方法・考え方があったらぜひフィードバックをいただけると幸いです.

このアプローチ・考え方に至るまで色々と試行錯誤をしたのですが確かなのは,

• レビュアーはプロダクト・サービスの事に目を向けつつ, レビュイーの良い学び・気付きになるようなレビューに心がける
• メンターはメンティーにとって「超える壁」になるようなタスクを提供し続け, メンティーの成長を支えること

という想い・思考が元になっています.

なお現在JX通信社では,

• データサイエンティスト　※本日（11/18）より募集開始しました
• フロントエンドエンジニア

のインターンを募集しています！

※学生さん限定です🙇‍♂️

データサイエンスのコードレビューはこのエントリーで触れたとおりですが, エンジニア側もメンターやチームによっていいかんじにケアしたりしてるので興味ある方はぜひカジュアル面談にお越しください（フルリモートでもOKです！）.

www.wantedly.com

www.wantedly.com

最後までお読みいただきありがとうございました.

*1:アカウント名（shinyorke）をUKの某バンドのボーカルから拝借する程度にUK Rock🎸好きな影響でいつもバンドTシャツ着てます（どうでもいい注釈）.

*2:本文脈とは関係ないですが, 一部のデータはAWS AthenaだったりS3/GCSのストレージ上の生データです.

*3:後述の通り, Colabはマストって訳ではないので個々のPCで環境作ってやるケースもあります, 私が実はその派閥でして

*4:私の観測範囲ではGCPのAI Platformを使ったり, まだお試し中ですがstreamlitを使うこともあります.

*5:弊社はデータサイエンスのみならず, 通常の開発でもPythonを使うことが多く分析業務のデファクトスタンダードもPythonですが中にはRでタスクをこなしてバリューを出しているメンバーもいます.

*6:よくやる処理とか定石が車輪の再発明になってる的な意味での「資産活用が難しい」という話です

*7:余談ですがFASTALERTやNewsDigestといったプロダクトはこの辺しっかりやってます.

*8:正規表現頑張ったりJSONをParseしたりとかそういうレベルの難易度の高さ. もちろん仕様の話もあります.

*9:言い方を変えるとこのアプローチは会社オフィシャルでテンプレート化しているわけではないです&したいなっていう欲はあります.

*10:これはこれで苦労もありますがシフトや働く場所の成約が物理出社の時と比べて334倍以上の自由度があるので良いことのほうがおおい気がします. 首都圏以外の学生さんもインターンとして定期的に入れるとか.

*11:どのツールを使うか, 他社さんでどうやってやっていたか?という話題でもちきりになりました. お互いを知る意味でも有意義な30分でした

*12:notebookをバッチなどの定期実行処理にそのまま使うやり方もあるらしいですが個人的にはこのアプローチはとったことないです.

*13:nbdimeとかが代表的な手段なんですかね?他にもありそう.

Jamstack とサーバーレスで提供する「大阪都構想」特設サイトの舞台裏

開発担当役員(CDO)の小笠原(@yamitzky)です。

11月1日に予定されている「大阪都構想」の住民投票*1についての特設サイトを、先日、ABCテレビと共同リリースしました。JX独自開発のオートコール電話情勢調査システムを活用し、週一ペースでの情勢調査を発表するなど、今までにない取り組みを行っています。

www.asahi.co.jp

より詳細なデータは、ニュース速報アプリ「NewsDigest」でも配信しています。

なんだか宣伝っぽい導入になってしまいましたが、今回は NewsDigest の「大阪都構想」特設ページの技術的な舞台裏をご紹介します。

インフラ全体像

まず、特設サイトのインフラ概略図は次のようになってます。

インフラ全体

サイト全体としては、Next.js という React のフレームワークを使っています。特徴的なのは、

• Next.js を Lambda@Edge を使ってデプロイ
• 自作 Headless CMS と Firebase を活用した Jamstack 風なアーキテクチャ
• Fargate を使ったワードクラウドの自動更新

など、最新技術をうまく組み合わせながら構築しています。

Next.js のデプロイ

サイトのデプロイには、 serverless-next.js を使っています。

github.com

serverless-next.js は Serverless Framework のプラグインで、非常に簡単に AWS のサーバーレスな環境へのデプロイが行えるものです。

serverless-next.js でデプロイをすると、次のような構成になります。

• CloudFront(CDN) が前段に立つため、キャッシュ時間なども調整できる
• API や SSR *2 は Lambda@Edge でハンドリングされる
• SSG *3も Lambda@Edge でハンドリングされるが、事前に S3 に保存されている
• 静的ファイルは S3 から配信

かなりアクティブに開発されており、比較的最新の Next.js の仕様*4にも対応しているのですが、 Incremental Staic Regeneration (自動での SSG の再更新)には対応していません。GitHub の Issue でも議論はされていますが、そんなに CloudFront × サーバーレスな構成と相性が良くないようにも感じます*5

Headless CMS によるサイト更新

今回、ABC テレビのサイト側での配信が静的なものだった*6ため、 SSG を前提とした構成にしました。一方で、週一で更新する情勢調査の解説コメントや、ユーザーからの質問受付など、動的な要素も含んでいました。これらのコンテンツ更新には CMS が欠かせないですし、同時に、コンテンツ更新のたびに HTML/JS を更新したくない、という課題がありました。

そのため、Headless CMS を使い、Jamstack な感じの構成 にしています。

Jamstack構成

Headless CMS とは、WordPress のようなコンテンツ管理と配信がセットになった CMS ではなく、コンテンツ管理だけができるような CMS を指しています。今回の場合、配信部分は Next.js が担っていることになります。Headless CMS は、 配信するページにコンテンツ管理機能が紛れ込まないのでセキュアである、というメリットもあります。

今回、Headless CMS には、小笠原が個人開発しているサーバーレスな Headless CMS を導入 しました。この CMS *7 は、データベースに Firebase を使っているので、リアルタイム＆安価＆柔軟に連携できます。

serverless-headless-cms.vercel.app

ワードクラウドの自動更新

特設サイトでは、週１の情勢調査だけではなく、ワードクラウドを毎日更新しています。

特設サイト内ワードクラウド(左)

こちらは Python 製のプログラムを Docker 化し、Fargate を CloudWatch Events 経由で動かして S3 に保存しています。また、インフラ構成管理には Terraform を使っています。

Flourish によるデータの可視化

情勢調査の結果を大阪市民の方々にわかりやすくお伝えするため、 Flourish でデータの可視化を行いました。Flourish は Google Sheets をデータソースとしてグラフを自動更新できるなど便利です。

flourish.studio

ワードクラウドとデータ可視化に関しては、データ×ジャーナリズムを担当している阪神ファンの衛藤さん主導で作っています。

まとめ

振り返ってみると、 特設サイトは開発開始から１週間半程度でリリースすることができました。OSS を利用*8して、サーバーレスを活用しながら、JX通信社のバリューを体現できたかなと思います。また、今回もインターン生に多大なご協力をいただいております。

www.wantedly.com

www.wantedly.com

大阪市民の方、ぜひ特設サイトをご覧になって、11月1日の住民投票にお役立てください。

www.asahi.co.jp

*1:いわゆる「大阪都構想」とは、大阪市を廃止し4つの特別区に再編する構想です

*2:サーバーサイドレンダリング。リクエスト時に動的な HTML を生成する

*3:静的サイト生成。リクエスト時に動的な HTML を生成するのではなく、事前に HTML を生成しておくもの。ただし、動的にはならないので、ISR という仕組みが Next.js では提供されている

*4:redirect などは、Next.js 9.5 の仕様です

*5:Vercel のインフラがどうなっているのか気になります

*6:HTML と JavaScript を提供し、静的ページとして配信しています

*7:まだ名前がないので名前案ください

*8:少額ではありますが、serverless-next.js に寄付しました

GitHub Actionsで実現する、APIキー不要でGitOps-likeなインフラCI/CD

※ 今はGitHub ActionsでOIDCが使えるので、本記事の内容は少し古いです。*1 現場のルール等で「インフラを触るワークロードはオンプレでしか動かしてはならない」みたいなルールがある場合には多少参考になるかと思います。

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

JX通信社では「インフラチーム」のようなものは存在せず、開発したチームが運用までやるFull-cycleなスタイルを取っています。AWS・GCPリソースの管理も特定のメンバーが担当するのではなく、必要とする人が必要な時に作成・修正等を行います。すると、terraformなどIaCのツールを利用する場合に「今リポジトリにあるコードは実態を正しく反映しているのか」「誰かが矛盾する変更を加えていないか」という問題が発生します。

CIツール上でterraformを実行することで、問題の一部は回避できるかもしれませんが、CIにSaaSを利用している場合、クラウド上のリソースを操作する強い権限を持ったAPIキーを外部に預けることになってしまいます。

GCPのCloudBuildを使った解決策 *2、AWSのCodeBuildを使った例*3はそれぞれあるのですが、せっかくterraformをつかうならできるだけ同じ仕組みに載せたいところです。

そこで、「CIの仕組みとしてはSaaS(今回はGitHub Actions)を利用しつつも、実行場所はクラウド内にとどめることでGitOpsの考え方を一部取り入れたterraform運用のしくみ」を作ってみました。

TL;DR;

GCPの場合

AWSの場合

• Self-hosted runnerを使えば、GitHubにクラウドの認証情報を渡さなくともGitHub Actionsでterraformを実行できる
• Pull Request作成でplan、masterへのマージでapplyして、また定期的にmaster最新コミットでplanして乖離をチェック することでGitOps-likeに運用できる *4
• 発想としては単純で「GCP Service AccountまたはAWS IAM Roleを使ってCIのRunnerにterraform実行に必要な権限を与える」なので、GitLab.comでも同じようにできるはず *5

やってみる

GKE(GCP)・EKS(AWS)にて、実際にやってみます。 AWS・GCPの権限を引き受けることができれば良いので、k8sではなくEC2・GCEでも実現可能なのですが、できるだけクラウドベンダごとの違いがでないようにk8s上のPodとして動かしました。

• GKE・EKSクラスタは構築済みの前提
• RunnerにGCP・AWSの強い権限を持ったAPIキーを渡さない
  • GKE・EKSの機能を使ってAPIキー自体を発行しないで権限をRunnerに付与する
• 定期的にplanを実行して、masterの最新commitと食い違いを検知する

1. Runnerをつくる

今回は下記の記事の中で紹介されている gh-runners/gke at master · bharathkkb/gh-runners · GitHub を参考にしました

github.blog

気を付けるポイントとしては、

• あとで hachicorp/setup-terraform を使うために、unzipをDockerイメージにインストールする必要がある
• 権限付与の動作確認用にgcloudやaws cliなども追加しておくと便利かもしれません

Podが削除されるときにGitHub上のからRunnerを除名する処理をシェルスクリプトで書いて、preStop のlifecycleで実行するようにしても良いでしょう。

apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: github-runner
  name: github-runner
  labels:
    app: github-runner
spec:
  replicas: 1
  selector:
    matchLabels:
      app: github-runner
  template:
    metadata:
      labels:
        app: github-runner
    spec:
      serviceAccount: github-runner
      containers:
      - name: runner
        image: gcr.io/your-project-name/github-runner
        env:
        - name: REPO_OWNER
          value: "your_github_name"
        - name: REPO_NAME
          value: "your_repo_name"
        - name: GITHUB_TOKEN
          valueFrom:
            secretKeyRef:
              name: name-of-secret
              key: GITHUB_TOKEN
        lifecycle:
          preStop:
            exec:
              command: ["sh", "-c", "'./remove.sh'"]

ちなみにPodが削除されたまま放っておいても、GitHub側で30日経てば自動で取り除いてくれるようです。しかしお片付けはきちんとしたほうが気持ちが良いでしょう。

A self-hosted runner is automatically removed from GitHub if it has not connected to GitHub Actions for more than 30 days.

About self-hosted runners - GitHub Docs

また、今回は使いませんでしたがRunnerの登録/削除などを良い感じに管理してくれる素敵なControllerもありました。

github.com

2. Actionを定義する

HashiCorpのチュートリアルにGitHub Actionsを使った自動化の例 があるので、そちらを参考にすれば環境やチームのリポジトリ構成に合わせてすんなり書けると思います。

learn.hashicorp.com

また、追加で定期的にplanを実行して、tfファイルと実態の乖離を検知するworkflowを定義してみます。

検知の方法は色々あるとおもいますが、planをファイルに書き出して、jsonとしてterraform showしたものをjqでパースして判断してみます。今回はついでに例として、乖離があったらIssueを作成してみます。

下記の例の通りやると乖離が解決されない限り重複するIssueを作成しつづけてしまうので、cronの頻度を落としたり通知先をGitHub IssueではなくSlackにする、復帰のためのapplyまで実行してしまうなど、チームの方針に合わせて調整してみてください。

name: check-drift

on:
  push:
  schedule:
    - cron:  '*/10 * * * *'

jobs:
  check-drift:
    runs-on:
      - self-hosted
    steps:
      - uses: actions/checkout@v2

      - uses: hashicorp/setup-terraform@v1
        with:
          terraform_version: 0.13.2

      - name: Terraform Init
        id: init
        run: terraform init

      - name: Terraform Plan
        id: plan
        run: terraform plan -out tfplan

      - name: Print the result of terraform plan as json
        id: print_json
        run:  terraform show -json tfplan

      - name: Check configuration drift
        id: check
        env:
          PLAN_JSON: ${{ steps.print_json.outputs.stdout }}
        run: |
          DIFF=$(echo "$PLAN_JSON"| jq -c '.resource_changes[] | select(.change.actions!=["no-op"])')
          if [ -z "$DIFF" ]; then
            echo 'No configuration drift detected'
            echo '::set-output name=STATUS::synced'
          else
            echo 'Configuration drift detected!'
            echo '::set-output name=STATUS::drifted'
            terraform show tfplan -no-color
          fi

      - uses: actions/github-script@0.9.0
        id: show_plan
        if: steps.check.outputs.STATUS == 'drifted'
        env:
          PLAN: "terraform\n${{ steps.plan.outputs.stdout }}"
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            const output = `\`\`\`${process.env.PLAN}\`\`\``;

            github.issues.create({
              owner: context.repo.owner,
              repo: context.repo.repo,
              title: "Configuration drift detected",
              body: output
            });

3. Runnerに権限を渡す

GCPのservice accountまたはAWSのIAM roleと、k8s service account(KSA)の紐付けをするterraformのサンプルコードを示しておきます。どちらも github-runner というk8s namespaceにrunnerをデプロイすることを前提としています。 *6

GCPの場合

GKE上のPodにGCPリソースの操作権限を渡すには、Workload Identityを使います。

resource "google_service_account" "github_runner" {
  account_id   = "github-runner"
  display_name = "github-runner"
}

resource "google_project_iam_member" "github_runner_owner" {
  role   = "roles/owner"
  member = "serviceAccount:${google_service_account.github_runner.email}"
}

resource "google_service_account_iam_member" "github_runner_wi" {
  service_account_id = google_service_account.github_runner.name
  role               = "roles/iam.workloadIdentityUser"
  member             = "serviceAccount:${var.project_id}.svc.id.goog[github-runner/github-runner]"
}

紐付けるKSA

apiVersion: v1
kind: ServiceAccount
metadata:
  name: github-runner
  namespace: github-runner
  labels:
    app: github-runner
  annotations:
    iam.gke.io/gcp-service-account: github-runner@your-project-id.iam.gserviceaccount.com

AWSの場合

EKS上のPodにAWSリソースの操作権限を渡すには、こちらのドキュメントを参考にします。

resource "aws_iam_role" "github_runner" {
  name               = "GitHubRunnerRole"
  assume_role_policy = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "${aws_iam_openid_connect_provider.this.arn}"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "${replace(aws_iam_openid_connect_provider.this.url, "https://", "")}:sub": "system:serviceaccount:github-runner:github-runner"
        }
      }
    }
  ]
}
EOF
}

resource "aws_iam_role_policy_attachment" "github_runner" {
  role       = aws_iam_role.github_runner.name
  policy_arn = "arn:aws:iam::aws:policy/AdministratorAccess"

}

紐付けるKSA

apiVersion: v1
kind: ServiceAccount
metadata:
  name: github-runner
  namespace: github-runner
  labels:
    app: github-runner
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/GitHubRunnerRole

動かしてみる

実際にPull Requestを作成してみると、下記のようなコメントが自動でつきます。 show plan のところをクリックすれば terraform plan した内容が確認できます。 確認できたらマージすると、applyが実行されます。

自動でplanの結果がコメントされる

また、定期的にplanして定義と実態の乖離を検知すると、Issueが作成されます。

自動で作成されたIsuue

まとめ

得られたメリット

• GCP・AWSの強い権限をもったAPIキーをGitHubに預けなくてよくなった
• AWSでもGCPでも、仕組みの作り方がほぼ共通で利用・メンテナンスがしやすい
  • クラウドベンダごとの違いはterraformとk8sで吸収
• terraformを運用者の手元で実行する必要がなくなった
  • 「これって反映済み?どれが実態?」「planが食い違ってしまった、今誰か作業してる?」が発生しなくなる
  • tfenvに頼らなくてもterraformのバージョンを指定して実行できる
• terraformの定義と実態の乖離を検知できるようになった

注意点・残った課題

• GitHubのself-hosted runnerはリポジトリ単位か組織単位でしか設定できない
  • 組織でterraform用runnerを共有すると、組織以下のすべてのリポジトリがCIでAWS・GCPの強い権限を利用できてしまう
  • GitLabにはgroup単位のrunnerを設定できるようですが、GitHubにはそのあたりを細かく設定できなさそうなのでもうひと工夫する必要がありそう
• masterへpushできる人は(アプリケーションでもそうですが)しっかり管理する必要がある
  • masterへpushできる人は(与えた権限の範囲で)Runnerを通じて何でも出来てしまうため
  • 同じ理由でrunnerを動かしているk8sクラスタ上でのPodへの権限も、きちんと管理する必要がある
• HashiCorpのチュートリアルにあったworkflow定義では、Pull Request作成時にplanした分はファイルへ書き出さず、マージ時に改めてapplyしているので、Pull Requestコメントに書き出したplanと実際に行われるapplyの内容が異なる可能性がある
  • planした結果を何処かへ保存して、その内容を参照するようにworkflowを改善できるかも

チームの体制やポリシーによって、持たせる権限やRunnerの運用方法には工夫が必要ですが、「credentialを外に出さない」「GitリポジトリをSingle Source of Truthにする」「乖離を検知する」というGitOpsの特徴を持ったterraform運用が実現できました。少しでも参考になれば幸いです。

*1:https://github.blog/changelog/2021-10-27-github-actions-secure-cloud-deployments-with-openid-connect/

*2:https://cloud.google.com/solutions/managing-infrastructure-as-code

*3:https://medium.com/mixi-developers/terraform-on-aws-codebuild-44dda951fead

*4:GitOpsの定義は https://www.weave.works/technologies/gitops/ や https://www.gitlab.jp/blog/2020/09/03/is-gitops-the-next-big-thing-in-automation/ など揺らぎがあるので、今回はその一部である「権限を外に出さない」「GitリポジトリをSingle Source of Truthとする」を取り入れつつもsyncはCI上で行っていることからGitOps-"like"としました

*5:調べてみると、事例がありました 絶対に止められない超重要サービスをGitOpsで安全に開発できるようにしている話

*6:本記事ではroles/ownerやAdministratorAccessといった強い権限を渡していますが、実際にはチームの方針にあわせて調整してください。

リモート下でチームのコミュニケーションを円滑にするための試み

こんにちは、サーバーサイドエンジニアの @kimihiro_n です。

新型コロナの影響で、オフィスに出社して働くというスタイルに大きな変化が生じてきています。 弊社でも原則リモートでの勤務が推奨となっており、従来通りのコミュニケーションを続けることが困難になってます。 今回はコミュニケーションを活性化するために、チームでどのような工夫をしているかを紹介したいと思います。

リモートワークだとなにができないか

最初にリモートワークへ移行して感じた課題を挙げてみます。

気軽な話しかけができない

一番違いを感じるのはこの点でした。 仕様の相談だったり、困ったときにちょっと質問するみたいなことは、物理でオフィスに集まっているときは気軽に出来ていました。相談しやすいようにチームごとに座席が近くなるよう席替えしたりして、できるだけコミュニケーションの障壁となるものを廃していました。

しかし、リモートワークでお互いが別々の場所にいるとなると、話しかけるという行動が難しくなります。ボイスチャットをするために話し相手と通話部屋を都度用意し、お互い通話可能なタイミングを調整するというのは結構コストのかかる行為です。 忙しくなさそうなタイミングを見計らって隣の人に声をかけるのと比べるとどうしてもためらいがちになります。

空気感が伝わらない

音声でのコミュニケーションのハードルが上がった結果、Slack などの文字ベースでのコミュニケーションが主流になってきます。文字として記録が残るのでメリットもあるのですが、話し手の意図が伝わりづらいというデメリットもあります。 対面レビューと比べて指摘の語気が強くとられてしまったり、やってもらったことに対しての感謝が伝えづらかったりします。

また 音声 VS 文字 だけでなく、実際の会話 VS 通話越し であっても空気感の伝わりづらさというのは感じています。 物理的に空間を共有して会話するというのはやはり強いですね。 みんなでOKR決めようとかブレストしようみたいな場合、やはりビデオ通話より会議室に集まってやった方が楽しいです。

顔を見ないとメンバーの調子が分からないという面もありますね。 出社していた頃は多少冗長でも朝会で集まって各自タスク共有をしてたりしました。

ランチ行けない

チームの人を誘ってランチ行くことが多かったのですが、リモートだとこれが出来なくなりました。 業務に関係ないゲームの話とかをするのは昼休みの時間がうってつけだったのですが、リモート化が進むにつれこういった話がしにくくなりました。

シャッフルランチというランダムなメンバーでご飯いくという制度もあったのですが、こちらもコロナの影響で実施できていない状況です。

あと単純に神保町のおいしいランチが食べられないのは期待損失が大きいです。

そのほか

• 同時に複数人が話すと聞き取れない
• 通話環境に左右されやすい
• MTG がスムーズに開始できない
• 打ち上げができない
• 業務後ゲーム(ボードゲーム、スマブラ)ができない

などなどリモートならではの問題が生じてきています。

チームで取り組んでること

上記の問題すべてを解決することは出来ないですが、少しでもコミュニケーションを円滑にするためチームで取り組んでることを紹介していきます。

朝会

出社時にやっていた朝会はリモートでも毎日継続してやるようにしました。 最初は音声のみでやっていたのですが、新しいメンバーが入ってきて「顔見ながらやりたい」という意見があったため、朝会はカメラありで実施するようにしています。やはりメンバーの顔色が分かった方が安心感がありますね。

ツールとしては Zoom をつかってビデオ通話しています。Zoom の場合バーチャル背景の機能が組み込まれているため、周囲の状況を気にせずビデオ通話ができます。ビデオ通話するのに部屋を片付けたり洗濯物をどけたりする必要がなくて便利です。

朝会の内容としては当日やるタスクの確認と、相談・周知したいことの共有をしています。

常時通話

気軽に話しかけるのが難しいことの対策として、常時通話状態にしておくというのをやってみました。 都度音声通話に来てもらうのではなくて、話せばチームにすぐ声をかけられる仕組みですね。 ツールとしては Discord というツールを使ってます。

Zoom とちがって気軽に音声通話の部屋を移動できるので、相談したいからこっちの部屋で、とか集中モード( or 休憩中)だから話しかけないでみたいなことがサッとできます。画面共有もできるので後述するペアプロとかも Discord をつかってやっています。 通話のハードルが下がったことで気軽な相談がしやすくなったように思います。1対1のつもりで話す内容でもグループ通話で聞いてる人が増えることで思わぬ助け舟が降ってくることもあります。 ただ他のチームから何をやっているかが見えづらいという意見ももらったので、文字に残すべきもの(仕様や決定事項)はちゃんと文字に残こすよう注意すべきだなと思いました。

ペアプロ・モブプロ

ちょうど1年前くらいからチームでペアプロ、モブプロを導入し始めました。 PCを操作してコードを書く人(ドライバー)と、画面をみて指示を出す人(ナビゲーター)に分かれて一緒にコーディングを進めていく手法です。 個別に実装を行ってあとからレビューする形式と比べて出戻りが少なく、メンバーの知見を共有しつつ開発を進められるので大きな機能を実装するときによく活用しています。

出社してモブプロするときは、1台のモニタ使ってみんなで見ながらナビゲートする形で進めていました。 今にして思うとなかなか密な作業環境ですね。 リモートになってからは、Discord の画面共有機能を主につかってモブプロを実施しています。メンバーが Discord で待機していることもあり、モブプロで進めようとなったときはスムーズに開始することができます。 ただやはりオフラインでやっていた頃と比べると、ワイワイと実装を進めている感覚が乏しくなったように思います。3人以上のモブプロだと、モニタ越しにドライバーが実装していくのを見守るだけということになりやすく、複数人が参加するシナジーが得られにくいです。そのため最近はペアで作業することが多くなってます。

ティータイム

最近導入してよかったのがこのティータイム制度です。 リモート下で｢雑談が少ない｣という振り返りから、意図的に雑談する時間を業務内に用意することにしてみました。

毎日16:00から15分間、Discord に集まって雑談するというだけなのですが、これが結構チームの健全性に貢献しているように思います。ランチや飲み会といった業務外の話ができる場がなくなってしまったので、こういったブレイクタイムを意図的にもたせることは大事だなと感じました。特にインターンで来てくれている方ともお話できるのが大きいですね。やってもらっているタスクによってはメンターとメンティの1対1のやりとりで完結してしまうことがあるのですが、こういった雑談タイムに参加してもらうことで、お互いを知る機会を作れています。

ちなみに最初は｢おやつタイム｣という名称だったのですが、16時に間食すると夕飯に支障がでるという理由からティータイムへと変更になりました。

物理出社

リモートが続いてしんどくなってきたときの最終手段です。 リモート推奨下でもオフィスは空いているので、一人での作業が堪えてきたら出社することもできます。 自分のチームでもだいたい週0.5〜1くらいの頻度でバラバラと出社している印象があります。 出社するとチーム外の人とも会話できるのでいい気分転換になります。 やはり人と実際に話せる場というのは大切なのかもしれませんね。

KPT

KPT という振り返りのミーティングを毎週実施しています。 Keep(継続すべきよかったこと)とProblem(課題に感じていること)を共有して、Try(改善策)を続けていくやりかたですが、こちらもリモート前から継続してやっています。 形式としてはおのおの事前に GoogleDoc へKとPを書いておき、MTGの際に「前回のTはどうだったか」「K、Pの共有」「今回のTの決定」を話しています。

「朝会でカメラオンにしよう」「ティータイムつくろう」みたいな試みはこのKPTの中で生まれました。 継続的な振り返りを通して試行錯誤を続けていたことで、フルリモートへの移行のような大きな変化でも柔軟に適応できたように思います。

おわりに

以上がチームでやっているリモートのコミュニケーション施策でした。 これからもより良いリモート開発体制を求めて試行錯誤していきたいと思ってます。

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