『gmoプライベートdmp』の開発にあたって取り組んできた...
TRANSCRIPT
『GMOプライベートDMP』の開発に あたって取り組んできた DevOps
GMO インターネット株式会社 次世代システム研究室
山邉 哲生
～ 更にその反省点と現在進行中のカイゼン事例の紹介 ～
【20-B-1】#devsumiB
2
山邉 哲生 (id:beniyama) 外資系携帯メーカーの研究所を退職後、博士号を取得し2012年4月に GMOインターネット株式会社 に入社。 EC、ソーシャルゲームの経験を経て現在は『GMO プライベート DMP』の開発に従事。 フロントエンド開発から DevOps、Hadoop/Spark などの大規模分散処理まで幅広い興味を持つ。 詳しくは べにやまぶろぐ beniyama.hatenablog.jp で。
3
7
今回のお話は GMO プライベート DMP
開発の裏側
8
① GMO プライベート DMP 開発初期に取り組んだこと
② 実開発の中で直面した問題点
③ その後の取り組みと変化
GMO プライベート DMP 開発初期に 取り組んだこと
①
10
『ポータブルでモダンな開発環境の実現』
12
個々の開発者が、他者に影響されない 自分だけの開発環境を持つことができる
その１
13
14
15
誰かの環境が 壊れても他の人は平気
16
それぞれの開発環境は任意のタイミングで 容易に再構築・最新化することができる
その２
17
18
19
開発環境の構成・構築手順は ステージング環境や本番環境の それと何も変わらない
その３
20
ローカルから本番環境まで、リポジトリで管理された同一手順で構築
本番環境と同じ手順で構築され、 かつ独立した開発環境を個々人が持つ
ポータビリティ＆一貫性
22
24
• Docker 社が Go 言語で開発した、コンテナ型の仮想環境を管理するためのツール • Yelp, Spotify, Baidu, ebay …
• ハイパーバイザー型より軽量な仮想環境をLinux カーネルの機能で実現 • Namespaces, CGroups, UnionFS…
Docker とは
VM
ハイパーバイザー (VirtualBox など)
ホスト OS (Linux)
ゲスト OS
ミドルウェア
アプリ
コンテナ管理ツール (Docker など)
VM
ゲスト OS
ミドルウェア
アプリコンテナ
ミドルウェア
アプリ
コンテナ
ミドルウェア
アプリ
25
26
• Infrastructure as Code • Dockerfile というコードで記述できる
• Immutable Infrastructure • 状態を保持しない”使い捨て”イメージ • 設計思想として１コンテナ１サービス
27
Dockerfile の記述例 FROM centos MAINTAINER Tetsuo Yamabe !# パッケージのインストール RUN yum groupinstall -y "Development Tools" RUN yum --enablerepo=epel install -y rsyslog wget sudo passwd openssh openssh-server openssh-clients… !# ユーザー管理 RUN groupadd web RUN useradd -M -g web web …
28
• Infrastructure as Code • Dockerfile というコードで記述できる
• Immutable Infrastructure • 状態を保持しない”使い捨て”イメージ • 設計思想として１コンテナ１サービス
Hadoop クラスタ
管理画面
29
Docker を使って初期開発を行ったもの
Hadoop クラスタ
管理画面
30
Docker を使って初期開発を行ったもの
• Dockerfile による構成管理の記述が楽。 • 軽量なので手軽に構成を組み替えられる。 • スタブ的に使うことで共用環境調達までのリードタイムを稼ぐことができた。
31
実開発の中で直面した 問題点
②
34
Dockerfile の ビルドがつらい
35
構成が複雑になると一回のビルドに時間がかかって気軽にトライ＆エラーできない。
!
36
… RUN git pull RUN git checkout develop RUN git submodule init RUN git submodule update RUN php composer.phar self-update RUN php composer.phar update RUN npm install RUN grunt RUN php oil r install …
37
• 気がつくとライブラリがバージョンアウトしてリポジトリから消失していたりする。 • Dockerfile 内でバージョンを縛らない限り冪等性は保証できない。
38
Windows がつらい
39
• Docker に限らず Vagrant や VirtualBox を使う際に様々な箇所で躓きやすい。 • BIOS の設定、バージョン間差異など • cygwin 地獄 • 開発環境整備コストの増加
Docker に関しては boot2docker の インストーラ利用で敷居が下がる？
Windows Mac
VirtualBox VirtualBox
boot2docker (Linux) boot2docker (Linux)
コンテナ コンテナ コンテナ コンテナ
40
41
作業内容が 消えそうでつらい
42
• Immutable Infrastructure を体現する Docker は内部状態を永続的に保持しない。 • ホストからイメージを commit しない限り、コンテナ内の変更は停止とともに消失。
43
複雑な 分散システムが つらい
44
• 様々なサブシステムそれぞれについて構成管理を開発・保守するコストが大きい。 • 共用の開発環境が出来てからは直接サーバー上で作業することも多くなった。
Docker の アンチパターンを 理解していませんでした
46
1. ビルド済みのイメージではなく Dockerfile を配布してしまった。
2. ホスト OS のディレクトリをマウントしたところで作業していなかった。
3.複数のサービスを一つのコンテナに詰め込んで複雑化してしまった。
Ansible x Vagrant で 管理画面の構成管理を整理してみた
49
• Chef や Puppet に並ぶ構成管理ツール。 • YAML で記述できる。 • SSH だけで良いクライアントレス方式。 • 柔軟なディレクトリ構成。
Ansible とは
50
Dockerfile!!
Nginx / PHP / FuelPHP / MariaDB
51
Dockerfile!!
Nginx / PHP / FuelPHP / MariaDB
Playbook!!
Nginx / PHP / FuelPHP
Playbook!!
MariaDB
52
• Web / DB を分離して変更に強くなった。 • データの揮発を意識しなくて良くなった。 • Dockerfile に記述していた構成管理を Ansible に担わせたことで、本番環境へのプロビジョニングが可能になった。
53
• VM の複数起動はやはり嵩張る。 • Windows の敷居はまだまだ高い。 • VM イメージ保守のコストが大きく、手元のイメージがマスターと乖離していく。
③ その後の取り組みと変化
技術面
56
×
57
× ×
58
Playbook!!
Nginx / PHP / FuelPHP
Playbook!!
MariaDB
管理画面でいうと これを
59
Playbook!!
Nginx / PHP / FuelPHP
Playbook!!
MariaDB
管理画面でいうと こうしたい
60
全てのサブシステムを ローカルで再現するのではなく 必要に応じて手元の構成を組み替えて 共有の Hadoop 環境に 接続できるような仕組みが欲しい。
61
開発者が開発環境を 導入・保守するコストを 極限まで下げたい。 メンバーを増やしているとき、 職務横断な開発をしているときは特に。
62
1. サービスの細分化・軽量化と管理 2. Ansible による Docker イメージ構築 3. Docker イメージの継続的デリバリー
63
Playbook!(Web)
1. サービスの細分化・軽量化と管理
Playbook!(DB)
オーケストレーションツール
複数コンテナの定義NW の構築など
65
• Docker 社に買収され、近く Docker Compose として提供される予定 • YAML で定義が可能で、小規模のコンテナクラスタを構築するには使い勝手が良い
Fig とは
66
fig.yml の記述例 db: image: postgres ports: - "5432" web: build: . command: bundle exec rackup -p 3000 volumes: - .:/myapp ports: - "3000:3000" links: - db
67
Playbook!(Web)
2. Ansible による Docker イメージ構築
イメージ構築ツール
Ansible の Playbook を再利用して VM だけでなくコンテナイメージも作成
Playbook!
(DB)
69
• Vagrant や Serf の開発元の HasiCorp 社製。 • 様々な構成管理ツールと出力イメージに対応。 • Ansible の資産を Docker に再利用、など。 （※ 現在 docker 1.4 系以上だと docker builder x ansible provisioner の組み合わせが正しく動作しない）
Packer とは
70
3. Docker イメージの継続的デリバリー4. Docker プライベートレジストリへの登録
Playbook
2. Docker イメージの構築
3. イメージのテスト
5. 開発環境への適用
1. Playbook の更新
開発者
71
• イメージの構築は CI が担う。 • 継続的なスクラップ＆ビルド＆テスト。 • バージョン管理されたコンテナイメージ。
体制面
73
• 構成管理に対する理解と導入が進んだ。 • 新規の設定だけでなく既存のシェルスクリプトも少しずつ Ansible で置換え。 • チームで環境構築のタスクを回したり、リリースの効率改善を測ったのも一因。 • 一方で誤って環境を破壊してしまうことも。
74
• DevOps のためのインフラ整備を行う専任者を置いたり、環境を刷新するという流れが起きた。 • フルセットの開発環境を継続的に提供し続けるのは開発の片手間だと困難。 • 多様化する DevOps 技術を理解するために検証しやすい環境が必要。
まとめ
76
『本番環境と同じ手順で構築された独立した開発環境を個々人が持つ』 という理想から出発して
直面してきた現実についてお話ししました。
その上で、今後の心構え
78
開発者が、そのメリットを意識せずに 享受できるような環境を提供する当たり前になるとその価値は忘れられる
”まだ足りない” だけで着実に進歩はしていた
その１
79
継続的にデリバリーするのは プロダクトだけではない
インフラは開発し続けるものという認識を共有する
その２
その３
80
最初から完全を目指さない価値のある技術には勝手に人がついてくる
検証を重ねて柔軟に適応させていくことがより重要
81
今後も引き続き、より実践的な 『ポータブルでモダンな開発環境の実現』
に取り組んでいきます
82
http://recruit.gmo.jp/engineer/jisedai/
次世代システム研究室では エンジニアを募集しています！
ご清聴、ありがとうございました