Submit Search
Upload
分散システムについて語らせてくれ
•
Download as PPTX, PDF
•
731 likes
•
120,497 views
Kumazaki Hiroki
Follow
NTT Tech Conference #2 にて話した資料 時間が足りなかったので全部は話せなかった。
Read less
Read more
Engineering
Report
Share
Report
Share
1 of 45
Download now
Recommended
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
Kumazaki Hiroki
分散システムのFault Injectionの話 NTTデータテクノロジーカンファレンス2017で発表する際に用いたプレゼン資料 https://oss.nttdata.com/hadoop/event/201710/index.html
地理分散DBについて
地理分散DBについて
Kumazaki Hiroki
Database Lounge Tokyo #4 https://database-lounge-tokyo.connpass.com/event/54855/ で話した資料。 動画はこっち https://www.youtube.com/watch?time_continue=1&v=VTEAJHJHIpY
分散システムの限界について知ろう
分散システムの限界について知ろう
Shingo Omura
↓↓↓↓訂正あります。↓↓↓↓ 2018/07/02に株式会社エフコード社内で行われた勉強会のスライドです。 訂正版(随時更新中): https://docs.google.com/presentation/d/15HOMfAbtdWwO48njcB8IdkN3kVAMu3wsmZo0O3S-f_4/edit?usp=sharing 専門家による資料・専門家向けの資料ではありません。自分自身で学習し、論文・文献等を読解してまとめた内容となります。間違い等あるかもしれませんが、あれば是非コメント頂ければと思います。 【訂正事項】 スライド16: 誤:たった一つのプロセスが故障しただけでも有限時間で合意できない 正:たった一つのプロセスが故障しうるだけでも有限時間で合意できない スライド20: 誤: 重要: あるschedule σ1, σ2 がdisjoint (nodeが被ってない) なら可換 正: 重要: あるschedule σ1, σ2 がdisjoint (processが被ってない) なら可換 スライド24, 34 誤: “分散システムについて語らせてくれ” 熊崎宏樹 NTTデータテクノロジーカンファレンス2017 #2 正: “分散システムについて語らせてくれ” 熊崎宏樹 NTT Tech Conference #2
Paxos
Paxos
Preferred Networks
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Kohei Tokunaga
NTT Tech Conference 2022 での「Dockerからcontainerdへの移行」の発表資料です https://ntt-techconf.connpass.com/event/241061/ 訂正: P2. . 誤: ``` Ship docker run -it --rm alpine Run docker push ghcr.io/ktock/myalpine:latest ``` 正: ``` Ship docker push ghcr.io/ktock/myalpine:latest Run docker run -it --rm alpine ```
KafkaとPulsar
KafkaとPulsar
Yahoo!デベロッパーネットワーク
イベントURL: https://kafka-apache-jp.connpass.com/event/222711/ イベント名: Apache Kafka Meetup Japan #9
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
NTT DATA Technology & Innovation
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~ (Kubernetes Meetup Tokyo #33 発表資料) 2020/08/26 NTT DATA Yasuhiro Horiuchi
普通の人でもわかる Paxos
普通の人でもわかる Paxos
tyonekura
Paxos Made Simpleをさらに簡単に説明するよう試みてみました。
Recommended
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
Kumazaki Hiroki
分散システムのFault Injectionの話 NTTデータテクノロジーカンファレンス2017で発表する際に用いたプレゼン資料 https://oss.nttdata.com/hadoop/event/201710/index.html
地理分散DBについて
地理分散DBについて
Kumazaki Hiroki
Database Lounge Tokyo #4 https://database-lounge-tokyo.connpass.com/event/54855/ で話した資料。 動画はこっち https://www.youtube.com/watch?time_continue=1&v=VTEAJHJHIpY
分散システムの限界について知ろう
分散システムの限界について知ろう
Shingo Omura
↓↓↓↓訂正あります。↓↓↓↓ 2018/07/02に株式会社エフコード社内で行われた勉強会のスライドです。 訂正版(随時更新中): https://docs.google.com/presentation/d/15HOMfAbtdWwO48njcB8IdkN3kVAMu3wsmZo0O3S-f_4/edit?usp=sharing 専門家による資料・専門家向けの資料ではありません。自分自身で学習し、論文・文献等を読解してまとめた内容となります。間違い等あるかもしれませんが、あれば是非コメント頂ければと思います。 【訂正事項】 スライド16: 誤:たった一つのプロセスが故障しただけでも有限時間で合意できない 正:たった一つのプロセスが故障しうるだけでも有限時間で合意できない スライド20: 誤: 重要: あるschedule σ1, σ2 がdisjoint (nodeが被ってない) なら可換 正: 重要: あるschedule σ1, σ2 がdisjoint (processが被ってない) なら可換 スライド24, 34 誤: “分散システムについて語らせてくれ” 熊崎宏樹 NTTデータテクノロジーカンファレンス2017 #2 正: “分散システムについて語らせてくれ” 熊崎宏樹 NTT Tech Conference #2
Paxos
Paxos
Preferred Networks
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Kohei Tokunaga
NTT Tech Conference 2022 での「Dockerからcontainerdへの移行」の発表資料です https://ntt-techconf.connpass.com/event/241061/ 訂正: P2. . 誤: ``` Ship docker run -it --rm alpine Run docker push ghcr.io/ktock/myalpine:latest ``` 正: ``` Ship docker push ghcr.io/ktock/myalpine:latest Run docker run -it --rm alpine ```
KafkaとPulsar
KafkaとPulsar
Yahoo!デベロッパーネットワーク
イベントURL: https://kafka-apache-jp.connpass.com/event/222711/ イベント名: Apache Kafka Meetup Japan #9
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
NTT DATA Technology & Innovation
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~ (Kubernetes Meetup Tokyo #33 発表資料) 2020/08/26 NTT DATA Yasuhiro Horiuchi
普通の人でもわかる Paxos
普通の人でもわかる Paxos
tyonekura
Paxos Made Simpleをさらに簡単に説明するよう試みてみました。
並行実行制御の最適化手法
並行実行制御の最適化手法
Sho Nakazono
2017年3月29日に開催された第七回ビッグデータ基盤技術研究会(BDI研究会)での発表資料です。
例外設計における大罪
例外設計における大罪
Takuto Wada
例外設計における大罪 Jun 27, 2012 @ java-ja
暗号技術の実装と数学
暗号技術の実装と数学
MITSUNARI Shigeo
九州大学談話会「IMI Colloquium」 https://www.imi.kyushu-u.ac.jp/seminars/view/3001
トランザクションの設計と進化
トランザクションの設計と進化
Kumazaki Hiroki
2016年7月27日 Database Lounge Tokyoで話した内容。 タイトルは名ばかりでリカバリとIn-MemoryDBの話が主体
Raft
Raft
Preferred Networks
Raftの解説
PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)
PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)
NTT DATA Technology & Innovation
PGOを用いたPostgreSQL on Kubernetes入門 (PostgreSQL Conference Japan 2022 発表資料) 2022年11月11日(金) NTTデータ 技術開発本部 先進コンピューティング技術センタ 加藤 慎也
SAT/SMTソルバの仕組み
SAT/SMTソルバの仕組み
Masahiro Sakai
Proof Summit 2015 <http: /> で発表した、SAT/SMTソルバの仕組みです。 Proofということで、論理学的側面からの面白さを出来るだけ紹介しています。
ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方
Yoshiyasu SAEKI
ビッグデータのリアルタイム処理技術勉強会 http://futureofdata.connpass.com/event/40077/ 発表資料
TLS, HTTP/2演習
TLS, HTTP/2演習
shigeki_ohtsu
セキュリティ・ミニキャンプ in 北海道 2015
コンテナとimmutableとわたし。あとセキュリティ。(Kubernetes Novice Tokyo #15 発表資料)
コンテナとimmutableとわたし。あとセキュリティ。(Kubernetes Novice Tokyo #15 発表資料)
NTT DATA Technology & Innovation
コンテナとimmutableとわたし。あとセキュリティ。 (Kubernetes Novice Tokyo #15 発表資料) 2021年12月7日(火) NTTデータ システム技術本部生産技術部 クラウド技術センタ 望月 敬太
目grep入門 +解説
目grep入門 +解説
murachue
目grep入門があまりにもKernelVM::入門だという指摘があったため、解説をつけてよりstd::入門に近づけてみました。
アーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーション
Masahiko Sawada
OSSコンソーシアム DB比較セミナー(2018/1/26)での講演資料です。
Marp Tutorial
Marp Tutorial
Rui Watanabe
北村研Notion用
DockerコンテナでGitを使う
DockerコンテナでGitを使う
Kazuhiro Suga
Dockerコンテナ内からGitを利用する手順
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
2022-03-05 YAPC::Japan::Online 2022
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021
Hiroshi Tokumaru
こちらのスライドは以下のサイトにて閲覧いただけます。 https://www.docswell.com/s/ockeghem/ZM6VNK-phpconf2021-spa-security シングルページアプリケーション(SPA)において、セッションIDやトークンの格納場所はCookieあるいはlocalStorageのいずれが良いのかなど、セキュリティ上の課題がネット上で議論されていますが、残念ながら間違った前提に基づくものが多いようです。このトークでは、SPAのセキュリティを構成する基礎技術を説明した後、著名なフレームワークな状況とエンジニアの技術理解の現状を踏まえ、SPAセキュリティの現実的な方法について説明します。 動画はこちら https://www.youtube.com/watch?v=pc57hw6haXk
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
NTT DATA OSS Professional Services
2019年3月14日に開催されたHadoop / Spark Conference Japan 2019での講演資料です。
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
NTT DATA Technology & Innovation
PostgreSQLをKubernetes上で活用するためのOperator紹介! (Cloud Native Database Meetup #3 発表資料) 2022年1月14日 NTTデータ 技術開発本部 先進コンピューティング技術センタ 藤井 雅雄
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
Yahoo!デベロッパーネットワーク
Apache Kafka Meetup Japan #3 https://kafka-apache-jp.connpass.com/event/58619/ 発表資料
え、まって。その並列分散処理、Kafkaのしくみでもできるの? Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理
え、まって。その並列分散処理、Kafkaのしくみでもできるの? Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理
NTT DATA Technology & Innovation
え、まって。その並列分散処理、Kafkaのしくみでもできるの? Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理 (NTTデータ テクノロジーカンファレンス 2019 講演資料、2019/09/05) NTTデータ 技術革新統括本部 システム技術本部生産技術部 インテグレーション技術センタ データ活用チーム 佐々木 徹
エンジニアなら知っておきたい「仮想マシン」のしくみ v1.1 (hbstudy 17)
エンジニアなら知っておきたい「仮想マシン」のしくみ v1.1 (hbstudy 17)
Takeshi HASEGAWA
Google Dremel
Google Dremel
maruyama097
More Related Content
What's hot
並行実行制御の最適化手法
並行実行制御の最適化手法
Sho Nakazono
2017年3月29日に開催された第七回ビッグデータ基盤技術研究会(BDI研究会)での発表資料です。
例外設計における大罪
例外設計における大罪
Takuto Wada
例外設計における大罪 Jun 27, 2012 @ java-ja
暗号技術の実装と数学
暗号技術の実装と数学
MITSUNARI Shigeo
九州大学談話会「IMI Colloquium」 https://www.imi.kyushu-u.ac.jp/seminars/view/3001
トランザクションの設計と進化
トランザクションの設計と進化
Kumazaki Hiroki
2016年7月27日 Database Lounge Tokyoで話した内容。 タイトルは名ばかりでリカバリとIn-MemoryDBの話が主体
Raft
Raft
Preferred Networks
Raftの解説
PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)
PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)
NTT DATA Technology & Innovation
PGOを用いたPostgreSQL on Kubernetes入門 (PostgreSQL Conference Japan 2022 発表資料) 2022年11月11日(金) NTTデータ 技術開発本部 先進コンピューティング技術センタ 加藤 慎也
SAT/SMTソルバの仕組み
SAT/SMTソルバの仕組み
Masahiro Sakai
Proof Summit 2015 <http: /> で発表した、SAT/SMTソルバの仕組みです。 Proofということで、論理学的側面からの面白さを出来るだけ紹介しています。
ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方
Yoshiyasu SAEKI
ビッグデータのリアルタイム処理技術勉強会 http://futureofdata.connpass.com/event/40077/ 発表資料
TLS, HTTP/2演習
TLS, HTTP/2演習
shigeki_ohtsu
セキュリティ・ミニキャンプ in 北海道 2015
コンテナとimmutableとわたし。あとセキュリティ。(Kubernetes Novice Tokyo #15 発表資料)
コンテナとimmutableとわたし。あとセキュリティ。(Kubernetes Novice Tokyo #15 発表資料)
NTT DATA Technology & Innovation
コンテナとimmutableとわたし。あとセキュリティ。 (Kubernetes Novice Tokyo #15 発表資料) 2021年12月7日(火) NTTデータ システム技術本部生産技術部 クラウド技術センタ 望月 敬太
目grep入門 +解説
目grep入門 +解説
murachue
目grep入門があまりにもKernelVM::入門だという指摘があったため、解説をつけてよりstd::入門に近づけてみました。
アーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーション
Masahiko Sawada
OSSコンソーシアム DB比較セミナー(2018/1/26)での講演資料です。
Marp Tutorial
Marp Tutorial
Rui Watanabe
北村研Notion用
DockerコンテナでGitを使う
DockerコンテナでGitを使う
Kazuhiro Suga
Dockerコンテナ内からGitを利用する手順
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
2022-03-05 YAPC::Japan::Online 2022
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021
Hiroshi Tokumaru
こちらのスライドは以下のサイトにて閲覧いただけます。 https://www.docswell.com/s/ockeghem/ZM6VNK-phpconf2021-spa-security シングルページアプリケーション(SPA)において、セッションIDやトークンの格納場所はCookieあるいはlocalStorageのいずれが良いのかなど、セキュリティ上の課題がネット上で議論されていますが、残念ながら間違った前提に基づくものが多いようです。このトークでは、SPAのセキュリティを構成する基礎技術を説明した後、著名なフレームワークな状況とエンジニアの技術理解の現状を踏まえ、SPAセキュリティの現実的な方法について説明します。 動画はこちら https://www.youtube.com/watch?v=pc57hw6haXk
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
NTT DATA OSS Professional Services
2019年3月14日に開催されたHadoop / Spark Conference Japan 2019での講演資料です。
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
NTT DATA Technology & Innovation
PostgreSQLをKubernetes上で活用するためのOperator紹介! (Cloud Native Database Meetup #3 発表資料) 2022年1月14日 NTTデータ 技術開発本部 先進コンピューティング技術センタ 藤井 雅雄
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
Yahoo!デベロッパーネットワーク
Apache Kafka Meetup Japan #3 https://kafka-apache-jp.connpass.com/event/58619/ 発表資料
え、まって。その並列分散処理、Kafkaのしくみでもできるの? Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理
え、まって。その並列分散処理、Kafkaのしくみでもできるの? Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理
NTT DATA Technology & Innovation
え、まって。その並列分散処理、Kafkaのしくみでもできるの? Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理 (NTTデータ テクノロジーカンファレンス 2019 講演資料、2019/09/05) NTTデータ 技術革新統括本部 システム技術本部生産技術部 インテグレーション技術センタ データ活用チーム 佐々木 徹
What's hot
(20)
並行実行制御の最適化手法
並行実行制御の最適化手法
例外設計における大罪
例外設計における大罪
暗号技術の実装と数学
暗号技術の実装と数学
トランザクションの設計と進化
トランザクションの設計と進化
Raft
Raft
PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)
PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)
SAT/SMTソルバの仕組み
SAT/SMTソルバの仕組み
ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方
TLS, HTTP/2演習
TLS, HTTP/2演習
コンテナとimmutableとわたし。あとセキュリティ。(Kubernetes Novice Tokyo #15 発表資料)
コンテナとimmutableとわたし。あとセキュリティ。(Kubernetes Novice Tokyo #15 発表資料)
目grep入門 +解説
目grep入門 +解説
アーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーション
Marp Tutorial
Marp Tutorial
DockerコンテナでGitを使う
DockerコンテナでGitを使う
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
え、まって。その並列分散処理、Kafkaのしくみでもできるの? Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理
え、まって。その並列分散処理、Kafkaのしくみでもできるの? Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理
Viewers also liked
エンジニアなら知っておきたい「仮想マシン」のしくみ v1.1 (hbstudy 17)
エンジニアなら知っておきたい「仮想マシン」のしくみ v1.1 (hbstudy 17)
Takeshi HASEGAWA
Google Dremel
Google Dremel
maruyama097
Yahoo!ブラウザーアプリのプロダクトマネージャーが考えていること
Yahoo!ブラウザーアプリのプロダクトマネージャーが考えていること
Yahoo!デベロッパーネットワーク
行列ができるECサイトの悩み~ショッピングや決済の技術的問題と処方箋
行列ができるECサイトの悩み~ショッピングや決済の技術的問題と処方箋
Yahoo!デベロッパーネットワーク
ヤフオク!の快適なカスタマー体験を支えるモバイルアプリのライブアップデート技術
ヤフオク!の快適なカスタマー体験を支えるモバイルアプリのライブアップデート技術
Yahoo!デベロッパーネットワーク
市場で勝ち続けるための品質とテストの技術①
市場で勝ち続けるための品質とテストの技術①
Yahoo!デベロッパーネットワーク
市場で勝ち続けるための品質とテストの技術②
市場で勝ち続けるための品質とテストの技術②
Yahoo!デベロッパーネットワーク
Yahoo! JAPANのサービス開発を10倍早くした社内PaaS構築の今とこれから
Yahoo! JAPANのサービス開発を10倍早くした社内PaaS構築の今とこれから
Yahoo!デベロッパーネットワーク
Serverlessconf Tokyo 2017 Biz serverless お客様のビジネスを支えるサーバーレスアーキテクチャーと開発としてのビジ...
Serverlessconf Tokyo 2017 Biz serverless お客様のビジネスを支えるサーバーレスアーキテクチャーと開発としてのビジ...
Hiroyuki Hiki
Serverlessconf Tokyo 2017で喋った資料です! サーバレス案件のお話待ってます!
Software Productivity and Serverless
Software Productivity and Serverless
Nick Gottlieb
Keynote from ServerlessConf Tokyo. Outlines 9 ways Serverless can help make software development and the economy as a whole more productive.
[serverlessconf2017]FaaSで簡単に実現する数十万RPSスパイク負荷試験
[serverlessconf2017]FaaSで簡単に実現する数十万RPSスパイク負荷試験
Takahiro Moteki
serverless conf 2017 発表資料 http://tokyo.serverlessconf.io/ ○ 概要 HTTPベースの負荷試験を行う負荷ツールはたくさんあります。 しかし、既存の負荷ツールでは、数十万RPSクラスのスパイクする直角リクエストを生成するには、infrastructureレイヤのプロビジョニングが手間です。 これをLambdaを使用して、簡単に実現するOSSをいくつか紹介したいと思います。
now
now
Hiroyuki Hara
Speaker Deck 👉 https://speakerdeck.com/aggre/now Serverless Conf Tokyo 2017 での LT 資料です。
Pythonと機械学習によるWebセキュリティの自動化
Pythonと機械学習によるWebセキュリティの自動化
Isao Takaesu
PYCONJP 2017. https://pycon.jp/2017/ja/
BluetoothメッシュによるIoTシステムを支えるサーバーレス技術 #serverlesstokyo
BluetoothメッシュによるIoTシステムを支えるサーバーレス技術 #serverlesstokyo
Masahiro NAKAYAMA
2017-11-03 ServerlessConf Tokyo 2017 リンクが白色になってしまっていました。以下です。 https://exbeacon.where123.jp/faret/ https://exbeacon.where123.jp/docomocschiba/
Step functionsとaws batchでオーケストレートするイベントドリブンな機械学習基盤
Step functionsとaws batchでオーケストレートするイベントドリブンな機械学習基盤
Yu Yamada
リクルートライフスタイルでは機械学習を用いたサービスの展開もしています。サービスが増え続ける中で素早く市場に対応するためには、いかに簡単に基盤を作り、運用を減らせていくかが重要になってきます。 上記の課題を踏まえパワーが必要な機械学習処理のためのサーバレス基盤を構築しました。 なぜserverlessを選択したのか? 構築にあたり使用したStep FunctionsやAWS Batchの注意点と共に機械学習基盤を紹介します。 山田 雄(株式会社リクルートライフスタイル)
Cassandra Explained
Cassandra Explained
Eric Evans
データテクノロジースペシャル:Yahoo! JAPANにおけるメタデータ管理の試み
データテクノロジースペシャル:Yahoo! JAPANにおけるメタデータ管理の試み
Yahoo!デベロッパーネットワーク
Lecture univ.tokyo 2017_okanohara
Lecture univ.tokyo 2017_okanohara
Preferred Networks
Lecture at the Univ. of Tokyo, 2017.
Docker最新動向2017秋+セキュリティの落とし穴
Docker最新動向2017秋+セキュリティの落とし穴
Masahito Zembutsu
Developers Summit 2017 KYUSYU 2017年9月22日(金)アクロス福岡 http://event.shoeisha.jp/devsumi/20170922 発表資料 【A-1】Docker最新動向2017秋+セキュリティの落とし穴
CPUから見たG1GC
CPUから見たG1GC
Kenji Kazumura
G1GCの動作をCPUの視点から考察します。
Viewers also liked
(20)
エンジニアなら知っておきたい「仮想マシン」のしくみ v1.1 (hbstudy 17)
エンジニアなら知っておきたい「仮想マシン」のしくみ v1.1 (hbstudy 17)
Google Dremel
Google Dremel
Yahoo!ブラウザーアプリのプロダクトマネージャーが考えていること
Yahoo!ブラウザーアプリのプロダクトマネージャーが考えていること
行列ができるECサイトの悩み~ショッピングや決済の技術的問題と処方箋
行列ができるECサイトの悩み~ショッピングや決済の技術的問題と処方箋
ヤフオク!の快適なカスタマー体験を支えるモバイルアプリのライブアップデート技術
ヤフオク!の快適なカスタマー体験を支えるモバイルアプリのライブアップデート技術
市場で勝ち続けるための品質とテストの技術①
市場で勝ち続けるための品質とテストの技術①
市場で勝ち続けるための品質とテストの技術②
市場で勝ち続けるための品質とテストの技術②
Yahoo! JAPANのサービス開発を10倍早くした社内PaaS構築の今とこれから
Yahoo! JAPANのサービス開発を10倍早くした社内PaaS構築の今とこれから
Serverlessconf Tokyo 2017 Biz serverless お客様のビジネスを支えるサーバーレスアーキテクチャーと開発としてのビジ...
Serverlessconf Tokyo 2017 Biz serverless お客様のビジネスを支えるサーバーレスアーキテクチャーと開発としてのビジ...
Software Productivity and Serverless
Software Productivity and Serverless
[serverlessconf2017]FaaSで簡単に実現する数十万RPSスパイク負荷試験
[serverlessconf2017]FaaSで簡単に実現する数十万RPSスパイク負荷試験
now
now
Pythonと機械学習によるWebセキュリティの自動化
Pythonと機械学習によるWebセキュリティの自動化
BluetoothメッシュによるIoTシステムを支えるサーバーレス技術 #serverlesstokyo
BluetoothメッシュによるIoTシステムを支えるサーバーレス技術 #serverlesstokyo
Step functionsとaws batchでオーケストレートするイベントドリブンな機械学習基盤
Step functionsとaws batchでオーケストレートするイベントドリブンな機械学習基盤
Cassandra Explained
Cassandra Explained
データテクノロジースペシャル:Yahoo! JAPANにおけるメタデータ管理の試み
データテクノロジースペシャル:Yahoo! JAPANにおけるメタデータ管理の試み
Lecture univ.tokyo 2017_okanohara
Lecture univ.tokyo 2017_okanohara
Docker最新動向2017秋+セキュリティの落とし穴
Docker最新動向2017秋+セキュリティの落とし穴
CPUから見たG1GC
CPUから見たG1GC
More from Kumazaki Hiroki
An overview of query optimization in relational systems 論文紹介
An overview of query optimization in relational systems 論文紹介
Kumazaki Hiroki
輪読会の資料です。 2021年12月20日
トランザクション入門
トランザクション入門
Kumazaki Hiroki
ログの書き出しタイミングの
Cache obliviousの話
Cache obliviousの話
Kumazaki Hiroki
過去に話したスライドの一部抜粋。 データの出典元はここ http://www.1024cores.net/home/parallel-computing/cache-oblivious-algorithms
トランザクションをSerializableにする4つの方法
トランザクションをSerializableにする4つの方法
Kumazaki Hiroki
2015年12月18日に行われたビッグデータ基盤勉強会で発表する際に使った資料です。
Jubatus hackathon2
Jubatus hackathon2
Kumazaki Hiroki
with 読売新聞
キャッシュコヒーレントに囚われない並列カウンタ達
キャッシュコヒーレントに囚われない並列カウンタ達
Kumazaki Hiroki
第6回DSIRNLPで発表した資料。
What is jubatus (short)
What is jubatus (short)
Kumazaki Hiroki
What is jubatus? How it works for you?
What is jubatus? How it works for you?
Kumazaki Hiroki
よくわかるHopscotch hashing
よくわかるHopscotch hashing
Kumazaki Hiroki
冬のLock free祭り safe
冬のLock free祭り safe
Kumazaki Hiroki
MerDy
MerDy
Kumazaki Hiroki
Bloom filter
Bloom filter
Kumazaki Hiroki
A description of Bloom filter
SkipGraph
SkipGraph
Kumazaki Hiroki
Lockfree list
Lockfree list
Kumazaki Hiroki
Lockfree Priority Queue
Lockfree Priority Queue
Kumazaki Hiroki
Lockfree priority queue
Lockfree Queue
Lockfree Queue
Kumazaki Hiroki
Lockfree queue introduction in Japanese.
More from Kumazaki Hiroki
(16)
An overview of query optimization in relational systems 論文紹介
An overview of query optimization in relational systems 論文紹介
トランザクション入門
トランザクション入門
Cache obliviousの話
Cache obliviousの話
トランザクションをSerializableにする4つの方法
トランザクションをSerializableにする4つの方法
Jubatus hackathon2
Jubatus hackathon2
キャッシュコヒーレントに囚われない並列カウンタ達
キャッシュコヒーレントに囚われない並列カウンタ達
What is jubatus (short)
What is jubatus (short)
What is jubatus? How it works for you?
What is jubatus? How it works for you?
よくわかるHopscotch hashing
よくわかるHopscotch hashing
冬のLock free祭り safe
冬のLock free祭り safe
MerDy
MerDy
Bloom filter
Bloom filter
SkipGraph
SkipGraph
Lockfree list
Lockfree list
Lockfree Priority Queue
Lockfree Priority Queue
Lockfree Queue
Lockfree Queue
Recently uploaded
ビジュアルプログラミングIotLT17-オープンソース化されたビジュアルプログラミング環境Noodlの紹介
ビジュアルプログラミングIotLT17-オープンソース化されたビジュアルプログラミング環境Noodlの紹介
miyp
ビジュアルプログラミングIoTLT17資料です。
「VRC海のおはなし会_深海探査とロボットのお話」発表資料
「VRC海のおはなし会_深海探査とロボットのお話」発表資料
Yuuitirou528 default
深海探査を行うロボットについてざっくりと初心者向け?に解説したおはなし会の資料です。 https://x.com/INHI_UV2B/status/1796712335765369263
エンジニアのセルフブランディングと技術情報発信の重要性 テクニカルライターになろう 講演資料
エンジニアのセルフブランディングと技術情報発信の重要性 テクニカルライターになろう 講演資料
Toru Miyahara
エンジニアのセルフブランディングと技術情報発信の重要性 テクニカルライターになろう 講演資料
Linuxサーバー構築 学習のポイントと環境構築 OSC2024名古屋 セミナー資料
Linuxサーバー構築 学習のポイントと環境構築 OSC2024名古屋 セミナー資料
Toru Miyahara
Linuxサーバー構築 学習のポイントと環境構築 OSC2024名古屋 セミナー資料
Compute Units/Budget最適化 - Solana Developer Hub Online 6 #SolDevHub
Compute Units/Budget最適化 - Solana Developer Hub Online 6 #SolDevHub
K Kinzal
Solana Developer Hub Online #6 https://lu.ma/evx8jtpi
今さら聞けない人のためのDevOps超入門 OSC2024名古屋 セミナー資料
今さら聞けない人のためのDevOps超入門 OSC2024名古屋 セミナー資料
Toru Miyahara
今さら聞けない人のためのDevOps超入門 OSC2024名古屋 セミナー資料
本の感想共有会「データモデリングでドメインを駆動する」本が突きつける我々の課題について
本の感想共有会「データモデリングでドメインを駆動する」本が突きつける我々の課題について
Masatsugu Matsushita
下記の会の感想 https://kichijojipm.connpass.com/event/315276/presentation/
Recently uploaded
(7)
ビジュアルプログラミングIotLT17-オープンソース化されたビジュアルプログラミング環境Noodlの紹介
ビジュアルプログラミングIotLT17-オープンソース化されたビジュアルプログラミング環境Noodlの紹介
「VRC海のおはなし会_深海探査とロボットのお話」発表資料
「VRC海のおはなし会_深海探査とロボットのお話」発表資料
エンジニアのセルフブランディングと技術情報発信の重要性 テクニカルライターになろう 講演資料
エンジニアのセルフブランディングと技術情報発信の重要性 テクニカルライターになろう 講演資料
Linuxサーバー構築 学習のポイントと環境構築 OSC2024名古屋 セミナー資料
Linuxサーバー構築 学習のポイントと環境構築 OSC2024名古屋 セミナー資料
Compute Units/Budget最適化 - Solana Developer Hub Online 6 #SolDevHub
Compute Units/Budget最適化 - Solana Developer Hub Online 6 #SolDevHub
今さら聞けない人のためのDevOps超入門 OSC2024名古屋 セミナー資料
今さら聞けない人のためのDevOps超入門 OSC2024名古屋 セミナー資料
本の感想共有会「データモデリングでドメインを駆動する」本が突きつける我々の課題について
本の感想共有会「データモデリングでドメインを駆動する」本が突きつける我々の課題について
分散システムについて語らせてくれ
1.
Copyright©2016 NTT Corp.
All Rights Reserved. 分散システムについて 語らせてくれ 日本電信電話株式会社 ソフトウェアイノベーションセンタ 熊崎 宏樹 (@kumagi)
2.
Copyright©2016 NTT Corp.
All Rights Reserved. 2 1.分散自体を目的にしない事 2.論文を読んでそのまま実装しない事 3.Two Phase Commitを使わない事 4.手を動かす事 目次 分散システムを作る際に気をつけて欲しい事
3.
Copyright©2016 NTT Corp.
All Rights Reserved. 3 • よくわかってない人でもCloudera Managerをダウンロードして1時間後 には巨大なHadoopクラスタを立ち上げてYARN, HDFS, Spark, HBase などで遊ぶ事ができる。 • 世の中では分散システムが必要以上に喧伝されている • 「コンピュータ1台よりも2台の方が高速」という直感に対して反論するの は意外と難しい • あなたのそのシステム、本当に分散システムじゃないとダメ? 分散自体を目的にしない事
4.
Copyright©2016 NTT Corp.
All Rights Reserved. 4 L1 キャッシュ参照 分岐予測ミス L2 キャッシュ参照 Mutexのlock/unlock メモリ参照 1KBをZIP圧縮 1Gbpsで2KB送る メモリから1MB連続で読む 同一のデータセンタ内のマシンと通信1往復 HDDシーク HDDから1MB読み出し カリフォルニアとオランダ間で通信1往復 システムの肌感覚を掴め 0.5 ns 5 ns 7 ns 25 ns 100 ns 3,000 ns 20,000 ns 250,000 ns 500,000 ns 10,000,000 ns 20,000,000 ns 150,000,000 ns みんなが知っているべき数値 by Jeff Dean
5.
Copyright©2016 NTT Corp.
All Rights Reserved. 5 L1 キャッシュ参照 分岐予測ミス L2 キャッシュ参照 Mutexのlock/unlock メモリ参照 1KBをZIP圧縮 1Gbpsで2KB送る メモリから1MB連続で読む 同一のデータセンタ内のマシンと通信1往復 HDDシーク HDDから1MB読み出し カリフォルニアとオランダ間で通信1往復 システムの肌感覚を掴め 0.5 ns 5 ns 7 ns 25 ns 100 ns 3,000 ns 20,000 ns 250,000 ns 500,000 ns 10,000,000 ns 20,000,000 ns 150,000,000 ns みんなが知っているべき数値 by Jeff Dean
6.
Copyright©2016 NTT Corp.
All Rights Reserved. 6 分散システム化すると基本的に遅くなる。 大抵はネットワークが遅延の支配項になる。 速くなる場合のほうがむしろ例外的と思ったほうが良い。 ワークロードと照らし合わせてマイクロベンチを取った 後で分散システム化を検討して欲しい(頼むから実装上 の重要な意思決定で分散ミドルウェアを使用する事を目 的にしないで欲しい) システムの肌感覚を掴め とにかく測れ 測らずに分散システム化するのは Early Optimizationの一種
7.
Copyright©2016 NTT Corp.
All Rights Reserved. 7 • 分散システムの論文は多く出ているがその大半は「やってみたレポート」 「作ってみた」→「動いたっぽい」→「測った」→「Yappy!」 • 分散システム界隈の研究は過去の研究の蓄積が蓄積扱いされにくい分野の 一つであり、論文を真に受けてはならない • 他にそう感じる研究分野はHCI分野 • 故障モデルなどが実は結構厳しく規定されており、そこを読み飛ばすと痛 い目に遭う 論文を読んでそのまま実装しない事
8.
Copyright©2016 NTT Corp.
All Rights Reserved. 8 • レプリケーションプロトコルとして典型的に見かけるパターン • 一番IDが小さいServerをPrimaryとして、MasterがBackupへのレプリケーション を担当する • ReadもWriteもPrimaryが受け取ることによって一貫性の問題を回避 • Primaryが壊れたらBackupのうち一番IDが小さい奴がPrimaryへ昇格する • HDFSでメタデータの複製に使われているのはこれ ケーススタディ:Primary-Backup Client Server1 Server2 Server3 Server4 Read Write
9.
Copyright©2016 NTT Corp.
All Rights Reserved. 9 • 次に見かけるレプリケーションプロトコル • バケツリレーのように受け取ったものを即座に次のサーバに渡していく • データを全部受け取る前から次のサーバにリレーできるので大容量のデータ転送に強 くメッセージの飛び交う回数はサーバ台数+1で最小だがサーバ台数に比例するメッ セージ遅延がかかる • 故障したサーバはスキップする • HDFSでデータの複製に使われているのはこれ ケーススタディ:Chain-Replication Client Server1 Server2 Server3 Server4 Read Write
10.
Copyright©2016 NTT Corp.
All Rights Reserved. 10 プロトコル名 通信遅延数 メッセージ数 Primary-Backup 4回 2N個 Chain-Replication N+1回 N+1個 ケーススタディ: Primary-Backup と Chain-Replication • 通信の特性を見極めて最適なプロトコルを使おう • Primary-Backupは「細かくて素早い」特性 • Chain-Replicationは「時間が掛かっても通信効率が良い」特性 • どちらもサーバが故障する場合は縮退運転していき、最小1台でも稼動は する
11.
Copyright©2016 NTT Corp.
All Rights Reserved. 11 ちょっと待った
12.
Copyright©2016 NTT Corp.
All Rights Reserved. 12 • これは容易にバグる • Readを常に全体に伝える必要があるかは実装次第だが典型例として • みんながカジュアルに生死判断を行うと食い違ったときに容易に世界が壊れる いわゆるSplit-Brain ケーススタディ:Primary-Backupの故障 Client Server1 Server2 Server3 Server4 Write(x=2) Read(x) -> 0 Server2の 応答が遅かったので 死んでると想定して 無視 Server1の 応答が遅かったので 死んでると想定して Server2へリトライ
13.
Copyright©2016 NTT Corp.
All Rights Reserved. 13 間違った実装が世界を揺るがす • 「Redis Sentinelという自動レプリケーションの仕組みを作りました。 最強です(キリッ」 • しかし特定の実行パターンによって内容物の半分以上が失われる • Jepsen Testが築く屍の山 • 様々な分散ミドルウェアで 意図的にSplit-Brain状態を引き起こして挙動を確認する一連のブログポス ト群:Call me maybe • 面白いぐらい多くのシステムが次々と壊れていく (生き残ったのはZK, Riak, etcd, consulぐらい? • 興味のある人はぜひURL参照 https://aphyr.com/tags/jepsen
14.
Copyright©2016 NTT Corp.
All Rights Reserved. 14 • サーバが壊れた場合の挙動をどうするかは論文に書いてあるけれど、何が 起きたらサーバが壊れたと認識するかは書いてない • これらのプロトコルはサーバの故障情報を天から与えられる物として設計している • プログラマ「そっか、じゃあ通信がタイムアウトしたら故障ね」←バグの温床 • プログラマ「タイムアウトの閾値を大きくすれば誤検知が減って安心だね」←低速化 • プログラマ「タイムアウトの閾値をどうすればいいのさ??」←決定解はない • 分散システムの論文ではシステムに対して前提を置いていることが多いが、 なぜその前提を置いているのかは知識がないとわからない • Primary-BackupとChain-ReplicationはFail-Stop故障モデルを前提 としている • それより厳しい故障モデルの上では容易に壊れる • その故障モデルの解説はこれからする そのプロトコル、凶暴につき
15.
Copyright©2016 NTT Corp.
All Rights Reserved. 15 故障なし • サーバが壊れる状況のしんどさを段階的に切り分けたモデルのこと • より楽な故障モデルで動かないプロトコルは、しんどい故障モデルでは 「絶対に」動かない • Fail-Stop: 壊れたサーバはいずれ全部のサーバから故障として観測される。壊れてい ないサーバを壊れたと誤認する事や、壊れたサーバを壊れていないと誤認する事は発 生しない。壊れたサーバは二度と復活しない。 • Crash-Recover: サーバは壊れるかも知れないが復活する事もある。つまりいつまで も故障したと断言できない。 故障モデル し ん ど い Fail-Stop(同期通信) Fail-Stop(非同期通信) Crash-Recovery Byzantine
16.
Copyright©2016 NTT Corp.
All Rights Reserved. 16 故障モデルと複製アルゴリズム 故障なし Fail-stop Crash-Recovery Byzantine 2-Phase Commit 3-Phase Commit Paxos Raft Primary-Backup Chain-Replication Viewstamped-Replication Broker-Replication Stake-Replication PBFT
17.
Copyright©2016 NTT Corp.
All Rights Reserved. 17 • Fischer,Lynch,Pattersonの3人が提唱したのでその頭文字から取って FLP不可能性と呼ぶ • 端的に言うと、下の図の赤線より下の世界では「全ての壊れていないサー バが有限の時間で確実に合意に至るアルゴリズムは存在しえない」という 事を理論的に証明した • 比較的緩い故障モデルでもダメということはそれより下では絶対に無理という事 FLP不可能性 故障なし Fail-Stop(同期通信) Fail-Stop(非同期通信) Crash-Recovery Byzantine
18.
Copyright©2016 NTT Corp.
All Rights Reserved. 18 • 個々のサーバ内の時間の流れを操って絶対に合意を終わらせようとしない 悪魔が存在したと仮定する • 昼ごはんの行き先について合意を取る例 FLP不可能性を簡単に 状態を変更しうる通信と、状態の変更のタイミングとの間が悪ければ 非決定的な状態(bivalent)な状態が無限に続きうる カレー 牛丼 牛丼 カレー 牛丼いいな カレーいいな カレーいいな 牛丼いいな
19.
Copyright©2016 NTT Corp.
All Rights Reserved. 19 • 分散システムの問題が複数ある中、それぞれはお互いに「帰着」しあう事 ができる • 合意問題が解ければリーダー選出ができる(リーダーを誰にするかに合意する) • リーダー選出ができれば合意問題が解ける(リーダーが決めた値に全員従う) • 合意問題が解ければアトミックブロードキャストができる(順序について合意する) • アトミックブロードキャストができれば合意問題が解ける(最初の値で合意する) • 合意問題が解ければState Machine Replicationが解ける(Multi Paxos的な) • Replicated State Machineが解ければ合意問題が解ける(合意するステートマシン を作ればよい) などなど • その中で「合意問題が解けない」は他の全ての問題も有限の時間では解けな い事を意味する • みんな無限の時間が掛かりうるから適当に迂回するなり諦めるなりしている FLP不可能性の意味する大事な所
20.
Copyright©2016 NTT Corp.
All Rights Reserved. 20 •全員の参加者から「同じ順序」が観測できるブロード キャスト • 単一のリーダーから全員に送る、というのも立派な一つの解 • 参加者がそれぞれバラバラの順序で受信したブロードキャスト メッセージを、同一の順序で観測し直すように合意する、という 方法もある 個々のアルゴリズムは詳しくないのでまた今度 補足:アトミックブロードキャスト ZooKeeperはZookeeper Atomic Bloadcast(ZAB)プロトコル を使っている。
21.
Copyright©2016 NTT Corp.
All Rights Reserved. 21 • 「同じ命令列を受け取ったら同じ状態になる」という仮想的なマシンを想 定する。 • 意識としては、オブジェクト指向でいうところのクラスが仮想的なマシン、メンバメ ソッド呼び出しとその引数のセットが命令、命令の羅列が命令列、と考えて良い • 仮想的なマシンを複製し、同じ命令列を与える事で同じ状態を複数台作り 上げる事ができる 補足: State Machine Replication Walk(5) Beam Jump Walk(3) Dash(1) Walk(5) Beam Jump Walk(3) Dash(1) Walk(5) Beam Jump Walk(3) Dash(1) 整列アルゴリズム
22.
Copyright©2016 NTT Corp.
All Rights Reserved. 22 • 合意→リーダー選出→アトミックブロードキャスト→State Machine Replicationの順で問題は難しくなるが、組み合わせて解く事ができる • 問題を分解して代替可能な部品(モジュール)にするのでモジュラーアプローチ • 解どのレイヤーまでをどう解くと効率が良いか未だに決定解はない 分散システムのモジュラーアプローチ State Machine Replication アトミックブロードキャスト リーダー選出 合意 ZAB ZK Raft Paxos Multi Paxos Chubby
23.
Copyright©2016 NTT Corp.
All Rights Reserved. 23 •まともな論文であれば分散システムの歴史に立脚してい るはず •その歴史の中でそのアプローチはどの立ち位置なのか、 問題をどう分解しているのかを理解してから実装する (尺が足りないから話せないFailure Detectorとか Syncronizationとかの問題の話はまた今度) 論文を読んでそのまま実装しない事
24.
Copyright©2016 NTT Corp.
All Rights Reserved. 24 Phase 2 Two Phase Commit •分散合意プロトコルの金字塔 •誰が最初の発明者かも明白でないほど古い •故障時の挙動に大量の亜種がある prepare ok commit ok coordinator worker worker Phase 1
25.
Copyright©2016 NTT Corp.
All Rights Reserved. 25 Two Phase Commit • prepare完了前にworkerが故障したらabort • これはいい prepare ok abort ok coordinator worker worker
26.
Copyright©2016 NTT Corp.
All Rights Reserved. 26 Two Phase Commit prepare ok coordinator worker worker Phase 1 •Commit前にcoordinatorが故障したら
27.
Copyright©2016 NTT Corp.
All Rights Reserved. 27 Phase 2 Two Phase Commit •Commit前にcoordinatorが故障したら、それを検 知したリカバリノードがabortを依頼してロールバッ ク • 1つもcommitが成功していない事を調べる prepare ok recover ycoordinator worker worker Phase 1 check abort
28.
Copyright©2016 NTT Corp.
All Rights Reserved. 28 Phase 2 Two Phase Commit •死んだと思っていたcoordinatorが生きていたら? • 食い違って死ぬ • Two Phase Commitは基本的に死ぬ prepare ok coordinator worker worker Phase 1 abort commit committed aborted check
29.
Copyright©2016 NTT Corp.
All Rights Reserved. 29 Phase 2 Two Phase Commit •commit途中でcoordinatorが落ちたら prepare ok commit ok coordinator worker worker Phase 1
30.
Copyright©2016 NTT Corp.
All Rights Reserved. 30 Phase 2 Two Phase Commit •commit途中でcoordinatorが落ちたら回復ノー ドが表れて一つでもcommitしていたら全部を commitさせる prepare ok commit coordinator worker worker Phase 1 commitcheck ok
31.
Copyright©2016 NTT Corp.
All Rights Reserved. 31 Phase 2 Two Phase Commit •commit途中でcoordinatorが落ちたら一つでも commitしているときリカバリノードが全部を commitさせる •その途中で一部のworkerが落ちて後で復活したら?→死 prepare ok commit coordinator worker worker Phase 1 abortcheck ok committed aborted
32.
Copyright©2016 NTT Corp.
All Rights Reserved. 32 Two Phase Commit •Two Phase Commitは故障したり復活したりするとす ぐ壊れる •回復中に壊れるパターンや回復ノードが壊れるパターンま で挙げだすと壊せるシナリオは山ほど出てくる •弱点を補強したという触れ込みの3 Phase Commitなん てものもあるけどやはり壊れている •GoogleのChubbyの開発者Mike Burrows「合意プロ トコルは一つしかない。Paxosだ」(≒他の合意プロトコ ルは全て合意不能) 覚えていただきたい事実: 2 Phase Commitはバグっている
33.
Copyright©2016 NTT Corp.
All Rights Reserved. 33 •「Paxosっていうアルゴリズムがあるんですが…説明す るには難しいのでまた今度にします」←分散システムに ついて語る人あるある •Paxos怖くないよ!合意しかできないだけだよ! 分散システムあるある
34.
Copyright©2016 NTT Corp.
All Rights Reserved. 34 Paxos •Lamport先生が「参加者の故障や復活がある場合絶対 に合意には至れない」ということを証明しようとして逆 に生み出してしまった合意プロトコル • 実は故障に耐える合意プロトコルは他にもviewstamped replicationと かstake replicationとかいろいろあるが、きっちり証明されたのは Paxosが最初 出典:http://lamport.azurewebsites.net/pubs/pubs.html#lamport-paxos Lamport先生 最近はTLA+の布教にお熱
35.
Copyright©2016 NTT Corp.
All Rights Reserved. 35 Paxos • 複雑さに定評がある(とよく言われる) • prepare, proposeがバージョン番号を持つ prepare(n) ok(n, v) propose(n, v) accept(n) proposer acceptor acceptor
36.
Copyright©2016 NTT Corp.
All Rights Reserved. 36 Paxos • Coordinator • prepare(n)に対して過半数からok(n,v)が貰えたらその中で最大のnに対するvを全 workerに投げる このvがnullなら自分自身のvを使う nullでないならvは生死不明な他のCoordinatorのvである • Acceptor • 過去に見たprepare(n)のうち最大のnであればそれにok(n,v)を返す。そうでなけれ ばng(n') vは過去に一度も合意してない場合nullかも知れない • Learner • 確定した値を読みに来る。Acceptorに最新の値vを訊きに来る。 • 過半数のAcceptorが同じ値を返さない限り、値が読めた(確定した)事にならない • Learnerが観測するフェーズまで含めるとPaxosはThree Phaseある事になる 25行で説明するPaxos: http://nil.csail.mit.edu/6.824/2015/notes/paxos-code.html
37.
Copyright©2016 NTT Corp.
All Rights Reserved. 37 Paxos •2PCだと死んだシナリオ • 蘇るcoordinator •間に入った別のcoordinatorがバージョン番号を変 えるので間違った合意に至らなくなる prepare(n) ok(n,v) proposer acceptor acceptor propose(n',v) propose(n) prepare(n') ng(n',v) ng(n',v)
38.
Copyright©2016 NTT Corp.
All Rights Reserved. 38 Paxos • 過半数にproposeが届いた時点でクラスタは合意した事になる • workerが復活してもok • 不完全な複製は後続のcoordinatorが複製し直してくれる prepare(n) ok(n, v) propose(n, v1) proposer1 acceptor acceptor coordinator2 prepare(x) ok(x, v1) propose(x, v1)
39.
Copyright©2016 NTT Corp.
All Rights Reserved. 39 Paxos • 最後にLeanerが値を読みに来る prepare(n) ok(n, v) propose(n, v) accept(n) proposer acceptor acceptor learner read() ok(n, v) ok(n, v)
40.
Copyright©2016 NTT Corp.
All Rights Reserved. 40 Multi-Paxos • Paxosは一度合意した値は二度と覆らないので、まっさらな合意を 次々と新しく作り出していく事で命令列を複製し、State Machine Replicationを成す • Learnerが読んで合意の確認が取れた命令を実行していく • 命令列に隙間ができたらスキップとかいろんな工夫があるので気になる人はRaftの論文を。 未実行命令 実行済命令x=10 x=10 x=10 1 y=3 y=3 y=3 2 z=2 z=2 z=2 3 a=8 a=8 a=8 4 b=5 5 c=9 6 Paxosの合 意1回分
41.
Copyright©2016 NTT Corp.
All Rights Reserved. 41 •In Search of an Understandable Consensus Algorithmという衝撃的なタイトルで登場したRaft • Understandableの価値を学会に認めさせるために苦労したのだとか • Paxosが合意(Consensus)しか解いてないのに対し、Raftは 合意はもちろんState Machine Replicationも解ける(=多く の分散アルゴリズム問題に帰着できる) • Googlerは合意アルゴリズムに過ぎないPaxosをロックマネージャ等へ 帰着させるのに大変な苦労をしたが、SMRから帰着させるのはずっと楽 であるという目論見 • PaxosのProposerとLearnerの両方をRaftのLeaderが兼ね ている点がすごい(Multi-Paxos的な高速化をしやすい) RaftとPaxosの類似性
42.
Copyright©2016 NTT Corp.
All Rights Reserved. 42 • Candidate(候補者)のみの状態からスタート • お互いがお互いを知っている • 全員にRequestVoteに半数以上がOKを返してくれたらLeaderへ昇格 • RequestVoteを送るまでの時間を乱数で散らす事で収束を高速化 • LeaderがAppendEntriesを送る事でSMRを実現 Raftを手短に RequestVote(t) ok AppendEntries(t,h) ok(n) candidate candidate candidate
43.
Copyright©2016 NTT Corp.
All Rights Reserved. 43 Raftを手短に AppendEntries(t,h+1) ok(n+1) candidate candidate leader • AppendEntriesの中にMulti-Paxosの重要な要素が詰まっている • Entryが空ならheartbeat変わり • candidateから返ってきたnの中の最小値を全員に送る事で「過去に合意に至ったロ グのIDを共有」できる Multi-Paxosでの合意済みIDの共有もこの中に入ってる AppendEntries(t,h) ok(n)
44.
Copyright©2016 NTT Corp.
All Rights Reserved. 44 Raftを手短に •AppendEntries • Leader「みんなー、Team 13番のリーダーだよ。前回のログの IDは同じTerm13の38だったね。39のログの内容はXXXだよ。 過去にみんなに合意してもらえたIDの最小値は36までだからス テートマシンは36まで進めて良いよ。」 •RequestVote • Candidate「Leader死んでる気がするから僕が立候補します。 前回のログはTerm13の46だったよ。」 •これら2つのRPCだけでMulti-Paxosに相当する事が実 現できるように練りこまれたのがRaft • 過去の合意の観測(PaxosでいうLearnerの仕事)を、Leaderが同 時に行ってRPCの中に折りたたんでいるのがかっこいい。
45.
Copyright©2016 NTT Corp.
All Rights Reserved. 45 •分散システムエアプ勢多すぎる • ポンチ絵とにらめっこし続ける会議をヤメロ •既成品を使うだけではなく、一緒に血反吐吐き ながらコード書きましょう • コードを書かないと見えてこないものはいっぱいある • システムの肌感覚を掴んでこそエンジニア 手を動かせ
Download now