HOME > BLOG > 初心者から見たマイクロサービスとdocker/k8sの関係
作成: 更新:

初心者から見たマイクロサービスとdocker/k8sの関係

LINE
この記事は最終更新日から1年以上が経過しています。この記事は最終更新日から21か月以上が経過しています。
このエントリーは約5分で読めます。
dockerkubernetescontainermicroservices

  • マイクロサービス
  • docker
  • k8s

上記初心者が、どんな事例で↑使えるのか気になってまとめた備忘録。
※インプットが2018/12時点のものなので、都度修正していきます。

マイクロサービスとは

  • 2014年にシステム開発のベストプラクティスとして発生
    • 効率的な運用方法の提案
    • ベストプラクティスとしてあるが、原則ベースではない、提案ベースの単語

マイクロサービスのメリット

  • モノリシックではなく、用途・目的別にモジュール分割する
    • モジュールが小さいので、必要なサービス毎のスケールアウトが可能
    • モジュールの影響範囲が少ないので、変更が局所的にかけやすい
    • 開発者ごとにモジュールを用意でき、コミュニケーションコスト減る

マイクロサービスの課題

  • 時間とともに複雑になる
    • どうやって管理していく？

マイクロサービスの事例

  • ポケモンGO
  • GitHub
  • Google
  • etc..

なぜ今containerに注目？

containerとは

  • ハードウェア/OSレベルで分離されている空間
    • dockerに限らない、VMWareも同じくくり

過去の物流から見るcontainer(container導入以前)

  • 大量の作業員が手渡しで船に積み下ろし
    • 属人化が物流における最大のボトルネック

過去の物流から見るcontainer(container導入後)

  • 海陸一貫輸送を発明(マルコム・マクリーン)
    • スタートからエンドまで、containerで移動
    • container移動は「フォークリフト」に任せられるように
    • 最大のボトルネック「属人化」が解消された

ITで見るcontainer(container導入以前)

  • オンプレ運用が基本
    • デリバリ(デプロイ、テスト...)が1環境
      • 開発者・運用者が環境奪い合い
      • 既存環境にマージ、コンフリクトの怖さ
    • ITIL準拠の手順書を用意した結果↑に。。。

ITで見るcontainer(container導入後)

  • クラウド・container運用
    • デリバリがn環境
      • 開発者間のコンフリクト可能性減
      • テストも別環境
      • 開発者毎に開発環境の用意可能
      • 本番環境と開発環境の冪等性が担保されてて、開発コスト減

まとめ

  • 基本的にcontainer採用がマイクロサービス実現にはベスト

docker

  • Linuxのcontainer環境において、現時点のデファクトスタンダート
  • engine
    • containerを動かす環境
    • Linux上のカーネルで動作
    • カーネル依存のため、ディストリによる環境差異を教授しない→どのLinuxでも同じく動く
  • image
    • containerを作成する上で必要な型
  • container
    • imageから作成された、実働環境

メリット

  • リソース効率がいい
    • ホストOSのカーネルを共有
      • engine上でcontainerを動かす
  • ポータビリティがある
    • engineさえあれば、どんなcontainerでも動く
    • 開発〜本番まで同じimageを横展開できる
  • containerの起動が早い

デメリット

  • engineのスコープはマシン内。マシンの外は関心外
    • n個のマシンが存在するのが主な運用。マシン間とのコミュニケーションはどうする？
  • ◇耐障害性
    • マシン死んだら、載ってるcontainerはもちろん全滅
    • マシン死んだら、どうする？
  • ◇運用性
    • containerをどのマシンで動かす
    • containerと通信する場合は、相手のcontainerをどう知ればいい？
  • ◇スケール性
    • 負荷に応じてマシン台数を増やしたい(スケールアウト)場合
    • マシン間の同containerをロードバランシングしたい場合

k8s(ケイツって読むらしい。)

  • docker環境管理のデファクトスタンダート
  • オーケストレーションツール
    • 指揮者(k8s)が演奏者(マシン)を操作する
  • pod
    • docker-containerのこと
    • n個のdocker-containerで構成
  • node
    • podを集約する単位
    • n個のpodが存在
    • リソースごとに存在する
  • クラスタ
    • nodeを集約する単位
    • n個のnodeが存在
    • nリソースにまたがる
  • コントロールプレーン
    • k8sが動作する環境
    • マスタnodeが存在するのはここ
  • データプレーン
    • マスタnodeからコピーしたnodeを動作する環境
    • 実際の運用時、エンドユーザにサービス提供するのはここ
  • Service
    • podのフロント(名前解決、ロードバランス)を担当
  • Deployment
    • podの操作を担当

メリット

  • 詳しくはhttps://kubernetes.io/ja/docs/concepts/overview/what-is-kubernetes/
  • あるpodに問題発生したら、他nodeにある同podを切り替え可能
  • あるnodeに問題発生したら、他nodeにある同podに切り替え可能
  • pod毎にIPを割り振りしてくれる
    • 深堀
  • podの自動ロールアウト契機の設定ができる
    • ユーザのセッションを維持したまま、podのver変更が可能！
    • podの更新に、サーバ全体の停止が不要！
      • 例：UTC9時にアクセス数XXXだったら、YYYpodをn個停止
      • 例：podデプロイ後healthcheckNGなら、一つ前のverのpodを起動
  • デファクトスタンダート＝情報一番多い

docker/k8sこと始め

  • dockerはcontainer化、k8sはcontainer運用だけ
    • セキュリティ担保、docker/k8s設定のバージョン管理、devOpsは3rd.OSSで実現する必要性
    • ↑の前提知識が必要なため、導入コストが高い
  • IaaS,SaaSを活用！
    • フルマネージド環境がはじめやすい
      • GKS(Google),EKS(aws)...
    • k8s/docker運用のためのサービス
      • dockerhub,github,github-actions, circleci...
    • dockerhubに関しては、脆弱性多いimageが多い
      • 使うなら、3rd.containerスキャンサービスを使って担保するべき
      • ゼロから使うより、↑使ったほうがコスト減

↓をインプットとさせていただきました。※動画です

日本アイ・ビー・エム株式会社 戸倉 彩 氏の「Docker & Kubernetes入門 – (1) 概要編」