首先

dots. Conference Spring 2016 5日目午前の部「大規模Webサービスを支える技術」に参加してきましたので、メモを共有します。

イベント概要

日期和时间：2016年2月28日（星期日）10:30至14:15
链接：http://eventdots.jp/event/580339

請給予的東西

セッション

10年来，可以扩展和提升的网络服务

株式会社はてな 田中 慎司氏

The transformation of Hatena’s system foundation.

• 初期（2003年頃〜）

 

• 主力ははてなダイアリー。オンプレ　自作サーバ　LAMP。

 

• 中盤（2006,7年頃〜）

 

• LAMPはそのまま。ユーザ増加に伴いLB/JOBQueueは追加。自作サーバ→ベンダ製ハードウェア。

 

• 現在

 

主力ははてなブログ。Nginx perl mysql AWS。はてなダイアリーは延命策中（HWリプレース、centos5→debian）。

10年不断才能产生变化。

プログラミングパラダイム

• 厚いフレームワークから薄いフレームワークがトレンドに。

 

動的型付け→静的片付け

開発プロセス

• 小規模チーム→中規模チームへ

 

• テスト、レビューが当たり前な文化ができてきた

 

スクラムの導入(一部)

外部环境: The external environment

• 開発リソースの変化　売り上げや会社の戦略で変化。

 

開発対象環境 → デバイスの変化　PCブラウザだけ考えればよかったのが、スマホetc.

用户属性的变化

エンジニアだけじゃなく、普通の人も増えてきた

中長期的にパフォーマンスマネジメントをどう考えるか

• 短期的にパフォーマンス出すには方法論はいろいろある

ボトルネック解消、サーバ増やす、クエリ改善、キャッシュetc..

10年やってくためには短期的な改善だけではなく、キープしていかないといけない
変化しない、しにくいもの

DBスキーマやシャーディング。はてなのユーザDBのスキーマは2001年に切ったものがベース。負債が今も残っている。
基本アーキテクチャ(実装言語　キャッシュ方法)

機能追加は容易　でも　削除は困難

パフォーマンスチューニングした後

• 日々の機能追加は、基本的にパフォーマンス劣化に繋がりがち

 

• どうやってパフォーマンスが劣化していくことに気づくがが重要

 

• はてなでモニタリングしていること

応答時間

PV/CPU。PV数をCPU%で割る
→ 応答時間だけ見てても分からないことも分かる。これを時系列、サービス間で比較することもある。

コストパフォーマンス指標は効率改善タスクの理由としやすい。現場もマネージャも。
この手の改善は一気にやると大変なので、小規模な変更の積み重ねで対処する。
とはいえ長いことやっているとメンテナンスが厳しい場面も出てくる。するとフルスクラッチしたいと言い出す人がでてくる。でもフルスクラッチは最終手段。想定スケジュール、リソースでは収まらないことが多い。基本的には部分的に書き直していく。

关于接下来的十年

增强适应变化的能力.

• シンプルなアーキテクチャを採用する

 

• 効果の薄いレイヤを導入しない。面白そうだから使い出すのは簡単、やめるのは大変。

 

• システム間を疎結合に。マイクロサービス。ただし障害時にどのサービスが原因になっているか、パフォーマンスのボトルネックはどこか、分かりにくくなる。メンテナンスはしやすくなるがトレードオフ。

 

• アプリケーション実行環境は、下位レイヤ(OS etc)との依存減らす（docker etc）

 

• クラウドは普及していくが、コスト管理はしっかりやらないといけない。AWSは使っていくと高くなる。

 

機械学習は組み込むのは簡単になってきているが、技術的負債に繋がりやすいと最近よく言われている。

总结

• 10年やってるといろいろあって大変だが、それが面白さに繋がっているところもあるので頑張っていこうという気持ち

 

10年後は予測不能なので頑張っていきましょう

「Mercari DevOps故事-我们的战斗才刚刚开始-」

Mercari Co., Ltd. Mr. Kenichi Sasaki

服务规模的变迁

• アプリダウンロード数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株式會社 山崎大輔先生
クックパッド株式會社 成田一生先生

从会场提出的问题。

向Merucari先生，切换从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台で十分だと思う。実は、オンプレでやっているのでサーバの個体差があったりする。たまに変なやつを見つけたら、そいつをカナリアサーバと呼んだりしてる。

对于Hatena，以成本效益为指标，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自体のサービス終了リスクがある。「買収された」というのは１つのシグナルになると思う。買収された時に、そのサービスを引き続きやりたい経営者と辞めたい経営者に分かれる。

你使用什么构成管理工具？（来自Mercari的佐々木先生向会场逆向提问）

※会场上有很多人使用ansible。

• (cookpad)cookpadは名前空間がかぶるからchefを使わなかったというのが半分本当。recipeとかcookbookとか普通にテーブルあったりするので。。

 

(cookpad)puppetは好きだがitamaeにリプレースしたのは、そのタイミングで古いゴミを捨てられたり、いろいろバージョンがあがったり、メンバの理解が深まったりするから。定期的にそういうことしていこうということにしている。どうせいろいろ自前で機能追加したりするので、それなら薄いツールを自分たちで作ることにした。

在支撑大规模系统的过程中要注意的事项。

• (cookpad)システムが大規模になるのはそれなりに売れて、組織も大きくなってというのがある。なので事業継続性が大事になる。負債が問題になる。なのでシンプルなものを作るようにするべき。

 

• (メルカリ)シンプルに作ること。どうしても変更しないといけない時は、シンプルということを念頭に入れて大胆に方針を考える。それを実行する時は繊細に綿密に計画をする。

 

• (はてな)大規模システムは盆栽。組織によって要件が千差万別。ちゃんとこういう感じにしていこうとか、成長に伴ってこうしていこうとかコントロールしたい。でも成長自体はコントロールできないので、木の成長に合わせて手を入れていく。愛着をもってきれいな盆栽を作るようなつもりでやっていく。

 

(Supership)18年広告システムをやってきたが、上の人間からは今乗り切ればいいことある！と18年言われ続けてきた。真に受けて頑張り続けると死んじゃうのでまず生き延びること。長くやっていけば、それ自体が価値になることがある。俺が頑張んなきゃってずーっと頑張り続けると死んじゃうので、まずは生き延びること！

个人的总结

• 今回登壇されていた、世の中的に最先端でイケてるとされるような会社でも、悩むことやハマるポイントは私たちと大きな違いはなく、ただ１つ１つを丁寧に取り組んできた積み重ねで今があるのだなと思った。

 

• 特にSupership山崎さんのお話が示唆に富んでいて興味深かった。

 

pv/cpu% という指標は取り入れてみたい。