DBA+SRE+アプリケーションエンジニアで開発合宿行ってきました!

DBA+SRE+アプリケーションエンジニアで開発合宿行ってきました!

HRMOS採用管理事業部プロダクト開発部(プラットフォーム基盤推進室)のtakakoです。

私は9月入社なのですが、Joinして二回合宿に参加させていただきました。そのうち開発合宿の方で、技術的負債の返却やサービスの導入検討をして成果発表までしたので、まとめました。
全員集合

背景

SRE+DBAチームは緊急対応や割り込みタスクがすごく多く、がっつりとした開発時間が取れていませんでした。そこで合宿形式で、いつもと違う環境でリフレッシュしつつ、何者にも割り込まれない時間を確保し、がっつりアウトプットをだそう!という経緯でいってきました。

開発部署全員で行った訳ではなく、今回はSREチームをメインにアプリケーションエンジニア数名と、合計13人で箱根の大平台に合宿に行って来ました!

チーム

チーム分け

テーマ チーム発足の理由 ゴール
技術的負債を返却する
アプリケーションの操作ログの仕組みを構築する アプリケーションのログ出力内容にHTTPヘッダ情報を含めて、ユーザーがいつどこから何をしたのか簡単に分析できるようにしたい。 アプリを利用したユーザーの操作ログの仕組みを検証する。
ElasticSearch 1.5 → 6.3 乗せ替え 現状はEC2にElasticSearchを直接乗っけて3台構成で運用している。AWSのElasticSearch Serviceに移行してスケールイン・アウトできるようにして運用したい。 ElasticSearch Serviceに乗せ替え。
Elasticache (memcached) のSPOFをなんとかする ユーザーのセッション情報を格納している仕組みがよくない。
・現状(memcached): ユーザ → Cache
Cache飛ばすとセッション情報が消えてしまう。
・理想(redis): ユーザ → Cache → (Cacheがなければ)永続層に取りに行く&Cacheにputする
に構成変更したい。
セッションのキャッシュをRedisに乗せ替え。
Redisの理由は、memcachedと同様にインメモリ型のKVSで高速に動作する。… etc
サービスの導入を検討する
ログ解析の基盤のリプレースを検証 Dev・ステージ・本番と同じfluentdを使ってしまっていたので、それを分割して影響を少なくしたい。 単純にfluentdを分割するより、CloudWatchLogsを利用して、各環境ごとにログを集計して可視化する。
AWSで起動させている定期バッチ (crawlerアプリ) のGCP乗せ替え検証 弊社はコンテナ化が進んでいて、ECSを利用していたが、k8sの方が運用が楽ではないかという話が上がった。
また社内でもk8s勉強会等をしており、そろそろ本番環境の移行検証してみて、知見を貯めたいというニーズがあった。
GPCのGKEでcrawler(本番)アプリを動かす。
グラフDB グラフDBは、データとデータのつながりを表現できるDB。HRMOS(採用管理アプリ)のデータは、人と企業をつなぐデータ。
人と企業のつながりを可視化できると、レコメンドとかに使えてハッピーかも!
ステージのデータを使用して、人と携わっている企業を可視化する。

私はGCPの乗せ替えチームに入りました!

スケジュール

~事前準備

1日目 移動日

  • 16:00 到着
  • 20:00 開発終了
  • 夕ご飯
  • 21:00 宿にシャワーしかなく、お風呂(温泉)を探す特殊ミッション発生

2日目 がっつり開発

  • 09:00 朝会(進捗共有、方向性が変わったりヘルプが必要であれば伝える)
  • 12:00 お昼休憩
  • 15:00 中間報告(進捗共有、方向性が変わったりヘルプが必要であれば伝える)
  • 20:00 開発終了
  • 鍋開始
    今後のビジョンを語ったり、UNOを始めたり、親睦を深める

3日目 成果発表、解散

  • 06:00 ~ 09:00まで最後のあがき + 成果発表の資料作成
  • 09:00 成果発表
    発表10分、質疑応答5分、チーム切り替え5分
  • 11:00 集合写真、解散

数日後 事業部全体に向けて成果発表

事前準備

チームごとに下記フォーマットで書き出して、他のチームに共有していざとなったらお互い助けあえるようにしていきました。

  • やりたかったこと
  • ゴール(Must/Want)
  • やらないこと
  • 現状把握
  • 合宿に行くまで必要な準備
  • 成果物の想定

私のチームはこんな感じです!

# AWSで起動させている定期実行バッチ(crawlerアプリ)のGCP乗せ替え検証
 ## やりたかったこと
   今後サービスをGKE(GCP)に移行するための知見を貯める。
   (移行するかどうかの判断をするための知見も)
 ## ゴール(Must/Want)
  - Must
    Crawler(API)をGKEに移し、動作すること。
    動かした際の知見が共有できること。
  - Want
    CI/CDができる
    モニタリングができる
 ## やらないこと
  今回は移行の検証のみ、実際に本番環境のGCP移行はやらない
 ## 現状把握
  github: https://xxx.xxx.co.jp (プライベートリポジトリのためダミーです)
  運用中のAWSアカウントの確認。
 ## 合宿に行くまで必要な準備  
  ざっくりGKEのサービスを把握する
   各自、サンドボックスのGCPのアカウント準備
   Crawlerのドメイン共有
  作業チケットの起票

成果発表

技術的負債を返却する

  • アプリケーションの操作ログの仕組みを構築する
・アプリ側の変更少なく、インフラ側で操作のログを取れないかと考えた。
 Lambda@Edge + CloudFrontでリクエストを取得し、DBに格納する。
 Lambda@Edge → SQS → Lambda → DynamoDB は作れた。
 GETは問題なく捌けたが、なぜかPOSTリクエストのレスポンスが
 403・503になってしまったりした。
 また、まだ東京リージョンにはLambda@Edgeはいなく、
 バージニアリージョンのを利用しているためか、処理が遅く感じる。
・本格導入は厳しそう、
 Lambda@Edgeが東京リージョンに来たら再度速度を測ってトライしたい。
  • ElasticSearch 1.5 → 6.3 乗せ替え
・AWS ElasticSearchはhttpしかサポートしていない。
 弊社が導入しているScalaのElasticSearchライブラリ(elastic4s_1.5.6)は
 TCPしかサポートしていない。
  = elastic4sは最低でもtcp/httpが選べる5系以上にあげないといけない。
  一部の機能だけライブラリをあげて試すうちに根本的なところのサービス名が
  被ってしまったり泥沼化。
・リーダーが一人でやれる範囲を超えてしまったので、持ち帰り。
  • Elasticache (memcached) のSPOFをなんとかする
・ElastiCache(Redis)クラスターを利用しない方を構築して、
 cacheAPiをplay-redisに書き換えてアプリからの接続を確認できた。

サービスの導入を検討する

  • ログ解析の基盤のリプレースを検証
・脱fluentdは成功。
 CloudWatchLogs(Subscription Filter) → kinesis Furanose
 → S3(ローデータ) → Lambda(整形圧縮) → S3(圧縮整形したログ格納)
 → SNS → Lambda(Slack) → ElasticSearch(Kibana)
 Kinesisの設定で苦戦したが概ね流れはできた。
・詳しくはこちらの記事参考。
 https://tech.bizreach.co.jp/posts/235/pitagora/
  • AWSで起動させている定期バッチ (crawlerアプリ) のGCP乗せ替え検証
  - GCPのCodeBuild・Container Registry・GKE・Spinnakerを
   各々ざっくり動かすことには成功。
    ただサービス間の権限につまづいたり、
    AWS運用中のをそのまま持って来たのでCPUやメモリーの設定につまづいたり、
    stackdriver(ログ)が不親切だなあと感じてしまったり、
    使いこなせるところまではいかなかった。
  - 全員そんなにこれまでGCPには携わってこなかったので、
    あまり良い結果にはならなかったが、
    次は社内のk8s勉強会とかでメンバーに助けてもらいつつ、学びあいたい。
  • グラフDB
  - 目標:Amazon NeptuneかNeo4Jに検証環境のデータを突っ込んで、クエリが叩けること。
    達成!
  - 努力目標1:その可視化(Neo4Jで目標が達成できたなら、多分簡単なはず。)
    達成!
  - 努力目標2:検証環境のデータから日次でグラフDBを構築するスクリプトを作成する
    構築するスクリプトは適当に書いた

写真

  • 宿到着
    とりあえず、欅坂観戦。
    開発初日
  • 宿にはシャワーと一人用のお風呂しかなくググると22時まで入れる温泉が近くにあると思っていたが難しく、街の中で温泉を探していました。写真は登山列車道。
    温泉を探しに
    結局一部メンバーで箱根大平台から小田原まで登山列車に乗って入りに行きました。
    小田原へ1
    帰りはタクシー。
  • 思わぬ来客が。。
    来客
    来客2
  • 開発2日目
    • 朝会
      朝会
    • 開発中
      開発二日目
  • 2日目はアルコール解禁、みんなでメンバーを褒め称えたり、チームの行く末を話しました。
    鍋_人.jpg
    イケメン.jpg
    鍋の具_白菜.jpg
    鍋_肉.jpg
  • 最終日の発表の様子
    羽田さん成果発表
    GCPチーム成果発表

まとめ

私は今回ビズリーチに入社して始めての開発合宿参加だったのですが、とても楽しくリフレッシュしながら開発をすることができました。全体的にも困ったらすぐ隣のチームに聞けたり、進捗がわかるので良い意味で煽り合いながらできました。

ただ私が携わったチーム的には不完全燃焼というか成果発表でやりきれなくて悔しいねという振り返りになってしまったので、次回の開発合宿ではもう少し事前準備とドメイン共有に割きたいです。