Empowered by expect

希望は体力

第5回ペパボテックカンファレンスに行ってきました

今回は「〜インフラエンジニア大特集〜」という副題が付いているとおりインフラ系のイベントなのですがWeb系な雰囲気満載だった第5回ペパボテックカンファレンスに行ってきました。
pepabo.connpass.com

本篇1 トーク&LT

各発表資料はアップされているので、発表部分は資料リンクとQ&A部分の書き起こしおよびひとことコメントだけで。
発表のフォーマット感があって流れが掴みやすいのがとても印象的でした。
発表されたみなさんが大まかに以下に沿っていました。

  • アジェンダ - 背景経緯 - 問題設定/設計実装 - 結果/効果 - 残課題 - まとめ - 今後 といった構成
  • イメージカラーベースの共通スライドマスター
  • ごせいちょうありがとうございました -> 拍手 がしやすい区切り方
  • 資料公開はSpeakerDeck

発表1 100行あったmod_rewirteを ngx_mrubyで書き換えた話 by buty4649さん

speakerdeck.com
Q&A
Q: apache/mod_rewriteの頃のテストは?
A: テスト環境に設定を入れて人手で確認

Q: Luaでも同じ事ができそうだがmrubyを選んだ理由は?またmod_rewriteよりレビューコストが上がっていないか?
A: Luaでもできるが、matsumotoryさん始め社内の知財的にruby,mrubyが強いので選んだ。元々得意な人が多いのでレビューコストもそれほどではない

Q: パフォーマンス劣化は無かったか
A: ngx_mrubyのwikiの情報ではパフォーマンスはそれほど落ちない。実際abコマンドでやってみてもそれほど劣化は見られなかった

発表2 ペパボのプライベートクラウド "Nyah" その後 / Pepabo's PrivateCloud "Nyah" After That by tnmtさん

speakerdeck.com

Q&A
Q: バックアップ構成は?
A: 現状けっこう課題
  OpenStack上の別インスタンスやOpenStack外の基盤に採っている

Q: OpenStackのバージョンアップ後の切り戻りは?
A: 新バージョンは別途構築して移行しているので実質切り戻しはない

Q: Neutro使うとLinuxでパフォーマンス落ちないか?
A: 現状構成は組めたけどパフォーマンスは細かく見られていない

LT 高集積ホスティングにおけるセキュリティとPHP実行基盤の高速化 by tshpaperさん

speakerdeck.com

下matsumoto-rさんの内容を超高速でご紹介された勢いのある発表でした。
5年ちょっと前くらいに当時のParalellsさんの製品で物理一台に7000ドメインくらい積めるのがありましたが今のハードスペックだと万単位でやってるんですね。


LT インフラエンジニアもCIがしたい by alotofweさん

drone.ioのCIをnested dockerで実施するお話。CIの行き倒れゴミとか経験してるとdrone.ioの良さ嬉しいですよね。CIツールはまだまだ増えていますがインフラで使うときはテスト環境の生成と、単体ではないテストを流せるか/どう流すかがネックというか鍵になる印象です。GitHub Ent.がすでに運用の真ん中に根付いているという前提条件もうらやましくも重要なポイント。
speakerdeck.com

発表3 時代が求めたSTNSと僕 〜夏の日の1986〜 by pyama86さん

AD以外のLDAPは挫折しましたすみません。deploy用の共通アカウント使うならChatからdeployすればいいかなとか(軟弱)。基本認証に対応していたり、api end pointを並べて書けば冗長できたり、使う側に便利なポイントも抑えてあったのが好印象でした。
SSH鍵管理はクッ社さんもいろいろ便利ツール作っていたり、管理の面では新たな課題ですね。
speakerdeck.com

Q&A
Q: 冗長可能な部分は
A: componentのdeployで考慮する必要有り。capistranoとか

LTベンチマークテストやろうぜ by pbmasakiさん

最後の大オチがwwEC2とか同じリソースサイズでもハードの世代によってパフォーマンスに差があるけど見えない部分だから..というIaaSガチャ的な話はありますよね。公開されているベンチマークはレギュレーションの読み解きが大事、というのはおっしゃる通りで刺さりました。個人的な昔話ですが、qmailからpostfixへ移行したら遅くなった、と言われていろいろいじって最終的に/var/spoolをext2にしたという闇経験があります。
speakerdeck.com


LT構成管理ツールを用いたインフラ開発フローの改善 by k_hanazukiさん

・本番環境とテスト環境の差分
マニフェストと実サーバー設定の差分
の検知と撲滅のお話。個人的にはテスト駆動インフラとかエンタープライズアジャイルとかの背景の一つが「本番と同じ環境でテストせよ」だと感じて取り組みを始めたので、ここを一番見張っています。先日のImageMagickのpolicy.xmlファイルとか変更する機会はそうそう無いので、Serverspecテストに即時に組み込まないと忘れ去られていきますからね(アップデートによって不要になった要素もありますが)。究極的にはサーバーに直接sshログインするのか、という話になるかと思います。ポータル&Chat(Slack)という通知共有は鉄板ですが良いですね。
speakerdeck.com



発表2のtnmtさんにはHosting Casual #1でもお世話になったのですが、Serverspec周りの2014年のこの発表資料だけでもリスペクトできます。今日の話題範囲にも関連するので貼っておきます。
speakerdeck.com

それぞれの発表内容は多岐に渡ったのですが、いずれも設定された具体的な課題に対する改善解決が示されていて聞いている私にも「おお、自分もやってみようかな」という思い持たせるような、巻き込む魅力のある発表で非常に有益でした。

トークセッション「ペパボのインフラを読み解く」

sugyさん(東京/EC事業) 以下S
tshpaperさん(福岡/ホスティング事業) 以下T
司会kumanoさん 以下K

K「インフラは幅広くラックやスペースを含めたモノからヒトまで含める範囲で。
  当初ペパボではインフラはGMOグループからホスティングで借りていた。
  それを自前ハウジング、さらにプライベートクラウドNyahへ移行しているが
  ハウジングに移行して自前サーバーが増える時の苦労は?」
S「キッティングやラッキングなどそれまではお願いしていたことを自分たちでやるのは大変だった」
K「福岡はしばらくホスティングでしたがあるプロジェクトで一気に移行した時の苦労は?」
T「ホスティングは自分たちでやってるものでもあるので、できるだけ現地に行かなくて済むようにはしていた」

K「ハウジング当時、自力人力でセットアップしていた頃は一台どのくらいかかっていたか?」
T「ホスティングは一台半日くらい」
S「簡単なもので1日、複雑なものは2-3日+他業務とかで期間的には1週間かかることも」

K「そうやっていると"サーバーを作るのがうまい人"になってしまいがち。
  これではイカン、と2007年頃(mizzyさんが)Puppetを使おうと提案してきた。
  で、今は一台どのくらいかかるか?」
T「1時間もあればできあがる。並列も可能で多いときは十数台並列とか」
S「10分弱から2,30分程度。時間が短いことよりも検証のテストが楽になることや繰り返しが楽になったメリットを大きく感じる」

K「Puppetもちょっとバージョンアップすると動かなかったり問題もあったがここまで来るのに苦労した点は?」
T「mizzyさんが創り出したものを福岡側で引き継いで吸収していた。その後Ver.3系に移るときに難しさはあったが、都度調べて議論して、を経てきたのでメンバーの共有&成長でカバーできている」
S「根付くのが大変だった印象。(自分の意識が低かったかもだが)Puppetは遅いイメージがあったのでShellでいいじゃん感は有った。その後、仮想環境および仮想環境を扱うツールが揃ってきた事でメリットを感じやすくなり意識が高まってきた」
K「秘伝のタレ化していたものがコード化されたのはメリットだと思う」
(ここで会場挙手アンケート。
 構成管理ツールを使ってる人: ほぼ全員
 Puppet 数名、Chef 多い Ansible Chefと同じくらい多い
 itamaeとholoなワタシ)

K「コード化されたことでメリットはあるとして、今何台くらい管理してるか?」
T「VM除いて1000台くらい。VM入れると1100から1200くらい。今集約も行っている」
S「オンプレ150台、クラウド600台くらい」

K「Nyahプライベートクラウドを使うことで構成管理は変わったか?」
S「変わったと思う。ドライバインストールなどが無いので統一しやすく、シンプルになった気がする」

K「そこに携わるインフラエンジニアはどう変わってきたか。開発者がインフラの領域に踏み込んで来られる環境になった。今後インフラエンジニアはどう振る舞っていくのか?」
S「正直要らないなと思う事はある」
K「半分は要らないかなと思ったけど今日の発表のようにインフラエンジニアも逆に開発寄りになってきているのか?」
S「開発寄りに行く人と、より専門的に行く人とありそう」
T「高集約にこだわっているので、必要となるkernelの最適化などより低いところへ行く人とmrubyのようにコードを書いて行く人との道がありそう」

K「実際開発の人たちはインフラに入ってきているか?」
T「Puppetの設定にcommitしたりはしている。」
S「あるRoleに対してはインフラエンジニアはコードのレビューのみになっている」
K「今まで煩雑な依頼があったのが、だいぶ良い環境になってきている。
  数年前からDevOpsに取り組んでいるが、アプリケーション寄りの活動も、物理やネットワークにも取り組んで行きます」

以上。以下Q&A

Q: 構成管理ツール、の難しさを感じる。社内への普及や教育はどうやっているか?
A: (T)一番最初はmizzyさんから直接教えてもらって、落とし込みは自分たちで議論しながら行った
  (K)当時は良い教材が無かった。あと普及面では世の中にはまだまだ手順書があるが、これを置き換えたときに何が得なのか、逆に手順書でないとできないことは何か、とみんなで考えてはどうか
  (S)当時「スクリプトではダメだぞお前」という空気があった
  (K)同調圧力ではなくて、問題意識を共有してる上でのこと

Q: インフラエンジニアとアプリケーションエンジニアの責任範囲の分け方は?
A: (K)アプリケーションエンジニアのプルリクをインフラエンジニアがレビューするのでその時点で責任範囲というかコードの通り。振り返りは大事だが、責任範囲を問うことはしていない

感想や小話

全体

先のqpstudyは比較的泥臭さも感じるインフラエンジニア界隈でしたが、今日はさすがペパボさんというか技術で様々な施策を打っていて、自社サービスの環境をちゃんと把握した上での対応が行われているという感じでした。
ruby/mrubyという軸が強くあるので、環境やツール選定にも大きな理由があってすんなり行っている印象でした。自社プラットフォーム開発をされている会社さんはこれがありますね。運用系の集まりだと強い言語は無かったり個々人で違ったりするので「RubyDSLで書けるっ」はそれほどメリットでなかったりも。個人的には「フレームワークとしてメリットを得られるものを選べば良いんじゃないでしょうか」と言うシーンが最近多かったので、明確な軸があるのはうらやましくも感じました。

構成管理

cfengine is cool, puppet is sexyというフレーズを聞いたのは10年近く前の気がしますが、古参ツールのpuppetを会得して使いこなしている感にあふれていて、ツールがちゃんと手段に収まっているのも印象的でした。構成管理ツールって最初に使った時に気持ちの良い感動があるはずなので、そのメリットが活かされたまま定着できているのが良いなあと。世には「Chefツライ」とか「YAMLプログラミング(Ansible)ツライ」とか「本当にholoで良いの?」いった話も多いですからね..ベアメタルレベルの管理のお話が聞けなかったので、そこの施策も聞いてみたいです。OpenStackで言うIronicとかUbuntuならMAASとか
tnmtさんに「ストレージ選定ネタの続きも期待してます」「StackStorm便利ですよ。どうっすか」と2つお話できたので、もしかするとOpenStack MistralのワークフローベースでStackStormを操るお姿が見られるかもしれません。StackStormは、都合がつけばHosting Casual #3でディスカッションのまな板に乗せてみたかったのですが。

ヒト

一方で4月のqpstudyや3月のIaas Casualと同じくインフラエンジニアの今後のキャリア形成やチームメイキング、採用といったヒトのお話では共通した課題や悩みが聞かれた気がします。クラウドやらコンテナやらと基盤が進化してツールも充実したことで、変化は感じていてそれに伴った危機感も感じている、といったところでしょうか。今回のpbtechと併せた3つのイベントで割と共通して聞かれたメッセージとしては「すべてできる人はいない」「コミュニケーション大事。コミュニケーションもChatOpsとか技術で改善できる部分もある」「そこはきっと楽しいところ(デマルコ風)」がありました。あと懇親会でkumanoさんからファシリテーターの活用というお話もあり、これまた実際の活用話はあまりお聞きする機会が無かったので、ファシリテーター人材という課題も有りそうですが納得感がありました。

実は前日まで抽選に落ちたと勘違いしていて午前中に髪を切りに予約入れちゃったりしていたのですが、無事参加できて様々な刺激を得られて良かったです。今後もpbtechでインフラ/運用系のネタをやって欲しいし自分のチームメンバーにも参加して欲しいです。
また、懇親会のカレーが小分けで配布されたのは食べやすかったので、Zoho各位にはナンのこだわりもあると思いますが参考にしてもらえれば。

おまけ

Web+DB Press Vol.92の第一特集"Web開発新人研修"はまるごとペパボさんのご執筆です。
gihyo.jp


(5/16 公開資料へのリンクを追加しました)