振り返り
Developers Summit 2022 で登壇しました。 CloudNativeな時代に求められるWebサービス基盤モデルの再考 - Daprについての考察と実装 というタイトルで、CloudNativeな技術と共に歩んできた中で見えてきた、CloudNativeな技術を背景に持つ分散アプリケーションランタイムであるDaprがどういったもので何ができるかを解説するのを通してCloudNativeの必要性や立ち位置について発表しました。
今回の発表でもっと喋りたいと思ったのはDapr によって Complexity は解消されるのか？に関する部分でRepositoryが何をするのかとDapr になります。実は来週もDapr での登壇イベントがあるのでRepository 周りの話と実装面の話を重点的にさせていただきたいと思います。
登壇資料
体調が悪いのに頑張って資料作りましたね。偉いです。
文字起こししておいてます。意味はないです。
- 振り返り
- 登壇資料
- 自動化とコンテナの話
- Cloud Nativeと Webサービス基盤モデルについて再考
- ComplexityとDapr の実装について
- Repository において Dapr による抽象化の理想と現実
- 参考資料
自動化とコンテナの話
Infrastructure as Document 時代
システム運用担当者がアプリケーションを配置する方法
- 人間の思考や行動をコーディングしてシステムを管理する為の秘伝のドキュメントを引き継ぐ
- 一台一台を丁寧に設定していくが出自は不明
- なぜ、動いているかも分からず、さわったら動かなくなるから秘伝のタレとなりいつか腐る
- Document はあるが更新されてないこともしばしば
Infrastructure as Code 時代
システム運用担当者がアプリケーションをコードによって配置する
- 直訳すると「コードとしてのインフラ」、「インフラをコードで記述する」こと
- さまざまな手順や前提をCodeの中で表現していくことで全てが見えてくる
- 黎明期はシステム管理の自動化がその後はソフトウェア開発プラクティスを応用するのが焦点に
約束された勝利の自動化なんてない自動化の不都合な真実
自動化も腐りやすい
最初はうまくいく
- OS やミドルウェアのバージョンを上げると死ぬ
- アプリ毎、ホスト毎に個別化、属人化やシステムの複雑化が進行
- 自動化でトラブルので手作業が多くなっていく
- 触るのが怖くなったら秘伝のタレが腐敗している合図
腐らないようにする自動化
約束されてる勝利の自動化 は実は部分的
Immutable Infrastructure
インフラを管理する手法の一つで「一度構築した本番環境には更新やパッチの提供などの変更を加えず稼働させる」 というような考え方
自動化を進めていく中で発見された素晴らしいプラクティス
- 常にクリーンインストールから開始
- 必要なものは全て固めアプリを共存させない
コンテナへの道
アプリに必要なものを全て特定のフォーマットで固めて、展開するだけで起動
- 2013年に最初にリリースされ、Docker,Inc.によって開発
- Dockerは「コンテナ」と呼ばれるソフトウェアパッケージを実行される
起動の約束された 勝利のアプリケーション
- ベースイメージをダウンロード
- 必要な各種ソフトウェアは全てコンテナ内にインストール
- 必要な設定はコンテナ作成時に仕込む
自動化とコンテナのざっくりとした関係
同じモノとして扱いやすくなる
インフラの腐敗を防止
- 運用が統一的
- 開発でテストし、そのままを運用に適用可能
- 環境の影響を受けずに自動化の負担は軽減
クラウドによるアプリケーションファースト
クラウドにより組み上げ方式から呼び出し方式へ
- 要求すれば下位のリソースが自動的に割り当たる
コンテナによって取り扱いを共通化
- アプリとインフラの依存関係を断ち切ることができる
Cloud Nativeと Webサービス基盤モデルについて再考
Service Level indicator とService Level Objective
信頼性 100%と、信頼性 99.99%では大きな違い
- 信頼性 100%を実現するためには、99.99%とは異なり膨大な工数を投入が必要
ほとんどのユーザーにとっては「99.99%」が「100%」になったからといって、
大きなメリットがあるわけではありません🥺🥺🥺
各サービスごとに適切なSLOを設定することが大事
- SLOとは、SLIで計測されるサービスレベルの目標値、または目標値の範囲を指します
- SLOを「年99.99%」と設定すると、「1年のうち52分は稼働しなくてもよい」ということになります
- しかし、シングルノード100 台でアプリを動かすと… ｱｯｱｯｱｯ
Service Level Indicator の例
- リクエストのレイテンシ（リクエストに対するレスポンスを返すまでにかかった時間）
- エラー率（受信したリクエストを正常に処理できなかった比率）
- システムスループット（単位時間あたりに処理できるリクエスト数）
- 可用性（サービスが利用できる時間の比率）
シングルノード100 台でアプリを動かすと… ｱｯｱｯｱｯ
クラウドを使ったからといって… 可用性が勝手に高まるわけではない
シングルノードでの運用について * アプリの更新は？ * サーバー自体が電源断でサービス落よね？ * 負荷が増えたらどうするの？ * アクセスが増えたらどうするの？
何らかの方法でリスクを回避せねば、その方法の一つがKubernetesであり Cloud Native となる
Cloud Native とは？
などを用いて
- 回復性
- 管理力
- 可観測性
- 堅牢な自動化によって変化に強い
疎結合なシステムを実現する
疎結合ではないシステムとは？
Availability
コンポーネントが死ぬと全体が死ぬ
Scalability
一つの機能をスケールさせるためには全体のスケールが必要
Complexity
新しい機能を追加するときに全体との調和が必要なので大変
疎結合なシステムとは？
Resilient
一つのサービスが死んでも一部のサービスは継続
Flexible Scale
サービスごとに独立してスケールリソースの最適化
Simplicity
小さな単位で開発することにより新機能の追加が容易になる
Kubernetes の特徴
不変なインフラ
一度、構築したインフラは変更を加えることなく破棄して、新しいものを構築しなおせばよい Implicit or Dynamic Grouping(入れるところないのでココに書いておきます)
宣言的設定
命令的に手順や変更履歴を記録するのではなく宣言的な設定ではシステムのあるべき姿を定義します。Kubernetesはこの定義ファイルを確認してあるべき姿に自律的に動作する Declarative Configuration
自己修復機能
Kubernetesが障害や異常があった時にあるべき姿になる為にシステムが設定した通りにAPIを再起動したり様々な作業を自動で行う Reconciliation Loopにて実現
Webサービス基盤モデルについて
サービス層
実際のWebアプリやWebサービスのコンテンツ層
ストラテジー層
Webサービスの特性に合わせてコンテナ基盤をより特徴的に制御する層
オーケストレーション層
コンテナ群や収容ホスト群のモニタリングやリソース管理等によってCRIを 介してコンテナを制御する層
コンテナランタイム層
コンテナそのものの制御層
インフラストラクチャ層
ハードウェアやVM、ベアメタル等のコンテナのリソースプールを実現する層
ストラテジー層の進化と拡大
istio
マイクロサービスアーキテクチャにおけるネットワーク面での課題を解決する機能群を提供する
Knative
モダンなサーバーレスワークロードをビルド、デプロイ、管理するためのKubernetesベースのプラットフォーム Knative など、
さまざまな用途のアプリが誕生している
ストラテジー層の拡大とDapr について
Dapr とは
- 効率的なクラウドネイティブアプリ開発を目指した 分散アプリケーションランタイム
- Dapr は サイドカーによりサービス間の呼び出し、ステート管理、サービス間メッセージングなどの非機能要件を実現する事で分散アプリケーションの実装上の課題を解決する機能群を提供するフレームワークです。
- 非機能的ではあるが本来、サービス層が持っていた 一部機能をストラテジー層が担っている。
ComplexityとDapr の実装について
Dapr とは？
Distributed Application Runtime の略
Daprの特徴
Goal
- あらゆる言語やフレームワークを使用して、分散アプリケーションを記述することが可能
- ベストプラクティスのビルディングブロックを提供することで、マイクロサービス アプリケーションの構築で開発者が直面する困難な問題を解決
- コミュニティ主導で、オープンかつベンダーニュートラルであること
- 新たな貢献者の獲得
- オープンAPIによる一貫性とポータビリティの提供
- クラウドやエッジなど、プラットフォームにとらわれない
- ベンダロックインすることなく、拡張性とプラグイン可能なコンポーネントを提供する
- 高いパフォーマンスと軽量化により、IoTやエッジのシナリオを可能にする
- 実行時に依存することなく、既存のコードからインクリメンタルに採用できる
サイドカー パターンとは？
分散システムにおけるデザインパターンの一つ
サイドカーは、アプリケーションコンテナを拡張および拡張して、機能を追加します。サイドカーを使用して既存のレガシーアプリケーションなどにも適用できます。同様に、これらを使用して、一般的な機能の実装を標準化するコンテナを作成することもできます。
Dapr におけるサイドカーアーキテクチャ
Dapr の多様性
Dapr サイドカーにより、HTTP/gRPC での通信が可能であれば 開発ができる 公式SDKも提供されている
ビルディングブロック
ビルディングブロック
- 一般的にはシステムアーキテクチャを構成する要素
- Dapr では利用可能な機能群のことを指す場合が多い
- マイクロサービスのベストプラクティスを体系化して機能として実装されてる
- サイドカーのHTTP/gRPC を呼び出してこれらを利用することができる
2022年2月で 8つのビルディングブロックが用意されている
- サービス間呼び出し
- 状態管理
- パブリッシュとサブスクライブ
- バインダー
- アクター
- 可観測性
- シークレットの管理
- 構成設定
コンポーネント
- ビルディングブロックで利用される機能モジュール
- 一つ以上の複数のコンポーネントを使用可能
- IF が用意されているのでこれらに合わせて機能を実装
- 統一されたエンドポイントが利用できるのでアプリ側に複雑性を抱え込まなくて良い
Repository において Dapr による抽象化の理想と現実
Repository とは
- DDDのレイヤードアーキテクチャで提唱されいる
- Repository でインターフェースを定義することによりInfra層を抽象化、依存性の逆転
- モックの差し替えが可能になり、Application層のユニットテストが可能になる
Dapr によるRepository の吸収しきるのか？
何を抽象化しているのか？
- Repository は、抽象化とレイヤー化を同時に行うのが一般的
- Dapr は前述したビルディングブロックと公式のSDKによってプロトコルの抽象化が可能
- 抽象化に合わせた実装を一部しなくても良いので全体の実装量はそりゃ、減る
チームでどのような実装にしていくか話し合いが必要であり、レイヤー化に関してはあまり寄与しない
Dapr によって Complexity は解消されるのか？
Complexity とは
- 認識や変更を困難にするソフトウェアの構造に関する全てのものを指します
- どれだけ実装が「複雑」でも開発者が読み書きする必要がないようになっていれば、それはComplexityとは言いません
- Proxy が担う部分はまだ、機能がまだ少ない
DaprでComplexity の解消の夢は見れるか？
- Dapr によって抽象化の一部のメリットは得られる
- Dapr でもレイヤー化するのは自分達であることを忘れずに
- MockClient みたいな話がgo-sdk でも出ればいいが 特にないので自分達で用意する必要がある
参考資料
- Dapr Docs
- Infrastructure as Codeのこれまでとこれから/Infra Study Meetup #1 より
- ふつうのLinuxプログラミング 第2版 Linuxの仕組みから学べるgccプログラミングの王道
- コンテナ時代のWebサービス基盤モデル - FastContainerの研究発表をしてきました
- 目的に沿ったDocumentation as Codeをいかにして実現していくか / PHPerKaigi 2021
- クラウドネイティブとKubernetes（だいたいあってるクラウドネイティブ）
- Designing Distributed Systems (PUBLISHED BY: O'Reilly Media, Inc.)
- ボトムアップドメイン駆動設計
- Repositoryによる抽象化の理想と現実/Ideal and reality of abstraction by Repository
- A Philosophy of Software Design
