この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
こんにちは
モバイルアプリサービス部の田中孝明です。
今回の 突撃！隣のDevOps は、GMOペパボさんの福岡支社にお邪魔して、DevOpsに関する考えや取り組みについて徹底的に聞いてきました！
GMOペパボ紹介
どのようなサービスをやっている
福岡支社では ロリポップ や、 ムームードメイン 、ヘテムル 等のホスティング関連サービスを運営しています。他には情報セキュリティ関連事業を行う新会社、 GMOペパボガーディアン株式会社 も設立されました。
全社としては、ハンドメイドマーケット minne 、オリジナルグッズを手軽に作成・販売できるサイト SUZURI や、オンラインショップ作成サービス カラーミーショップ 等、B to Cのサービスを運営されています。
インタビューに答えていただいた方
- 小田さん
- 技術基盤チーム／プリンシパルエンジニア
- Pull Requestを見たり相談を受けたり
- ペパボ研究所の支援
- 山下さん
- ホスティング事業部／チーフテクニカルリード兼イケメンマエストロ
- 技術開発、エンジニア育成、事業部技術方針策定
- 近藤さん
- 技術基盤チーム／シニア・プリンシパル
- 利用しているコンテナ基盤の改善
- 教育支援・メンター
- 内村さん
- ホスティング事業部／ホスティンググループ／プロダクトチーム
- コントロールパネルのWebアプリケーションをプロダクトチームで担当
- カスタマーサポートからの技術的な内容の調査
- 三宅さん
- ペパポ研究所／研究員／プリンシパルエンジニア
- 得られたデータをもとに学会の研究報告会で発表
まずは、インタビューに答えて頂いた皆さんのご紹介をしたいと思います。
左から 近藤さん 、三宅さん 、内村さん 、小田さん 、山下さん です。
クラスメソッド田中（右端）も一緒に記念写真を撮らせてもらいました！
DevOpsについて
文化
貴社の考えるDevOpsの定義とは？
弊社では、様々な捉え方があるDevOpsをよりストレートな表現としてOneLoveや全員野球と呼んでいて、文化的な部分をDevOpsの入り口にしています。
社内の中にある課題を解決しようとすると、結果としてDevOpsに結びついたとのことでした。 デザイナーがJSを書いたり、開発者がCSSのモジュールを何にするのかをデザイナーに提案したり、職制の垣根を超えて議論ができる文化があります。
なぜDevOpsに取り組んでいるのか？
過去、エンジニアのロールによって仕事が分断されている時代があって、ロールとロールの中間的な作業を誰もやりたがらない状態、またはお互いに相手の仕事だと決めつけていることで仕様バグを産みやすい状態にありました。また、ロールによる仕事の線引きは、エンジニアの興味ややる気を阻害し、エンジニアの成長ひいてはサービスの成長の機会も奪っていました。それらを解決する手段としてDevOpsに取り組んできました。
例えば特定のDBを触る権限がいる場合、インフラ担当者に仕事の依頼するのを手間に感じ、自分でツールを作って解決していたことがあったそうで、ちょっとのコミュニケーションをやらずに、そういったツール類が乱立していたそうです。
そこで、仕事の領域を作ることを「やめた」。
そして、自分が責任を持つ部分から超えて作業をやった部分、そこに挑戦したことに対して評価する文化 Nice Try を根付かせていったそうです。
正しいことをやりたい、やり方がわからないときは専門家に聞く。そうすることで、やろうとしている本人もスキルアップに繋がり、自分のカバーするスキルセットが増えていく。
現場からの気づきとしては、インフラの方もコードを書いて課題を解決することが増えたので、Devが触れるコードが増えてOps寄りになっていた結果、DevとOpsの境界が無くなったそうです。
DevOpsにおいて重要な考え方とはなにか？
軸としては、チームメンバーが同じ目標、同じ方向を見ながら、自分とは違った意見や考え方を受け入れ、たとえ失敗があったとしても支え合い、より良い方法を選択し前進するという感じです。
SREチーム的な同じ目標を持ちつつ、いろんな人とアイデアを集める。仮に失敗したとしても Nice Try と声を掛け合って次に繋げ、お互いに切磋琢磨することが重要。
まずはチームが納得できるように議論し、それでも納得できない部分が出た場合は、テックリードが決めるようにされています。また、なぜこのやり方を選定したのかなどの点についても、テックリードが疑問点を突き詰めるようにされているとのことでした。
DevとOpsをどのように連携させているのか？
ロリポップマネージドクラウドチームでいうと、そもそもDevとOpsが分かれていません。プロダクトサイドとユーザサイドで責任を持つという役割分担はありますが、それぞれロール関係なく時間外の障害対応を行います。障害対応は、システムがどういう構成でどのような動きをするのかを把握しておかないと対応できません。なので、自然とロールを跨いで情報共有を行い、障害時にはベストエフォートで助け合います。また、開発も全員で行うので、コードレビューについても同じように別ロールでもレビューを依頼し、わからないところは皆んなで話し合う雰囲気ができています。
全員が開発し、全員が運用する というスタイルを取られていました。
障害対応されるときも、自分がわからなかったところはドキュメント化して次の人に残し、属人化しそうなところはドキュメント化することを徹底されていました。
個人が持っている情報をみんなに共有する時間を設けるようにし、聞きたいことがある人に尋ねると、
「では今から勉強会をやりましょう」
このように、 勉強会はすぐやる、ホワイトボードを写真に撮って書き起こし、それをissueにまとめる まで、知識の共有がスピード感を持って行われていました。
ナレッジの共有は GitHubのリポジトリに残すようにされていました。
個人的に、エンジニアってコミュニケーションが得意な人って多くないと思っていて、でも、お互いの距離感が遠いと前記の情報共有が少なくなってしまうので、Slackで仕事に関係ないどうでもいい話をたくさんしたり、一緒にランチに外出したりというのを意識して行っています。このような、友達に近い（ざっくばらんに話せる）関係がチームとして良い結果をもたらしている気がしています。
新しいことがあればSlackで共有する雰囲気があり、東京ー福岡で情報が分断されていることはないそうです。
また、プライベートチャンネルのように、密室で物事が決まる仕組みを廃し、みんながいるチャンネルで話しましょうという仕組みがありました。
気軽に質問できる、距離が近ければ近いほど、小さな問題を共有できる機会が増える ということで、お互い普段のコミュニケーションから生み出される「つぶやきレベルの改善」を重視されていました。
そのための仕組みとして、福岡支社にはサービスの垣根を超えてランダムにメンバーをマッチングし、 ランチを設定するChat BOT が存在するそうです。
チームのメンバー構成はどうなっているのか？
上記の補足になりますが、プロダクトサイドは、ホスティングのサインアップやコンソールに関するフロントエンドからサーバサイドの面倒をみて、ユーザサイドはホスティングのお客様であるユーザのコンテンツを動かすサーバの面倒を見ることに責任を持ちます。それぞれ、3〜4人の構成です。
ホスティングは、インフラが10名、フロントが5名の体制だそうです。 ほとんどのチームが3~4人で構成されており、10人以下のチームでずっとやってきたそうです。
新メンバーへのキャッチアップの支援をどのようにやっているか？
構成図やシーケンス図などのドキュメントと一緒に全体像をチームメンバが解説し、基本的に全てがコードになっているので、詳細はコードを実際に読んでもらいます。
作り込まれたドキュメントはメンテナンスにもコストがかかるため、極力最小限のドキュメントと全体のシステム構成図でやっているそうです。
構築手順はREADMEに書かれ、開発環境については Vagrant で管理されているため、エンジニア個人で構築し、実際に手を動かせる状態にしているとのことでした。
DevOpsを進めていく上で苦労したことなどはなにか？
組織構成の変更はトップダウンだと簡単ですが、組織変更だけでDevOpsになるかというと、そうではありません。DevOpsで重要なのは先述の通りで、まずはDevOpsとしての文化の醸成を重視しました。その中で必要なツールを導入しましたし、ルールの変更を各方面の協力のもと進めてこれました。正直、文化づくりは短期間で出来るものではありません。小さなことを繰り返し、いろんな人が意識を擦り合わせて気づいたらそうなっていたという流れでした。
DevOpsは文化であり、文化を作り上げるのは短期間では難しいとのことでした。 文化を重視して、いろいろ考え方ややりかたを長期的にすこしずつ変えていき、今では良い文化が出来上がったとのことです。
小田さんが技術基盤チームのプリンシパルエンジニアになられてから取り組みが始まり、5年くらいの期間を経てようやくDevOpsが実感できるようになったとのことです。自分の権限で出来ない部分は上長へお願いし、変えることでどういう好影響があるかを説得するなど、積極的にルールを変更されていったそうです。
それによって、「開発環境を Vagrant に変えましょう」等、「変えれば褒められる」文化が根付き、結果的にバリューを出しやすい文化が出来上がりました。
プラクティスとツール
CI、デプロイ、構成管理どのようにやっているのか？
CIは必須で、ビルドやテスト、lint、カバレッジチェック、脆弱性チェックを行なっています。CIは社内に構築したdrone.ioを利用し、ChefやPuppet、Ansible、Itamaeで構成管理をしています。どのツールを使うかは、ツールを選択する特定の理由がありその理由が間違っていない限り許可されます。デプロイツールは、Capistranoを使っているケースが多いです。
ソースコードを外部に置くのは、セキュリティの観点から一定のリスクがあるため、社内でまかなえるようにツール選定を行われたそうです。 問題のあるライブラリの検出、ディレクトリトラバーサルなど、静的な脆弱性チェックもCIで行われています。
自動テストは、どのレイヤにどの程度行っているのか？
テストはユニットテストからE2Eテスト、構成管理のテストまでほぼ自動化しています。今後の課題としては脆弱性診断テストをCDのフローに乗せたいと考えていて、そこをどう自動化するかを検討しています。少し話が逸れますが、ボーイスカウト精神でレガシーなコードでも手を加える機会があれば、それをモダンにしてユニットテストを書くのを勧めています。もちろん、対応するエンジニアのスキルや納期などを踏まえてのことになりますが。
セキュリティもDevOpsの延長（DevSecOps）と捉え、みんながセキュリティに責任を持つように、リリースフローのなかに継続的Web脆弱性検査ツール VAddy を加えようとされていました。
デプロイはどのような方法でやっているのか？
デプロイは、アプリケーションを配置する機能以外で、内部統制的に「誰」が「いつ」「誰の確認」で「どのバージョン」を本番にリリースしたというのを記録する必要もあります。その機能を Capistranoのプラグイン として実装しているので、ほとんどのチームがCapistranoを使用しています。また、CDとして機能するように、GitHubのPull RequestのマージボタンからCIタスク中のCapistranoからデプロイされます。
抽象化して、他のサービスでもつかえるようにしている。
社内の人に喜ばれると評価されるシステムがあり、OSSへの公開も積極的に行われています。
今やっている作業をOSSでやるべきかどうかと敷居を感じる人はいるが、三宅さんの The Platinum Searcher のように、業務から生まれたOSSもあるため、相談できる環境がありました。
障害をどのように検知して、どのような対応フローで進めているのか？
外形監視はMackerelやNagiosを使っていて、サービス監視はConsul AlertやPrometheus AlertManagerを使っています。異常を検知するとSlackに通知され、業務時間外であれば自前で構築したWakerとTwillioからエスカレ担当者に電話連絡されます。
エスカレ担当者については、Googleカレンダーでローテーションを管理し、Waker で最後に必ず山下さんに掛かるように構築されていました。構成を冗長化することで、異常が起きたマシンを切り離しても稼働に影響を与えないようにし、切り離し自体も人の手を介さずに行うことで、なるべく翌日対応にまわせるようにされていました。
チャットツールなど補助的なツールはどのようにつかっているか？
Slackで東京本社を含め密にコミュニケーションをとっています。ミーティングやテックミーティングを行う場合は、HangoutやZoomを使っています。Slackは、出来るだけ人がいるチャンネルで会話をするという目的でプライベートチャンネルを作るのが許可制になっています。
Talkチャンネルという、「誰に聞いたらいいかわからないけど、話すと誰かが答えるチャンネル」を設けることで、なるべくダイレクトチャットやプライベートチャットを使わないオープンなチャットコミュニケーションが行われるようにされていました。
Chat BOTも相当数あり、 前日分のスロークエリを出すChat BOT 、 売上系のサマリを共有するChat BOT を始め、 担当者にタスクを追加するChat BOT を活用して見える化することで、誰にタスクが集中しているのかをわかるようにされていました。
どのようなメトリクスを取得して、どのように改善をおこなっているのか？
ホスティングサービスは、一般的なサービスと違って自分たちのコンテンツ以外にお客様（ユーザ）のコンテンツを安定的に動かす必要があります。例えば、一部ユーザの負荷が他のユーザの環境に出来るだけ影響を与えないようにリソース分離のためにより良いアーキテクチャを考えることだったり、たくさんリソースを使いたいユーザのためシステムを考えたりして、サービスの改善を図っています。
お客様からの「遅い」「重い」などの問い合わせを自動的に一定の期間数値化し、改善につなげられていました。サーバーの稼働率もメトリクスで一覧で見れるようにされているそうです。
最後に
目指すところはどこか？
DevOpsは手段であって過程だと考えているので、目指すところは一番のサービスを提供するに尽きます。なので、目的のためにやっていたことが気づいたらDevOpsだったというのが自然でしょうか。
小田さん
「目指すところはどこか？」でも述べた通り、サービスをより良くするためにそれを運営する環境を良くしていきたいです。
三宅さん
「Nice Try」という文化は素晴らしい。全員野球を維持していけるように、キャッチーなキーワードを忘れないようにやっていきたいです。
内村さん
エンジニア全員が楽しく仕事をできるような、技術的な仕組みづくりをしていきたいです。
近藤さん
開発者のみんなが楽しくできるのが一番。得意な分野であるコンテナの知識で新しい技術を開発しつつ、更に開発効率を上げれるようにやっていきます。
山下さん
これまではDevの人がOps側の領域に寄せてきましたが、今後はOps側の人もDev側に寄せていきたい。また、この変化はインフラの領域から起きましたが、アプリの領域でも起きることなので、変化し続けていきたいです。
ペパボ研究所
DevOpsのインタビューに併せて、 ペパボ研究所 での取り組みについて、 小田さん 、 近藤さん 、 三宅さん の3名にお話を伺いました。
研究について
事業を差別化できる技術を作り出すために「なめらかなシステム」というコンセプトの下で研究開発に取り組まれています。
やろうとしていることの差別化を行う際、「新規性」「有効性」を思考の過程で練り上げることができる研究的アプローチを取られています。
そして、技術的な障壁を取り除いて「やりたいこと」に対して、「なめらかに」到達できることを目標にされています。
- ペパボテックブログ: 「事業を差別化できる技術」を生み出す
小田さん
メール基盤
FastContainerアーキテクチャ をメールに応用するため、メールサーバーの Postfix をインスタンス上で素朴に立ち上げた状態と、Container上の Postfix を稼働させた状態で比較検証し、論文化のサポートをしています。メールが滞留し負荷が上がっている状態で、マルチテナントとして他のドメインへの影響を比較するために 実装 し検証を行っています。
近藤さん
FastContener
Containerならではのメリットについて探っている段階です。
サーバーなら Nginx を立ち上げたいのに、システム外のものが必要になってくるが、Containerだと最低限の状態で実現できる。ということをFastContenerで実現させようとしています。
Blue-Green だと、専用のアーキテクチャも必要になり、また切り替えの手間が挟まる。場合によってはアプリ側にも影響を及ぼします。FastContenerによって、自律的に一定時間起動、一定時間経過で立ち上げ直す → メモリリークの回避や脆弱性あるライブラリの修正反映 などをなめらかに切り替えることができます。
Haconiwa には CRIU の技術を取り込んでいて、メモリに展開した状態をイメージ化できる技術をつかってコンテナの起動速度を向上させています。
三宅さん
推薦システム
利用者が欲しいというシステムと、サービス側が提供できるものをなめらかにしていくことで、結果としてユーザー導線をなめらかにしていきます。
研究単体で終わらせるのではなく、実際にサービスで導入し、練り上げて改善していく。それが事業の成長に繋がります。 例えば、画像類似検索を minne のサービスで利用したいときに、サービスへの導入をなめらかにしていきます。
予測的オートスケーリング
最大のアクセスに対応できるように、必要なアクセス数に対して必要なサーバー台数を算出します。仮想サーバーにくるアクセスから、それに基づいて必要なサーバーの台数を予測します。
ペパボ研究所が予測する部分をつくって、 minne のサービスのエンジニアが増減する仕組みをつくるなど、お互いに協力して事業を差別化しています。
そこで得たデータをつかって学会の研究報告会で発表しました。
あらかじめ予想できていて変動するパターン（決められた日の夜にクーポン配布）や、ECサイトへのアクセスが、次の日が平日だと多いが、次の日が休日だと少ないなど、サービスが経験してきた特徴量をもとに、外部からデータを与えることでできるような学習モデルをつくっています。
それでも予測できなかった部分に関しては、 近藤 のFastContenerが活きてくる。予測的にある程度の台数を起動した上で、予測していない突発的なアクセスに対する不足分を反応的にできるだけ早く起動させて、サービスをなめらかにしていきます。
研究成果
研究の進め方
セキュリティや、不正利用の検知など振る舞いをどう検知するかなど、課題があってそれに対する取り組みを研究的に汎用的に新規性をもって対応していきます。
研究は自分から課題などを見つけてリサーチして始めます。
研究会が週一であり、そこで進捗やどういうのに取り組もうかを話しながら進めていきます。研究の途中経過はissueにまとめていき、最終的に学会の研究報告論文にします。
文章にするという区切りを設けていくことで、理論的に書き下していき、ゆくゆくはジャーナルに出していく。文章にしていくというのもの重要視しています。
積極的に試していくことが重要で、失敗に対して寛容な文化を作っています。失敗を恐れてやらないことによって、鈍化するリスクを取り除くためです。
公表することについて
オープンにし議論してもらうことで、外部の方からフィードバックをもらう。その中で疑問があった時に、ここはどうなっているんだろうかという話ができます。
論文や実装もオープンにしています。これは、真似されるリスクよりも、返ってくるフィードバックの方が大きいからです。またオープンにした方が賛同してくれる人も出て来やすいです。
論文について
論文に書くまでが大変で、大体2、3週間くらいかけています。 書こうと思えばいくらでも書けますが、何らかの条件がある前提での新規性がある内容を締め切りまでに追い込んで書き込んでいきます。
書いたものが客観的に見てわからない時は、社内のレビューをもとに精度を高めていきます。そのようにして誰もが納得できるものを書き上げていきます。
査読を通した若手のメンバーもいます。
目指すところ
開発も運用も研究開発のアプローチを取る（ResDevOps）ことで、価値を提供していけるエンジニアになる。
まとめ
今回のインタビューで印象に残った点をまとめました。
失敗を恐れない文化「Nice Try」
Nice Try 、一番印象に残った言葉でした。失敗を恐れて行動が鈍化するよりも、エンジニアの成長を促すために、挑戦することに対して皆で称え合う環境が形成されていました。
全員が開発し、全員が運用する
わからないことはドキュメント化し、詳しそうな人がいれば、すぐに勉強会を開き、参加していない人にもわかるようにissueに残していくなど、属人化を減らすことで、みんなでサービスをより良いものにしていく仕組みづくりを行われていました。
開発も運用も研究開発のアプローチを取る
やろうとしていることの差別化を行う際、「新規性」「有効性」を思考の過程で練り上げることができる研究的アプローチを取ることで、サービスに対して価値を提供していけるエンジニアになることを目指されていました。
ペパボ研究所のインタビューも併せて3時間という長丁場でしたが、ご協力いただきましたGMOペパボ福岡支社の皆様、ありがとうございました。
12
