Skip to content

Instantly share code, notes, and snippets.

@south37

south37/infrastructure_README.md Secret

Last active June 7, 2023 01:51
Show Gist options
  • Star 4 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save south37/85d97e02d7816a31053971d63c164880 to your computer and use it in GitHub Desktop.
Save south37/85d97e02d7816a31053971d63c164880 to your computer and use it in GitHub Desktop.
Download ZIP
infrastructure_README.md
Raw
infrastructure_README.md

Infrastructure Squad

Why

Wantedly, Inc. の創造的な活動を支える / Boost creativity and innovation in the organization

How

開発チームが Ownership を持って Dev, CI/CD, Ops (Monitoring + On-Call) を行えるように、我々は Platform として Tool/Library/System/Infra を用意する。開発チームが Platform を利用することで、自然と "強いシステム" が "高い生産性" で実現されるようにする。

  • "強いシステム" の実現（= Site Reliability）
    • Performant
    • Reliable
    • Maintainable
    • Secure
    • Efficient
  • "スケーラブルな開発組織を支える Platform" の実現（= Developer Productivity）
    • Tool/Library/System (= Build)
    • CI/CD (= Test, Deploy)
    • Observability (= Operation)

What

"強いシステム" の実現のために、我々は "Platform 化" というアプローチを取る。背景は後述。

具体的に取り組むのは以下。ただし、"強いシステム" の実現を考える際も基本的には「開発チームから使われるものを Platform として提供する」ことを念頭におく。

  • "強いシステム" の実現
    • マイクロサービスアーキテクチャの強化
      • Availability, Resiliency, Scalability, Performance, Maintainability の向上
      • 以下の重要な関心ごとに対して「開発者が自然に意識できる、自然に適切なアプローチが取れる状態」の構築 => Platform 化
        • 適切な依存関係、組織にあったマイクロサービス境界、適切なインターフェースの宣言的管理、Fallback 機構の充実、通信の信頼性とパフォーマンス向上、非同期通信による結果整合性、バッチジョブの宣言的依存管理、バッチジョブの自動再実行、etc.
    • Cloud Infra の活用と Orchestration Layer の提供
      • AWS, GCP
      • Kubernetes
    • セキュリティ対応・セキュリティレベルの向上
    • 効率的なマシンリソース利用
  • "スケーラブルな開発組織を支える Platform" の実現
    • Tool/Library/System の開発・提供
    • 運用自動化 (k8s, terraform の利用)
    • CI/CD
    • Observability 強化 (Monitoring + Alert 強化, Error Rate 可視化)
    • 上記を Platform として提供してセルフサービス化、Ownership を持つ文化の構築
      • 障害検知 + 対応
      • Postmortem
      • Production Readiness Review

また、上記の実現を生産的に行うために、以下にも取り組む。

  • Toilの撲滅
    • 手動オペレーション効率化・自動化
      • Kubernetes Cluster Upgrade
      • K8s Manifest File 更新
      • Incident Issue
      • Postmortem
      • Production Readiness Review
      • 特定の Team のための Infra 構築
    • Support 運用の改善
  • 優先度判断が漏れなく行われる体制構築
    • Project と直接紐づかない Task を貯める仕組みと消化する仕組み（= Backlog 消化 Day）

その他、Tool/System に出来てないものは開発チームに Support Issue を立ててもらって対応する。

  • Support

KPI

  • "強いシステム" の実現（= Site Reliability）
    • SLA 99.9 % 以上を維持する
    • 未来の変化を見据えた上で、強いシステムを作るための部品を提供
  • "スケーラブルな開発組織を支える Platform" の実現（= Developer Productivity）
    • ヒアリングを通して課題を整理し、エンジニアリングによって解決

背景

以下のような Layered Architecture を考えた時、2014 年からは AWS を利用、2016年からは Kubernetes を利用と Layer を積み重ねてきた。Cloud + Kubernetes の Infra Layer を提供し、安定化させるということが行われてきて、年々良くなっている。

[Application (= Microservices)]
[Kubernetes]
[Cloud (= AWS, GCP)]

一方で、システムが巨大化し、機能が増え、開発チームが大きくなるほど、Application (= Microservices) のレイヤーの重要性が高まっている。この部分は開発チームが担う一方で、一方的に任せていれば良くなるというものでもない。特に、「開発 (Dev)」と「運用 (Ops)」が完全に分離してしまうと、そこに「新機能リリースのための変更（= Reliability 低下）」と「変更阻止（= Reliability 短期的に上昇）」という対立軸が生まれてしまい、開発組織が上手く行かなくなる。

そこで我々は、「Platform 化」というアプローチを取る。開発チームが Ownership を持って Dev, CI/CD, Ops (Monitoring + On-Call) を行い、我々はそのための Tool/Library/System/Infra を用意する。また、考え方や Best Practice の啓蒙、組織構造の改善など、開発組織の文化・組織的な改善の取り組みも行う。

Platform を提供することで開発 Team の負担を軽減しつつ、開発 Team が Dev から Ops までを責任範囲とする事で強いシステムを作ることへの健全なインセンティブを用意する。具体的には、以下のような姿を開発 Team が実現出来るようにする。

  • 強いシステム = 変化出来るシステム
    • <=> 弱いシステム = 変化出来ないシステム
      • 信頼性が低いために、システムを不安定にする「デプロイ」が出来ない => 信頼性が上がらない（むしろ下がる）という悪いループから抜け出せなくなる。
  • どう強いシステムをどう実現するか?
    • => システムを複数のコンポーネントから作る（= マイクロサービス）
    • マイクロサービス単位で小さく高速に変化可能にする（= 変化出来るシステム）
    • マイクロサービスアーキテクチャ
      • 適切な依存関係
      • 組織にあったマイクロサービス境界
      • 適切なインターフェースの宣言的管理
      • Fallback 機構の充実
      • 通信の信頼性とパフォーマンス向上
      • 非同期通信による結果整合性

短期的には Platform は「開発 Teamの負担を増やす」ように見えるが、長期的にはシステムの安定性を高めつつ各チームが高速に開発を行えるようになるため、全体としての生産性は高まるはず。Amazon, Google などの先人に倣う。

Project

  • "強いシステム" の実現（= Site Reliability）
    • Improve Monitoring and Alerting and Logging
    • Post-mortem / Incident Review
    • System Architecture
      • Event Driven Architecture
      • RPC framework (e.g. gRPC)
      • Service Mesh
    • Security
    • Efficiency
  • "スケーラブルな開発組織を支える Platform" の実現（= Developer Productivity）
    • Dockerized
    • Implement tools for Developer
    • Faster CI/CD
    • Distributed Tracing
    • Mentenance Common library

SLO/SLI

Wantedly では、サービスの健全性を示す重要な指標として SLI を定義しています。また、目標として SLO も定義しています。

SLI は、「サービスを運営する上で重要な endpoint の成功したリクエストの比率」です。HTTP status code が 5xx 及び 405 (Method Not Allowed) 以外のリクエストを成功と見なします。SLO は「リクエストの 99.9% の成功」です。

よく使うレポジトリ一覧（注: private repository なので社外の人はリンクを開けません）

インフラメンバー以外の人に知っておいて欲しいレポジトリとその説明。

外部リンク集

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment