読者です 読者をやめる 読者になる 読者になる

CA MOBILE エンジニアブログ

株式会社シーエー・モバイルのエンジニアブログです

第1回 CAMビアバッシュ ~ テーマは “すてる” ~

こんにちは。 シーエー・モバイルで、アドプロダクト事業を担当しているエンジニアの D.N です。 本日は、9月28日(水) に開催されました第1回 CAMビアバッシュについて、実施レポートをお届け致します。

はじめに

このたび、第1回 CAMビアバッシュと銘打ってエンジニア主導のイベントを開催しました。

過去にもシーエー・モバイルでは、社内での勉強会やエンジニア合宿など、エンジニアが中心となったイベントは数多く開催されてきました。

そんな中で、日頃業務に邁進しているエンジニアを労う意味もこめて、社内のエンジニア全員を対象とし、CAMビアバッシュという形でライトニングトーク大会を開催する運びとなりました。

テーマは "すてる"

今回のイベントのテーマは、"すてる" です。発表の紹介の前に、これについて少しだけ説明します。

エンジニアの方であれば、頷いていただけることと想像に難くないのですが、 サービス開発を進めていくと、多かれ少なかれどうしても発生してしまうのが技術的負債です。

技術的負債とは何でしょうか。

技術的負債とは、例えば、プログラミング言語フレームワークが古すぎたり、プロジェクトの設計書が最新版ではなかったり、 あるいは、特定のソースコードが著しく属人化している、などなど、理想的な継続開発を行う上で、阻害要因となるものを指します。

そういった数多くある技術的負債のうち、今回のイベントでは、開発環境サーバを圧迫するリソースなどにフォーカスを当て、 以前こちらのブログでも紹介させていただいた、CAM「技術戦略室」のメンバーが主体となって取り組んだ "すてる" 活動をライトニングトーク形式で発表しました。

tech.camobile.com

発表の内容

それでは、発表の内容を個別に紹介します。

1番目 : N・K チーム

f:id:cam-engineer:20161005150120j:plain:w300 f:id:cam-engineer:20161005150214j:plain:w300

  • 今回やること
    DBのクリーニング(共通開発DBサーバのおそうじ)
  • 解決すること
    • 容量問題を削減
    • 意味不明なものをなくす
    • peropero というナゾのDBが容量を圧迫している...!
  • 捨てる習慣を作る
    問題を解決したあとも継続的にキレイにできるように。

f:id:cam-engineer:20161005152104p:plain ※注釈:こちらの wiki は D.N が纏めさせていただきました!

  • 活動詳細
    • 削除方針
      • Phase1: まずは明らかに不要なDBから
      • Phase2: 次にクローズ or 移管したサービスのDBを
    • Slack にて告知して確認
    • 作業時は、ダブルチェック
  • 活動結果
    • Used 299GB -> 253GB
    • DB数 199 -> 131
      ※注釈:DB数であり、テーブル数ではないです。
  • まとめ
    • DBキレイになりました
      • 容量削減
      • 用途がわからないDBをなくした
    • 定期的にアラートを上げれる仕組みを作りたい

2番目 : M・N チーム

f:id:cam-engineer:20161005150923j:plain:w300 f:id:cam-engineer:20161005150937j:plain:w300

※注釈:こちらの発表は、某テレビ番組ビフォーアフターのナレーション風にお楽しみください。

過去の遺産を抱え続けるプロジェクトがありました。

  • 2015年のリニューアルから1年
  • 使わなれないのに消せないファイル
  • 肥大化するロード時間
  • 日々の運用の中で増え続けるバックアップ
  • 長年使い続ける機能

そんな状況を改善するべく、二人の匠が立ち上がりました。
まず最初に目をつけたのは、本番DB上に残った1年分のバックアップ。
これは、まとめて300テーブル以上を一気に削除。
すると、なんということでしょう。
こんなにスッキリしました。
WorkBench上で見ると、利用しているTableとBackupテーブルが散乱していた状況も
ごらんのとおり。格段に見やすくなりました。
ちゃんと3ヶ月以内に保存されたものはバックアップとして残しておくことも忘れません。

DB名 開発環境 ステージング環境 本番環境
A 86 65 94
B 44 39 68
C 33 36 66
D 41 43 66
E 44 12 17
63 28 21
合計 311 223 332
  • 今回、削除対象となったテーブルは866テーブルにもなりました

DB以外にも開発環境の不要ディレクトリ削除

監視ツールも綺麗に

  • MRTG の撤廃
    • UI がダサい
    • 更新が遅い
    • リロードしないと表示が更新されない
    • 情報の更新が止まる
  • Mackerel の導入
    • https://mackerel.io/ja/
    • 監視通知機能付き
    • とにかく見やすい! キレイ!
    • グラフはもちろん自動更新!
    • 拡大すれば1分間隔で参照可能!
    • その他の機能
      • Slack通知
      • サーバIP、ホスト名管理
      • ダッシュボード
      • グラフ共有
      • サービス、ロール機能
      • ホスト別アラート通知設定
      • 外形監視
      • Nagios, Munin, Sensu プラグイン
      • AWS 監視サポート
      • API での各種情報取得
      • 将来予測機能
  • 実際の利用シーン

f:id:cam-engineer:20161005153251p:plain

Memcache リプレース時、旧Memcache サーバへアクセスがこなくなったことを監視するのに役立ちました。

f:id:cam-engineer:20161005153304p:plain

  • 12時にトラフィックが一気に増加。
  • 何かしらイベントが行ったことが確認できる。

3番目 : E・T チーム

f:id:cam-engineer:20161005151123j:plain:w300 f:id:cam-engineer:20161005151148j:plain:w300

1. あるプロジェクトで運⽤しているリポジトリのブランチ整理

Mergeされたものや、検証でつかって不要になったもの、closeされたものが対象。
プロジェクトの特性上、コマンドで⼀括削除はできないのでGitHub Enterprise(以下、GHE)から内容を確認して1つずつdelete
作業結果
ブランチ数 593 -> 253
半分以下に!!!!!(それでも多い)

気づいたこと
* だれがブランチけしてないかがわかる
* 意外と作業フローが徹底できてなかった

2. 開発環境の不要なログ削除

$ find /x/*/logs/ -mtime +7 -type f
103641 ファイル。。。
$ cat /x/bin/delete_app_log_cron.sh [/x/bin 18:47]
#!/bin/bash
find /x/*/logs/ -mtime +7 -type f -name "*log" | xargs rm
# cat /var/spool/cron/root
# Remove logs in /x/PROJECT/logs
0 8 * * * /x/bin/delete_app_log_cron.sh > /dev/null

BEFORE

  /dev/sda2 557346600 462318700 66716348 88% /

AFTER

  /dev/sda2 532G 433G 72G 86% /

まとめ

  • 開発環境のログなんて⼀週間もあれば⼗分だよ!
  • 消そう!

3. 自社共通フレームワーク製媒体のエラー追跡⽅法の改善(途中経過 報告)

現状

前⽇のログファイルをERROR, WARNで grep して、MLに結果を送付

ある連休明けの朝

約2000行のログメール × 83通
OMG

問題点

  • (嬉しいことに)プロジェクトが増えメール件数が増えた
  • 無視して問題ないログも増えているがフィルタリングできない( egrep -v を媒体ごとに増やすのは現実的じゃない)
  • 無視していいならそもそもログを吐かないようにすれば良いが、可視化されていないためジャッジしづらい(個⼈の感覚に依存)
  • ⼈員不⾜による負担増
  • エラーの増減の傾向を、感覚でしか追うことができない

⾼速横転開発の恩恵の反⾯、もはやこのままでは耐えられない
改善開始
EFKスタック

今後の動き

  • Fluentd(td-agent)のインストール
  • ログ収集の開始
  • Kibanaでの⽇々の状態監視(fto-sysエンジニアにて)
  • MLへのメール廃⽌
  • ログフォーマットの⾒直し

Fluentdインストール状況

対象サーバ16台中10台導入済み

ログフォーマットの⾒直し

  • ⼀個のログが改⾏で分かれてしまっている
  • 将来的には jsonにするなどの、構造化が必要

4番目 : N・E チーム

N チームのやったこと

f:id:cam-engineer:20161005151331j:plain:w300

1. GHE ブランチの削除

  • 課題
    開発が進むにつれて,GHE に feature ブランチが散在している……。
    必要なものと不要なものが混在している状態は混乱のもとなので,放置されていたものを綺麗にしました。
  • 対応内容
    • GHE 上で merged となっているものや,いらないブランチを一個づつ削除した。
    • 各個人のローカル開発環境では,以下のように削除した。
git br -d $(git br --merged | egrep -v 'master|develop|*')
  • リモートで消されたブランチをローカル環境に反映を忘れずに。
git remote prune origin あるいは git fetch -p origin など
  • 結果
    ブランチ113個から9個へ!
    また、本番リリース手順書に以下の項目を盛り込みました。
  • GHE 上でタグを付ける。
  • GHE 上から不要なブランチを削除する。

2. パスワードなどの秘匿化

  • 課題
    本番環境の MySQL のパスワードなどが設定ファイルに直で書かれているプロジェクトがあるため,環境変数から読み込むようにしました。
  • 対応内容
    dotenv ( https://github.com/bkeepers/dotenv )とは
    • .env ファイルに記載されている環境変数を読み込んで使用できるようにするための gem
    • Rails の場合,dotenv-rails という gem を使うと autoload してくれる。
  • 補足

E チームのやったこと

f:id:cam-engineer:20161005151417j:plain:w300

  • エラー通知メールの抑制
    • 現状
    • 課題
    • 対策

現状

  • アプリやメールサーバのログをlogmonで監視
  • エラーログが出た場合、管理者にメールで通知

課題

  • 全てのエラーを一律メールで通知しているため、件数が多くなり、重要なエラーが埋もれてしまう
  • swatchを導入
    • ログファイル監視ツール
    • 所定のパターン出現時、所定のアクションを実行
    • アクションは「頻度」を設定可能

5番目 : O チーム

f:id:cam-engineer:20161005151634j:plain:w300

0 さん率いる開発メンバーそれぞれが "すてる" を行いました!

完全停止の媒体のクーロンを消す

結果 f:id:cam-engineer:20161005151741p:plain

  • ユーザに悪いイメージを与えないように、サイトのドメインを止める
  • 個人のローカル・リモートブランチの精査、削除

    • 396 -> 1
    • 1つ気になることとして、いなくなったメンバーのブランチがある!
  • apache, nginx の conf を綺麗にした話

  • ミドルウェアが動かないので OS を変えた話
  • デプロイを整理した話
  • ディレクトリ整理の話

6番目 : N with Infra チーム

f:id:cam-engineer:20161005151857j:plain:w300

すてるもの・すてたいもの がたくさん

  • 古い機器
    • サーバー(R300とかSolarisとか)
    • スイッチ(2960G)
    • disk
  • サービス終了後の不要なもの

だけど、消すのは難しい(´・ω・`)

  • サーバー内のプロセスが起動している
  • ヘルスチェックが成功している
  • サービスのあいのり
  • DNSの設定が残っている 終了サービス ・ ・ ほんとに消して大丈夫だろうか(つд⊂)
    ⇒ エンジニア全体の協力が必要!

  • 積もり積もったBIGIP古い証明書 130個

要因

  • BIGIPの仕様の問題(アクティブスタンバイで証明書削除の同期できない)
  • サービス終了後の削除フローなし

今後のすてる

  • DNSコメントアウトされているもの
  • GIP(サービス終了時に返却お願いします) と BIGIPの設定
    ⇒ 新ネットワーク環境

BIGIPの閲覧アカウントを共有しますので、いらなくなったIPは確認してくださいね。
宣伝:障害対応(よくある事象) を纏めましたので、みなさん、トラブルシューティングにご参照ください。

7番目 : K・H チ-ム

f:id:cam-engineer:20161005152650j:plain:w300

自称変態キーボーダーであるKさんは、今回の「第1回 CAMビアバッシュ」の発案者!!

  • 捨てたいものはないですか?
  • 捨てるって何?
    • 10万規模のコミット
    • 不要ファイルが大量にあるせいで肥大化
    • ブランチの命名規則がバラバラ
    • ログの削除やブランチの整理
    • git-svn使って移行
  • 捨てたのもの
    • httpd.conf@共通開発環境
    • 大量にあった conf のファイルをプロジェクトごとにコメント付与して見やすく!
  • 過去に捨てたもの
    • 『伝える第9回 大改造劇的ビフォーアフター 疲弊するシステム』
      注釈:過去に、社内勉強会にて、上記のタイトルで発表を行っていただきました。 「伝える」勉強会とは何かについては、また別の機会にこのエンジニアブログにてご案内があるかも?!

まとめ

今回、CAM 初の試みとしまして、ビアバッシュという形でライトニングトークのイベントを開催致しました。
当日は、70名以上のエンジニアが集まり、笑いあり、(当時を思い起こしつつ)涙ありの楽しいイベントにできたと思います。

"すてる"というテーマで、各チームが発表した今回の内容は、これで終わりにするのではなく、 エンジニア一人ひとりが業務の中で意識し、ワークフローに組み込むなど継続的に取り組んでいくことで効果が見えてくるものと思います。
これからも、日々新しく生まれる技術を追いかけながら、技術的負債を残さないように、シーエー・モバイルでは社内環境整備に取り組んでいきたいと思います。