2024-03-08

kubernetes 入門

技術書の備忘録を記録

k8s クラスタ
- k8s のさまざまなリソースを管理する集合体
Node
- クラスタが持つリソースで最も大きな概念。Docker コンテナのホスト。k8s でコンテナをデプロイするために利用される
- k8s クラスタには全体を管理する Master が一つは配置される。クラスタには Master Node と Node が存在する
Master を構成する管理コンポーネント
- kube-apiserver
  - k8s API を公開するコンポーネント。kubectl からのリソース操作を受け付ける
- etcd
  - キーバリューストア
- kube-scheduler
  - Node を監視し、コンテナを配置する最適な Node を選択する
- kube-controller-manager
  - リソースを制御するコントローラーを実行する
Namespace
- クラスタの中に入れ子となる仮想的なクラスタを作成するための概念
Pod
- コンテナの集合体の単位。少なくとも一つのコンテナを持つ。同一 Pod 内のコンテナは、全て同一の Node に配置される
ReplicaSet
- 同じ Pod を複数生成、管理するためのリソース
- 指定された Pod 数の確保や新しいバージョンへの Pod の入れ替え、以前のバージョンへの Pod のロールバックといった重要な役割を担う
Deployment
- アプリケーションのデプロイの基本単位となるリソース。ReplicaSet は同一仕様の Pod を管理・制御するためのリソースで、Deployment は ReplicaSet を管理・操作するために提供されているリソース
Service
- k8s クラスタにおいて Pod の集合（主に ReplicaSet）に対する経路やサービスディスカバリ（APIへの接続先が動的に変わる際に、クライアントは接続先を切り替えることなく一貫した名前でアクセスできるようにした仕組み）を提供するためのリソース。
ClusterIP Service
- デフォルトで作成される Service が ClusterIP Service。クラスタ上の内部 IP アドレスに Service を公開できる。ある Pod から別の Pod 群へのアクセスは Service を介して行うことが可能。外からのリーチは不可
NodePort Service
- クラスタ外からアクセスできる Service。非マネージドで k8s を運用する場合、Master が単一障害点にならないよう、マルチ Master で3台配置するのが一般的
Ingress
- 外部からのアクセスを制御し、クラスター内のサービスにルーティングするためのリソース。HTTP や HTTPS リクエストを適切なサービスに転送する。外部からのアクセスを一元的に管理することが可能

参考 Docker/Kubernetes 実践コンテナ開発入門

2023-08-29

Docker復習 Dockerfileからイメージを生成しコンテナを起動

以下、備忘録。

Dockerfile作成

# Ubuntuベースイメージを指定
FROM ubuntu:latest

# パッケージの更新とhttpdのインストール
RUN apt-get update && \
    apt-get install -y apache2

# コンテナが起動したときに実行されるコマンドを指定
CMD ["apache2ctl", "-D", "FOREGROUND"]

Dockerfileからイメージ生成

docker build -t sample:01 ./ -f Dockerfile

コンテナの起動

# host OSの8900ポートを指定
docker run -d -p 8900:80 sample:01

CMDとENTRYPOINTはコンテナ起動時の挙動に違いがある。CMDで指定したコマンドは docker run 実行時にコマンドを指定した場合にそれで上書きされるが、ENTRYPOINTだとコンテナ起動時に常に実行される。

2023-08-24

Docker イメージに関して復習

以下、備忘録。

Dockerイメージは複数のレイヤーから構成されている。レイヤーとは、イメージ内の変更や操作を表現するためのスナップショット。Dockerイメージ構築の際、ファイルの追加やコマンドの実行といった操作は新しいレイヤーとして保存される。各レイヤーは個別にキャッシュされるため、同じ操作を行う場合はキャッシュから再利用される。結果、重複する操作が最小限に抑えられ、ビルドの高速化につながる。
docker history コマンドでイメージの履歴情報を確認可能。各レイヤーが作成された際に実行されたコマンドを確認可能。
DockerのRUNコマンドはベースイメージに対して操作を行う。RUNコマンドは新しいレイヤーを作成し、そのレイヤー上でコマンドを実行する。ベースイメージは変更されず、新しいレイヤーに変更内容が追加される。
RUNコマンドではShell形式での記述とExec形式での記述が可能だが、Exec形式を利用するとシェルを介さずに実行できるので余分なプロセスを発生させずに済む。

# Dockerfile

# Shell形式
RUN echo hello
# Exec形式
RUN ["echo","hello"]

RUNはイメージを作成するために実行するコマンド。イメージから生成したコンテナでコマンドを実行するには、CMDを利用する。

参考

プログラマのためのDocker教科書インフラの基礎知識＆コードによる環境構築の自動化電子書籍（WINGSプロジェクト阿佐志保山田祥寛）｜翔泳社の本

2023-04-10

Docker/Kubernetes 実践コンテナ開発入門第１章を読んで

以下、本書に記載のあった点で覚えておきたいことを備忘録としてメモ。改めてDockerの基礎をインプットするのに良い章だった

ホスト型仮想化技術では仮想化ソフトウェアによってコンピュータリソースを抽象化して再現する分時間がかかるので、コンテナ型仮想化技術のDockerの方がマシンを迅速に起動できる
Docker利用の意義
- 不変な実行環境による冪等性の確保
- 実行環境構築とアプリケーション構成のコード化
- 実行環境とアプリケーションの一体化によるポータビリティ性の向上
- システムを構成するアプリケーションやミドルウェアの構成管理の容易さ
不変な実行環境による冪等性の確保
- アプリケーションはOSやメモリ、コンピュータリソース、言語ランタイム、ライブラリ等さまざまな要素に依存しているが、Dockerではアプリケーションが依存する環境差異によって発生するトラブルを回避することが可能
- Dockerfileによって構成を管理するのでInfrastructure as Codeが実現され、構成をコード管理可能
- OS部分の多くをホストOSと共有している分起動までの開始時間が短いので、インフラに更新があった際に既存のものを更新するのではなく破棄して作り直すImmutable Infrastructureと相性が良い。既存のコンテナを高速に破棄して作成し直すことが可能
アプリケーションとインフラがセットで構築される
- インフラの再現とアプリケーションのデプロイが完全に分離されていると、環境の差異を生み出す温床になる。DockerコンテナはOS（インフラ）とアプリケーションを同梱した箱のようなものなので、アプリケーションとインフラがセットになる
Docker Compose
- 複数コンテナを利用したアプリケーションの管理をしやすくする
- 依存関係を定義して起動順を制御できたりする

2023-03-07

オブザーバビリティ・エンジニアリング第２章「オブザーバビリティとモニタリングにおけるデバッグ方法の違い」を読んで

モニタリングは既知のバグに関してデバッグしたい場合は有効だが、未知の不具合では十分に機能しない、ということをこの章では読み取った。下記、読んで覚えておきたいことのメモ。

従来のモニタリングツール
- システムの状態をしきい値と照合し、過去に発生したエラーの状態が存在するか否かを示すことで機能する。リアクティブ（反応的）なアプローチであり、過去に発生した不具合を特定する場合にのみ有効
メトリクス
- 特定の時間感覚における記録されたシステムの状態を、数値で表したもの
- しきい値の設定は人間の判断による
ダッシュボード
- デバッグで新しい問題を発見するのには向いてない
- 探すべきだと把握してないものを見つけることができない
最高のデバッガーが、チームに一番長く勤める人になってないか
- システムに関する知識のほとんどが、ツールのような方法からではなく、個人の実地体験からだけ得られていることを示す致命的な兆し
モニタリング
- 既知の問題や以前特定されたパターンを検知するのには最適な、リアクティブなアプローチ
- 直感や勘を大切にするリアクティブなモニタリングベースのアプローチは、確証バイアスによって問題の本当の原因を見えなくしてしまう傾向がある
- 問題が発見された場合、そのパターンが以前発生した問題とどれくらい似ているかということに基づいて判断される
オブザーバビリティがある場合
- 問題がどこでどのように発生しているか、最初に予測する必要がない
組織的知識
- 人によって把握の度合いに偏りがある、不文律の情報
- モニタリングベースのアプローチでは、デバッグが以前から知られていたパターンを解析した経験に基づいて行われるので、チームに最も長く勤めている開発者が最高のデバッガーになりがち
- オブザーバビリティでは、根本的に違う方向に向かう
- オブザーバビリティでは最高のデバッガーは、最も好奇心旺盛なエンジニア
- オブザーバビリティとはあるシステムに関する深い知識で調査上の直感を与えるのではなく、異なるシステム間で通用する熟練した調査能力を評価すること

2023-02-24

マイクロサービス・パターンの「イベントソーシングを使ったビジネスロジックの開発」を読んで

イベントソーシングに関して復習したく、過去に読んだマイクロサービス・パターンのChapter6を復習。下記、読んで覚えておきたいことのメモ。イベントソーシング、正直難しい。。イベントソーシングを適用した実装パターンのイメージがまだ曖昧で輪郭をぼんやりとしか捉えられてないので、他のリファレンス等も参照して学びを深めたい。

イベントソーシング
- イベントを中心に据えてビジネスロジックを書き、ドメインオブジェクトを永続化するアプローチ。アグリゲート（境界の範囲内にあるドメインオブジェクトの集合）に対する全ての変更履歴が保持される
- イベントソーシングはアグリゲートが更新、作成された時に必ずイベントがパブリッシュされることを保証する
- 個々のイベントはアグリゲートの状態変更を表す
従来の永続化が抱える問題点
- 従来の永続化では、クラス（アグリゲート）をデータベースのテーブルに、クラスのフィールドをテーブルのカラムに、クラスのインスタンスをテーブルのレコードにマッピングする
- 上記のデメリット
  - アグリゲートの現在の状態しか格納しないので、履歴が失われる
  - ドメインイベント（アグリゲートの状態が変わった時に、アグリゲートがパブリッシュするイベント）のパブリッシュをサポートしないので、イベント生成ロジックを後付けで実装する必要がある
イベントソーシングの概要
- イベントという形でアグリゲートを永続化し、それらのイベントからアグリゲートの現在の状態を再構築する　　　　
- 個々のイベントがアグリゲートの状態変更を表す
- データベースにイベントのシーケンスという形で個々のアグリゲートを永続化し、それをイベントストアと呼ぶ
- アプリケーションはアグリゲートを作成、更新した時にアグリゲートが生成したイベントをEVENTSテーブルに格納する
楽観的ロックを使った同時更新
- 複数のリクエストが同じアグリゲートを更新しようとするパターンがある
- 従来の方法では他のトランザクションによる上書きを防ぐため、楽観的ロックを使用する
- イベントソーシングでも楽観的ロックが使用可能
- アグリゲートが更新されるたびにバージョンを更新し、アグリゲートを読み取ってバージョンに対して変更がない場合のみUPDATEに成功する。二つのトランザクションが同じアグリゲートを読み取った場合、先にアグリゲートを更新した方が成功する
メッセージコンシューマを開発するときに大切なこと
- メッセージブローカーは同じメッセージを複数回送ってくる可能性があるので、イベント消費時の処理をべき等にする必要がある
- 処理したメッセージのIDをprocessed_messagesに格納する。メッセージのIDが既にある場合、そのメッセージは重複分であり、捨てると判断できる

Chris Richardson　著/長尾高弘　訳/橂澤広亨　監修マイクロサービスパターン[実践的システムデザインのためのコード解説] (impress top gear)（インプレス発行 978-4295008583）　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

2023-02-23

オブザーバビリティ・エンジニアリングを読み出した

本を読んで学んだことのメモ。序文から一章まで。深い見識がないと、単純なトピックでラベル化されカプセル化され、本質を理解できないと書いてあった（耳が痛い。。）だからこそ、ソフトウェアシステムにおけるオブザーバビリティに対する正しい理解が大事。遭遇するシステムの不具合が、過去に発生した不具合の類型であるならば、従来のモニタリングといったアプローチで充分だった。システムが複雑化してきて従来のアプローチでは不十分になり、オブザーバビリティが注目されるようになったのだなと読み取った。システムが単純でありどこに問題があるか推測しやすいものであれば、モニタリングで充分と書いてあった。

オブザーバビリティをモニタリングやシステムテレメトリーの同義語として扱うのは誤認。継続的な開発を支援する手法を採用した場合にのみ効果的に利用できるので、オブザーバビリティのシステムへの導入は技術的課題であり文化的課題
一章の内容
- オブザーバビリティの意味
- オブザーバビリティを備えているか判断する方法
- オブザーバビリティが必要な理由
- 他のアプローチでは対処が不可能だった問題に関してオブザーバビリティが対応できるか
ソフトウェアシステムのオブザーバビリティ
- オブザーバビリティという単語は昔から存在するが、ソフトウェアシステムへの適用は比較的新たな用例
- システムがどのような状態になったとしても、どれだけ理解し説明できるかを示す尺度
オブザーバビリティがある状態
- 新しいコードのデプロイの必要が発生せずに、どんな状態になっても理解できる
オブザーバビリティを実現するには
- 効果的なデバッグに必要なデータを収集するための考え方を、進化させる必要がある
なぜオブザーバビリティが重要？
- 従来のモニタリングによるアプローチが不十分になってきた
  - モニタリングで見ることができるのは既知の障害
  - モニタリングは過去に異常と判断したしきい値を上回るか下回るかを検知するのに役立つが、そのような異常が起こりうるか分からない状態では活用するのが難しい
- メトリクスとモニタリングで不十分な理由
  - メトリクスやモニタリングベースのツールはある前提に基づいて構築されているため
    - アプリケーションはモノリス
    - データベースは一つ
    - CPUロードアベレージなど、多くの低レベルのシステムメトリクスが利用可能
    - エンジニアがシステムを調べるのは、問題発生後
- 上記の前提が、現代のシステムには不十分である
  - 多くのサービスがある
  - 複数のデータベースやストレージシステムがある
  - インフラストラクチャは動的であり、キャパシティが増減する
  - 遠く離れた疎結合のサービスが複数管理されており、自分の管理下にない
  - 問題が発生する前に早期に発見する必要がある
現代のシステムの例
- コンテナ化
- コンテナ・オーケストレーション・プラットフォームの台頭
- マイクロサービスへのシフト
- さまざまなデータ永続化方式の普及
- サービスメッシュの導入
レジリエンシーとは
- システムが障害の影響を最小限に抑え、いかに元の状態に素早く戻るかという能力のこと
オブザーバビリティを用いたデバッグ
- そのアクションが起こった時に何が起きていたかという深いコンテキストからスタートする
- オブザーバビリティを用いたデバッグでは与えられたリクエストの周りのコンテキストをできるだけ多く保持し、未知の障害に繋がったバグを起こした環境や状況を再構築できるようになる。モニタリングは既知の未知を扱うが、オブザーバビリティは未知の未知を扱う
改めてオブザーバビリティとは
- システムの任意の状態に対して、未知の事象だったとしても、新たなコードのリリースなしにシステムの内部状態を理解して説明できることを意味する
データベースにおけるカーディナリティ
- データの値の一意性を表す
- 高いカーディナリティは、ユニークな値を多く含んでいることを意味する
- メトリクスベースのツールはカーディナリティの低いディメンションしか扱えない
ディメンション
- データ内のキーの数を意味する
- データのディメンションが高ければ高いほど、システムの隠れた動作や捉えづらいパターンを認識できる可能性が高まる
制約の無いやり方でシステムを探索できる能力は、オブザーバビリティを備えるシステムの重要な機能

Charity Majors、Liz Fong-Jones、George Miranda　著、大谷和紀、山口能迪　訳オブザーバビリティ・エンジニアリング（オライリー・ジャパン発行 978-4-8144-0012-6）

scent-yのブログ

学んだことや感じたことの備忘録