LINEシステムの裏側を懇親会でいろいろ聞いてきた！【LINE Developer Conference@インフラ回レポート番外編】

公開日：2014/04/17

LINE Developer Conference@インフラ回に参加してきたのでその時のレポートを報告致します。

今回は最後の番外編として懇親会で聞いてきた内容などをレポートしておきます。

ネットワークチームの方々とは残念ながらお話をお伺いすることが出来ませんでした。。

べ、別にネットワークの知識弱くて話すのを尻込みしてたわけじゃないんだからね！！

システム運営チームに聞いてきた！

自社製のALIS(Auto Linux Install System)について
- 裏でkickstarterが動いている
- web上で動かせるらしい
- OSインストール後は自前で作ったシェルスクリプトが動いていろいろインストールしている
- Globalで同じインフラを標準化するために使っている
  - 自社製のほうがいろいろ連携とかやりやすい
サーバ情報を管理するツールも自社製
監視ツールも自社製(自社製多っ！！)
自社製のツールは重い。
- DBの負荷が高すぎてグラフが表示されないらしい
- 例えばサーバ情報を管理するツールも重い
- そのため、livedoorが作ったオープンソースのクラウドフォーキャスト(ググっても出てこなかった)をチーム内だけで使えるように構築して少しでも軽くしようと企んでいるとか。
仮想サーバの場合、IPをインフラからもらってWebで入力するとボタンひとつでサーバができるらしい
物理サーバの場合はインフラに頼むと作られる
データセンターは2拠点ある
- だけどもデータセンターには殆ど行かない
50Uラックについて
- 参考までに2core、メモリ192G FusionI/O つけた1Uサーバが35台のるらしい
- 通常のものだったら限界まではいる
- マシンはラックごとで大体同じものが入っている
- 壊れた時にHDDで違うものが入ったりするらしい

DBチームに聞いてきた！

DBチームは8名(懇親会には5名来てた)
今まで大きな障害はなく(！)、事前準備をいろいろやってたり、自動監視してたり、冗長化したり、自動フェールオーバーの設定などを必ず行っている
- データロストはまだ一度もないし、あってはいけない
- 1個の障害でダウンタイムが何時間もかかるのもだめ
- DuplicateKeyの障害もないらしい(！)
レプリケーションに遅延はない
- 遅延があったらそもそも使えない
- 遅延があったら、スレーブを増やすか、マスターを分散させている
マスターを分散する場合はアプリ側で対応してもらうらしい
- マスターAとマスターBをJOINする時とか大変なのであまり推奨はしてない
MySQLのマスターがおちたときのマスターに昇格するスレーブはPriorityをふっておりそれに応じてフェイルオーバーする
SELECT文にサブクエリは完全禁止
- JOINは許している。OUTER JOIN, LEFT JOINなどなど。
DBのメモリは128G。これ以上増やしても効果がないらしい。
キャッシュヒット率、swapを見ながらメモリチューニングを行ってます
MySQLのバージョンは5.5が多い。5.6はこれからちょっとずつ使っていくらしい。まだ検証中
DB使用の内訳
- MySQL ：ユーザ情報などの格納
- Oracle：課金情報の格納
監査についてはSQLや結果をアプリに戻す際に別途MySQLに保存していたりしている(Oracleの機能とかは使ってなさそうだった)
N-baseはAPサーバにもいてメモリにマッピング情報がのっているらしい
Shardのテーブルコピー時の挙動としてはテーブルロックは切り替える瞬間にすこしだけやるだけらしい(Oracleとかのオンラインリビルドと同じ感じの挙動ですね)