はじめに
dots. Conference Spring 2016 5日目午前の部「大規模Webサービスを支える技術」に参加してきましたので、メモを共有します。
イベント概要
日時：2016/02/28(日) 10:30 〜 14:15
http://eventdots.jp/event/580339
頂いたものたち
セッション
10年間戦えるWebサービスのスケールアウト/アップ
株式会社はてな 田中 慎司氏
はてなのシステム基盤の変遷
初期（2003年頃〜）
主力ははてなダイアリー。オンプレ 自作サーバ LAMP。中盤（2006,7年頃〜）
LAMPはそのまま。ユーザ増加に伴いLB/JOBQueueは追加。自作サーバ→ベンダ製ハードウェア。現在
主力ははてなブログ。Nginx perl mysql AWS。はてなダイアリーは延命策中（HWリプレース、centos5→debian）。
10年継続すると変化すること
プログラミングパラダイム
- 厚いフレームワークから薄いフレームワークがトレンドに。
- 動的型付け→静的片付け
開発プロセス
- 小規模チーム→中規模チームへ
- テスト、レビューが当たり前な文化ができてきた
- スクラムの導入(一部)
外部環境
- 開発リソースの変化 売り上げや会社の戦略で変化。
- 開発対象環境 → デバイスの変化 PCブラウザだけ考えればよかったのが、スマホetc.
ユーザ属性の変化
- エンジニアだけじゃなく、普通の人も増えてきた
中長期的にパフォーマンスマネジメントをどう考えるか
- 短期的にパフォーマンス出すには方法論はいろいろある
- ボトルネック解消、サーバ増やす、クエリ改善、キャッシュetc..
- 10年やってくためには短期的な改善だけではなく、キープしていかないといけない
- 変化しない、しにくいもの
- DBスキーマやシャーディング。はてなのユーザDBのスキーマは2001年に切ったものがベース。負債が今も残っている。
- 基本アーキテクチャ(実装言語 キャッシュ方法)
- 機能追加は容易 でも 削除は困難
パフォーマンスチューニングした後
- 日々の機能追加は、基本的にパフォーマンス劣化に繋がりがち
- どうやってパフォーマンスが劣化していくことに気づくがが重要
- はてなでモニタリングしていること
- 応答時間
- PV/CPU。PV数をCPU%で割る → 応答時間だけ見てても分からないことも分かる。これを時系列、サービス間で比較することもある。
- コストパフォーマンス指標は効率改善タスクの理由としやすい。現場もマネージャも。
- この手の改善は一気にやると大変なので、小規模な変更の積み重ねで対処する。
- とはいえ長いことやっているとメンテナンスが厳しい場面も出てくる。するとフルスクラッチしたいと言い出す人がでてくる。でもフルスクラッチは最終手段。想定スケジュール、リソースでは収まらないことが多い。基本的には部分的に書き直していく。
次の10年について
変化に強くなる
- シンプルなアーキテクチャを採用する
- 効果の薄いレイヤを導入しない。面白そうだから使い出すのは簡単、やめるのは大変。
- システム間を疎結合に。マイクロサービス。ただし障害時にどのサービスが原因になっているか、パフォーマンスのボトルネックはどこか、分かりにくくなる。メンテナンスはしやすくなるがトレードオフ。
- アプリケーション実行環境は、下位レイヤ(OS etc)との依存減らす（docker etc）
- クラウドは普及していくが、コスト管理はしっかりやらないといけない。AWSは使っていくと高くなる。
- 機械学習は組み込むのは簡単になってきているが、技術的負債に繋がりやすいと最近よく言われている。
まとめ
- 10年やってるといろいろあって大変だが、それが面白さに繋がっているところもあるので頑張っていこうという気持ち
- 10年後は予測不能なので頑張っていきましょう
メルカリDevOps物語 - 俺たちの戦いはこれからだ -
株式会社メルカリ 佐々木 健一氏
サービス規模の変遷
- アプリダウンロード数2014年に400万、今は2400万。
- Request/Secは、2014年に3k/Sec、今は20k/Secくらい。
- server 2014年から50%増しくらい
- DB 2014年から+9台
- インフラは、日本ではさくらの専用サーバ+クラウド、USではaws。
- 共通で akamai,route53,cloudfront,bigquery。
- 2014年頃は、LB無しでwebサーバをグローバルに直接出していた、DNSラウンドロビン。redis、php53。
- 今は、LBを導入している。redis→memcache、php53→php56。
今まで起こった問題
アクセス増
- CPU,network帯域が足りない。物理だしすぐに増やせない。
- 解決策
- もともとさくらのクラウドだけでやっていたが、専用サーバにしたら安くなった。スペックも上がった。
- DNSラウンドロビンからnginxを使うようにした。nginxにSSLアクセラレート、SPDYを担当させることで効果があった。
- mysql index tuning
- データベタ書きのphpをrequire_onceしていたのを、複数のtsvにわけて必要なデータだけロードするようにしたら速くなった。
増え続けるデータ
- 履歴データ、商品データ。ディスク容量足りない、検索レスポンス遅くなる。
- 解決策
- DBを役割ごとに分割。
- 検索はsolrを導入していたが、今までは1クラスタだったのを、直近数日用と昔用でクラスタを分けた。更新は両方に実施。nginx+luaで、まずlatestを参照して、検索結果が少なければ昔クラスタを参照するようにしている。
- fluentd→bigqueryで分析。kibana、norikuraも。
増え続ける仕様
- 2014年は週１リリースルールだったが、１回でリリースする内容が膨れ上がってしまった。
- ロールバックが大変。
- 毎日緊急リリース的な状態になってしまった。
- 解決策
- たくさんリリースすることにした。
- googleカレンダーにPR内容書いておくと、botがリリースしてくれるようにした。
- 今のデプロイの仕組みはメルカリのテックブログに書いてある。
- http://tech.mercari.com/entry/2015/10/15/183000
不安定なデプロイ
- rsyncでappサーバにphpコードを配っていたら、phpのopcacheと不整合で500エラーが発生したりしていた。
- 解決策
- nginx+lua ngx_dynamic_upstream を活用。LBから切り離して、デプロイして、完了したら再び組み込む。
まとめ
- いろいろ頑張ってきたけど、そんなに特殊なことはしていない。
- ローマは1日にしてならず。
スケールアウト再考 - 数千億アクセスへの道 -
Supership株式会社 山崎 大輔氏
広告システムの規模について
- 月間数千億アクセス
- サーバ1000台程度
- レスポンス50〜100msec
- ユーザ数億UU
- 基盤はほぼオンプレ。なぜならこの規模でawsを使うと高いから。オンプレにすることで、awsの1/3くらいの金額でできている。
リトルの法則
-
いつも10人並んでいるATMがあるとする。1台増やすとどうなるか。
- 行列人数は0に近づいていく。入りと出が同じだったのだから、台数を増やしたら出が多くなるので、徐々に行列は減っていく。5人にはならない。
- 逆に、入りの方が多ければどんどん並んでいく。
-
まとめると
- システムの処理性能 ＞ アクセス よい
- システムの処理性能 ＜ アクセス 悪い
スケールアップ/アウトは、どちらもシステムの処理性能 ＞ アクセスとするために実施することである。
1%でもアクセスが多ければ、システムは無限に遅くなる
逆に、応答速度が10倍遅くなっても、10台サーバを増やす必要はない
システムの処理性能 ＞ アクセス を1%でも満たせばいいので、大抵は数割の増強で事足りるはず。
逆に、1台減らしたら10倍以上遅くなることもある。
ミドルウェアの選定基準
- ピーク性能ではなく、性能の安定度（分散の小ささ）に着目する＝制御がしやすい
- パフォーマンスが不安定なものはピーク性能がよくても良くないものだと考える
- 複雑な機構をもったものはさける、単純なものを選定する
- GCやデータリバランスなどコントロールしにくい挙動のものを避ける(MongoDB,Cassandra...)
- やかんは壊れない
スケールアウトあるある
- システムは設計を端折ったところからほころびはじめる
- あらゆる箇所が現在の100倍になっても大丈夫か確認しよう
- 処理能力を超えると一気にダメになる
- ピークアクセス時の予兆を見逃さない
- ちょっと超えてすぐ復旧したからよかった、ではなく、すでにやばい状態なのですぐ動く
- カナリアサーバの準備
- ちょっと弱いサーバを組み込んでおいて、それに問題があったら動き始める
- アクセスの強制的な平準化
- 例えば2割のアクセスを捨てて、8割救う。それで安定稼働まで持っていく。
- それでもダメなら
- スケールアップも積極的に
- ネットワーク帯域はスケールアップしにくいので、ネットワーク帯域を使わないようなシステム設計を心がける
まとめ
- システムの処理性能 ＞ アクセス を強く意識
- 普通を積み重ねれば数千億アクセスは十分対応可能
- とはいえ大量アクセスを浴び続けることで養われることもある
パネルディスカッション
株式会社はてな 田中 慎司氏
株式会社メルカリ 佐々木 健一氏
Supership株式会社 山崎 大輔氏
クックパッド株式会社 成田 一生氏
会場からの質問
メルカリさんへ redisからmemcachedへ切り替えた際の判断基準は？
- redisクラスタを組んでいたが、謎の挙動で自動で切り替わらなかったりして困っていた。そんな時mixiからmemcachedに詳しい人がjoinしてくれたので変えた。
マイクロサービスは今後も流行っていくと思いますか？それとも古くなったら全体を取り替えればいいじゃないかと考えますか。
- (cookpad)流行り廃りというよりはアーキテクチャの一つで今後もあると思います。経験では、ロジックを分けておくと問題発生時に切り分けやすい。 railsとマイクロサービスの相性はけっこう悪いと思う。型でしばったRPCとかできないのでみんなで規約を決める感じになる。 ただ、railsはバージョンアップに追従してかないといけないものなので、マイクロサービス化しておくとサービスごとにバージョンアップしやすいとは言える。
- (はてな)マイクロサービスという言葉が流行る前から「サブシステム」と呼んで同じようなことをしていた。
- (Supership)上手に切らないと負債になっていきそうな気はする。
はてなさんへ フルスクラッチは最終手段と言いながらはてぶをフルスクラッチで作り直す判断したのはなぜ？
- いろいろやるのが大変になったのでそろそろやろうかとなった。まだ途中だが。
- cookpadも2〜3年周期でフルスクラッチムードがでてくるが毎回破綻している。coldfusionから2006年にrailsに移行したのが伝説にはなっている。このころはエンジニア3人くらいでコード規模的にもギリギリだったかも。みんな若かったので気合いでやった。
構成管理とかどうされてますか？
- (はてな)2006年くらいから自作ツールを使っている。その流れでMackerelがある。基本的には何かDBで管理しないと破綻すると思う。SaaSのものがモダンじゃないかと思う。
- (メルカリ)スプレッドシート！監視目的でMackerel使い始めたが、この流れはフラグたったな。プロビジョニング用途でansibleを使っている。スプレッドシートとずれてるなってことがある。
- (はてな)hostsやaws consoleで管理しているという話を聞いたことがあります
- (Supership)たいてい二重か三重管理になっちゃってるんじゃないかな。
- (cookpad)逆にサーバ一覧って何に使うんですか？
- (Supership)起動してるけど誰もわからないサーバとか。ec2で知らないインスタンスが動いているとかないですか？
- (cookpad)オンプレだったら起こりうるかもしれないですね。cookpadではec2インスタンスをたてる時にroleとホスト名を設定するルールにしている。
- (Supership)逆引きで管理するのはアリかもしれないですね。googleとかはIPの下一桁の数字で管理してたみたい。xx.xx.xx.x9だったらメールサーバ、とか。
Supershipさんへ カナリアサーバはどのくらいの割合で入れていますか？
- 1~2台で十分だと思う。実は、オンプレでやっているのでサーバの個体差があったりする。たまに変なやつを見つけたら、そいつをカナリアサーバと呼んだりしてる。
はてなさんへ コスパの指標でpv/cpu、あれはコア数あたりですか？全体ですか？
- 20coreだったら2000%として。CPU使用率の合計。アプリケーション全体の効率を見る目的。
- 個々のアプリサーバのPV単位の見方もする。
長年やってきたノウハウを暗黙知とさせないためには？
- (はてな)難しい。障害が起きた時にどうなってるか職人芸みたいな。
- (Supership)はてなやcookpadはみんな長いしやめないからなんとかなってると思う。
- (メルカリ)USに力入れてるので、分かる人がUS時間で動いてたりする。のでコードをちゃんと読むとか地道に頑張っています。。
- (Supership)この4社は退職率が低いのでズルできてると思う。。
- (はてな)新入社員とかに、いかにリスクを取れる環境を用意してあげるか。はてなだとはてラボとか。本番サービスだけど落としても何とかなるサービス。
- (cookpad)ドキュメント書いても最新かどうか証明できない。なのでgithub enterpriseにドキュメントではなくコードで残すようにしている。
- (Supership)そもそも論として、会社にメンバーが残ってくれるようにしていく。いい会社を作る。
新しいサービスを作る時の基盤選定（Iaas/PaaS/オンプレとか）について、何かわかりやすい選定基準とかあれば。
- (メルカリ)人によっちゃう。ブラックボックスが嫌いな人と、らくちんがいい人。USはIaaSを選んだ。急ぐ時はRDSを使ったりもするけどベースはIaaSにしている。
- (cookpad)PaaSで動くならPaaSにしたほうがいいと思う。小規模な会社だとインフラエンジニアがいなかったり。awsはマネージドと言ってもあまり管理してくれなかったり。流行ってきたらIaaSやオンプレにいかないといけない時がくると思うけど、まずはPaaSでちゃらっと作ってみれればいい。
- (Supership)まずはマネージドではじめて、流行ったらIaaSやオンプレ、というが流行りかな。
- (はてな)どれだけ稼げるサービスなのかが重要。1PVあたりいくら稼げるのか。マネージドサービスは、トラブった時に手が出せないのをどれだけ許容するのか。awsだけでいいのか、gcpも使うのか。今はいろんなファクターがある。
- (Supership)Paas自体のサービス終了リスクがある。「買収された」というのは１つのシグナルになると思う。買収された時に、そのサービスを引き続きやりたい経営者と辞めたい経営者に分かれる。
構成管理ツールは何をつかってますか？（メルカリ佐々木氏より会場へ逆質問）
※会場はansibleが多かった。
- (cookpad)cookpadは名前空間がかぶるからchefを使わなかったというのが半分本当。recipeとかcookbookとか普通にテーブルあったりするので。。
- (cookpad)puppetは好きだがitamaeにリプレースしたのは、そのタイミングで古いゴミを捨てられたり、いろいろバージョンがあがったり、メンバの理解が深まったりするから。定期的にそういうことしていこうということにしている。どうせいろいろ自前で機能追加したりするので、それなら薄いツールを自分たちで作ることにした。
大規模なシステムを支えていくにあたっての心構え
- (cookpad)システムが大規模になるのはそれなりに売れて、組織も大きくなってというのがある。なので事業継続性が大事になる。負債が問題になる。なのでシンプルなものを作るようにするべき。
- (メルカリ)シンプルに作ること。どうしても変更しないといけない時は、シンプルということを念頭に入れて大胆に方針を考える。それを実行する時は繊細に綿密に計画をする。
- (はてな)大規模システムは盆栽。組織によって要件が千差万別。ちゃんとこういう感じにしていこうとか、成長に伴ってこうしていこうとかコントロールしたい。でも成長自体はコントロールできないので、木の成長に合わせて手を入れていく。愛着をもってきれいな盆栽を作るようなつもりでやっていく。
- (Supership)18年広告システムをやってきたが、上の人間からは今乗り切ればいいことある！と18年言われ続けてきた。真に受けて頑張り続けると死んじゃうのでまず生き延びること。長くやっていけば、それ自体が価値になることがある。俺が頑張んなきゃってずーっと頑張り続けると死んじゃうので、まずは生き延びること！
個人的なまとめ
- 今回登壇されていた、世の中的に最先端でイケてるとされるような会社でも、悩むことやハマるポイントは私たちと大きな違いはなく、ただ１つ１つを丁寧に取り組んできた積み重ねで今があるのだなと思った。
- 特にSupership山崎さんのお話が示唆に富んでいて興味深かった。
- pv/cpu% という指標は取り入れてみたい。