20200725の #JTF2020 セッションスライド。 (資料内で説明した資料へのリンク) ・昨年のJTF発表資料 https://speakerdeck.com/tzkoba/cloud-nativekai-fa-zhe-falsetamefalsedatabase-with-kuber…
Amazon が 2 台目のサーバーを追加した時から、分散システムは Amazon で馴染み深いものになりました。私が 1999 年に Amazon に入社したとき、サーバーの数が非常に少なかったため、「fishy」や「online-01」などのわかりやすい名前を付けることができました。けれども、1999 年であっても、分散コンピューティングは容易ではありませんでした。また現時点で、分散システムの課題には、レイテンシー、スケーリング、ネットワーキング API の理解、データのマーシャリングとアンマーシャリング、および Paxos などのアルゴリズムの複雑さが含まれます。システムが急速に大きくなり、分散するにつれて、理論的なエッジケースであったものが定期的に発生しました。 信頼できる長距離電話ネットワークやアマゾン ウェブ サービス (AWS) のサービスといった分散ユーティリティコンピュー
[速報]「The Amazon Builders' Library」発表。大規模分散システムの構築、運用などについて、Amazonが学んできたことをコンテンツとして公開。AWS re:Invent 2019 Amazon.comが開発してきた世界最大級の電子商取引システムや、それを支えるインフラであるところのAmazon Web Servicesは、世界でも最も複雑で巨大な分散システムの1つです。 そしてAmazon.comやAWSにとってさえ「分散システムの構築は難しいものだった」と、Amazon.com CTO Werner Vogels氏。 そしたなかで、Amazonはどのように堅牢でスケーラブルな分散システムを作ったのか? エンジニア組織をスケールさせてきたのか? どのように運用しているのか? どうやってサービスを迅速に提供しているのか? AWSのブログに投稿された記事「Check
はじめに July Tech Festa 2020において、「マイクロサービスの今だからこそ!理解して拡げる 分散システムの基礎知識」のタイトルで登壇をしてきました。スライドはこちらにありますが、資料内や当日のトークで話せていない部分を含めて、こちらでblogとして解説をしておきたいと思います。 1. セッションの導入 - 新たなムチャブリ - 今回は昨年の#JTF2019で私が話した、「Cloud Native開発者のためのDatabase with Kubernetes」からの続編という形にしてみました。 昨年は、 「せっかくKubernetesを使うのにアプリケーションだけじゃもったいない。 DB、そしてステートフルなワークロードにも適用していきましょう」 という話をしましたが、Kubernetes-native Testbedなど、そうした取り組みが増えつつある傾向にはとても興味を
目次 分散システムを作る際に気をつけて欲しい事 1.分散自体を目的にしない事 2.論文を読んでそのまま実装しない事 3.Two Phase Commitを使わない事 4.手を動かす事 Copyright©2016 NTT Corp. All Rights Reserved. 2 分散自体を目的にしない事 • よくわかってない人でもCloudera Managerをダウンロードして1時間後 には巨大なHadoopクラスタを立ち上げてYARN, HDFS, Spark, HBase などで遊ぶ事ができる。 • 世の中では分散システムが必要以上に喧伝されている • 「コンピュータ1台よりも2台の方が高速」という直感に対して反論するの は意外と難しい • あなたのそのシステム、本当に分散システムじゃないとダメ? Copyright©2016 NTT Corp. All Rights Reserve
分散Erlangシステムを楽しむには複数のPCがあるといいのですが、それだと準備が大変で敷居を高く感じるかもしれません。 Dockerを使えば一つのPC上に複数の仮想ホストを簡単に立ち上げられます。それらを別々のPCに見立てれば、気軽に遊べるのではないでしょうか。 やりたいこと Dockerで仮想Linuxマシンを三つ起動してそれらを別々のPCと見立てる それぞれの仮想Linuxマシンでノードを起動する すべてのノードを接続 後は自由に遊ぶ ノードとは 分散Erlangのドキュメントによると A distributed Erlang system consists of a number of Erlang runtime systems communicating with each other. Each such runtime system is called a node. 分散
今から10年ほど前の2013年、筆者は六本木のダイニングバー「The Pink Cow」に入り浸っていた。多国籍の料理や酒を楽しむため……ではなく、そこに集う暗号資産(仮想通貨)Bitcoin(ビットコイン)ファンに話を聞くためだ。 銀行を介さず自らデジタル通貨を管理し、店で決済できるBitcoinの可能性に、誰もが興奮していた。ブロックチェーンを使えば、銀行や国家から独立したDecentralized(非中心、非中央集権)なマネーを運営できる。そんな魅力に引かれていた。 そして2022年。DeFi(分散型金融)やNFT(非代替性トークン)、DAO(分散型自律組織)などに代表される「Web 3.0(Web3)」のブームにおいても、やはり人々を引き付けたのは非中心という考え方だった。「Web 1.0やWeb 2.0は中央集権的だが、Web 3.0は非中心になる」といわれるようになった。 とは
Amazonの分散システム開発のノウハウが凝縮された「Amazon Builder’s Library」の中身を見てみた #reinvent 本日、Wernerのキーノートにて、開発者向けドキュメントラブラリーであるところの「Amzon Builder's Library」のリリースが発表されました。 Welcome to the Amazon Builders’ Library 弊社西澤の速報記事もでております。Amazon Builder's Libraryの概要はこちらを参照ください。 [速報] The Amazon Builders’ Libraryが発表されました #reinvent | Developers.IO 現在、13個のライブラリが登録されていますが、この中から自分が気になったライブラリーを何個か紹介しようと思います。想像していた以上に内容が濃い! (祭) ∧ ∧ Y
重大な障害が発生したサービスからは、有用な結果を得ることができなくなります。たとえば、e コマースウェブサイトでは、製品情報のデータベースクエリが失敗すると、ウェブサイトは製品ページを正常に表示できません。Amazon のサービスは、信頼性を高めるために、重大な障害の大部分を処理する必要があります。重大な障害を処理するための戦略には、大きく次の 4 つのカテゴリーに分かれます。 • 再試行: すぐに、または少し遅れて、失敗したアクティビティを再度実行します。 • 積極的な再試行: アクティビティを並行して複数回実行し、最初のアクティビティを使用して終了します。 • フェイルオーバー: エンドポイントの別のコピーに対してアクティビティを再度実行するか、できればアクティビティの複数の並行コピーを実行して、それらの少なくとも 1 つが成功する確率を上げます。 • フォールバック: 異なるメカニズ
目次 目次 はじめに 分散システム視点での自動テストシステム 分散システム構成 入力 出力 テスト対象システム コンポーネント ノード Testcase Allocator Cucumber Selenium Browser 事例:食べログで起きた分散システム視点でのFlakyテスト 問題 Flakyテストの事象: "たまに" "不特定" "多数のテストケースが" "Cucumberのstepの60秒タイムアウトエラーで失敗する" Flakyテストの原因調査の複雑さ 原因と対策 「事象A: たまに(4回に1回程度の頻度で)」の原因と対策 「事象B: 不特定 (毎回異なるテストケース)」の原因と対策 「事象C: 多数のテストケースが(テストケース全体の20~70%程度)」の原因と対策 「事象D: Cucumberのstepの60秒タイムアウトエラーで失敗する」の原因と対策 結果 巻き込まれて
技術記事『Amazon Builders' Library』にフォーカスを当てた勉強会「AWS Tech talkNight#5 クラウドネイティブ時代のエンジニアが押さえておきたい ソフトウェアの構築・運用で考慮すべき5つのポイント ~AWSプリンシパルエンジニアの技術記事をソリューションアーキテクトが解説~」。ここで、ソリューションアーキテクトの松田氏が登壇。まずは分散システムについて話します。 松田氏の自己紹介 松田丈氏:あらためまして、みなさんこんばんは。アマゾンウェブサービスジャパン ソリューションアーキテクトの松田丈です。よろしくお願いします。 私からは「分散システムの課題とリーダー選挙」というテーマでお話しします。本日4つ目の発表で、そろそろお疲れの方も多いかもしれませんが、チャットなどで盛り上げていただけるとうれしいです。ぜひリラックスして聞いてください。 はじめに自己紹
技術記事『Amazon Builders' Library』にフォーカスを当てた勉強会「AWS Tech talkNight#5 クラウドネイティブ時代のエンジニアが押さえておきたい ソフトウェアの構築・運用で考慮すべき5つのポイント ~AWSプリンシパルエンジニアの技術記事をソリューションアーキテクトが解説~」。ここで、ソリューションアーキテクトの松田氏が登壇。続いて、リーダーノードについて話します。前回はこちらから。 リーダーノードを設ける3つのメリット 松田丈氏:次に、この問題を単純にしてくれるリーダーノードという考え方について説明します。リーダーノードとは何でしょうか。(まず)リーダーノードを設けるメリットについて見ていきます。 1つ目のメリットは、データの整合性担保をリーダーノード内で完結させられることです。例えば競合する書き込みがあった際に、その順序性をリーダーノード内で整理す
MicrosoftはCNCF(Cloud Native Computing Foundation)が主催するWebinarで、クラウドネイティブなシステムにおいて分散処理を実装するランタイムであるDaprを解説するセッションを実施した。CNCFのWebinarページには、CNCFにホストされている多数のプロジェクトのセッションだけではなくCNCFのメンバーによる技術解説が公開されている。今回紹介するセッションは2020年10月1日に公開されたもので、CNCFのプラチナムメンバーであるMicrosoftがコンテンツを提供したものになる。 参考:Dapr, Lego for microservices セッションのタイトルは「Dapr, Lego for Microservices」というもので、マイクロサービスを構築する際にランタイムとして機能するDaprの最新情報を紹介する内容となった。
※この投稿は米国時間 2020 年 5 月 2 日に、Google Cloud blog に投稿されたものの抄訳です。 分散システムには数多くの設計方法が存在しますが、その一つにシステムの自然な拡張を考慮した設計があります。この方法では、システムがより多くのリクエストを処理していくにつれて、コンポーネントの書き換えや再設計を行います。また、概念実証から始める手法もあります。システムによってビジネスに付加価値がもたらされたら、次のバージョンがゼロから設計されます。 Google では、Non-Abstract Large System Design(NALSD)と呼ばれる手法を使用しています。NALSD は、分散コンピューティング向けの Borg クラスタ管理や Google の分散ファイル システムなど、分散システムの設計、検証、評価を行うための反復プロセスについて記述しています。最初から
これは何? 分散システム初学者が、MITの院生向け講義 6.824: Distributed Systems を一通りやってみたので、その内容をまとめる。 分散システムなる分野に入門したいと思った際の一つの選択肢として個人的にオススメできるコンテンツだったので、この場で広く推すために書いている。 Lab3で扱うRaftのアーキテクチャ図より引用1 きっかけ 元々のモチベーションとしては、お仕事周りでAurora2やDynamo3、EBS4といった文献に目を通す中で、そもそも根底にある分散システムという分野を全然知らない。俺たちは雰囲気でクラウドをやっている(画像略)5…という気分になったのがきっかけだった。 ちょうど年末の空き時間に分散システムのオススメコンテンツを探している中で、推されていたこのコンテンツに出会ったのが12月末。その後は仕事の後など空き時間にちまちまやって、結局Lab3ま
ネットワークの次は、さまざまなAPIやエンドポイント、つまり、リソースバインディング - 他のプロトコルやさまざまなデータ形式と通信できるようにします。おそらく、あるデータ形式から別のデータ形式に変換することも必要でしょう。ここには、ろ光器 (light filtering) なども含めます。つまり、トピックをサブスクライブするときに、特定のイベントにのみ関心があるかもしれません。 最後のカテゴリーは何だと思いますか? それは状態です。私が状態とステートフル抽象化と言うときは、データベースの機能やファイルシステムなど、実際の状態管理については話していません。私は開発者が状態に依存している舞台裏の抽象化についてもっと話しています。おそらく、ワークフロー管理を行う能力が必要です。実行時間の長いプロセスを管理したり、一時的なスケジューリングやcronジョブを実行して、サービスを定期的に実行したい
この記事はEnjoy Architectingからの転載です。 概要 分散システムを学術的に学びたくて、 Chord Protocolというアルゴリズムが面白かったので実際に論文を読んで実装してみました。 この記事では、分散システムにおける名前付けの概念と、Chord Protocolの紹介、簡単な検証について言及していこうと思います。 分散システムにおける名前付けとは? 分散システムの分野には「名前」、「名前付け」、「アドレス」と呼ばれる概念があります。 それぞれどのような意味を持っているのでしょうか? 名前付けと名前 分散システムはネットワークを通じてそれぞれのサーバ、プロセスが協調して動作しています。 この中で、各サーバ、プロセスはやり取りをする相手の「名前」を知らなければやり取りを行うことができません。 この名前の解決を行うことを「名前付け」と呼んでいます。 そして、あるリソース(
あけましておめでとうございます(いまさらw)。もーすけです。 最近は呪術廻戦にハマっています。ぜひまだ見てない方見てみてください! さて本題ですが、新年はじめの投稿はデータ指向アプリケーションデザインという書籍についてです。 最近読んだ中で一番良かった本ではないかと思っています。 実は、勤めている会社内でこの書籍の輪読会を行っていて、自分が12章(最終章)を担当しました。 12章はこの本の一番言いたいことが書いてある章でもあったので、本の魅力を理解してもらうのにもしかして役立つのでは!?と思い、この書籍の紹介しつつ、輪読会で発表した内容を動画で解説していきたいと思います。 どんな本なのか? もしかしたら本のタイトルから「データエンジニアとかデータサイエンスの人とかよむ本かな?」と思ってしまうかもしれません(自分は最初ちょっとそうおもってましたw)。しかし、この本は 「信頼性があり、スケーラ
AWS Summit tokyo 2023の「Everything fails, all the time:分散システムにおける耐障害性のある設計について」のセッションレポートです。 セッション概要 【スピーカー】 アマゾン ウェブ サービス ジャパン合同会社 グローバル・オートモーティブ事業部 シニアソリューションアーキテクト 小林 芙美 システムは必ず壊れます。マイクロサービスのような分散システムや、AWS のマネージドサービスを活用したクラウドネイティブなシステムは、上手く設計することで高い耐障害性を実現できます。一方でコンポーネント間の連携が複雑化することで障害の原因特定が困難になったり、挙動を完全に予測することが困難になります。このような分散システムにおいて、高い耐障害性を備えたシステムを設計するための方法をお話しします。 セッション視聴 5/22からAWS Summit Tok
概要 分散システムを学術的に学びたくて、 Chord Protocolというアルゴリズムが面白かったので実際に論文を読んで実装してみました。 この記事では、分散システムにおける名前付けの概念と、Chord Protocolの紹介、簡単な検証について言及していこうと思います。 実際に作ったサーバ 分散システムにおける名前付けとは? 分散システムの分野には「名前」、「名前付け」、「アドレス」と呼ばれる概念があります。 それぞれどのような意味を持っているのでしょうか? 名前付けと名前 分散システムはネットワークを通じてそれぞれのサーバ、プロセスが協調して動作しています。 この中で、各サーバ、プロセスはやり取りをする相手の「名前」を知らなければやり取りを行うことができません。 この名前の解決を行うことを「名前付け」と呼んでいます。 そして、あるリソース(特定のプロセス、サーバなど)を一意に特定する
大学卒業後に Amazon に入社したとき、最初のオンボーディングの練習の 1 つは、amazon.com ウェブサーバーを開発者のデスクトップで起動して実行することでした。最初の試行はうまくいきませんでした。何を間違えたのかすらわかりませんでした。親切な同僚が私に、ログを見て何が間違っているのかを確認するように提案しました。彼は、そのために「ログファイルを猫にする」べきだと言いました。 私は、彼らが何らかのいたずらをしているか、私には理解できない猫に関する冗談を言っているのだと確信しました。私は大学で Linux のみで、コンパイル、ソース管理、およびテキストエディタを使用しました。そのため、「cat」が実際に端末にファイルを出力するコマンドであり、別のプログラムにフィードしてパターンを探せるものだとは知りませんでした。 同僚に、cat、grep、sed、awk などのツールを教えてもら
原文(投稿日:2021/09/03)へのリンク Ably Blogの先日の記事では、Alex Diaconu氏が、公開から13年を経た"eight fallacies of distributed computing (分散コンピューティングの8つの嘘)"を振り返るとともに、それらに対処するためのいくつかのヒントを紹介している。そのDiaconu氏に、Ablyのエンジニアたちがそれらの誤謬にどう対処しているのか、詳しく聞くことができた。 "eight fallacies"は、ソフトウェア開発を失敗に導く可能性のある、分散コンピューティングに関わる一連の誤謬(誤った考え方)だ。具体的には、"ネットワークは信頼できる"、"遅延はゼロである"、"帯域は無限である"、"ネットワークは安全である"、"トポロジは変化しない"、"管理者はひとりである"、"転送コストはゼロである"、"ネットワークは均一で
リチャード 伊真岡です。この連載では非同期処理に役立つアクターモデルを学ぶため、JavaとScalaから使えるOSSであり、アクターモデルの実装を提供するAkkaを紹介します。前回の記事ではアクターと永続化層を接続する有効な設計パターンである、イベント・ソーシングとCQRSを紹介しました。今回は複数台のノードで構成したクラスター上でAkkaアクターを動かす、Akkaクラスターを解説します。 伝統的3層アーキテクチャでのスケールアウト 現代のシステムでは、ノード1台(本稿では、Akkaクラスターが立脚している分散システムの用語に合わせ、1台のコンピュータやサーバーを指します)で構成するシステムは稀で、負荷分散や耐障害性のため複数のノードで構成することが一般的です。 例えばアクターを用いない伝統的な3層アーキテクチャで、かつアプリケーション層に内部状態が存在しない設計の場合は、ノードの数を増や
CDSLでは,これまで仮想マシンで踏み台サーバを運用していました.踏み台サーバの役割はアクセス境界での認証のみです.今回,この踏み台サーバをコンテナ化しました. 研究室内に構築したKubernetes上に以下の構成ファイルでデプロイしました. cdsl-research/container-jumpsv: 踏み台サーバー(コンテナ) 以下の図は,アーキテクチャの全体像です.ESXi上のVMで構成されたKubernetesクラスタ上では,sshdが動作する踏み台コンテナが動作しています.踏み台コンテナは外部からのアクセスをNodePortにより実現しています.コンテナのログはrsyslogによりログサーバ(Fluentd)へ転送されます.踏み台の認証にはSTNSにより構築したID管理サーバにより実現しています. 外部からのアクセスは,RouterからポートフォワードでKubernetesクラ
LINEで働くエンジニアが、各職種別に日々の業務内容や開発体制、働く環境、今後の展望などについて話す「LINE 新卒採用 技術職 コース別説明会」。ここでデータプラットフォーム室の奥田氏が登壇。Data Platform室について話します。 奥田氏の自己紹介 奥田輔氏(以下、奥田):じゃあ始めます。よろしくお願いします。LINEのData Engineeringセンター Data Platform室の奥田と申します。 私からは、Data Platform室が何やってるかとか、先ほど紹介もありましたが、LINEはデータプラットフォームを持ってます。(なので)それに関しての技術的だったり、ビジネス、会社的な位置付けも含めて紹介できればと思います。よろしくお願いします。 まず自己紹介です。奥田と申します。実は私も新卒(入社)で。ただかなり昔ですね。2013年の新卒入社になります。最初はインフラデ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く