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

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

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

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

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

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

f:id:nsmr_jx:20200821210659p:plain:w160

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

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

空気感が伝わらない

f:id:nsmr_jx:20200821210319p:plain:w160

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

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

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

ランチ行けない

f:id:nsmr_jx:20200821210455p:plain:w160

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

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

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

そのほか

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

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

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

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

朝会

f:id:nsmr_jx:20200905145210p:plain:w160

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

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

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

常時通話

f:id:nsmr_jx:20200905145758p:plain:w160

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

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

ペアプロ・モブプロ

f:id:nsmr_jx:20200905144529p:plain:w160

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

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

ティータイム

f:id:nsmr_jx:20200905145545p:plain:w160

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

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

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

物理出社

f:id:nsmr_jx:20200905145621p:plain:w160

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

KPT

f:id:nsmr_jx:20200907105305p:plain:w160

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. 動作確認

f:id:TatchNicolas:20200827151837p:plain
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[].namehttp を指定してやる必要がありました。(そういう仕様なのか意図せぬ挙動なのかまでは調べきれてません...)

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を使って反映させています。

f:id:TatchNicolas:20200827091516p:plain
PyCon JP 2020 SNSリアルタイム配信システム 構成図

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

設計のポイント

前提としては、

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

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

やってみて

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

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

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

永続化や認証は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完了したタイミングで再起動するメソッドを呼び出すことでアプリを再起動させられます。

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

f:id:sakebook:20200826004435p:plain

即時(Immediate)

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

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

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

f:id:sakebook:20200826004507p:plain

実装

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

ざっくりいうと、アプデが可能かどうか確認し、可能であれば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のアプリをインストールしていても更新判定は行われません。

f:id:sakebook:20200826004923p:plain

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のフローに入る

f:id:sakebook:20200826004951p:plain

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

f:id:sakebook:20200826005325p:plain

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

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

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

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

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

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

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

f:id:sakebook:20200826005132p:plain

今回のような例の実装であれば、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で扱えます。この2つは似たような思想のライブラリと言えるでしょう。つまりここで言う「便利な Hooks」は「特定のバックエンドに密結合にする代わりに、めちゃくちゃ便利にバックエンドを使えるようになる Hooks」です。この手軽さは、Hooks のない時代には考えられないものでした。

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

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

疎結合にする方法1: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 のメリットがどんどん薄れてしまうような良くない手段である と考えています(あくまで個人的な意見です)。

疎結合にする方法2:クライアントを 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

疎結合にする方法3:Hooks 自体を Injection する

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

「方法2」は、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 そのものではなく、それをラップしたクライアントを注入する方法の方がベターだと思います。しかし方法3の方が Hooks っぽい責務の分割になると思っています

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