インフラを意識したアプリケーションの書き方

Hatena 新卒研修2016

Apr 11th, 2016

Profile

• id: Songmu (ソンムー)
• Masayuki Matsuki
• おそらくはそれさえも平凡な日々 http://www.songmu.jp/riji/
• https://metacpan.org/author/SONGMU
• 趣味はCPANizeです
• 東京オフィス チーフエンジニア
• 去年を含めてISUCONで3回優勝したことあります

Agenda

• インフラを意識してコードを書くと何が良いか
• データベースについて
• 技術選定や技術の深め方

インフラを意識すると何が良いか

• ISUCONで優勝できる(かもしれない)
• ...

インフラを意識すると何が良いか(改めて)

• はてなはベンチャー
  • 全員が下から上まである程度できるというところでスピードを高めている
    • ハードウェア
    • ネットワーク
    • OS
    • ミドルウェア
    • Webアプリケーション
    • クライアントサイド
• もちろん全部はできないので役割分担
• 完全に縦割りになってお互いの共通言語がなくなるとまずい
• 単純にサーバーを減らせるとコスト削減

インフラを知ることは強みになる

• IaaSの台頭により多くのものが隠蔽化されている
  • 隠蔽化しきれないほころびもある
  • 隠蔽化されたところに想像を巡らせる
• はてなはデータセンターがある

さわりでいい

• http/1.0を理解する
• Unixのプロセスモデルを理解する
• RDBMS/SQLを理解する
• Infrastructure As Code ← いい時代

Webアプリケーションの特性

• IOメイン
• 単純 (でなくてはいけない)
• 複雑な演算とかはしない
  • するなら別のところに任せる
• データベースの読み書きに気をつける

データベース

• はてなではほぼすべてのサービスでOSSのRDBMSを利用
• 主にMySQL
• MackerelではPostgreSQL

何故RDBMSを使うのか

• モデリングを適切に行う
  • データモデリング共通言語としてのSQL
  • スキーマを見れば何やっているかだいたい分かる
  • 引き継ぎとかで楽
• データストアは最終防衛ライン
  • しっかりとデータに制約をかけられるデータストアを使う
  • スキーマレス幻想
• 変なデータは10年残る
  • 一時的なサーバーエラーのほうがマシ

RDBMSを使うことでよく言われるネガ

• アプリケーションとDBが相互に依存してしまう
  • DBを変更するときにアプリケーションを気にしないといけないしその逆もある
  • 疎結合じゃない
  • ただコレはアプリケーションとDBを一体として考える
  • 複数のコンポーネントが一つのDBに依存するとよくない兆候
• 「共有データベース」アンチパターン (O'Reilly マイクロサービスアーキテクチャ)
  • DBに依存している複数のアプリケーション間による依存スパゲッティ
  • コレは時代としてはてなは見事に通り過ぎている
    • 昔は良いとされていたことがアンチパターンになる例
• でかくなりすぎて分割が難しくなる
  • 便利なのでついついドメインをわけられるようなデータであっても同じDBに入れてしまう
  • とは言え、アプリケーション開発者側としては一つのDBで頑張りたい
• 「パフォーマンスが悪い」というFUD
  • 単に使いこなせてないだけ
  • 「オンメモリKVSの方が爆速」 → 使いどころが違うだけ

巨大なDBを負荷分散する手法

• 冗長化
  • Multi Master
  • Slave参照
• キャッシュ
• シャーディング

時代の変遷は意識する必要がある

• 一昔前の主流: Webアプリケーションは(開発が)軽量な言語で作り、データストアを堅牢にする
  • 今でも通用しないわけではない
• 表現力の高い言語で高度な抽象化をおこない、Webアプリケーションレイヤーでも高度なデータモデリングをおこなう
  • 各種クライアントとの共通データモデリング手法のデファクトが求められている (JSON Schema等)

RDBにおけるテーブル設計

• 「SQLアンチパターン」は良い本だが…

正規化

• 極力正規化しよう
• サロゲートキーを使うことが多い

kamipo TRADITIONAL

SET SESSION sql_mode='TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BY'

• とにかく不正な値が入らないようにする
• http://www.songmu.jp/riji/entry/2015-07-08-kamipo-traditional.html

リレーションシップについて

• 各テーブルはidカラムがpkになっている(サロゲートキー)
• hoge.id ← hoge_id でのリレーション
  • 逆に外部キーではない時は *_id は極力使わない (_code とか)
  • 外部キー制約を使わない代わりに自動検出しやすくする
• リレーションが複数あるような場合は、カラムにprefixを付けて調整する
  • ex. user.id ← user_id, friend_user_id
  • friend_idとかにしてしまうのはNG

サロゲートキー

• SQLアンチパターンにおける 「IDリクワイアド」アンチパターン
• アンチパターンだとよく言われるが無難なことも多い
• primary keyの要件
  • uniqueであること
  • immutableであること
    • 意味を持たないこと
    • 意味を持ってしまうと変更したくなる
  • 例: TwitterのID/はてなのID
    • はてなIDは変更不可/TwitterのIDは変更可能
    • もちろん両方共内部的に不変な数値のidは持っている

サロゲートキーの発番

• 時系列に並んでいることが望ましいことが多い
• はてなではあまりAUTO_INCREMENTを利用していない
• 様々なテクニック
  • SELECT UUID_SHORT()
  • snowflake等の採番ソフトウェア
  • MyISAMを用いた発番テーブル (古い)
• 採番機構を採用するメリット
  • INSERTをする前にidを取得できる
  • AUTO_INCREMENT と違って、マスタ切替時に、値がかぶるリスクがない
  • 採番の負荷を分散できる
• デメリット
  • 自分でINSERTしたい時に、どうにかして採番する必要がある

外部キー制約

• MySQLではあまり使わない
  • これも SQLアンチパターンにおいてはアンチパターンとされている
• パーティション切れなくなるのが痛い
• 余計なINDEXが作られる問題
• 参考: 我々(主語が大きい)は何故MySQLで外部キーを使わないのか
• まあこれはバッドノウハウの類

インデックス

• 使われているデータ構造と特性

「心にいつもB+Treeを」 by kazeburo

• フルテーブルスキャンを避ける
• 必要以上に張らない
• 張る順番に気をつける
  • B treeを意識して、どういう順番で絞り込んでいくかを考える
• カーディナリティの少ないカラムをINDEXに含めるときにどうするか問題
  • パーティションを使うなど
• http://www.slideshare.net/kazeburo/isucon-yapcasia-tokyo-2015

Exercise: 蔵書管理システム

• ユーザーがどれくらい本を持っているか管理したい
  • user_id
  • book_id

データ型について

https://dev.mysql.com/doc/refman/5.6/en/storage-requirements.html

• 1レコード1byte削れると、1億行あるテーブルで、100MByteの節約になる
• データ量を気にしつつある程度規約ベースで考えるのが吉
• 細かいところで悩む位だったら規約を富豪側に倒したほうが良い気がしている

個人的な数値型の方針の例(MySQL)

• JOINされうるキーのデータ型を揃える (重要)
• 数値系は基本的にunsigned
  • ただ、Java界だとunsignedを使わない…
  • PostgreSQLにはunsignedは無い…
• マスタデータのid: SMALLINT
• トランザクション系のid: BIGINT
• フラグや数パターンしかないtypeなど: TINYINT
• データ量が少ないマスタデータでもidはTINYINTにはしない(混乱を防ぐため)
• 日付はDATETIME(DATE)で構わない
  • MySQL5.6.4以降は5byteだし(マイクロ秒を格納しない限り)
  • TIMESTAMP型は非推奨になりつつある
• JSONを格納するカラムとかはカジュアルにTEXTを使う
  • ただし、TEXTの上限は実は65535bytes
  • MIDEUMTEXTとかLONGTEXTとかある
  • 最近はJSON型がある
• 小数型はなるべく使わない。使うときはDECIMALの方が吉
  • 誤差が出にくいように

文字列における767bytes問題(MySQL)

ユニークキー制約をかける場合、そのフィールド長の上限が767bytesになっている。 文字列にユニークキー制約をかける場合等に注意が必要

• UTF8だとVARCHAR(255)
• UTF8MB4だとVARHCAR(191)
• VARBINARYとかカラムをCHARACTER SET latin1する手とかもある
• 最近だと innodb_large_prefix というものがあって 767bytes 制約を外せる

その他MySQLアンチパターン

• 空行へのロック(FOR UPDATE)
• no kamipo TRADITIONAL
• INSERT IGNORE
• LIMIT OFFSET
• ORDER BY RAND()
• ...等々

何を情報源とするか

• 公式ドキュメント
• 書籍
• 同僚

その他技術全般の話

セオリーやパターンを知る

• 知る
• それから理解する

持ち駒を増やす

• 言語
  • システム言語からアプリケーション言語まで
• ミドルウェア
  • memcached
  • Redis
  • Nginx
  • Haproxy
  • Keepalived
  • ElasticSearch

早すぎる最適化を避ける

• ハードウェアの進化が進んだ結果、不要になる技術もある

ミドルウェアの特性を知る

• どういう形でデータを持っていて、処理にどれくらい時間がかかるか
  • メモリ消費
  • ディスク消費
  • IO
  • 帯域

新規プロジェクト時

• インフラアーキテクチャーを含めて設計する
  • Webアプリケーションはミドルウェアまで含めて一つのソフトウェア
• スケールアウト・アップ戦略まで考える
• 本番投入前に負荷試験とかできると望ましい

技術選定

• コントロールできる技術を選ぶ
  • 技術に振り回されない
• 分散システムかmaster-slaveか
  • 小さなものを組み合わせる
  • Unix哲学
  • インフラアーキテクチャでも同じ
  • 「ミドルウェアを愚かなままにし、エンドポイントに知性を保持する」 (マイクロサービスアーキテクチャより)

危機察知能力

• やばそうだな、と勘付けるように
• これもパターンがある。インフラを知ることで気付きやすくなる
  • 大量の更新や削除が一度に発生しないように
  • 一斉同時アクセスを避ける工夫など
    • mackerel-agentの例

障害対応

• 最初は何もできない
  • 何もできなくてもそこにいる
• できることを探す
• 無力感をバネに成長する
• 根性論ぽいけど…
• もちろんそんな根性論が不要になるくらい仕組み化することが一番大事

技術の深め方

• 1mを10箇所ほるのと10mを1箇所掘るのでは労力がぜんぜん違う
• 深めに掘る
  • 深く掘ると横を掘れる
• 同じレイヤーの技術を浅めにたくさん掘るのは効率が悪い

個人サービスを持つ

• 砂場
• 自分のサービス
• たまに作り変えて遊ぶ