1.
GMO プライベート DMP 開発で
取り組んできた DevOps と今後の展望
GMO インターネット株式会社
次世代システム研究室
山邉 哲生
1

2.
2 http://pr.gmopdmp.jp

3.
4
今回のお話は
GMO プライベート DMP 開発の裏側

4.
5
① GMO プライベート DMP 開発初
期に取り組んだこと
② 実開発の中で明確になった問題点
③ 今、取り組み始めたこと
開発着手
3月くらい
∧＿∧
∧＿∧ （́<_｀ ）
（ ́_ゝ`） / ⌒i
／ ＼ | |
/ /‾‾‾‾/ |
＿_ (__ﾆつ / FMV / .| .|＿＿＿＿
＼/＿＿＿＿/ （u ⊃
イマココ！
10月末
リリース

5.
GMO プライベート
DMP 開発初期に
取り組んだこと①
6

6.
7
『ポータブルでモダンな開発環境の実現』

7.
8
էԺՙԳԷԯՊյՈԱ

8.
9
1. 開発者が自分だけの開発環境を持つこと
ができる
2. それぞれの開発環境は独立しており、
個々の変更は互いに影響を及ぼさない

9.
10

10.
11
誰かの環境が
壊れても他の人は平気

11.
12
3. それぞれの開発環境は任意のタイミング
で容易に最新化することができる
4. 開発環境の構成・構築手順はステージン
グ環境や本番環境のそれと何も変わらない

12.
13
ローカルから本番環境
まで、リポジトリで管理さ
れた同一手順で構築

13.
14
『個々人が、他者に影響されない
本番環境と同じ構成の開発環境を持つ』

14.
15

15.
http://www.slideshare.net/beniyama/continuous-delivery-35944479
16

16.
ポータビリティ＆一貫性
17

17.
https://www.docker.io/
18

18.
19
• Docker 社が Go 言語で開発した、コンテ
ナ型の仮想環境を管理するためのツール
• Yelp, Spotify, Baidu, Rackspace,
ebay…
• ハイパーバイザー型より軽量な仮想環境の
実現（ホストからはプロセスとして見える）
https://www.docker.com/resources/usecases/

19.
VM
アプリ
ミドル
ウェア
アプリ
ミドル
ウェア
ハイパーバイザー
OS
OS
アプリ
アプリ
コンテナ管理ツール
(Docker)
VM
OS
コンテナ
ミドル
ウェア
コンテナ
ミドル
ウェア
20

20.
21
• Infrastructure as Code
• Dockerfile というコードで記述できる
• Immutable Infrastructure
• 状態を保持しない”使い捨て”イメージ
• 設計思想として１コンテナ１サービス
• コンテナを維持するには常駐するプロ
セスが必要

21.
22
Dockerfile 記述例
!
FROM centos
MAINTAINER Tetsuo Yamabe
!
# Misc packages
RUN yum groupinstall -y "Development Tools"
RUN yum --enablerepo=epel,centosplus install -y rsyslog wget
sudo passwd openssh openssh-server openssh-clients…
!
# User management
RUN groupadd web
RUN useradd -M -g web web
…

22.
23
• Infrastructure as Code
• Dockerfile というコードで記述できる
• Immutable Infrastructure
• 状態を保持しない”使い捨て”イメージ
• 設計思想として１コンテナ１サービス
• コンテナを維持するには何かしら常駐
するプロセスが必要

23.
Build
Run Push
Pull
Stop
24

24.
25
!
Docker を支える要素技術
!
1. Namespaces
2. Control groups
3. Union file systems
4. Container format
https://docs.docker.com/introduction/understanding-docker/#what-is-dockers-
architecture

25.
26
1. Namespaces (名前空間)
• PID : プロセス ID (Linux 2.6.24 ～)
• NET : ネットワーク (Linux 2.6.24 ～)
• IPC : プロセス間通信 (Linux 2.6.19 ～)
• MNT : マウント (Linux 2.4.19 ～)
• UTS : ホスト名、ドメイン名など (Linux
2.6.19 ～)
http://lwn.net/Articles/531114/

26.
27
2. Control groups (コントロールグループ)
• 通称 cgroup(s)
• プロセスをグループ化して、それぞれに提
供するリソースのコントロールを行う
• CPU 時間、CPU コア
• メモリ
• デバイス etc

27.
28
3. Union file systems (UnionFS)
異なる FS のファイ
ル・ディレクトリを
透過的に重ねて利用。
!
親は読み取り専用。
https://docs.docker.com/terms/layer/

28.
29
4. Container format
LXC (Linux
Containers) から
Docker 独自の
libcontainer へ移行
http://www.zdnet.com/docker-libcontainer-unifies-linux-container-powers-
7000030397/

29.
GMO プライベート DMP 概観
Hadoop エコシステム
管理画面
30

30.
31
Docker を使って初期開発を行ったもの
1. 管理画面
• Nginx + PHP + MariaDB
2. Hadoop (CDH5)
• Flume (+HDFS)
3. RabbitMQ
4. ファイルサーバー

31.
32
• Dockerfile による構成管理の記述が楽
• 軽量なので必要なときに必要なイメージを
手軽に起動して開発できる

32.
33
実開発の中で明確になっ
た問題点②

33.
34
էԺԷժՊԽվՃՏ

34.
35
Dockerfile の
ビルドがつらい

35.
36
• 外部から取得するファイルが多すぎて再ビ
ルドに時間がかかる

36.
37
…
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.
38
• 気がつくとライブラリがバージョンアウト
してリポジトリから消失
• Dockerfile に記述しただけでは冪等性は保
証できない

38.
39
Windows
がつらい

39.
40
• Linux カーネルの機能を使う Docker は
Win/Mac 直上では動かない
• 一枚 VM をかまして動かす必要がある

40.
コンテナコンテナコンテナコンテナ
boot2docker boot2docker
VM (Linux) VM (Linux)
Windows Mac
41

41.
42
• Docker というより Vagrant / VirtualBox
を使う上での障壁が大きい
• 64 bit イメージを動かすために BIOS 設定が
必要、Vagrant / VirtualBox のバージョン差
異に起因するエラーなどなど
• 今は win 用の boot2docker インストーラが
あるので楽になっている様子

42.
43
作業内容が
消えそうでつらい

43.
44
• Immutable Infrastructure を体現する
Docker は内部状態を永続的に保持しない
• 作業スペースを外出し（マウント）してお
かないと commit しない限り Docker の
停止とともに消失する

44.
45
サブシステムも
多いし
分散環境が
つらい

45.
46
• Git のリポジトリ（プロジェクト）数６つ
• 常に最新の状態に保つための仕組みを作る
余力がなかった
• 共用の開発環境が出来てからは Hadoop
がらみの開発は直接 on-server で行われ
るようになっていった

46.
47
Docker の
アンチパターンを
理解していませんでした

47.
48
• ビルド済みのイメージではなく Dockerfile
を配布してしまった
• 複数のサービスを一つのコンテナに詰め込
んでしまった (supervisord パターン)
• 作業ディレクトリをホスト OS に外出しし
ていなかった

48.
Vagrant
49
環境構築を Ansible 化するに伴って
Vagrant 環境へ移行
Docker
Nginx
PHP
FuelPHP
MariaDB !
上記イメージ
の環境構築
(Dockerfile)
Ansible
Web と DB の構成管理
DB マイグレーション
VirtualBox
Nginx
PHP
FuelPHP
VirtualBox
MariaDB
移行

49.
http://www.ansible.com/home
50

50.
51
• Chef や Puppet に並ぶ構成管理ツール
• YAML でデータをいじるので Python を意
識しなくて良い
• ほぼ全部入りでクライアントレス
• 柔軟なディレクトリ構成

51.
52
• Web / DB を独立させて変更に強くなった
• データが揮発しなくなった
• Dockerfile に記述していた構築手順を
Ansible に担わせることで、各種サーバへ
のプロビジョニングを可能にできた

52.
53
• 重いので同時起動できる VM は限られる。
ノート PC での開発がたまに辛い。
• Win の敷居はまだまだ高い
• box ファイルの作成・取得・差し替えの手
間が割と大きいので、一度配布されたイメー
ジとマスターの乖離が大きくなりがち
（DB スキーマ含む）

53.
54
③ 今、取り組み始めたこと

54.
55
これを
Vagrant
Ansible
Web と DB の構成管理
DB マイグレーション
VirtualBox
Nginx
PHP
FuelPHP
VirtualBox
MariaDB

55.
56
こうしたい
Vagrant
Ansible
Web と DB の構成管理
DB マイグレーション
オーケストレーション
Docker
Nginx
PHP
FuelPHP
Docker
MariaDB

56.
57
• Vagrant だろうが Docker だろうが開発
者には極力意識させたくない (PaaS 化)
• せめてビルドせずに出来上がりの最新イメー
ジをすぐ使えるようにしたい

57.
58
Docker イメージの継続的デリバリー

58.
59
日次での Docker イメージの作成 & 単体・結合テスト
テスト結果修正
開発者
Docker プライベートレジストリ
登録
オーケストレーション
Docker コンテナ群

59.
60
Docker オーケストレーションツール
!
• Kubernetes (Google + Docker, MS, Redhat…)
• Panamax (Centurylink)
• Fleet x CoreOS (CoreOS)
• Fig (Orchard => Docker)
• Serf (HashiCorp)
• Maestro (signalfuse)

60.
61
まとめ㝹尳

61.
62
• Docker を使って局所的に仮想化を行うこ
だけでも、必要な部分だけローカル環境で
立ち上げて開発を行ったり、共用環境調達
までのリードタイムを稼ぐことができる
• Ansible による構成管理でプロジェクトを
横断したサーバ構築手順の再利用が進む

62.
63
• 分散システムはフルセットの開発環境を仮
想化で提供・保守するのは片手間だと困難
• 適切なバージョニングやマスターとの差
異の検知、統一的なデプロイの実装
• Ansible などで構成管理を切り出すため
には専任の人員が必要

63.
64
• Mac で作ると大抵上手くいってしまうので
現場に一人でも Windows で開発する人が
いるのであれば必ず Win 環境で構築・テ
ストする
• イメージの構築プロセスは隠蔽して極力出
来上がったものを共有する

64.
65
ご清聴ありがとうございました