Kush's Wiki

Kubernetes

HTTP

Hypertext Transfer Protocol #Network

DDD

Domain Driven Design #Software Design ドメイン（事業領域）ファーストでプロダクト開発を行う考え方 大きく戦略的設計と戦術的設計に分かれる 戦略的設計ではユビキタス言語と境界付けられたコンテキストが大きなトピックとなる 戦術的設計ではコード実装におけるデザインパターンを提供する。デザインパターンは集約と呼ばれるドメインモデル群を中心に据える ビジネスロジックが置かれるドメインレイヤを中心に業務手順や技術的関心事といったレイヤをどのように整理するかについては、クリーンアーキテクチャ等のいくつかのアーキテクチャが議論されている

CNCF

ロードバランシング

#API Architecture #Network 外部からの大量トラフィックを捌けるよう用意された重複データを持つ多数のリソースサーバー群が均等に使用されるよう制御する役割 アプリケーションの可用性を高め、リバースプロキシと同様にサーバーを保護するセキュリティ機能が組み込まる ロードバランシングとは? - ロードバランシングアルゴリズムの説明 - AWS

DevOps

#Agile 10+ Deploys Per Day: Dev and Ops Cooperation at Flickrにて初めて登場した言葉 開発とオペレーションを一つのチーム内で両立させる 広義な用語ではあるが、共通して以下のような手法が定義されることが多い Continuous Integration Continuous Delivery IaC マイクロサービス

Protocol Buffers

Protobuf #API Architecture Googleによって開発されたインターフェース定義によるバイナリエンコーディングライブラリ。 フィールド名のエイリアスとして扱うフィールドタグ（数値）によってバイトを節約している。 フィールドタグによる互換性に関する仕様の要点は以下。 フィールドの追加 未使用のタグ番号を割り当てることで前方互換あり 必須でなければ後方互換あり フィールドの変更 フィールド名の変更は前方・後方互換あり フィールドの削除 追加時の前方・後方と逆 またProtocol Buffersはフィールド制約である optional と repeated 間の互換性にも対応している。これはバイナリ上でフィールド情報を単純に複数回並べているため。 Protocol Buffers Documentation

Datadog

Martin Fowler

マイクロサービス

#Software Design #API Architecture DDDにおける境界付けられたコンテキストに対応する形でサービスを用意し、サービス間通信を行う設計パターン マイクロという名前の通り、サービスインターフェースが小さく疎結合になっていて各サービスの責務が凝集されていることが望ましい

APIゲートウェイ

#API Architecture #Network 外部トラフィックに対してリバースプロキシ・ロードバランシングが持つようなネットワークのルーティング・セキュリティと可用性の向上に加え、以下のような機能横断的な要件を扱う役割 認証 認可 レートリミット リトライ サーキットブレーカー etc.

MySQL

REST

Representational State Transfer #API Architecture HTTPを基礎とするアーキテクチャ上の制約、定義 Architectural Styles and the Design of Network-based Software ArchitecturesにRESTfulとみなされるための定義が書かれている 第一にサービス提供者と利用者のやり取りがモデル化されていること、が定義となる

吉羽龍太郎

TDD

Test-Driven Development #XP

市谷聡啓

技術的負債

Technical Debt

スクラム

#Agile スクラムの三本柱は 透明性(Transparency) 検査(Inspection) 適応(Adaptation) 以下の5つの価値基準によって成功を導くとされている 確約(Commitment) 集中(Focus) 公開(Openness) 尊敬(Respect) 勇気(Courage)

OSI参照モデル

Open Systems Interconnection (OSI) #Network ネットワーク通信機能（プロトコル）を7つの層に分割するフレームワーク OSI参照モデル - Wikipedia OSI モデルとは何ですか? - 7 OSI レイヤーの説明 - AWS

リバースプロキシ

#API Architecture #Network 外部トラフィックに対して単一のサーバーへルーティングを行い、サーバーの保護や負荷分散を行う役割

Docker

RPC

Remote Procedure Call #Network #API Architecture リモート上のリクエスト発行をプログラミング言語の関数呼び出しのように利用できるよう抽象化したもの。 ただし実際に関数呼び出しと同等に利用できるわけではなく、ネットワーク上の様々な不測の事態を考慮する必要がある。

Robert C. Martin

BDD

Behavier Driven Development #Testing #TDD サイクルとなるプロセスとして3項目存在する 発見（Discovery） 定式化（Formulation） 自動化（Automation） 参考スライドは以下 Discovery and Formulation: Story Mapping, Example Mapping and Scenario Writing

和田卓人

カナリアリリース

Canary Release #Continuous Delivery リリース時に旧環境と新環境を同時に稼働させ、一部のユーザーに絞って新環境を限定公開し徐々に移行していくことでパフォーマンス劣化等の問題がないかをテストするリリース手法 ブルーグリーン戦略との違いはトラフィックを徐々に切り替える点 Canary Release

TCP

Transmission Control Protocol #Network OSI参照モデルにおけるトランスポート層にあたる通信プロトコル エンドデバイス間でコネクションを確立することで信頼性を向上させる データ送信は複数のパケットをシーケンス番号とともに送信し、パケットロスがないよう再送制御がされる

Pod

サービスメッシュ

#Network #Observability #Security #API Architecture マイクロサービスで行われるようなサービス間通信をルーティング、監視、保護する機能を提供する Kubernetesにおいてはクラスタ単位でサービスメッシュを構築する サービスメッシュはクラスタ内の全てのサービス間通信を制御するコントロールプレーンとコントロールプレーンで指定された作業が実行されるデータプレーン（サービス）の2つの基本要素を持つ。

チームトポロジー

#Team Organization コンウェイの法則を中心に据えた適応型の組織設計モデル。DevOpsとも深く関連がある チームファーストな考え方で以下の4つのチームタイプを説明している ストリームアラインドチーム プラットフォームチーム イネイブリングチーム コンプリケイテッド・サブシステムチーム 最も中心となるのはストリームアラインドチーム それぞれのチーム間の関係性に関して3つのインタラクションモードが説明されている コラボレーション X-as-a-Service ファシリテーション

gRPC

レートリミット

#Security #API Architecture 以下のような目的でAPIの使用回数を制限する、制限を超過した時はHTTPの場合一般に429エラーを返す処理 STRIDEにあるようなDenial of Service（サービス拒否）からアプリケーションを保護する カスケード障害の可能性を制限する リソースの使用量を測定し従量課金に利用できる レートリミットの実装アルゴリズムには以下のようなものがある 固定ウインドウ（Fixed window） 固定期間内の制限 スライディングウインドウ（Sliding window） 直近の期間内の制限 トークンバケット方式（Token bucket） 総リクエスト数（トークンのバケツ）を定義しリクエストごとにトークンが利用される。バケツは定期的に充填される リーキーバケット方式（Leaky bucket） リクエストが処理される速度は固定で、バケツから溢れ出るリクエストを漏れ（リーキー）として扱う APIゲートウェイを利用している場合、ゲートウェイに配置するとよい

コンウェイの法則

#Team Organization 原文は以下 システムを設計する組織は、そのコミュニケーション構造をそっくりまねた構造の設計を生み出してしまう Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure. Conway’s Law

Open API

XP

エクストリームプログラミング #Agile

サーキットブレーカー

#Reliability アプリケーションが失敗する可能性のある操作を繰り返し試行するのを防ぐ信頼性パターン サーキット ブレーカー パターン - Azure Architecture Center

TLS

Transport Layer Security #Network #Security #HTTP HTTPSへの対応に用いられる暗号化プロトコル ネットワーク通信時にTLSハンドシェイクによって鍵交換を行いセキュアな通信を行う

Kent Beck

ストラングラーフィグアプリケーション

StranglerFigApplication #Continuous Integration Martin Fowlerによる理論。既存のシステムを置き換える際、既存のシステムの周辺に新規のシステムを追加していき段階的に置き換える。 イチジクの成長段階に似ていることからFigの命名を含んでいる。 原文はこちら

風間裕也

コントラクトテスト

Contract Testing #Testing API提供者とAPI利用者間のやり取りの定義をコントラクトとして扱い、スタブサーバ等を用意することで各システムが独立してテストできるようになるテスト手法。依存するシステムが増えうるマイクロサービスの文脈で適用されることが多い 全てのシステムを統合するE2Eテストと異なりテストの実行が軽量でありメンテナンス容易であるといった利点を持つ What is Contract Testing & How is it Used? | Pactflow

Tom DeMarco

#Person

JWT

JSON Web Token #Security トークン自体の情報（例: 期限）を自身で構造化して保持することで、共有データベースへ保持・検索をする必要がないトークン。トークンが自身の情報を持つことで外部からのトークン取り消しのような操作はできない JWTは.によって3つのセクションの文字列に分割できる（署名がない場合3つ目のセクションは空） それぞれのセクションの文字列は構造化されたJSONをBase64URLエンコードした結果となっている ヘッダー 1つ目のセクションはヘッダーとして以下のような構造を持つ { "typ": "JWT", "alg": "RSA256" } algで指定する署名アルゴリズムは3つ目の署名セクションの解読にて用いる ペイロード 2つ目のセクションはトークン自体のペイロードになる。ペイロードの中身はJSONであれば自由だが、JWTクレームと呼ばれる役割が明示・明示された項目群が存在する。 例として　iss（発行者）、sub（対象者）、exp（有効期限）などがある 署名 3つ目のセクションはHMACやRSAのような署名アルゴリズムを使った結果が保持される RFC 7519 - JSON Web Token (JWT)

ブルーグリーン戦略

#Continuous Delivery リリース時に旧環境と新環境を同時に稼働させ、リバースプロキシ/ロードバランシング/APIゲートウェイ相当のポイントで旧環境から新環境へ完全に切り替えるリリース手法 旧環境をブルー、新環境をグリーンとする

Envoy

クロスファンクショナルチーム

#Team Organization 名前の通り職能横断型で自己組織化されたチーム

Swarming

#Agile #Team Organization 重要な領域または主要な活動に焦点を置いてチームのエネルギーを集中させる。バックログに課題を積むのは最後の手段である。 障害にチームメンバー複数人で集中して対処するイメージを日々のスプリントにも適用していく。 Agile Teams Swarm to Greatness スワーミングがアジャイルチームを助ける ハイインテグリティコミットメントを実現するスクラム開発の進化

OAuth2

#Security #API Architecture RFC6749によって定義された認可フレームワーク 主に以下の定義を利用する リソースオーナー（Resource Owner） 保護されたリソースへのアクセス許可を行うエンドユーザー リソースサーバー（Resource Server） 保護されたリソースを所有するサーバー、アクセストークンを受け取り検証する クライアント（Client） リソースオーナーによる認可の委譲先、アクセストークンを使ってリソースサーバーへリクエスト可能 認可サーバー（Authorization Server） リソースオーナーの認証・アクセス許可時に認可グランドを返却したのち、クライアントにアクセストークンを発行する 初回アクセストークン利用までのプロトコルの流れは以下 Protocol Flow リソースオーナーによるアクセス許可時に認可サーバーが返す認可グランドは、認可コードが利用されることが多い RFC 6749 - The OAuth 2.0 Authorization Framework

Agile Testing

#Agile #DevOps #Testing

ACID

#Database トランザクションが保証する安全性について以下の4つの頭文字を取ったもの 原子性（Atomicity） 一貫性（Consistency） 分離性（Isolation） 永続性（Durability）