Kush's Wiki

Cloud Native (34)

Observability (29)

Team Organization (26)

Software Design (25)

Data Store (25)

API Architecture (25)

Programming (23)

Continuous Delivery (17)

Continuous Integration (16)

Sort by - linked count

#Software Design DDDにおいて不変条件を適用するエンティティや値オブジェクトのようなオブジェクトのグループ単位原文は以下エンティティと値オブジェクトを集約の中にまとめ、各集約の周囲に境界を定義すること。各集約に対してルートとなるエンティティを1つ選び、境界の内部に存在するオブジェクトへのアクセスはそのルートを経由して制御すること。外部のオブジェクトが参照を保持できるのは、ルートのみとすること。内部のメンバに対する一時的な参照を渡してよいのは、単一の操作で使用する時だけだ。ルートがアクセスを制御するので、内部が知らないうちに変更されることはなくなる。この取り決めにより、どんな状態変化においても、集約内にあるオブジェクトと集約全体に対して、不変条件をすべて強制することが現実的になる。 Eric Evans | エリック・エヴァンスのドメイン駆動設計 | P127

#Software Design DDDにおいて同一性を持つオブジェクトの呼び名原文は以下オブジェクトの中には、主要な定義が属性によってなされないものもある。そういうオブジェクトは同一性のつながりを表現するのであり、その同一性は、時間が経っても、異なるかたちで表現されても変わらない。そういうオブジェクトは属性が異なっていても、他のオブジェクトと一致しなければならないことがある。また、あるオブジェクトは、同じ属性を持っていたとしても、他のオブジェクトと区別しなければならない。同一性を取り違えるとデータの破損につながりかねない。 Eric Evans | エリック・エヴァンスのドメイン駆動設計 | P89

Testing文脈のBDD サイクルとなるプロセスとして3項目存在する発見（Discovery）定式化（Formulation）自動化（Automation）

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

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

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

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

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

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

#Software Design #Team Organization コンウェイの法則に対して、開発チームの組織構造を変更して、望ましいソフトウェア設計を目指すという考え方マイクロサービスが注目されるようになった2015年頃にコンウェイの法則が再評価され生まれた

#Continuous Delivery #Team Organization チームトポロジーにおける4つのチームタイプの中で中心となるチームビジネス価値を提供するフロー（ストリーム）に従って、クロスファンクショナルチームを形成する要求の探索から本番環境の運用までの全ての能力を備え、他のチームを待たずにデリバリーができる

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

CNCFによるObservabilityに関する文書 tag-observability/whitepaper.md at main · cncf/tag-observability

#Observability ログ、分散トレース、メトリクスのようなシステムの状態に関するデータ Datadogのようなオブザーバビリティソリューションに送信される

#Reliability ネットワーク接続先からのレスポンスが失敗している場合、すぐにあるいは少し時間を置いてからアクティビティを再度実行する信頼性パターンバックオフ戦略としてExponential backoffのようなパターンがある Retry with backoff pattern - AWS Prescriptive Guidance

#Cloud Native 1つのPod内で複数のコンテナを定義し、メインアプリケーションコンテナとそれを拡張するSidecarコンテナのような関係性を持たせるパターン

#Programming Rust Programming Language

概念的な同一性を持たないオブジェクト DDDにおけるモデル要素の一つ以下、参考あるモデル要素について、その属性しか関心の対象とならないのであれば、その要素を値オブジェクトとして分類すること。値オブジェクトに、自分が伝える属性の意味を表現させ、関係した機能を与えること。値オブジェクトを不変なものとして扱うこと。同一性を与えず、エンティティを維持するために必要となる複雑な設計を避けること。 Eric Evans | DDD | P97

#Documentation #Software Design DDDにおいて、ドメインエキスパートと開発者、またその周辺のステークホルダーが共有する言語以下、原著から抽出モデルを言語の骨格として使用すること。チーム内のすべてのコミュニケーションとコードにおいて、その言語を厳格に用いることを、チームに約束させること。図やドキュメント、そして何より会話の中では同一の言語を使用すること。ドメインエキスパートは、ドメインについての理解を伝えるには使いにくかったり不適切だったりする用語や構造に異議を唱えるべきであり、開発者は、設計を妨害することになるあいまいさや不整合に目を光らせるべきである。 Eric Evans | エリック・エヴァンスのドメイン駆動設計 | P26-27 また同一の単語でも異なるユビキタス言語として定義するケースもあり、境界づけられたコンテキストを明示にした上で、どのコンテキストで用いる言語なのかを決定する

#Continuous Delivery #Kubernetes Pod上で定期的に実行されるコンテナの診断、ヘルスチェックチェックの方法として以下の4つがある gRPC HTTP TCP Socket Exec 任意のコマンドを実行し、成功の返り値0を期待する Probeには戦略を示すようないくつかの種類が存在する Podのライフサイクル | Kubernetes

Service level objectives #Reliability サービスレベル目標の略。サービスレベル指標(Service level indicators = SLI)に対してターゲットとする値または範囲を目標とする。サービスレベル指標に用いられるのは主に以下のようなもの可用性リクエストレイテンシエラー率システムスループットサービスレベルアグリーメント(Service level agreement = SLA)は、SLOを守るまたは守れないケースに関する規定をユーザーと同意するもの。 SLO, SLI, SLAは定義が曖昧になりやすいので注意が必要

#Agile 作業バッチサイズを最小化させるための観点の頭文字を略称にしたもの Independent Negotiable Valuable Estimable Small Testable

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

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

Role-based access control #Security #Authorization ロールごとに許可を定義する認可モデルこれによりユーザーの部署異動等の際に即座に権限を変更できる

Amazon Web Service

定期ジョブの実行頻度を表現する Cron表現方式によって実行するJobを一般にCronJobと呼ぶ cron - Wikipedia

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

開発者がサーバーの管理を気にすることなくアプリケーションの構築と実行を可能にするクラウドネイティブな開発モデル Serverless | Cloud Native Glossary

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

バージョンアップデートを段階的に行うようなデプロイメント戦略を適用した上で、デプロイ結果を分析し漸進的にデプロイの継続かまたはロールバックかを自動化するようなデリバリ手法 Continuous Deliveryの進化系として紹介されることが多い Concepts - Argo Rollouts - Kubernetes Progressive Delivery Controller

#Continuous Integration DevOps capabilitiesの1つ、Fast Flowに分類される価値提供フローの可視化、チームによる実験、顧客フィードバックの可視化と組み合わせることで高いソフトウェアデリバリパフォーマンスに寄与するバッチサイズの最小化にはINVESTの原則を用いると良い DORA | Capabilities: Working in small batches

#Continuous Integration DevOps capabilitiesの1つ、Fast Flowに分類される Working in small batchesをベースに少なくとも1日に一回はトランクブランチにマージをするテストの自動化も重要な要素となる DORA | Capabilities: Trunk-based Development

DevOps capabilitiesの1つ、Climate for Learningに分類される DORA | Capabilities: Team experimentation

#Testing DevOps capabilitiesの1つ、Fast Feedbackに分類される DORA | Capabilities: Test automation

#Team Organization チームトポロジーにて紹介される4つのチームタイプの内の1つ他のチームを技術等の知識によって支援する

prev next