概要 ※この記事は弊ブログ記事(はてな)、Kubernetesの負荷試験で絶対に担保したい13のチェックリストと同内容です ここ最近、Kubernetesクラスタを本番運用するにあたって負荷試験を行ってきました。 Kubernetesクラスタに乗せるアプリケーションの負荷試験は、通常の負荷試験でよく用いられる観点に加えて、クラスタ特有の観点も確認していく必要があります。 適切にクラスタやPodが設定されていない場合、意図しないダウンタイムが発生したり、想定する性能を出すことができません。 そこで私が設計した観点を、汎用的に様々なPJでも応用できるよう整理しました。 一定の負荷、スパイク的な負荷をかけつつ、主に下記の観点を重点的に記載します。 Podの性能 Podのスケーラビリティ クラスタのスケーラビリティ システムとしての可用性 本記事ではこれらの観点のチェックリスト的に使えるものとして
20200725の #JTF2020 セッションスライド。 （資料内で説明した資料へのリンク） ・昨年のJTF発表資料 https://speakerdeck.com/tzkoba/cloud-nativekai-fa-zhe-falsetamefalsedatabase-with-kuber…
README.md この和訳メモは以下のリンク先の記事の和訳です。 https://www.linkedin.com/pulse/microservices-client-side-load-balancing-amit-kumar-sharma/ マイクロサービス: クライアントサイドロードバランシング プロダクションでのフェイルセーフ性を確保するために、同じアプリケーションを複数のインスタンスにデプロイします。 同じアプリケーションをホストする論理的なサーバ（ノード）のグループは Application Clusterを構成します。 伝統的なアプローチ それらのノードの一つに伝達させるための伝統的な方法はロードバランサーを通して行われます。 クライアントはアプリケーションクラスタの前にあるロードバランサを知っています。 リクエストを受け取った際に、ロードバランサはクラスタにあるどのノー
はじめに 皆さんKubernetesを使っていますか？ 宣言的にコンテナベースのインフラを構成できるKubernetesは便利ですが、Internetへ何らかのサービスを公開する場合には必須となる「公開サービスの経路暗号化」や「公開サービスの認証認可」は、残念ながらKubernetes自体には備わっていません（Kubernetes自体には認証認可機構が有りますし、Kubernetes上に起動されるサービスのアレコレはKubernetesの範疇外なので、当たり前といえば当たり前ですが）。 Kubernetesのパッケージマネージャ的な位置づけであるHelmには、nginxでL7ロードバランサーを構成するnginx-ingressが公開されています。このnginx-ingressは非常に高機能で、パスベースのルーティングもできますしTLSの終端やBASIC認証等をさせることもできます。上手くハ
layout: true .footer[ .copyright[© 2019 TIS Inc.] ] --- class: center, middle .glass[ # Akka を用いた<br>リアクティブシステムの<br>設計パターン ] --- ## 私は何者？ - *根来 和輝* .small[Negoro Kazuki] - *TIS株式会社* - テクノロジー開発部 - *ミッション* - 高可用システムを安価なインフラで - *課外活動* - Akka 実践バイブル執筆 .with-twitter-icon[[@negokaz](https://twitter.com/negokaz)] .with-github-icon[[negokaz](https://github.com/negokaz)] .float-bottom-5.right-3[ .height-8[
メッセージの耐久性と持続性 分散型システムのノードは演算し、データを保存し、互いにメッセージを送信し合います。メッセージ送信の重要な指標は、これらのメッセージがどれだけ確実に届くかです。基幹システムでは、消失メッセージがゼロでなくてはならない場合がしばしばあります。 分散型システムにおける通信は、RabbitMQ、Kafkaなどの分散型メッセージングサービスを用いることがほとんどです。こういったメッセージングサービスはメッセージ配信において様々なレベルの信頼性をサポートしています（または、サポートするように設定を変えられます）。 メッセージの永続性とは、メッセージを処理しているノードで何らかの問題が起こった時、その問題の解決後に処理されるよう、メッセージはそこに残ることを意味します。メッセージの持続性は多くの場合、 メッセージキュー レベルで用いられます。持続性のあるメッセージキューを実装
バックエンドに関する経験があった私は、2年前にモバイルソフトウェアエンジニアとしてUberに入社しました。担当することになった仕事は、決済機能の構築を含む アプリの刷新 です。その後、 技術管理の側に回る ことになり、チームそのものを率いることになります。配下のチームは、決済を行うバックエンドシステムの多くを担当していたため、責任者となった私もバックエンドに触れる機会が以前にも増して多くなりました。 Uberで働く前は、分散型システムの経験はなきに等しかったと言っていいと思います。 それまでの私は、一般的なコンピュータサイエンスの学位を取得後、フルスタックのソフトウェア開発に10年間、関わっていました。分散型システムについては、一応、大まかな仕組みやトレードオフなどは知っていましたが、一貫性や可用性、冪等性などの概念に精通していたとはお世辞にも言えません。 この記事では、大規模で可用性が高
GitHubが障害を総括、43秒間のネットワーク断が1日のサービス障害につながった：データベースの不整合解消に時間 GitHubは2018年10月30日（米国時間）、2018年10月21日16時頃（米国太平洋時）から約24時間にわたって発生した障害に関する分析報告を、同社のブログに掲載した。これによると、ネットワーク機器の部品交換で生じた43秒のネットワーク接続断が、GitHubのメタデータ管理データベースの不整合を引き起こし、復旧に時間を要したという。 GitHubは2018年10月30日（米国時間）、2018年10月21日16時頃（米国太平洋時）から約24時間にわたって発生した障害に関する分析報告を、同社のブログに掲載した。これによると、ネットワーク機器の部品交換で生じた43秒のネットワーク接続断が、GitHubのメタデータを管理するデータベースの不整合を引き起こし、復旧に時間を要した
はじめに ドワンゴではniconicoの配信系サービスのバックエンドで利用するために、Frugalosという名前の分散オブジェクトストレージを開発しているのですが、この度OSSとして公開することとなりましたので、この場を借りて軽く紹介させて貰います。 FrugalosはRustで実装されており、現時点では以下のリポジトリが公開されています: raftlog_protobuf: raftlogへのProtocol Buffersサポートの追加 “Frugalos"って何？ “Frugal object storage"の略です。 “frugal"は日本語では「倹約な」や「節約する」といった意味となり、「読み書き性能を犠牲にせずに、膨大な数のBLOB（Binary Large OBject）を、容量効率良く保持する」ことを目指して開発されているオブジェクトストレージです。 提供されている機能は
July Tech Festa 2018 で使用したスライドです。二相コミットを例として、分散アルゴリズムの検証にモデル検査を使用する手法について解説しています。また、代表的なモデル検査ツールである SPIN、TLA+、P について、同じシステムを各ツールで記述してみることでその特定の違いについて学びま…
"Designing Data-Intensive Applications"は濃密すぎる一冊だったので2018年の自分にも読んでもらいたい 分散システムに関する理解を整理するための一冊として素晴らしい、という声があり気になっていた "Designing Data-Intensive Applications" を一通り読んだ： https://twitter.com/frsyuki/status/846431130437890049 僕のような「用語としては知っている」程度の新人に「なぜそれが大切なのか」「なにが難しいのか」といったポイントを丁寧に説明してくれる、学びの多い充実の一冊だった。 冒頭では『早すぎる最適化（不要不急のスケーラブルなシステムの構築）は制約が増えてシステム設計が不自由になるだけなので無駄』という事実に触れ、適切なツールを選択することの重要性を説いている。本書が50
10分でわかるアクターモデルです。 Erlang, Elixir, Scalaあたりを触るときに理解すべき内容です。 元ネタ: www.brianstorti.com Introduction 我々のCPUは速くなりません。 CPUには今やたくさんのコアを積んでいますが、 全てのハードウェア資源を利用したければ コードを並行的に走らせる必要があります。 マルチスレッドの利用が進むべき道でないことは、 数十年もの追跡不能バグや開発者の憂鬱が示しています。 しかし恐れることはありません。 素晴らしいいくつかの代替案があります。 今回はその中の一つを紹介しましょう。 それはActor Modelです。 Model Actor Modelは並行計算を取り扱うための概念的なモデルです。 システムコンポーネントがどのように振る舞い、相互作用すべきかについてのいくつかの原則が定義されています。 Acto
![The actor model in 10 minutes [日本語訳] - Memento memo.](https://cdn-ak-scissors.b.st-hatena.com/image/square/dc9383c4b9b345f46750cf4b42b8da31a526007f/height=288;version=1;width=512/https%3A%2F%2Ffanyv88.com%3A443%2Fhttps%2Fcdn.image.st-hatena.com%2Fimage%2Fscale%2F75e78bd20f3222324b28ff013bb35b75777d0c54%2Fbackend%3Dimagemagick%3Bheight%3D1300%3Bversion%3D1%3Bwidth%3D1300%2Fhttp%253A%252F%252Fwww.brianstorti.com%252Fassets%252Fimages%252Factors.png)
Cassandra 先ほど触れたCassandraは分散型のNoSQLデータベースで、CAP定理のAとP（可用性と分断耐性）の特性を基準に最終的な一貫性が確保されています。ただ、このように言ってしまうと少し誤解を招くかもしれません。というのも、実際のところCassandraの設定は非常に柔軟性が高く、可用性を犠牲にして強い一貫性を提供することもできるからです。ですが、そうした使用ケースは一般的ではありません。 Cassandraでは、 コンシステントハッシュ法 を使って、渡そうとするデータをクラスタのどのノードが管理するのかを決めています。そしてその際は、データを複製するノード数を示す レプリケーションファクタ を設定します。 注釈： レプリケーションファクタ＝3 挿入（キー、値） Cassandraのノード（コーディネータ） Cassandraのノード ハッシュ（キー）＝2 ノード#2
kappa-architecture.com Repository dedicated to Kappa Architecture. I collect and publish articles, tutorials, talks, projects and examples related to Kappa Architecture. What is Kappa Architecture? Kappa Architecture is a software architecture pattern. Rather than using a relational DB like SQL or a key-value store like Cassandra, the canonical data store in a Kappa Architecture system is an appen
BitTorrent BitTorrentは、Web上でtorrentを使って大容量ファイルを転送する際に広く使われているプロトコルです。その主な目的はメインサーバを経由することなく、ネットワーク内のさまざまなピア間でのファイル転送を容易にすることです。 BitTorrentクライアントを使うと、世界中の複数のコンピュータに接続してファイルをダウンロードします。.torrentファイルを開くと、コーディネーターのような役割を果たすマシン、いわゆる トラッカ に接続されます。トラッカはピアを見つけ出し、欲しいファイルを持っているネットワーク内のノードを示してくれます。 注釈： トラッカ ・オンラインのノードをトラッキングする ・ノードが何のファイルを提供しているかを認識する Seeder：シーダ Leeche： リーチャ 破線：ファイル転送 実線：メタデータ転送 ネットワークのサンプル ユー
Private content!This content has been marked as private by the uploader.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
