コンテナを利用したWebサービス開発と実運用

はてな×さくらが考えるテクノロジーの未来〜コンテナ・分散型データセンター〜

Mar 20th, 2019

Profile

• id: Songmu (ソンムー)
• Masayuki Matsuki / 松木雅幸
• おそらくはそれさえも平凡な日々 http://www.songmu.jp/riji/
• https://metacpan.org/author/SONGMU
• はてな東京オフィス チーフエンジニア
• Mackerel プロダクトマネージャー
• 60+ CPAN Modules
• 3 Times ISUCON Winner Using Perl
• YAPC::Tokyo 2019 ベストスピーカー
• 最近はGoが好き

Mackerel

Mackerel

• はてな謹製のサーバー・クラウド管理・監視SaaS
• 小規模から大規模システムまで
• ユーザー登録から3分でサーバー監視が可能
• 専属UI/UXデザイナーによる圧倒的な使い勝手
• 200週連続機能リリース達成

【宣伝】書籍発売中

【宣伝】みんなのGo言語

【宣伝】入門 監視

• 空前の監視ブーム
• 付録Cを執筆しました
• タイトルが不穏だという噂も
• なんかめっちゃ売れてるみたいです
  • いい本です

コンテナは20世紀最大の発明

• リアルコンテナの話
  • 書籍「コンテナ物語」
• 物流をコンピューターで制御するように
• 箱ではなくて「システム」である
• コンテナリゼーションの影響
  • ニューヨーク港の衰退
  • 日本の輸出の発展
    • トヨタ式「ジャスト・イン・タイム」の実現

Linux Container

• Dockerの登場によって一躍脚光を浴びた
• まずはテストやCIで活用が始まった
• 今や本番環境でもバンバン使われ始めている

コンテナが実現すること

• 隔離性 (isolation)
  • 他から影響を受けない独立性の高いコンポーネントの実現
• 可搬性 (portability)
  • 多くの場所にdeploy可能

「コンテナイメージ」によりベンダーがミドルウェアの配布も容易に

コンテナが必要とされた背景

Infrastructure as Code (IaC) やクラウド黎明期で主にVMを使っていた頃のこれらの用語は聞かれなくなった。

• Immutable Infrastructure
• Disposable Infrastructure

冪等性幻想

• 冪等性の担保は困難
  • パッケージのバージョンロックの難しさ
  • リソースの削除の再現の難しさ
  • そもそも担保の実装の難しさ
    • cookbook-mackerel-agent / ansible-role-mackerel-agent
• blue green志向へ

コンテナが持つ制約を逆手に活用する

制約とも言える以下の特徴をデフォルトで持っている

• Immutable: 不変性
• Disposable: 廃棄容易性

VMからコンテナへ

• リソースをより動的に配置しやすくなった
• 頭を切り替える必要がある

twelve factor app

herokuのエンジニアにより2010年提唱されたアプリケーションが満たすべき12個の要件

• Ⅲ 設定は環境変数に持たせる
• Ⅹ 本番/開発一致
  • コードと設定の分離
• Ⅴ ビルド・リリース・実行
  • 宣言的にフェーズを切る
• Ⅵ プロセスをステートレスにする

コンテナ利用ではコードと設定の分離が必須に

• 環境変数
• サービスディスカバリ
• → Ⅲ 設定は環境変数に持たせる

動的なインフラの中でどの様に接続先を見つけるのか

• オーケストレーションに課題
• そういう意味でも「コードと設定の分離」が必要
• → Ⅹ 本番/開発一致

ワークフローの変化

• コンテナをビルドしてコンテナレジストリに配置
• それをdeploy時に取得して利用
• 手続き的プロビジョニングから宣言的オーケストレーションへ
• → Ⅴ ビルド・リリース・実行

ステートを持てない

• ディスクが揮発する前提
• 状態を持てない
• → Ⅵ プロセスをステートレスにする

オーケストレーション

輸送コストの圧縮に必要なのは単に金属製の箱なのではなく、貨物を扱う新しいシステムなのだ コンテナ物語

コンテナを適切に運用するために

• 配置や管理を適切に行うツールが必要になる
• Kubernetesに代表されるオーケストレーションツール

設定や認証情報をどこに持たせるのか

• 環境変数だけだと限界がある
• サービスディスカバリ
• Istioに代表されるサービスメッシュ

サービスメッシュ

• より動的なシステムを管理するためのフレームワーク
• 解決したい問題
  • Observability
  • Authentication
  • Encryption
  • Service Discovery
  • Load Balancing
  • Circuit breaking
• Envoyの登場により実現しやすくなった
  • Istioの登場

進化期にある

• KubernetesとIstioでだいたい趨勢は決した感じはある
• とは言え変化が早いのでクラウドベンダーが提供するソリューションに乗っかるのもあり

コンポーネント設計

コンポーネント分割

VMであってもコンテナであっても基本的な考え方は大きな違いはない

• 一つのコンポーネントを単機能につくる
  • 一つの役割だけをもたせる
  • app server/web server etc
• よりマイクロサービス的な設計はやりやすく

VMは引き算・コンテナは足し算

コンポーネントの作り方が異なる

• VMはプロセス数を絞る
  • 余計なプロセスを停止する
• コンテナは必要なコンテナを組み合わせて一つのPod/Taskをつくる

Pod/Taskをどう捉えるか

システムを構成する最小単位

• 1コンテナ=1コンポーネントではない
  • ログ・プロキシ・モニタリング、必要なものは組み合わせる
• 汎用パーツを「サイドカー」の形で横付けする
• プラクティスが固まってきた

Pod/Task

• Kubernetes: Pod
• ECS: Task

その単位でdeployが行われる

コンテナ自体の話

コンテナ自体は単なるプロセス

• Linuxの要素技術を活用して実現している
  • OSの機能を使っている
• なのでリソース効率も良い
• Dockerはそれをパッケージングしたもの
  • unshareコマンド

要素技術

• Namespace (プロセス空間やネットワークの隔離)
• cgroup (リソースの制御)
• Capability (権限管理)
• chroot/pivot_root (ファイルシステムの隔離)

「コンテナ技術入門 - 仮想化との違いを知り、要素技術を触って学ぼう」

• https://employment.en-japan.com/engineerhub/entry/2019/02/05/103000

OSの機能だからこそ限界もある

• それ自体に脆弱性があったらどうするのか
• OSの外でレイヤーを切る必要性
  • Firecracker/gVisorなどのアプローチ

単なるプロセスである明快さ

既存のUNIXスタイルをきちんと意識して踏襲しておけば良い。そこの基本的な知識が必要とされるとも言える。

• 終了コード
• 標準入出力
• 環境変数
• シグナル

【余談】すべてがコンテナになる？

• Paas,FaaS的なものも内部的にはコンテナ的な技術が活用されていく
• コンテナも隠蔽されていきコンテナ自体を「生々しく」扱うことも減っていく
  • Dockerfileでさえ生々しい

課題

コネクションプーリング

• コネクションプールはステートである
  • ステートレスにしたいが難しさがある
  • なるべく都度接続にしたいがそうもいかない
• スケールさせるとDBなどがコネクション過多になる
  • → 自律的なスケールが難しい
• →コネクション管理は汎用プロキシに任せるという解法
  • envoy

ウォームアップ

• 依存なくスケールさせたい
• クラスタへのジョイン方法を工夫する
• → Readiness Probe の活用など

BlueGreenの難しさ

• 一時的にリソースを2倍にできる状態になっているか
• Preforkモデルだとワーカーを徐々に入れ替えるパターンも
• 同様の仕組みの再発明が必要に
• 若干大掛かり感
• → 最初からそれ前提で設計する

CI/CDの待ち時間問題

LL言語の優位性が減った

状態を持つサーバーの扱い

ローカルファイルを使わずに外部サービスに任せる

• オブジェクトストレージ
• データベース
• ログコレクタ

無理せずVM as a Containerでも

• まだまだ考えないといけないことも多い

マイクロサービス時代の監視設計

従来型のアプリケーション設計

「モノリシックなWebアプリケーション」 & 「汎用ミドルウェア群(MySQL, memcached etc.)」

• 汎用的なミドルウェアに対しては、すでにある吊るしのプラグインを利用して監視設定をする
  • mackerel-plugin-mysql/memcached etc.
• Webアプリケーションに関して固有の監視を入れず、アプリケーションが動いているホストのリソース監視でカバーする

一昔のWebアプリケーションレイヤーというのは比較的薄く単純な作りであり、Webサーバーと密結合していることも多かったため、アプリケーション固有の監視を作るという発想にもあまりならなかった。

healthエンドポイントパターンの発見と命名

• 「入門 監視」
• /health/ にアクセスすることで死活監視やメトリック取得をおこなう
• Webアプリケーションの複雑化が背景

マイクロサービス時代における監視設計

• 「モノリシックなWebアプリケーション」&「汎用ミドルウェア群(MySQL, memcached etc.)」ではなくなる
  • Wev, App, Cache, DBと言った分かりやすい分かれ方にならない
  • 汎用ミドルウェアに有り物のプラグインを入れるだけでは終わらない
• サービス同士がAPIで通信する
  • 共有DBアンチパターンを避ける
  • 汎用ミドルウェアを複数箇所から生で使うのを避けて、それをラップしたAPI経由でアクセスする
• 「独自ミドルウェア」群的世界観
  • アプリケーションとミドルウェアの境界は曖昧になる

監視も同時に設計する

マイクロサービス時代にはそれぞれが独自ミドルウェア的なコンポーネント群になるのが望ましい。

• 監視を自分で考える
• 開発しながら監視設計をする
• テスト駆動開発と同じ

監視をどう設計するか

• 基本的には「不安なところ」を監視するで良い
• 具体的には？

幾つかのヒント

• The Four Golden Signals (in SRE Book)
• USE Method (Internal / for Resouces)
• RED Method (External / for Services)

The Four Golden Signals in SRE Book

SRE本

• Latency
• Traffic
• Errors
• Saturation

USE Method

http://www.brendangregg.com/usemethod.html

• Utilization - 利用率
• Saturation - 飽和
• Errors

内部の状態に着目 → ブラックボックス的
「詳解システムパフォーマンス」でも言及
UtilizationとSaturationの違い

RED Method

https://www.slideshare.net/weaveworks/monitoring-microservices

• Rate - 単位時間辺りのリクエスト割合
• Errors
• Duration - Latency

外部からの振る舞いに着目 → ホワイトボックス的

USEとRED

それぞれ補完しあうものである

• USEは内部の状態を観察するためのメソッド
• REDは外部からの振る舞いを観察するためのメソッド

USEとREDを捉えることで、Four Golden Signalsが見えてくる。

改めてThe Four Golden Signals

USEとREDが網羅されている。

• Latency - REDにおけるDuration
• Traffic - RED におけるRate
• Errors - USE/RED両方におけるエラー
• Saturation - USEにおけるUtilization/Saturation

SaturationとUtilizationを分離したほうが良いかもしれないが、おそらくホワイトボックス的なふるまい(RED)のほうが重要なのでSaturationにまとめられていると想像。

例: ある認証コンポーネント

• 監視すべきはなにか
  • 死活監視・プロセス監視だけにとどまらない
• レスポンスタイム (Latency)
• リクエスト数 (Traffic)
• エラー数・エラーレート (Errors)
  • 認証成功・失敗
  • 4xx/5xx (HTTPサーバーであれば)
  • 内部エラーログ
• 内部ワーカー・スレッドの利用状況 (Saturation)

Mackerelコンテナエージェントの話

Mackerelコンテナエージェント

• https://github.com/mackerelio/mackerel-container-agent
• Kubernetes/ECS(EC2 or Fargate)サポート
• Pod/TaskをMackerelのホストとして登録
• 「開発者自身が自律的に監視をおこなえるように」

Mackerelコンテナエージェントの特徴

• Pod/Taskをインフラ管理の最小単位として捉える
• サイドカーとして設計
• 独自の監視を入れやすい
  • 独自プラグインを用いて細かく独自のアプリケーションメトリクスを収集可能
• ロール登録することで、そのマイクロサービスの系の全体傾向が一目瞭然

ロールグラフの様子

• 退役Podのメトリックも残存

Mackerelコンテナエージェントの今後

• 「マイクロホスト」による新規課金体系
• プラグイン同梱イメージなど
• よりObservabilityを上げていけるように
  • サービスメッシュ・Prometheus連携も検討
• サービスメッシュはMackerelとも相性が良いはず
• コンテナエージェント開発者によるマニアックな話はこの次

以上