こんにちは。 GMOペパボの広報、ちんさつちゃんです。
今回は、われらがEC事業部CTL（チーフテクニカルリード）けんちゃんくんが登壇した「Speee Cafe Meetup #03」の様子をお届けします。
会場は株式会社Speeeさんのスペース。
普段は社員のみなさんが休憩やミーティングなどに使用されていますが、こうしてイベント会場として使われることも多いそうです。
とてもお洒落な内装で、入った瞬間からテンションが上がっていたのですが、なんとこちらでは、丁寧にハンドドリップされたコーヒーをいただくことができます…！
コーヒー好きの社員さんが多く、よくみなさんそれぞれにコーヒーを淹れてくださるそうです。
トン単位の珈琲豆が消費されたこともあるんだとか…並のコーヒー好きではない…！
もちろん珈琲豆もこだわりのセレクション。とっても美味しくいただきました。し、仕事ですからね！（美味しかったです！）
今回は4つの会社からエンジニアやマネージャーが登壇し、各社における開発基盤への取り組みについて発表がありました。
順番にレポートしていきます！
「クラウド&コンテナ活用でDevOpsを加速させる！」 by 株式会社オールアバウト 大原和人氏
トップバッターは株式会社オールアバウト開発部技術基盤グループマネージャーの大原さん。
この記事を読んでいる方の中にはお心当たりのある方もいらっしゃるかもしれません。気軽にバージョンアップできないレガシー化、あたたかみのある手動リリース…
長年ウェブサービスを世に送り出してきたオールアバウトさんでも例外ではなく、6〜7年前から開発の内製化を進め、エンジニアもGitHubのリポジトリも増えているそう。
また、開発とインフラが別部門として存在することでコミュニケーションコストが重くなってしまうこともあったんだとか。やることは山積み、でもすぐに開発者を増やせるわけではないし、増やした分だけ開発量が上がるとも限らない。そんな課題を解決して開発効率を上げるために、今年4月に技術基盤グループが誕生しました。
開発運用の効率化を図る手段として採用したのは、オンプレからクラウドへの移行とDevOpsの推進。そこでは開発とインフラの連携強化が不可欠です。この役目を担ったのが技術基盤グループです。クラウドプラットフォームとしてGoogle Cloud Platform（GCP）を採用し、DockerとKubernatesを採用。構成もシンプルになり、開発エンジニアがアプリケーションの動作環境も簡単に設定できるようになりました。
このことで、「インフラエンジニアはコンテナの外側（サイジングやクラスタ作成など）に責任を持ち、開発エンジニアは内側（アプリケーションや動作環境など）に責任を持つ」という明確な役割分担が生まれました。
コンテナにいろいろと詰め込みたくなる気持ちをぐっと抑えたり、運用しながらルールを決めたり、苦労する点もあるとのことですが、「サービス成長のために開発効率向上は必要！開発と運用が同じ方を向いてよりよい開発基盤を作っていきます」との力強いまとめをいただきました。
発表スライドはこちら
「技術基盤チームでの2年間とこれから」 by GMOペパボ株式会社 髙橋健一
続いては我らがペパボのEC事業部チーフテクニカルリード、けんちゃんくん。
現在のポジションに就くまで2年間所属していた技術基盤チームの役割についてお話しました。
ペパボの技術基盤チームに求められているものはまとめると、「いい感じにバーンとする」です。完！先生の次回作にご期待ください！
と、こんなことを書いているといろんなところからツッコミを受けそうなので、けんちゃんくんによる内訳をご紹介します。
- 会社を横断する技術課題を解決する
- 統一基盤の整備など
- 事業部固有の大きな課題を解決する
- 言語処理系のメジャーバージョンアップ、ログ集約基盤の設計開発など
- 技術を差別化する技術を開発し、サービスに導入する
これらを実現するため、技術基盤チームには以下のスキルが高いレベルで必要とされています。
- 大きな課題を分解して着実に成果を出し続ける
- 視点を高くして広い範囲で人を巻き込む
- プロセスや成果を社内外に公開し広い範囲に影響を与える
中でもけんちゃんくんが注力してきたのは「2. 事業部固有の大きな課題を解決する」こと。
新規プロジェクトのローンチ、既存サービスのDC移設とPHPバージョンアップ、事業の成長加速など、それぞれのサービスにコミットして技術基盤チームとしての役目を果たしていました。（詳しくは発表資料をご覧ください）
そして9月からは、EC事業部でその役割を発揮するチーフテクニカルリードに就任。いわゆる「部門CTO」として、事業部門固有の課題を解決するために技術者組織の強化や技術方針の再策定に取り組んでいます。これからは技術基盤チームとも連携し、もっと「いい感じにバーンと」していくとのことです。
発表スライドはこちら
「Speeeで採用した監視ツールの選定プロセス」 by 株式会社Speee 森岡周平氏
3人目は会場提供いただいている株式会社Speee開発部 開発基盤チームのエンジニア森岡さん。
今年7月に発足した開発基盤チームで、社内全プロダクトの開発効率を上げるというミッションのもとに監視ツールを導入するまでの流れを発表していただきました。
開発基盤チームができる前の開発体制は、エラー監視ツールも導入されず、リソース監視ツールはあるもののサービス毎に仕様がバラバラで情報共有ができていないため、問題が起こったときに助け合えないという問題に悩まされていたそうです。
一念発起して、まずは「全プロダクトで導入可能で、なにかあっても他のプロダクトに影響を与えない」という条件でエラー監視ツールを導入することに。
エラー検知のリミットや、JavaのロギングライブラリであるLogbackに対応しているかどうかで選びました。
一方で、プロダクトを横断して使えるリソース監視ツールの導入にも取り組みます。 今回候補に上がったのはDatadogとMackerel。どちらも想定した機能は備えていますが、現在の構成と料金を鑑みてDatadogを採用したとのこと。ディスプレイに常時表示して、エラー監視だけではキャッチできない問題の検知にも活用しているそうです。
ハッピーエンド回収できたよかったよかった〜！と思いきや、ここで検証段階で森岡さんから恐怖体験の共有が。
（ハッピーエンドと見せかけてバッドエンド〜！？心臓に悪いよ〜！）
プロダクトが少ない状態で検証を進めていた土曜日の深夜、なぜかDatadogから高額請求がきたそう！！身に覚えがない…と思って調べてみたところ、AWSintegrationのタグ指定が漏れていたためにとんでもないお金がかかっていたそうです。この失敗を糧に、監視状態の監視をするためのツール（Event MonitorとMetrics Query Function）を新たに導入したとのこと。リソース管理ツールを使うときは、Tagによるフィルタリングを！そして監視状態の監視は忘れないようにしよう！と力強いお言葉をいただき、発表は終わりました。
一連の恐怖体験を元にしたTipsはDatadogの請求書に怯えないためにするべきこと - Qiitaに記載されているとのこと。
発表スライドはこちら
「Serverless Frameworkを本番環境に投入するために」 by 株式会社ドリコム 井上幸亨郎氏
ラストはWebアーキテクト部エンジニア井上さん。
インフラ版microservicesとも言えるServerless Frameworkについての発表です。
まずはサーバーレスアーキテクチャの説明から。サーバーは非常に多くのクライアントからリクエストされるイベントと、それを受ける非常に多くの常駐プロセスを常に管理しなければなりません。でもそれって…めんどくさい！！！！！！（バーーーーーン）
サーバーレスアーキテクチャは本来アプリケーションの中にあったFunctionを第一級市民（オブジェクト）として扱うことで、管理コストを下げることができます。
ちなみに、「Serverless」でググっても後述する「Serverless Framework」しか出てこないそうなのでご注意ください。 井上さんが思わず発表中に「ばかやろう！」と叫んでしまっていたので、早く適切なページが登場するように祈ります！
続いてFaaSの解説。 FaaSとは「Function as a Service」の略称で、代表的なプロダクトには「AWS Lambda」や「Google Cloud Functions」などがあります。
Functionとは「１つの入力と１つの出力をもって状態を変更するもの」。FaaSは、これを実行するインフラを提供するサービスのことを指します。1つのEventに対してFunctionも1つ存在し、Eventが終了すればFunctionも消えます。アプリケーションとインフラ管理を分離できるため、Eventの振り分けや割り当て、プロセス数の考慮やバージョン管理もする必要がなくなります。
えっ…めちゃハッピーでは？？？？（筆者の感想です）
ちなみに、「FaaS」でググっても「詐欺代行（Fraud-as-a-Service）」のページしか出てこないそうなのでご注意ください。
そして満を持して登場するのが「Serverless Framework」。代表的なサービスにはServerlessがあります。これまでの話を聞くと、「FaaSって楽そうだし、フレームワークなんてなくてもいいんじゃない？」と思われるかもしれません。
たしかにFaaSそのものは簡単ですが、そのもとになるEvent Sourceは種類も数も大量に存在します。対応するFunctionもまた然り。これらすべてを管理するのは、実はとても大変です。Serverless Frameworkは、リソース管理や操作まで行ってくれる優れもの。FaaSに周縁サービスを簡単にデプロイする役割を担います。
ちなみに、「Serverless Framework」はググっても大丈夫だそうです。よかった！
ウェブサービスが複雑な場合はmicroservicesへ、インフラが複雑な場合はServerless Frameworkへ、というまとめで発表は終わりました。
発表スライドはこちら
まとめ
懇親会では、登壇者も参加者も熱量を持ってコミュニケーションを取っているのが印象的でした。
たとえ立場や所属する組織が違っても、開発効率を上げて、よりよいサービスをユーザーに提供したい！という願いは同じ。
今回の発表をきっかけに、基盤開発の機運がどんどん高まっていくことを期待しています。
最後に、会場と写真をご提供くださった株式会社Speeeさん、ありがとうございました！