Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

『GMOプライベートDMP』の開発にあたって取り組んできた DevOps、更にその反省点と現在進行中のカイゼン事例の紹介

2,763 views

Published on

昨年の10月末にリリースされた『GMOプライベートDMP』を題材に、私たちの部署で取り組んできた最新の DevOps 事例を時系列を追ってご紹介します。今回、Hadoop を活用した大規模分散処理システムの構築を行うにあたってDocker や Vagrant、Ansible などのツールを初めて導入したのですが、分散環境特有の問題から単なる調査不足からのミスまで様々な壁に直面してきました。その中で試行錯誤した過程や、結果として今なお進んでいるカイゼン事例について、現場の声を生々しくお伝えします。

Published in: Internet

『GMOプライベートDMP』の開発にあたって取り組んできた DevOps、更にその反省点と現在進行中のカイゼン事例の紹介

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

×