Help us understand the problem. What is going on with this article?

Docker導入するべき?するべきではない?

More than 1 year has passed since last update.

Docker導入するべき?するべきではない?

by taishin
1 / 32

これは何?

Dockerを導入するにあたって、漠然としたイメージしかないという方も多そうなので、

  • どういうシステムに導入したらいいのか?
  • どういうシステムなら導入しないほうがいいのか?
  • 導入までにどんなことしないといけないのか?

をまとめてみました。
つっこみあればお願いします!


対象

下記のような方を対象として記載しています。

  • Docker自体はなんとなく分かったけど、自分の組織でやった方がいいのかよく分からない
  • 導入の検討しろって言われてるけど、具体的な内容まで落とせない

一般的なコンテナ(Docker)の特徴/メリット


  • パフォーマンス

    • 仮想マシンと比較すると、オーバーヘッドが少なく軽量
    • 起動が高速
  • 再現性、ポータビリティ

    • Dockerが動く環境であれば環境に依存しない
    • 1つのコマンドを実行した状態を再現
    • ホストと分離できる
  • コードで管理できるのでバージョン管理が可能

    • ロールバックが容易

メリットを活かすために必要なこと


  • アプリケーションのマイクロサービス化

    • 1サービス1コンテナ
    • 永続データの考慮
      • ステート情報
      • 共有データ
      • ログ
  • イミュータブルな環境の構築

    • CI/CDシステムの導入
      • バージョン管理システムとの連携
      • テストの自動化
      • デプロイ/ロールバック
  • オーケストレーションツールの導入

    • クラスタの管理
    • スケジューリング
    • スケーリング

他のAWSソリューションとの違い


CodeDeploy

  • OSの状態は再現できない
  • コードのみのロールバックなので、OSの変更には対応できない
    • コンテナはイメージごとロールバック

AMI運用

  • イメージの容量が大きい
    • 起動に時間がかかる
  • 変更作業の負担が大きい
    • インスタンス起動 → 変更 → イメージの保存 → インスタンスの削除
    • Dockerはコードの修正 → 再ビルド
      • CI/CDシステムがあればさらに容易

コンテナに対する誤解 (クラウドで使う場合)


  • オーバーヘッドが少ないのでパフォーマンスがいい

    • 仮想サーバとの比較であって、クラウド上で使う場合は コンテナ on 仮想サーバ になるのでオーバーヘッドは増える
  • どこでも同じ環境を再現できる

    • コンテナは環境に依存しないが、クラウドで利用する場合、LB等のクラウドサービスと組み合わせることが多いので、その違いの考慮は必要
    • 例外もある
  • 同一ホストにコンテナを相乗りさせることによに費用削減が可能

    • 1ホストを割り当てる必要がないレベルのコンテナがばかりであれば正しいが、ある程度のリソースが必要なコンテナであればトータルのリソース利用量はあまり変わらない

導入の問題点/課題


  • 構成が複雑になる
  • リソース管理/分離が難しい
  • 学習コスト
  • 組織の体制、線引
    • Dev と Ops

コンテナに向く/向かないシステム


向くシステム

  • システムの変更が活発に行われる
  • アップデート等の変更に対応していく必要がある
  • バッチ処理のために起動するシステム

向かないシステム

  • システムの変更がほとんどない
  • 長期の安定性が求められる
  • ライセンス管理、保守サポートが必要

導入のモチベーション


解決したい課題は何か?


共通インフラをつくりたい → X

  • すべてのアプリケーションがコンテナに向いているわけではない

そのまま移行したい → X

  • コンテナ化すること自体に意味はない

費用削減 → X

  • 使用するリソースは減らない

パフォーマンス向上 → ☓

  • クラウドサービス上で使う場合、コンテナ on 仮想マシンになる
  • マイクロサービス化した場合、コンテナ(サービス)間はネットワークを介するので、そのオーバーヘッドも発生する

運用負荷軽減 → △

  • 頻繁に変更が発生する場合で、CI/CD Pipelineの仕組みを適切につくれている場合は負荷の軽減は可能
  • CI/CD Pipelineの構築には試行錯誤が必要

変化への対応を容易にしたい → ◯

  • アプリケーションのアジリティを高める

導入に向けてやらないといけないこと


  • アプリケーション(再)設計

    • マイクロサービス化
    • 再実装
    • コードリポジトリの作成/導入
  • Dockerイメージの作成

    • Dockerfileの作成
    • コンテナリポジトリの作成/導入
  • インフラの設計/構築

    • オーケストレーションツールの導入
  • CI Pipelineの作成

  • 監視/運用フローの確立


AWSで利用できるDockerオーケストレーションサービス


Amazon ECS (Amazon EC2 Container Service)

  • AWS独自のオーケストレーションツール
  • 料金
    • ホスト(EC2)利用料金のみ発生
    • スポットフリート等のコスト削減に関するサービスが利用可能

AWS Fargate

  • クラスタ、ホストの管理をAWSが提供するサービス
    • ユーザー側でインフラ運用が不要
  • re:Invent2017でリリース
  • 東京リージョン未対応 (2018年1月現在)
  • AWS独自の概念
  • 料金
    • 同スペックのコンテナをスポットフリートで構成した場合に比べると高額

Amazon EKS (Amazon Elastic Container Service for Kubernetes)

  • AWSが提供するKubernetesのマネージドサービス
  • re:Invent2017で発表
  • プライベートベータが間もなく?(2018年1月現在)
  • 東京リージョンに来るのは・・・?

まとめ

  • メリットを理解し、導入するシステムの選定が必要
  • 導入に際しやらなければいけないことを整理し、自分の組織で対応できるかの見極めが必要
  • クラウドのマネージドサービスを理解し、うまく活用する
taishin
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした