1対NやN対1の転送では1台のサーバに高い負荷がかかる一方で、log(N)対1やN対Nの転送ではディスクへのアクセスが起こってしまうというトレードオフがあります。以下において、より詳細な転送方向ごとの実装と掛かるコストについて解説します。 DriverからExecutorへの転送 - Broadcast、Closure BroadcastはTask間で共通のデータ(現在のパラメータなど)をDriverから各Executorに一つだけ転送するSparkの機能です。Taskとして実行されるClosure(関数オブジェクト)に共通のデータを直接埋め込むと、Executorに対してTaskの数だけ共通データが転送されることになるため、これを避けるためにBroadcastが利用されます。 Broadcastでモデルのパラメータを転送する場合、Driverと各Executorのメモリ上でそれを持つ必要
ギリシャからこんにちは!こんばんは! NTTコミュニケーションズアドベントカレンダー 6日目です。 私は今、神々の王ゼウスが生まれた伝説の島、クレタ島にいます。 というのも、こちらで開催されているACM CoNEXT 2018という国際学会に参加しているからです。 QUICに関する最新成果を発表する Evolution, Performance, and Interoperability of QUIC (EPIQ) ワークショップ も併催されました。 ポスター発表もしてきたので、今日はそれに関連して、kubernetes(k8s)を使ったQUIC負荷テスト の構成方法について、お話します。 この記事でわかること QUICについての基礎知識 kubernetesを使った負荷テストの構築手順(kubeadm + kubenet) QUICとは QUICは、TCP+TLSに代わるUDP上の新し
From Type Theory to Haskell in 10 Minutes Type systems are so prevalent in modern programming languages that we probably take them for granted. But what exactly is a "type", and what are its origins in the history of computational logic? In this post, we'll take you on a 10-minute tour from Leibniz's effective computability dilemma, through Russell's theory of types and Church's lambda calculus, a
SSRF(Server Side Request Forgery)という脆弱性ないし攻撃手法が最近注目されています。以下は、ここ3ヶ月にSSRFについて言及された記事です。 EC2上のAWS CLIで使われている169.254について SSRF脆弱性を利用したGCE/GKEインスタンスへの攻撃例 SSRFを利用したメール送信ドメインの乗っ取り 「CODE BLUE 2018」参加レポート(岩間編) この「空前のSSRFブーム」に便乗して、SSRFという攻撃手法および脆弱性について説明します。 SSRF攻撃とは SSRF攻撃とは、攻撃者から直接到達できないサーバーに対する攻撃手法の一種です。下図にSSRF攻撃の様子を示します。 攻撃者からは、公開サーバー(203.0.113.2)にはアクセスできますが、内部のサーバー(192.168.0.5)はファイアウォールで隔離されているため外部から直接
TL;DR マイクロサービスの4層アーキテクチャごとの可用性 Kafkaを使ったチャットアプリサービスをk8sにデプロイ chaoskubeを使ってカオステストを実施 マイクロサービス4層アーキテクチャ Production-Ready Microservicesの著者である、Susan Fowler氏はマイクロサービスを4層アーキテクチャとして定義している。 The Four Layers Of Microservice Architecture マイクロサービス(サービス本体) アプリケーションプラットフォーム(ロギング、監視) 通信(サービス間の通信) ハードウェア ハードウェア部分をクラウド、サービス間の通信をk8sに任せる。アプリケーションプラットフォーム以上についてもk8sとの組み合わせで高機能・高可用性を実現できる。 高可用性を実現するためには、レイヤー毎に単一障害点(SPO
Kubernetes in Startup ~UbieのインフラをKubernetesに乗せた話~ Japan Container Days v18.12 MeetUp
この記事は、下書き供養 Advent Calendar 2018 - Adventarの2日目の記事です。 めっちゃ専門的な内容になってしまいました。ごめんなさい。 某Slackでの議論内容をブログに書こうとしたのですが、下書きのまま放置していました。 Wednesday, August 15th と書いてあるので、約半年前の内容となります。 もくじ もくじ はじめに 「データ基盤の3分類」と「(一般的な)技術要素」 1.データレイク(Data Lake) 2.データウェアハウス(Data Warehouse) 3.データマート(Data Mart) 私が考えるデータ基盤の定義 私が考える「あるべき構成」 技術要素を分けるのはアンチパターン 進化的データモデリングを容易にしよう チームとアーキテクチャを選ぶ まとめ 参考 余談 追記 はじめに データ基盤と世間一般で言われるシステムには分類
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く