はじめまして！社内では少数派のEmacs愛好家の大将です。 Emacsは15年以上使っています。まだまだ使いこなせていません・・・。 簡単に自己紹介しますと、2016年にWWWaveに入社し、入社してからDockerを利用し続けております。
そうです。今回はDockerのお話です。
2018年3月に社内勉強会で発表した資料を一部編集してちょっと手を抜いて記事を書きました。 今回の記事では、WWWaveでのDocker採用について振り返りたいと思います。なお、Dockerなどのコンテナ技術に関する詳細な情報は他の記事をご参考ください。
記事のアウトラインですが、以下の様な流れで話を進めます。
- Dockerに関する当社の取り組み
- Docker 採用理由と得られたメリット
- 事例
Dockerに関する当社の取り組み
WWWaveでは2016年からDockerの利用を始めていますが、今までの実績と、採用したオーケストレーション関連の技術について表にまとめてみました。
| date | docker | 当社 | 採用した関連技術 |
|---|---|---|---|
| 2013年3月 | Docker発表 | ||
| 2014年6月 | Docker v1.0リリース | ||
| 2014年10月 | docker-compose v1.0リリース | ||
| 2016年前半 | - | 新規プロジェクトで初採用 | 開発環境:docker-compose 本番環境:AWS ElasticBeanstalk |
| 2016年後半 | - | 新規プロジェクトで採用2例目 | 開発環境:docker-compose 本番環境:AWS ElasticBeanstalk |
| 2017年 | - | 既存プロジェクトのリニューアルで採用3例目 | 開発環境:docker-compose 本番環境:AmazonECS |
| 2017年 | - | 新規プロジェクトで採用4例目 | 開発環境:docker-compose 本番環境:Kubernetes |
Docker 採用理由と得られたメリット
社内ではDockerが普及し「必須技術」の１つになったのではないかと思います。 今ではエンジニア全員が業務で毎日使っています。 ここでDocker採用した理由について振り返ろうと思います。
結論としては...
いきなり結論になりますが、端的に表現すれば、以下の言葉で言い表せると思います。
- Twelve-Factor Appの実現容易性と対象領域の拡大
Twelve-Factor Appは「アプリケーション開発の方法論」です。 各環境間の違いを環境変数などの注入により吸収させるなどして、冒頭に記載されている以下の項目および詳細の12項目を最大限享受できます。
セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。
下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。
モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。
開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。
ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。
弊社で採用しているRuby on RailsはTwelve-Factor App内の例で度々紹介されている通り、これらを実現しやすいフレームワークです。 これに加えてDockerfileで管理可能になったライブラリ・ファイル群（依存ライブラリなど）までカバーできるようになり、Portabilityをさらに高めることに成功しています。
具体的には...
- 共通のDockerイメージを使い回しつつ、差分は環境変数およびVolumeMountで環境ごとに異なる設定を行う
- k8sだとconfigmapやsecret
- アプリケーションを動作させるために必要なミドルウェア・設定ファイル・ライブラリ群をコードベースでバージョン管理
- NGINXのconfファイルなど
- Ansibleを使って類似のことも可能
- CI/CDパイプラインからアプリケーションと一緒にデプロイ
- 開発環境から本番環境まで共通設定/依存ライブラリを利用することで環境依存を軽減
- アプリ側での出し分けなどがあるため、実際はゼロにはならない
得られたメリット
- Portabilityの向上により CI/CD パイプラインの実現や、各環境のみで発生する不具合の抑制
従来ではHostOSに何かしらインストールを伴う変更があるケースでは力を発揮します。 Ruby on RailsだとKaminariのインストールに手こずったりした経験がある方もいらっしゃると思いますが、このようなケースの問題は抑制できます。
事例
主に本番環境でのコンテナオーケストレーションについての振り返り。
上記表の１，２，４例目に関わりましたので、それらについて振り返りたいと思います。
事例①
- 初採用時はdocker やコンテナがバズワードとなっていた。
- まだ本番環境での採用事例をそれほど耳にすることなく、当社にとってはチャレンジだった。
そのため dockerの採用を開発環境のみで留めるか、本番環境に導入するか検証を継続しつつギリギリまで悩んでいた。s-inの時期が決まってたし。
ちなみにこの事例ではスマホアプリ開発でした。 そのため、バックエンドのRuby on rails と nginxを コンテナ化して運用した。
よかったこと
- ElasticbeanstalkはAmazon ECSなどを統合したマネジメントサービスなので、運用はAWSに任せてアプリ開発に専念することができる。
- 少人数開発でインフラにリソースを避けない場合にはとても良い。
リリース後、一人でアプリからバックエンドサービス、インフラ全てを見ていた。 ワンオペが求められるケースには良いかもしれない。
課題
- Immutable deployment を行なっていたのだが、デプロイ時間に非常に時間がかかることが難点であった。
- 15分程度かかっていたと思う。
事例②
- 前例があり私自身経験していたため、前プロジェクトをそのまま移植した形に近い。
よかったこと
- 前のプロジェクトから引き続き同じサービスを利用したため学習コストは非常に少なく構築でき、運用面でも比較的楽だった。
- Immutable deploymentを廃止したことで、デプロイ時間を5分程度に短縮。
課題
- 色々まとまっている関係でかゆいところに手が届きにくい印象。
- 不具合が発生した時にブラックボックスが多いため、迅速な対応ができないことがあった。この件以降、Elasticbeanstalkに使われていた印象が強くなった。
- 次のプロジェククトでKubernetesを使う原動力に...
事例④
- Kubernetesを採用。
よかったこと
- 安定運用： self-healing , ReadinessProbeによる異常PODにトラフィックを流さない, HPAによる pod autoscalingなどの機能の恩恵を受けられる。
- デプロイ時間：1-2分に短縮( ReadinessProbe,POD数, strategy設定で変動する。ロールバックは1-2分くらいでできる）
- H/Wリソース有効活用：プロビジョニングしたH/Wリソースに余裕があれば、追加費用を発生せずにPODをデプロイできる。
課題
- 開発環境がdocker-composeで本番環境がKubernetesのため、その違いによる学習コスト。両方学習必要になってしまっていること。
- self-healingを始めたとした便利機能の恩恵を受けて安定運用が可能になったが、問題が発生しても自動復旧してしまい本質的な改修が後手になる。
- Elasticbeanstalkの時より運用コストが増えた。
- Elasticbeanstalkの時みたいにワンオペ開発&保守&運用は厳しいかも。
まとめ
- 初採用から普及に約２年を要し、弊社では必須技術の一つに昇格。
- 現在（2018年10月)で社外向けサービスにおいて、すでに導入実績が4例となった。
- 内製の対外向けサービスはコンテナ技術を利用した運用に全て置き換わり、全エンジニアがコンテナ技術を用いた開発・保守・運用に携われるようになった。
弊社で開催しているもくもく会でdockerがテーマに含まれており、関心の高さを感じ取れると思います。
本番環境での利用実績
開発環境の利用実績
最後に
弊社ではdockerに関心のある方はもちろん、新しい技術に積極的にチャレンジしたい勇猛果敢なエンジニアを募集しています。
興味はあるけど応募する前に潜入調査したい方は、もくもく会に一度参加されてみてはいかがでしょうか？
