Reading Log 2021-H1

July 11, 2021

2021年01月~06月の間に読んだ本の記録

一覧

プロダクションレディマイクロサービス

マイクロサービスではAPIエンドポイントのバージョニングはアンチパターン
- 独立したサービスなのでクライアントサービスに特定のバージョンを指定する事を許すべきではない
チェックリスト
- 安全性、信頼性
  - 標準化された開発サイクルの有無
  - lint,unit,integration,e2eテストの有無
  - テスト、パッケージング、ビルド、リリースのプロセスの自動化
  - ステージング、カナリア、本番のフェーズを備えたデプロイパイプラインの有無
  - クライアントサービスを把握できている
  - 依存関係が明確で、障害発生時のバックアップ、代替、フォールバック、キャッシュが用意されている
  - 安定性、信頼性のあるルーティングが存在している
- スケーラビリティ、パフォーマンス
  - 質的、量的な成長についての判断基準を把握している
  - ハードウェアリソースの効率的な使用
  - リソースの要件とボトルネックの把握
  - キャパシティプランニングの自動化
  - クライアント、依存関係、マイクロサービスともにスケール可能
  - トラフィックのパターンを把握している
  - 障害発生時にトラフィックのルーティングを変更する事で対応が可能
  - スケーラビリティとパフォーマンスを両立するプログラミング言語の利用
  - データの処理、格納、タスクの処理がパフォーマンス、スケーラビリティを考慮して行われている
- 耐障害性、大惨事対応力
  - 単一障害点がない
  - あらゆる障害のシナリオと起こりうる大惨事が明らかになっている
  - コードテスト、ロードテスト、カオステストを通じて回復性のテストが行われている
  - 障害の検知、修正が自動化されている
  - インシデント、機能停止時の対応手順が用意されている
- 監視
  - ホスト、インフラ、マイクロサービスで主要なメトリクスが特定され、監視されている
  - 過去の状態を記録するロギングシステムがある
  - 全てのメトリクスが含まれているダッシュボードの有無
  - アクション可能な、閾値に基づいたアラートシステムがある
  - 監視、インシデントへの対応を行うオンコールローテーションが実施されている
  - インシデント発生時の明確で標準化されたオンコール手順書がある
- ドキュメント
  - 包括的なドキュメントの有無、定期的な更新の有無
    - マイクロサービスの説明
    - アーキテクチャ図
    - 連絡先とオンコールの情報
    - 重要情報へのリンク
    - オンボーディング
    - 開発ガイド
    - リクエストフロー
    - エンドポイント
    - 依存関係についての情報
    - オンコールランブック
    - FAQ
  - ドキュメントの内容が理解されている
  - 本番対応の標準に準拠しており、要件を満たしている
  - アーキテクチャのレビュー、監査が頻繁に行われている
評価基準
- 安定性と信頼性
  - 開発サイクル
    - 全てのコードが格納されるリポジトリの有無
    - 本番環境の状態を正確に反映している開発環境で作業をしている
    - 適切なlint,unit,integration,e2eテストの有無
    - コードレビューのプロセスや方針の有無
    - テスト、パッケージング、ビルド、リリースのプロセスは自動化されているか
  - デプロイパイプライン
    - 標準化されたデプロイパイプラインを持っている
    - 完全ステージング、もしくは部分ステージングのステージングフェーズがパイプラインに含まれている
    - ステージング環境から本番サービスへのアクセス方法
    - カナリアフェーズの有無
    - あらゆる障害を補足できるくらいの期間を使って、カナリアフェーズが実施されている
    - カナリアフェーズは本番トラフィックのランダムなサンプルを正確にホスティングしているか
    - マイクロサービスのポートはカナリアと本番で同じになっている
    - 本番環境へのデプロイは一度にまとめて行っているか、漸進的に展開しているか
    - 緊急時にステージング、カナリアフェーズを省略する方法の有無
  - 依存関係
    - 依存関係が明確になっている
    - クライアントが明確になっている
    - 依存関係の障害影響をどのように緩和しているか
    - 個々のパスにバックアップ、代替サービス、フォールバック、防御的キャッシュの用意
  - ルーティングと検出
    - マイクロサービスの信頼性に対する健全性チェックの有無
    - 健全性チェックは適切か
    - 健全性チェックは通信レイヤ内で別チャネルを使って行われているか
    - サーキットブレイカーの有無
  - 非推奨と廃止
    - 廃止のための手続きの有無
    - APIエンドポイントを非推奨にするための手続きの有無
- スケーラビリティとパフォーマンス
  - 成長の判断基準
    - 質的な成長の判断基準は何か
    - 量的な成長の判断基準は何か
  - リソースの効率的な使用
    - マイクロサービスは専用ハードウェアか共有ハードウェアでホストされているか
    - リソースの抽象化、配分のためのテクノロジーの利用有無
  - リソースの把握
    - リソース要件(CPU,RAM)はどうなっているか
    - 1インスタンスが処理できるトラフィックはどれくらいか
    - 1インスタンスが必要とするCPUキャパシティはどれくらいか
    - 1インスタンスが必要とするメモリはどれくらいか
    - 独自のリソース要件はあるか
    - リソースのボトルネックは何か
    - 水平スケーリング、垂直スケーリング、またその両方を必要とするか
  - キャパシティプランニング
    - スケージュールに基づいてキャパシティプランニングが行われているか
    - 新しいハードウェアのリードタイムはどれくらいか
    - ハードウェアリクエストの発生頻度
    - ハードウェアリクエストが優先的に認められるマイクロサービスはあるか
    - キャパシティプランニングは自動化されているか
  - 依存関係のスケーリング
    - マイクロサービスの依存関係は何か
    - 依存関係はスケーラブルでパフォーマンスが高いか
    - 依存関係のスケーリングは、マイクロサービスの予想される成長についてこれるか
    - 依存関係の所有者は、マイクロサービスの予想される成長に対して準備ができているか
  - トラフィック管理
    - トラフィックパターンは理解できているか
    - マイクロサービスの変更日程は、トラフィックパターンを中心に組まれているか
    - トラフィックパターンの極端な変化に適切に処理できているか
    - 障害発生時に、トラフィックを自動的に他のデータセンターにルーティングできるようになっているか
  - タスクの処理
    - スケーラブルでパフォーマンスの高いサービスを開発できるプログラミング言語を利用しているか
    - リクエスト、タスクの処理方法の中に、スケーラビリティやパフォーマンスが制限される要因は含まれているか
    - マイクロサービスがリクエストをどのように処理しているか、どれくらい効率的か、リクエスト数が増減したときにどのように対応するか理解しているか
  - スケーラブルなデータストレージ
    - スケーラブルでパフォーマンスの高い形でデータを処理しているか
    - 格納しなければいけないデータはどのような種類のものか
    - 必要となるスキーマはどのようなものか
    - 毎秒何トランザクションを処理しなければいけないか、また実際の処理トランザクションはどれくらいか
    - より高いパフォーマンスを必要としているか
    - リードヘビー、ライトヘビー、もしくはその両方か
    - 水平スケーリング、垂直スケーリングが行えるか、どちらは行われるか
    - レプリケーション、パーティション分割されているか
    - 専用データベースか、共有データベースか
    - テストデータをどのように処理、格納しているか
- 耐障害性と大惨事対応
  - 単一障害点の除去
    - 単一障害点はあるか
    - 複数の障害点があるか
    - 障害点は取り除く事が可能か、緩和することは可能か
  - 大惨事と障害のシナリオ
    - 障害シナリオと発生しうる大惨事は全て特定できているか
    - マイクロサービスエコシステム全体を通じてよく起こる障害は何か
    - マイクロサービスに影響を与えるハードフェアレイヤの障害シナリオは何か
    - マイクロサービスに影響を与える通信、アプリケーションプラットフォームレイヤの障害シナリオは何か
    - マイクロサービスに影響を与える依存関係の障害はどのようなものか
    - このマイクロサービスを停止させる可能性のある内部障害は何か
  - 回復性テスト
    - 適切なlint,unit,integration,e2eテストを持っているか
    - 定期的にスケジューリングされたロードテストを実行しているか
    - 全ての障害のシナリオがカオステストとしてテストされているか
  - 障害の検出と修正
    - 組織全体でインシデントや機能停止に対処するための標準的なプロセスが存在しているか
    - 障害や機能停止時に、ビジネスにどのように影響を及ぼすか
    - 明確に定義された障害のレベル、緩和戦略はあるか
    - インシデントや機能停止が発生した時に、チームは5段階のインシデント対応に従っているか
- 監視
  - 主要メトリクス
    - 主要なメトリクスは何か
    - ホスト、インフラのメトリクスは何か
    - マイクロサービスレベルのメトリクスは何か
    - 主要なメトリクスは全て監視されているか
  - ロギング
    - ロギングしなければならない情報は何か整理されているか
    - 全ての重要なリクエストをロギングしているか
    - ログは特定の時点におけるマイクロサービスの状態を正確に反映しているか
    - ロギングソリューションはコスト効果が高く、スケーラブルか
  - ダッシュボード
    - ダッシュボードの有無
    - ダッシュボードのわかりやすさ
    - 主要なメトリクスが表示されているか
    - ダッシュボードを見るだけでマイクロサービスが正常に動作しているかわかるか
  - アラート
    - 全ての主要メトリクスに対してアラートが設定されているか
    - 全てのアラートが適切な閾値で設定されているか
    - 機能停止が起こる前にアラートが生成されるようになっているか
    - 全てのアラートはアクション可能になっているか
    - オンコールランブックは、全てのアラートのトリアージ、緩和、解決の方法をステップバイステップで説明しているか
  - オンコールローテーション
    - 専用のオンコールローテーションの有無
    - シフトの担当者は最低でも二人以上になっているか
    - 技術組織全体で標準化されたオンコール手続きはあるか
- ドキュメント
  - マイクロサービスのドキュメント
    - ドキュメントは一元管理、共有され、簡単にアクセス可能か
    - 検索が簡単に行えるか
    - サービスを変更した時はドキュメントも更新されているか
    - ドキュメントに以下内容は含まれているか
      - マイクロサービスの説明
      - アーキテクチャ図
      - 連絡先とオンコール情報
      - 重要な情報へのリンク
      - オンボーディング、開発ガイド
      - リクエストフロー、エンドポイント、依存関係についての情報
      - オンコールランブック
      - FAQ
- 組織的な理解
  - チームの全ての開発者がマイクロサービスの本番対応についての質問に答えられるか
  - 満たさなければならない原則や標準はまとめられているか
  - 新規開発事に通過しなければいけない技術仕様プロセスはあるか
  - 既存のマイクロサービスのレビュー、監査は頻繁に行われているか
  - アーキテクチャレビューが全チームで実施されているか
  - 本番対応の監査プロセスは用意されているか
  - 本番対応の状態に引き上げるためのロードマップの有無
  - 全社のOKRは本番対応の標準に基づいて設定されているか
  - 本番対応のチェックプロセスは自動化されているか

入門監視

ユーザー視点での監視が最初の一歩
インシデント発生時の役割
- 現場指揮官
  - 決断する人
  - 改善、コミニュケーション、調査には関わらない
  - サービス停止に関する調査を監督する役割のみ
  - インシデントの初期段階はオンコール担当が担う事があるが、場合によって途中で他の人に引き継がれる場合がある
- スクライブ(書記)
  - 誰が何をいつ行ったか、どんな決断がされたのか、フォローアップすべき事項が見つかったのか
  - 調査や改善は行わず、起こったことを記録することに専念
- コミュニケーション調整役
  - 最新情報の提供。唯一のコミュニケーションポイント
  - 利害関係者が直接SMEなどにコミュニケーションをとり、作業の邪魔になるのを防ぐ
- SME
  - 実際にインシデント対応をする人
YelpのビジネスKPIの例
- 検索実行
- レビュー投稿
- サインアップ
- ページの取得
- アクティブユーザー
- アクティブビジネス
- 広告購入
- レビューに対する返事
Reddit
- 滞在ユーザー
- ログイン
- コメント投稿
- スレッド作成
- 投票
- プライベートメッセージの送信
- Gold購入
- 広告購入
上記KPIのより詳細情報を得るために失敗も計測する
- ログイン成功/失敗

その仕事、全部やめてみよう――１％の本質をつかむ「シンプルな考え方」

谷を埋めるな、山を作れ
- 短所を補うことは谷を埋める行為であり、長所を生み出し伸ばすのは山を作る行為
- 谷を埋めても山がなければ没個性な製品が生まれるのみ
山を作るコツ
- まだ誰もやっていない
- 他業種や他国の成功性のエッセンスを取り入れる
- ギャップに目をつける
  - IT活用が遅れている場所でITを先んじて活用する
山を作るプレゼンのコツ
- 共感する事実から入る
ラストマン戦略
- グループ内で一番になれる領域を探してスペシャリストを目指す
- グループ内で一番になれたら一段大きい組織でのラストマンを目指す
- なれない場合は領域を変えるか、領域を狭めてより細分化された分野でのラストマンを目指す
一番近くと一番遠くだけを見る
- 一番近くだけを見ていると直近でやるべき仕事を機械的にこなしていく事になりがち
- 一番遠くだけを見ていると、夢やアイディアは出るが情熱だけが残って現実的には何も得られずに終わることが多い

論点思考

論点とは
- 解くべき問題、課題のこと
- 問題解決のプロセスはいくつもの論点候補の中から本当の論点を設定し、その論点に対する解決策を考え出し、実装していく
与えられた論点を疑う
- 問題与えられた時に、論点の設定は間違っていないかという視点を持つことの重要性
論点思考の四つのプロセス
- 論点候補をあげる
- 論点を絞り込む
- 論点を確定する
- 全体像で確認する
論点と現象を見極める
- 現象や観察事実と論点は別物
- 例) 会社に泥棒が入った
  - 論点
    - 防犯体制に不備がある
    - 情報を盗まれ今後トラブルが発生する可能性
    - 会社のイメージダウン
- 何を論点とするかで解決策が変わる
  - 現象や観察事実を論点と勘違いすると解決策が適切な内容にならない
- 少子化というのも現象であって問題ではない=論点ではない
  - 論点候補
    - 労働人口の減少
    - 高齢化が進み若者負担増
    - 歳入減、歳出増により国家財政の破綻
    - 高齢者の割合が増えることによる地方の衰退
  - それぞれの論点によって解決策は変わる
  - また目的、誰のために解決するかによっても変わる
    - 若者のためであれば高齢者に手厚い社会保障体制を見直すなど
    - 高齢者のためであれば年金、医療制度などを充実されるか
論点を洗い出す方法
- 仮説を持つ
- 仕事の依頼者の関心を低い分野を探る
- なぜを五回繰り返す
論点を絞り込む方法
- 解決できるか、できないか
- 解決できるとして実行可能か
- 解決したらどれだけの効果があるか
依頼者の裏側の意図をによって論点は異なる
- 組織改革といっても真にやり切りたいのか、外向けのポーズとしてなのかによって求めているものが異なる
メンバーへの課題の与え方
- 論点のレベルで使い分ける
- 例) シャチについての四つの問い
  - シャチは魚か
    - 仮説に基づいた質問
  - シャチは魚か哺乳類か
    - 白か黒かをはっきりさせる質問
  - シャチは何類か
    - オープンの論点
  - シャチはどんな生物か
    - ただの質問

ポスト平成のキャリア戦略

キャリアの掛け算によっていかに希少価値を出せるか、ユニークネスを担保できるか
- 3つ以上の専門性を組み合わせることで新しい付加価値を出せる人材
- キャリアの掛け算はリスクヘッジでもあり心の安心にもつながる
組織固有スキルと汎用的スキルを分けて考える
ハングリーとノーブルの両立
- ハングリーさがないと事を成せない
- ノーブルでないと悪い事をしてしまう
成長の必須条件はコーチャビリティ
- 様々な人の意見やアドバイスを受け止めて、自分に必要なものを咀嚼する能力
仕事は反比例の世界。頑張って失敗する事もあるが、5~10年にわたる長期間の仕事に関する評価はフェア。中長期的には努力は報われる
30代はキャリアの掛け算の要素が明確になってくる時期
マネジメントの際には部下の最大感心事は何か、何をインセンティブとして働いているのかを見極めることが大事
- 最後は想像力の問題
出世する人の特徴
- 決めてくれる能力、部下に嫉妬しない能力
  - 普通の組織においては物事を決めてくれる能力と、部下に嫉妬せず一番働きやすい環境について考える能力があれば絶対に出世できる
- 1,2個上のレイヤーの目線を持って行動していた人
  - 課長の時に部長目線で考えていたが故に部長に認められる
- みんなが当たり前だと思っていた事を変えた
  - 当たり前を変えると、実力があるという評価になる
勝手な遠慮やルールを固定していない問う
- 決まっている物だと思ってました、はNGワード
- インパクトを出すために動かす必要がある前提、ルールがあるならまずはそれを動かせないか考える

分散システムデザインパターン

サイドカー
- アプリケーションコンテナを拡張したり改善するためのコンテナ
- 業務でもよく使ってる。ライブラリと異なり言語非依存で幅広い環境で再利用しやすい
  - 認証認可に関わる処理をライブラリで提供すると言語毎にライブラリが必要でサポートが辛い
  - サイドカーにすると複数言語のサポートをする必要がなくなる
- ex) HTTPS対応のためのSSL終端を担う、サービスメッシュ、モジュール化されたアプリケーションコンテナ
アンバサダ
- アプリケーションコンテナ -> アンバサダ -> 外部サービス
- ex)
  - シャーディングされたストレージにアクセスする際に適切なシャードに振り分けるためのロジックを持たせる
    - クライアント側でシャーディングについて意識する必要がなくなる
  - サービスブローカー
    - サービスディスカバリを担う
    - 上記の処理をアンバサダとして独立されるとアプリケーションコンテナからは単にlocalhostに接続すれば良くなる
アダプタ
- アプリケーションコンテナ <- アダプタコンテナ <- 外部インターフェイス
- ex)
  - アプリケーションコンテナのログを監視システムが要求するインターフェイスに変換するコンテナ
    - 今ならPrometheusのI/Fに揃えても良いかもしれないが、やがて新しい監視システムやI/Fが必要になった際に対応がしづらい
  - Fluentd
    - アプリケーションコンテナでは単に標準出力などにログを吐く
    - その後の変換や連携はFluentdがこなす
  - ヘルスモニタの追加
マルチノードパターン
- マイクロサービス
  - 各チーム、サービスが独立してデプロイなどを出来るようにする
    - 単にサービスを分割しただけだと分散モノリスになりかねない
  - 信頼性と素早さに関連するものが利点の代表
  - ピザ２枚分のチーム
    - チームサイズを小さくするとコミニュケーションのオーバーヘッドも小さくなる
- レプリカがロードバランスされたサービス
  - ステートレスなサービス
    - 各レプリカ、コンテナ、サービスはステートレスにしてロードバランサの下にぶら下げて水平スケールを可能にする
    - 普通の構成
  - セッションを保存するサービス
    - あるユーザーのリクエストは特定レプリカに送られるなど
    - IPアドレスなどを元にコンシステントハッシュ関数をセッションに利用する
      - ハッシュ関数を使うのはレプリカ数が変わった時に影響を小さくするため
  - キャッシュレイヤ導入
    - アプリケーションやDBの前段にキャッシュレイヤを置く
    - サイドカーとしてデプロイするとスケールの際も一緒にスケールさせる必要があるため、アプリケーションレイヤの上のレイヤに配置した方がいい
- シャーディングされたサービス
  - 大容量なデータを捌くためにDBやキャッシュをシャーディングする
  - シャーディングされたサービスへのアクセスにはアンバサダを経由する
  - どうシャーディングするかが大事
    - シャーディング関数(コンシステントハッシュ関数)の利用
- スキャッタギャザー
  - 処理時間をスケールさせるために、処理を分割して各レプリカに並列で実行させ、ルートで結果をまとめて返却する
  - ドキュメント検索
    - catとdogの両方を含む文章を検索
      - catとdogそれぞれに対する検索を並列で行う
      - 最後に結果をまとめる
  - 並列数を増やしてもパフォーマンスが改善されない可能性がある
    - 一番遅い処理に依存する
- ファンクションとイベント駆動、pub/sub
- オーナーシップの選出
  - オペレーター
    - 何らかのアプリケーションを動かすためのプログラム
    - 望ましい状態をユーザーが定義して、オペレーターはその定義通りに動作することを責務とする
    - k8sとかetcdとか