マイクロサービスをやっていく上で参考にしたい記事
ブログ納めとしてマイクロサービスをやっていく上で参考にした(い)記事をざっくりまとめました。
現状、がっつりマイクロサービスをやっているわけではないけれど、考え方を取り入れたりはしているし、来年の今頃はどこかでがっつりやっていったりもするかもしれない。
記事一覧
James Lewis/Martin Fowlerの"Microservices"日本語訳
THE マイクロサービスとは、的な記事。ここから全てが始まった...(本当か?)
リンク: https://kimitok.hateblo.jp/entry/2014/11/09/211820
"Microservices"を読んだ
上述の"Microservices"を読んだ後に読むと整理されそうな記事。
リンク: https://deeeet.com/writing/2014/09/10/microservices/
マイクロサービス運用の所感 #m3dev
エムスリーさんのマイクロサービス所感。
リンク: https://www.slideshare.net/seratch/microservices-ops
Microservices Architect in DMM Platform
マイクロサービスアーキテクトの話、アーキテクチャ全体の設計から組織設計など網羅的に役立ちそうなことが書かれている記事。
リンク: https://inside.dmm.com/entry/2021/12/05/microservices-architect-in-dmm-platform
マイクロサービスにひそむ複雑さに立ち向かう
より現場の生々しいマイクロサービスを想像できる記事。
リンク: https://qiita.com/behiron/items/017b12ee7ffa6dfeb254
マイクロサービス分割点の見つけ方
経験に基づいてどうやってマイクロサービスの分割点を見つけるかが書かれていて助かる記事。
リンク: https://lab.mo-t.com/blog/extracting-microservices
絵で見てわかるマイクロサービスの仕組み
これは記事じゃないけど、図が多くて良本の予感がしたのでついでに載せる。
まとめ
我々の間にマイクロサービスなどという都合のよい言い訳は存在せん。 あるとすればスタンドプレーから生じるマイクロサービスだけだ
経験学習とYWTをベースに、持続可能な個人の振り返り手法について考えてみた
チーム開発を行う際、スクラムのような手法に準拠し、レトロスペクティブでKPTなどで振り返りを行うことが多いと思います。良かったこと、良くなかったことを振り返って、TRYするアクションを決め、次のスプリントに活かし、また評価するサイクルを回す感じでしょうか。
これを個人でも継続的にやっていきたいと考えているのですが、闇雲に振り返りをしてもあまり効果を感じられないし、KPTも個人でやるとなるとあまりしっくり来ません。わざわざ時間をとって自分のPROBLEMを列挙するのは辛いです。
そこで今回、経験を学びに変え、次に活かすためのフレームワークである「経験学習サイクル」の考え方や振り返り手法の一つである「YWT」を取り入れて、持続可能な個人の振り返り手法について考えてみました。
経験学習について
経験学習の概要を学ぶ上で良さそうだった「職場が生きる 人が育つ 「経験学習」入門」という本をベースに簡単に内容をまとめておく。
経験学習サイクル
経験学習サイクルは以下の4ステップを回す。
- 具体的経験をする
- その内容を「内省(振り返り)」する
- そこから教訓を引き出す
- その教訓を「新しい状況に適用する」
ただし、このサイクルを単純に回すだけでは不十分で、「よく考えられた実践」の中でサイクルを回す必要がある。
よく考えられた実践とは以下。
- 課題が適度に難しく、明確であること
- 難しいけど懸命に手を伸ばせば届きそうな目標を持つ
- 実行した結果についてフィードバックがあること
- 実施した結果、どこが良くてどこが悪かったかについての情報を得ることができる
- 誤りを修正する機会があること
- それを次の機会に活かすことができるような練習や仕事のやり方をする
経験から学ぶための三つの力
経験から学ぶためのベースとなる三つの力が以下。
- ストレッチ
- 高い目標に向かって挑戦する姿勢
- リフレクション
- なにかアクションを起こしている最中やアクション後に、何が良くて何が悪かったかについて振り返ること
- エンジョイメント
- やりがいや意義を見出して仕事を楽しむこと
またそれぞれの方略は以下であると述べられている。
ストレッチの方略
- 挑戦するための土台を作る
- 周囲の信頼を得てストレッチ経験を呼び込む
- できることをテコにして挑戦を広げる
リフレクションの方略
- 行為の中で内省する
- 他者からフィードバックを求める
- 批判にオープンになり未来につなげる
エンジョイメントの方略
- 集中し、面白さの兆候を見逃さない
- 仕事の背景を考え、意味を見出す
- 達観して、後から来る喜びを待つ
その他、自分や他人への思いについてや啓発者とのつながりの大切さについても述べられていたが、ここでは割愛する。
また本題とは外れるのだが、紹介した書籍でOJTに関して言及している章があり、これは後輩や部下を持つ全ての人にとってとても参考になると思うのでぜひ読んでみてほしい。
YWTについて
YWTは、振り返りのために「日本能率協会コンサルティング」が提唱し日本で開発されたフレームワークです。Y(やったこと)、W(わかったこと)、T(つぎにやること)の日本語の頭文字をとって名付けられました。経験したことを思い出してから次の段階に進むので、問題点だけでなく良かった点も認識できる手法です
YWTの概要についてはこちらの記事を参考にさせてもらった。
経験学習の本からも感じられたが、成功したこともしっかり振り返ってそのエッセンスを言語化し、再現性を持たせられるようにするのが重要だと思う。
そのため個人的にはKPTよりも、「Y -> W」の過程で自分が具体的に経験したことから教訓やエッセンスを言語化し、次に活かせそうな雰囲気のあるYWTはしっくり来る。これは経験学習サイクルのプロセスとも合致する。
というか自分が無知なだけで、経験学習サイクルを回す目的でYWTが誕生した説あるな…
YWTはシンプルなのでシュッとできそうな予感はあるが、こちらの記事で言及されていた点に注意しなければならないと思った。
Y (やったこと)を挙げる際のポイント
- 客観的に事実を記載していく
- 自分の主観や感想は切り離す
- 良いことだけでなく、悪いことも記載する
W (わかったこと)を挙げる際のポイント
- やったことを通じて感じたこと、考えたことを書いていく
- 「わかったこと」という言葉で勘違いしがちだが「考えたこと」を挙げる
- 「xxという技術で開発をした」というYと、「xxという技術についてわかった」というWになるような浅い振り返りでは意味がない
- その開発という仕事を通じて、自分は何を考えたのか、どのように次の行動が変わるのか、を考えるべき
- 「どうしてそう考えたのか?」「経験を通じた変化は何か?」「他の人に伝えるには?」「今回の得られた学びは何か?」といった問いを立てることで、抽象化と言語化を促す
T (つぎにやること)を挙げる際のポイント
- 「次にやること」を考える際に重要なのは論理性
- せっかくの実績と考察をYとWとして出したにも関わらず、まったく関係のないことをTとして挙げてもうまく行かない
振り返りのやり方
経験学習サイクルとYWTの考え方、コツをざっくり学んだ上で「俺が考える最強の振り返り手法」を確立してみる。
ただ、ここまで色々言っておいて何なんだが、結局シンプルにTrelloで毎週YWTをやってみようというものになってしまった。Trelloに個人用YWTボードを用意し、work
とprivate
のラベルぐらい用意しておいて、毎週ひたすらYWTをするだけである。だがYWTする際はちゃんと経験学習サイクルや前で取り上げたYWTのポイントを意識するようにする。
Y
- 仕事、プライベートでやったことを最低1つずつ出す
- 頑張りすぎるとW以降がしんどくなり続かなくなるので、特に振り返っておきたいYに厳選して行う
- もちろん悪かったことも含める
- 仕事、プライベートそれぞれラベルぐらいはつけてカードを作成する
W
- 「○○についてわかった」「○○完全に理解した」みたいな浅い振り返りは禁止
- Yに対して、抽象化や経験学習を促す問いを立てる
- ストレッチ、リフレクション、エンジョイメントの観点でアクションできていたか?
- 「どうしてそう考えたのか?」
- 「経験を通じて起こった変化は何か?」
- 「他の人に伝えるには?」
- 「得られた学びは何か?」
- 上記問いを参考にカードを作成し、箇条書きでも良いのでdescriptionも必ず書くようにする
T
- 最低1つ出す
- 良かった点に対しては継続できるようなアクションを考える、もしくはよりストレッチなチャレンジを宣言する
- 悪かった点に対しては改善案を考える
あとはGoogleカレンダーなどで週次のYWTイベントが通知されるようにしておけば準備完了。やっていくのみ。
まとめ
経験学習サイクルに関してざっくり学んだ結果、「これ要するにYWTでは?」という結論に至り、結果、個人でYWTを運用することになりました。効果があり、かつ頑張れば続けられそうなギリギリを攻めた感じです。
ただおそらく以前から課題に感じていた、具体的な振り返り方、振り返り時の問いの立て方の精度は上がったように思います。
またプライベートや仕事のラベルをつけるTrelloの運用が地味によいなと思っていて、プライベートでやったこと、わかったことが仕事に活きているのが見える化するともっとやろうという気持ちになれたりします。
やはり振り返りは難しいですね。皆さんが考える最強の個人振り返り手法、ぜひ教えてください。
参考
Auth0のSilent Authentication (サイレント認証)とRefresh Token Rotation (リフレッシュトークンローテーション)を完全に理解した (い)
Auth0 の Silent Authentication (サイレント認証)と Refresh Token Rotation (リフレッシュトークンローテーション)を完全に理解したい気持ちが急に高まってきたので書きます。 全体の流れとして
- React SPA with Auth0 での認可フローについて
- Silent Authentication (サイレント認証)について
- Refresh Token Rotation について
- まとめ
みたいな流れで書きつつ、Silent Authentication や Refresh Token Rotation は何を解決しようとしているのか、それぞれのリフレッシュ方法でどのような挙動になるのか、などについて理解を深めていきたいと思います。
また、React SPA with Auth0 の認可フロー部分のイメージを沸かせるために以下のサンプルリポジトリを用意しています: https://github.com/danimal141/auth0-react-playground
こいつは
- frontend
- React の SPA でログイン、アクセストークンを取得する
- backend
- auth0
- Auth0 も一応コードからデプロイして環境構築可能
- めっちゃ個人名の入ったアプリ名になってしまっているので名前変えてください w
- 一部、設定ファイルだけでは更新できない設定もあるので注意 (デプロイ用のアプリ作成など)
- Auth0 も一応コードからデプロイして環境構築可能
みたいな構成になっていて、アクセストークン取得まわりの動作検証に使ったものなのでよかったら見てみてください。ちなみに GraphQL とか使っちゃっていますが、今回の文脈において GraphQL の知識は特に必要ありません。
React SPA with Auth0 での認可フロー
Auth0 の React 用 SDK: auth0-reactを利用した場合、認可フローはこちらに Under the hood, it implements Universal Login and the Authorization Code Grant Flow with PKCE.
と書かれているように、Authorization Code Flow with Proof Key for Code Exchange (PKCE)になる。より詳細な説明はこちらに書かれている。
PKCE は雑にいうと、「OAuth2 の Authorization Code Flow で認可コード奪われたらアクセストークンも奪われちゃうからツラいですよね、認可コード送信元も検証して、せめてアクセストークンは取られんようにしましょうや」っていう仕組み。こちらの記事の解説がめちゃめちゃわかりやすかったのでオススメ。
auth0-react
を使う場合、Authorization Code Flow with Proof Key for Code Exchange (PKCE)な実装は SDK 側でサポートしてくれているので自前で code_challenge
などをハンドリングするような必要はない。
ちなみにauth0-react
は元々あったauth0-spa-jsを React の Hooks ベースの実装でいい感じに抽象化しただけのものなので、実装詳細を知りたい場合はauth0-spa-js
の方のコードを読んだほうがよい (読まざるを得ない)。
ログイン -> アクセストークン取得 -> ログアウトまでのライフサイクル
会員登録済みで Auth0 上にすでにユーザが存在する前提で、ログインからアクセストークン取得、ログアウトまでの流れはざっくり以下のようになると思う。
auth0-react
のloginWithRedirectを利用してログイン処理を呼び出す- Auth0 の Application (SPA)で callback URL として許可している URL に
?code=xxx
のクエリパラメータ付きでリダイレクトされるcode
などが URL に含まれててツラいが、auth0-react
の onRedirectCallbackを指定しておくと勝手にその辺のツラいクエリパラメータが除外された URL に勝手にリダイレクトしてくれる
- 上記の
code
を使って{auth0_domain}/oauth/token
にリクエストを投げてaccess_token
を取得- アクセストークン以外にも
scope
など色々情報は返ってくるはずだけど、今回は割愛 auth0-react
のgetAccessTokenSilentlyというメソッドがその辺やってくれている
- アクセストークン以外にも
- トークンストレージはデフォルトではインメモリ
- 画面をリロードしたらアクセストークンは再取得する必要がある
- localStorage を利用することも可能 (後述するけど、リスクを理解せずノリで使うのは危険)
auth0-react
のlogoutを呼ぶとログアウトし、Auth0 ドメインとのセッションも切れる
Silent Authentication (サイレント認証)
上述したが、アクセストークンはデフォルトではインメモリにキャッシュされるので画面リロードなどで都度、再取得が必要になる。「Universal login -> ログイン成功 -> ?code=xxx
付きで SPA にコールバック」の流れでは特に問題なかったが、それ以降、Auth0 ドメインとのセッションが生きている状態でアクセストークンの再取得はどうするのか、またログインからやり直しなのか...?
Auth0 はアクセストークンをリフレッシュする手段としてSilent Authentication (サイレント認証)という仕組みをサポートしている。2021 年 6 月時点ではデフォルトで Silent Authentication がデフォルトのアクセストークンリフレッシュ手段になっている。リフレッシュトークンは auth0-react
の実装で Provider にuseRefreshTokens=true
を渡すと利用できるようになる (その他、Auth0 の設定側で offline_access
スコープを API で許可する設定なども必要)。
これは雑に説明すると、画面遷移などを介さずひっそりとセッションを確認してアクセストークンを再取得する仕組みで、Chrome のネットワークタブなどをよく見てみると{auth0_domain}/authorize?xx=xx
へのリクエストで prompt=none
とresponse_mode=web_message
が含まれているのが重要なポイントである。
prompt=none
をつけることで画面表示が行われない状態でセッション確認ができる。そしてresponse_mode=web_message
によってユーザからは見えない iframe
を作って、「そいつから {auth0_domain}/authorize
にリクエスト -> code
の含まれたレスポンスを受け取る -> そいつを Web Messaging API 経由で親に渡してアクセストークン再取得」みたいな動きを実現している。
詳しくはこちらの記事がわかりやすく解説してくださっている。
こいつのメリットは localStorage を使わないで、かつ毎回ログインを要求されるみたいなクソな挙動を避けてアクセストークンを再取得できることだと思う。SPA はブラウザが前提になるのでネイティブと違ってセキュアなストレージがない。こちらの記事にあるように localStorage は悪意のある npm ライブラリ経由でシュッとトークンが抜かれるリスクがあるなど、セキュアではない。アクセストークンのようなデリケートな情報を長期間そこに入れておくのは危険なので、そういったリスクを避け、かつユーザ体験をそこまで損なわないこの仕組みは非常によい。
ただこいつも完璧ではなく、こちらに書かれているように、昨今の Safari の ITP のような、3rd party cookie がブロックされがちなご時世では Silent Authentication がうまく動作しないケースがある。
実際、Safari や Chrome で 3rd party Cookie をブロックする設定のまま Silent Authentication ベースのアクセストークンの再取得を試みると期待通り動作せず、以下のような感じになる。
- SPA (iframe) <-> Auth0 ドメイン間でのリクエストのやり取りの際に 3rd party cookie に当たる情報が取得できない
- セッション確認失敗
login_required
の Error Response が返るため、code
が取得できない- アクセストークンも取得できない
これを回避するには Auth0 のカスタムドメイン機能を使って SPA をapp.example.com
、ログイン URL を login.example.com
みたいに設定して回避するか、後述の Refresh Token Rotation がサポートされたリフレッシュトークンを使う、あたりが選択肢になってくる。
Refresh Token Rotation (リフレッシュトークンローテーション)
上述のような Silent Authentication の弱点をカバーするための手段として生まれたのが Refresh Token Rotation (という理解で合ってる?)。詳しい説明はこちらに書かれている。
これまでリフレッシュトークンに有効期限がなかったので、それを localStorage に入れるのはリスキーだったが、Refresh Token Rotation を使うとリフレッシュトークンを使ってアクセストークン取得する際に新しくリフレッシュトークンも再発行され、以前のものは無効化されるのでよりセキュアにリフレッシュトークンが使えるようになった。
もちろんリスクが無くなるわけではないが、有効期間をそれなりに短めに設定して localStorage にトークンをキャッシュするアプローチも悪くはないと思う。
Refresh Token Rotation を有効にして localStorage をキャッシュに利用した場合のフローは以下のようになると思う。実際に色々設定をいじったり、 auth0-spa-js
のコードを読みながら挙動を確認したんですが、間違ってたらご指摘ください。
アクセストークンの有効期限が切れる -> リフレッシュトークンを使って再取得の流れ
まずアクセストークン取得からそいつの有効期限が切れる -> リフレッシュトークンを使って再取得するまでの流れは大体こんな感じかと思う。ちなみにアクセストークンの有効期限はデフォルトで 1 日、Auth0 API の Token Expiration の設定に依存する。
- 最初のログインで Auth0 のセッションができる
- アクセストークンの有効期限が切れた場合
アクセストークンの有効期限が切れる -> リフレッシュトークンも有効期限切れ / 無効だった場合の再取得の流れ
次にアクセストークンが無効になって再取得しようにもリフレッシュトークンも期限切れ、もしくは無効だった場合は設定によって挙動が変わる。ちなみにリフレッシュトークンの有効期間は Auth0 の SPA の Refresh Token Expiration にある Absolute Lifetime の設定に依存する。
- リフレッシュトークンが invalid となって 403 が返る
- セッション有効期間 > リフレッシュトークン有効期間な設定の場合
- セッション有効期間 < リフレッシュトークン有効期間な設定の場合
- リフレッシュトークンの有効期間が実質セッションの有効期間みたいになる
まとめ
- Silent Authentication はブラウザのあまりセキュアではないストレージに頼らないかつ、UX を損なわないアクセストークンのリフレッシュを実現できるが、3rd party Cookie の扱いに厳しくなってきた昨今、いつ動かなくなるかわからないというリスクがある
- Refresh Token Rotation はリフレッシュトークンをローテーションさせることで以前よりも気軽にトークン情報をブラウザのストレージに入れられるようになったし、3rd party cookie、いつ使えなくなるんだろうという恐怖から開放される(と信じたい)
参照
- https://github.com/danimal141/auth0-react-playground
- https://github.com/auth0/auth0-react
- https://auth0.com/docs/libraries/auth0-react
- https://auth0.com/docs/flows/authorization-code-flow-with-proof-key-for-code-exchange-pkce#how-it-works
- https://dev.classmethod.jp/articles/oauth-2-0-pkce-by-auth0/
- https://github.com/auth0/auth0-spa-js
- https://auth0.com/docs/sessions/cookies/authentication-api-cookies
- https://qiita.com/smesh/items/2673287c16524da3886d
- https://auth0.com/docs/authorization/configure-silent-authentication
- https://qiita.com/ksakiyama134/items/bb5a97bf7762b4a87e0d
- https://techracho.bpsinc.jp/hachi8833/2019_10_09/80851
- https://auth0.com/docs/authorization/renew-tokens-when-using-safari
- https://auth0.com/docs/tokens/refresh-tokens/refresh-token-rotation
Dockerとplantuml-serverを使ってPlantUMLの実行環境を用意する
手軽に PlantUML をいじれる環境が欲しかったけど、軽く調べた結果、Mac での環境構築が悩ましかった。
色々検討した結果、ひとまず Docker で環境構築する方法をとった。
候補
- ローカルで
brew install graphviz
,brew install plantuml
する- 変な依存ライブラリとかめっちゃ入れられそうなので、できれば
graphviz
をローカルに入れたくない w
- 変な依存ライブラリとかめっちゃ入れられそうなので、できれば
- PlantUML Viewerを使う
- plantuml-serverを使う
- Docker の image があるので一番手軽に使えそうだし、軽く PlantUML を書いて UML を確認できれば十分だったのでこれを使うことにした
環境構築
Vim
Vim を使っているので PlantUML を書く用に plantuml-syntaxだけ入れておいた。他のエディタを使っている人も何かしらシンタックス用のプラグインはあるはず。
Docker
上記の plantuml-server 用の image が公開されているのでシンプルにそれを使う。こんな感じ。
# docker-compose.yml version: '3.7' services: plantuml-server: image: plantuml/plantuml-server ports: - 8080:8080
あとは docker-compose up
して open http://localhost:8080
すれば PlantUML の実行環境が手に入り、サクッと UML を確認できる。
まとめ
とりあえず Vim で PlantUML 書いて、ローカルで plantuml-server を立ち上げてコピペで UML 確認できるようになった。若干スマートさに欠けるけどまあいいかという感じ。
エンジニアの自分がインプットのためによく聴いているPodcastの番組まとめた
最近はなにがし.fm みたいな番組がめっちゃ増えてきましたね。
普段、移動時間やジョギングする時とかに Podcast をよく聴いているけど、何をどういう目的で聴いているか自分で整理するためにもジャンル別に聴いている番組をまとめてみました。
Tech 系
Rebuild
- 言わずもがなの番組、まだ番組が乱立してなかった頃からずっと聴いている
- 話題になった Tech 系の話題や最新情報をキャッチアップできて良い
- 最近はガジェットだったりコンテンツ系の話題が多い気がするけど、新しい言語とか新しい技術、マネジメント等について議論してる回は特に面白い
- 英語回は英語の勉強も兼ねて死ぬほど繰り返し聴いた
fukabori.fm
EM.FM
- これもマネジメントとかキャリア考える上で参考にしている
- 1on1 とか、プロダクト開発とか、エンジニア評価についてとかトピックがめっちゃ刺さる
- この回とか好き
Misreading Chat
The Changelog
- Go とか Rust とか GraphQL とかイーサリアムとかトピックが個人的に刺さりまくることが多いのでチェックしてるけど、ガチの英語なので聴く頻度は少なめ
- めちゃめちゃ集中しないと聴き取れないので元気な時だけ聴く
集中しても全然聴き取れない
- Go の Rob Pike がゲストで来てたりでアツい
- めちゃめちゃ集中しないと聴き取れないので元気な時だけ聴く
- 余談だけど、公式サイトは Elixir でできてる
hidek のエンジニアと長話
- Podcast 枠に入れてよいかわからないが、stand.fm もたまに聴いていてその中でもこの番組が好き
- 他の Podcast 番組にはあまり出られていないような著名な方がゲスト出演されていたりして面白い
y_matsuwitter 相談部屋
- こちらも stand.fm から y_matsuwitter さんの相談部屋、トピックがエンジニアリングから経営、生産性、勉強法など自分が好きなものが多い
- 1エピソードが5分程度なのでさくっと聴きやすい、特に良い回を何回も聴く
ビジネス系
前田ヒロ Startup Podcast
- SaaS 界隈のスタートアップに投資されている前田ヒロさんの Podcast、SaaS 系のゲストや話題多め
- 個人的にも創業期のスタートアップにいた期間がキャリアの中で圧倒的に長いので、トピックが刺さりまくる
- ゲストの起業家の方々のマインド、考え方、失敗談などをインプットしまくれるので高まる、よい
- 2021 年2月現在、もはや Tech 系の番組よりもよく聴いているかもしれない
- この回とかめっちゃ面白い、URLからしてSUGOI
ゼロトピック
- 10X Yamotty さんの Podcast
- こちらも起業家の方やスタートアップみの強い方の経験談や考え方をインプットできて楽しいのでチェックしている
- プロダクト開発みたいな観点でもめちゃめちゃ参考になる
- 自分はスタートアップが長いエンジニアなので、こういう回は特によさを感じてしまう
その他
バイリンガルニュース
- 上述の Rebuild でもたまに話題が上がっていて、英語学習のためにチェックするようになった
- 話題もわりとテック系多めで英語と日本語が混ざっているので、フル英語の番組より気軽に聴けてよい
- 英語の学習抜きにしても面白い内容
- Mami さん、帰国子女とかではないのにあのレベルなのヤバすぎる(参照)
まとめ
今後も面白い番組を発見したら更新していきたい。