『GMOプライベートDMP』の開発にあたって取り組んできた DevOps、更にその反省点と現在進行中のカイゼン事例の紹介
•
13 gefällt mir•3,954 views
昨年の10月末にリリースされた『GMOプライベートDMP』を題材に、私たちの部署で取り組んできた最新の DevOps 事例を時系列を追ってご紹介します。今回、Hadoop を活用した大規模分散処理システムの構築を行うにあたってDocker や Vagrant、Ansible などのツールを初めて導入したのですが、分散環境特有の問題から単なる調査不足からのミスまで様々な壁に直面してきました。その中で試行錯誤した過程や、結果として今なお進んでいるカイゼン事例について、現場の声を生々しくお伝えします。
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie 『GMOプライベートDMP』の開発にあたって取り組んできた DevOps、更にその反省点と現在進行中のカイゼン事例の紹介
Ähnlich wie 『GMOプライベートDMP』の開発にあたって取り組んできた DevOps、更にその反省点と現在進行中のカイゼン事例の紹介 (20)
『GMOプライベートDMP』の開発にあたって取り組んできた DevOps、更にその反省点と現在進行中のカイゼン事例の紹介
- 1. 『GMOプライベートDMP』の開発に あたって取り組んできた DevOps GMO インターネット株式会社 次世代システム研究室 山邉 哲生 ∼ 更にその反省点と現在進行中のカイゼン事例の紹介 ∼ 【20-B-1】#devsumiB
- 2. 2 山邉 哲生 (id:beniyama) 外資系携帯メーカーの研究所を退職後、博士号を取得し 2012年4月に GMOインターネット株式会社 に入社。 EC、ソーシャルゲームの経験を経て現在は『GMO プラ イベート DMP』の開発に従事。 フロントエンド開発から DevOps、Hadoop/Spark な どの大規模分散処理まで幅広い興味を持つ。 詳しくは べにやまぶろぐ beniyama.hatenablog.jp で。
- 3. 3
- 8. 8 ① GMO プライベート DMP 開発初期に取り組んだこと ② 実開発の中で直面した問題点 ③ その後の取り組みと変化
- 13. 13
- 14. 14
- 17. 17
- 18. 18
- 22. ポータビリティ＆一貫性 22
- 24. 24 • Docker 社が Go 言語で開発した、コンテ ナ型の仮想環境を管理するためのツール • Yelp, Spotify, Baidu, ebay … • ハイパーバイザー型より軽量な仮想環境を Linux カーネルの機能で実現 • Namespaces, CGroups, UnionFS… Docker とは
- 25. VM ハイパーバイザー (VirtualBox など) ホスト OS (Linux) ゲスト OS ミドルウェア アプリ コンテナ管理ツール (Docker など) VM ゲスト OS ミドルウェア アプリ コンテナ ミドルウェア アプリ コンテナ ミドルウェア アプリ
- 26. 26 • Infrastructure as Code • Dockerfile というコードで記述できる • Immutable Infrastructure • 状態を保持しない 使い捨て イメージ • 設計思想として１コンテナ１サービス
- 27. 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. 28 • Infrastructure as Code • Dockerfile というコードで記述できる • Immutable Infrastructure • 状態を保持しない 使い捨て イメージ • 設計思想として１コンテナ１サービス
- 31. • Dockerfile による構成管理の記述が楽。 • 軽量なので手軽に構成を組み替えられる。 • スタブ的に使うことで共用環境調達までの リードタイムを稼ぐことができた。 31
- 32. 実開発の中で直面した 問題点 ②
- 36. 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. 37 • 気がつくとライブラリがバージョンアウト してリポジトリから消失していたりする。 • Dockerfile 内でバージョンを縛らない限り 冪等性は保証できない。
- 38. 38 Windows がつらい
- 39. 39 • Docker に限らず Vagrant や VirtualBox を使う際に様々な箇所で躓きやすい。 • BIOS の設定、バージョン間差異など • cygwin 地獄 • 開発環境整備コストの増加
- 40. Docker に関しては boot2docker の インストーラ利用で敷居が下がる？ Windows Mac VirtualBox VirtualBox boot2docker (Linux) boot2docker (Linux) コンテナ コンテナ コンテナ コンテナ
- 42. 42 • Immutable Infrastructure を体現する Docker は内部状態を永続的に保持しない。 • ホストからイメージを commit しない限 り、コンテナ内の変更は停止とともに消失。
- 46. 46 1. ビルド済みのイメージではなく Dockerfile を配布してしまった。 2. ホスト OS のディレクトリをマウントし たところで作業していなかった。 3.複数のサービスを一つのコンテナに詰め込 んで複雑化してしまった。
- 47. Ansible x Vagrant で 管理画面の構成管理を整理してみた
- 49. 49 • Chef や Puppet に並ぶ構成管理ツール。 • YAML で記述できる。 • SSH だけで良いクライアントレス方式。 • 柔軟なディレクトリ構成。 Ansible とは
- 50. 50 Dockerfile! ! Nginx / PHP / FuelPHP / MariaDB
- 51. 51 Dockerfile! ! Nginx / PHP / FuelPHP / MariaDB Playbook! ! Nginx / PHP / FuelPHP Playbook! ! MariaDB
- 52. 52 • Web / DB を分離して変更に強くなった。 • データの揮発を意識しなくて良くなった。 • Dockerfile に記述していた構成管理を Ansible に担わせたことで、本番環境への プロビジョニングが可能になった。
- 53. 53 • VM の複数起動はやはり嵩張る。 • Windows の敷居はまだまだ高い。 • VM イメージ保守のコストが大きく、手元 のイメージがマスターと乖離していく。
- 54. ③ その後の取り組みと変化
- 55. 技術面
- 56. 56
- 57. 57
- 58. 58 Playbook! ! Nginx / PHP / FuelPHP Playbook! ! MariaDB 管理画面でいうと これを
- 59. 59 Playbook! ! Nginx / PHP / FuelPHP Playbook! ! MariaDB 管理画面でいうと こうしたい
- 62. 62 1. サービスの細分化・軽量化と管理 2. Ansible による Docker イメージ構築 3. Docker イメージの継続的デリバリー
- 65. 65 • Docker 社に買収され、近く Docker Compose として提供される予定 • YAML で定義が可能で、小規模のコンテナ クラスタを構築するには使い勝手が良い Fig とは
- 66. 66 fig.yml の記述例 db: image: postgres ports: - "5432" web: build: . command: bundle exec rackup -p 3000 volumes: - .:/myapp ports: - "3000:3000" links: - db
- 67. 67 Playbook! (Web) 2. Ansible による Docker イメージ構築 イメージ構築ツール Ansible の Playbook を再利用して VM だけでなくコンテナイメージも作成 Playbook! (DB)
- 69. 69 • Vagrant や Serf の開発元の HasiCorp 社製。 • 様々な構成管理ツールと出力イメージに対応。 • Ansible の資産を Docker に再利用、など。 （※ 現在 docker 1.4 系以上だと docker builder x ansible provisioner の組み合わせが正しく動作しない） Packer とは
- 70. 70 3. Docker イメージの継続的デリバリー 4. Docker プライベートレジストリへの登録 Playbook 2. Docker イメージの構築 3. イメージのテスト 5. 開発環境への適用 1. Playbook の更新 開発者
- 71. 71 • イメージの構築は CI が担う。 • 継続的なスクラップ＆ビルド＆テスト。 • バージョン管理されたコンテナイメージ。
- 72. 体制面
- 73. 73 • 構成管理に対する理解と導入が進んだ。 • 新規の設定だけでなく既存のシェルスクリプト も少しずつ Ansible で置換え。 • チームで環境構築のタスクを回したり、リリー スの効率改善を測ったのも一因。 • 一方で誤って環境を破壊してしまうことも。
- 74. 74 • DevOps のためのインフラ整備を行う専任 者を置いたり、環境を刷新するという流れ が起きた。 • フルセットの開発環境を継続的に提供し続ける のは開発の片手間だと困難。 • 多様化する DevOps 技術を理解するために検 証しやすい環境が必要。
- 75. まとめ
- 77. その上で、今後の心構え
- 83. ご清聴、ありがとうございました