これは Aizu Advent Calendar 2019 の 15 日目の記事です。14 日目は uzimaru0000 さん、16 日目は kacky__917 さんです。 はじめに 世の中には日々たくさんの価値ある Web サービスが生まれていますが、その価値を正しく提供するにはアプリケーションが正しく動かなければなりません。 たとえばアプリケーションは適切なユーザに適切なリソースを提供しなければならず、エラーを返す際は十分に定義された仕様に沿って返し、UI 側ではユーザに適切なメッセージを表示しなければなりません。 実際のところ、これらを厳密に実現するのは非常に困難ですが、アプリケーションにはこれら以上に複雑な問題が常につきまといます。 現在の Web アプリケーションはほとんどが分散システムの一形態です。例えばクライアントとサーバや、サーバとデータベースがネットワークを介して接続
Twitterフォロー&条件付きツイートで「バリーくんぬいぐるみ」を抽選で20名にプレゼント！ 応募期間は2019/11/29～2019/12/31まで。詳細はこちらをご覧ください。 今すぐツイートするならこちら→ フォローもお忘れなく！ 【IIJ 2019 TECHアドベントカレンダー 12/12（木）の記事です】 久しぶりに書きました。 どうもこんばんわ。九州支社で働くとみです。お久しぶりです。 実は2016年に一つ記事を投稿したのですが、実に3年半経過した今になってアドベントカレンダーの話が聞こえてきたので、久方ぶりに書いてみることにしました。 当時はこんな記事なんかを書いてたわけですが、この記事を書いてから3年間色々あったので、その中の一つを書いてみようかなと思います。 3年間で覚えたことを並べてみる 2016年当時はTHE ON-PREMISEと言われてもおかしくないような、どイ
「JX通信社Advent Calendar 2019」10日目の記事です. 昨日は, @rychhrさんの「Pure WebSocketsをサポートしたAWS AppSyncでWebとiOS間のリアルタイムチャットを作ってみた(1)」でした. 改めまして, こんにちは. JX通信社でシニア・エンジニア&データ基盤エンジニアをしています, @shinyorke（しんよーく）と申します. JX通信社では, データ駆動での意思決定および施策実施をより円滑に進めるため, データ基盤の構築・運用を進めながらトライアル的に様々なFrameworkやツールの検証を行っています.*1 このエントリーでは, 私がシュッとPySparkで分散処理をする...前に, 手元で試したときの感想とその知見 のお話を残していきたいと思います. なお, 分散処理そのものの知見・ノウハウではなく, する前にPySparkに
「マイクロサービスとメッセージングのなぜ [概要編]」はこちらです。 レッドハットでインテグレーションのためのミドルウェア製品のテクニカルサポートを担当している山下です。 概要編ではメッセージングの良い面ばかりに焦点を当ててきましたが、今回の疑問編ではメッセージングを検討し始めたときに疑問に思ったり困りがちなことを説明したいと思います。概要編とは異なり、細かな技術的内容も含まれますので、その時々で必要な部分や興味ある部分だけ読んでいただければと思います。 (ところで、当初は前回を前編、そして今回を後編にして終わらせようと思っていたのですが、今回もあまりに長くなってしまったので、構成を変えたのでした。 このため当初の前編は概要編と名前を変更しています。) ではまず主に疑問とされることを確認して、その後に対処法を見ていきましょう。 メッセージングを利用することによる主な疑問 対処方法 Q1:
![マイクロサービスとメッセージングのなぜ [疑問編] - 赤帽エンジニアブログ](https://cdn-ak-scissors.b.st-hatena.com/image/square/f80853750b1c5f85bbe4ae4c26691362ff89c530/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Ft%2Ftyamashi-oss%2F20191208%2F20191208182318.jpg)
ジッターを伴うタイムアウト、再試行、およびバックオフ
あるサービスまたはシステムが別のサービスまたはシステムを呼び出すたびに、障害が発生する可能性があります。これらの失敗は、さまざまな要因から発生することがあります。サーバー、ネットワーク、ロードバランサー、ソフトウェア、オペレーティングシステム、またはシステムオペレーターからのミスが含まれます。故障の可能性を減らすようにシステムを設計していますが、故障しないシステムを構築することは不可能です。そのため、Amazon では、障害の可能性を許容して削減するようにシステムを設計し、わずかな割合の障害を完全に停止するまで拡大することを防いでいます。回復力のあるシステムを構築するために、タイムアウト、再試行、およびバックオフの 3 つの重要なツールを採用しています。 リクエストが通常より長くかかり、完了しない可能性があるため、障害の種類の多くが明らかになります。クライアントがリクエストの完了を通常より
【毎月更新・日本の AWS エンジニアがクラウド解説】 初心者向け解説、最新のクラウドネイティブな開発手法・利用シーン別ハンズオンを学ぶ »
The Amazon Builders' Library
Amazon is an Equal Opportunity Employer: Minority / Women / Disability / Veteran / Gender Identity / Sexual Orientation / Age.
LINE社内でのサービス横断データ活用の取り組み「Feature as a Service」の全体像 Feature as a Service at Data Labs #1/2 2019年11月20、21日、LINE株式会社が主催するエンジニア向け技術カンファレンス「LINE DEVELOPER DAY 2019」が開催されました。20日は「Engineering」をテーマに技術的な内容のセッション、21日は「Production」をテーマに実践的な内容のセッションを多数取り揃え、LINEのエンジニアリングにおける知見を各プロダクトのキーマンがシェアします。「Feature as a Service at Data Labs」に登壇したのはLINE Machine LearningチームのChaerim Yeo氏。データ専門研究開発組織「LINE Data Labs」での機械学習の特徴量
モノレポについての誤解 - Misconceptions about Monorepos: Monorepo != Monolith を翻訳しました | Graat（グラーツ）-グロース・アーキテクチャ＆チームス株式会社
モノレポについての誤解 - Misconceptions about Monorepos: Monorepo != Monolith を翻訳しました unsafe:このドキュメントは、モノレポについて書かれた記事 Misconceptions about Monorepos: Monorepo != Monolith (https://blog.nrwl.io/misconceptions-about-monorepos-monorepo-monolith-df1250d4b03c) を、筆者であるVictor Savkin氏の許可を得て翻訳したものです。 複数のプロジェクトを同一のリポジトリで運用する モノリシックリポジトリ（モノレポ）― この記事では、モノレポを使う際によくある誤解とその対策、モノレポが持つ本当の課題と利点がまとめられています。モノレポはガチガチの「一枚岩（モノリス）」
分散トレーシングの技術選定・OSS 貢献, Stackdriver Trace での性能可視化・改善 / Distributed Tracing case study
分散トレーシングの技術選定・OSS 貢献, Stackdriver Trace での性能可視化・改善 / Distributed Tracing case study パフォーマンスに苦労している並列処理システムを改善するために Stackdriver Traceを導入して動作の可視化を行った結果、 ボトルネックの存在が判明してパフォーマンスを改善できた事例について紹介します。 この事例でStackdriver Traceを選定した過程や OpenTelemetry へコントリビュートした経緯についても共有します。 また、新規開発のGraphQLサーバへ導入して REST APIサーバと通信をまたいだ可視化を行った事例についても紹介します。
PostgreSQL Conference Japan 2019 (2019-11-15) PostgreSQLの皮を被った次世代RDBMS - Project Tsurugi (劔) について https://www.postgresql.jp/jpug-pgcon2019#K1 資料→https://drive.google.com/file/d/1MYNyq3y2zlGh1qo92rWATSn8IhqU1GE4/view 解説→https://okachimachiorz.hatenablog.com/entry/2019/12/24/230908
Remote Work Statistics
Remote Work Statistics Statistics about remote work from 2498 companies working remotely in 3200 cities across 131 countries. Most countries Meet the TOP 10 distributed companies with employees coming from most countries.
Googleが作った分散アプリケーション基盤、Borgの論文を読み解く -その2- - inductor's blog
このエントリーについて このエントリーを書き始めた経緯は下記にあります。 inductor.hatenablog.com 今回は前回の続きでセクション3からです！前回のエントリーはこちらです。 inductor.hatenablog.com 3. Borgアーキテクチャ(Borg architecture) Borgセルは、マシンのセット、Borgmasterと呼ばれる論理的に集中化されたコントローラ、およびセル内の各マシン上で実行されるBorgletと呼ばれるエージェントプロセスで構成されます(図1参照)。 BorgのすべてのコンポーネントはC++で書かれています。 3.1 Borgmaster 各セルのBorgmasterは、メインBorgmasterプロセスと個別のスケジューラ（§3.2）の2つのプロセスで構成されています。 メインのBorgmasterプロセスは、ステートを変更（ジ
分散深層学習における耐故障性と可塑性 - Preferred Networks Research & Development
ImageNetを15分で学習して以来 [1]、Chainerと沢山のGPUを使って深層学習を並列化し、一回の学習に必要な時間を大きく短縮することができるようになりました。その後、ImageNetの学習は深層学習における並列化 ・高速化のデファクト標準ベンチマークとなりました [2]。それと同時に、深層学習の並列化および大規模化は進み、複数GPUどころか複数ノードで学習することは当たり前のこととなりました。深層学習の計算が大規模化し所要時間はどんどん短くなりましたが、一般的にはノードが増えれば増えただけ部分故障の確率は高くなります。また、大規模なクラスタでは個々の分散ジョブをスケールアウトしたりスケールダウンする機能、つまり可塑性をもとにした計算資源のやりくりが運用上重要になってきます。そこでChainerを拡張し、分散深層学習に耐故障性だけでなく可塑性を導入する実験を行いましたので、ここ
コードレビュー自動化、障害注入／分散トレーシング、マルチクラウドIaC――コンテナベースのCI/CDがもたらす新たな開発者体験とは
コードレビュー自動化、障害注入／分散トレーシング、マルチクラウドIaC――コンテナベースのCI/CDがもたらす新たな開発者体験とは：コンテナベースのCI/CD本番事例大解剖（終）（1/2 ページ） Kubernetes、コンテナ技術を活用したCI/CD基盤におけるサービス開発について、リクルートテクノロジーズの事例を基に解説する連載。最終回は、「プロダクト品質の磨き込み」「アジリティの向上への取り組み」の2つを中心に解説を進めます。 本連載「コンテナベースのCI/CD本番事例大解剖」では、リクルートテクノロジーズが取り組んだ事例を基に、Kubernetes、コンテナ技術を活用したCI/CD（継続的インテグレーション／継続的デリバリー）基盤におけるサービス開発について解説しています。 これまで3回にわたる連載では、アプリケーションエンジニアおよびインフラ／運用エンジニアの観点から、技術選定に
こんにちはあんどう(@t_andou)です。 今回はKubernetesを使って並列処理させた記録です。 まだ「とりあえずそれっぽく動くまで試してみた」という段階で、kubernetesを理解できてはいないので自分用のメモを公開しているという認識でご覧ください。 間違っている部分や、よりスマートなやり方がありましたらご指摘いただけると幸いです。 この記事の概要 機械学習に使う特徴量の作成で1週間かかりそうな処理を10分くらいで終わらせられないかと考え、GKE(=GoogleのKubernetes環境)を使い試行錯誤した記録です。 今回は一部失敗して完了時間が1.5時間になったものの、設定を上手く出来れば15分程度で終わる見込みです。 対象読者 ・Kubernetesの概要は知っているくらいのレベルの人 ・KubernetesのJobを使った並列処理をしたい人 目次 この記事の概要 対象読者
Googleが作った分散アプリケーション基盤、Borgの論文を読み解く -その1- - inductor's blog
このエントリーについて このエントリーを書き始めた経緯は下記にあります。 inductor.hatenablog.com 上記の理由の通り、目的は論文を翻訳することだけではなく、最終的にこれを踏まえて自分の見解をつらつらと書いていくところにもあります。 おそらく一番時間がかかるのはそれなので、一旦は翻訳を一通り終えた上で更に頑張っていきます。ゆっくりお待ちいただければと思います＞＜ 1. Introduction(まえがき) Borgが内部的に呼び出すクラスター管理システムは、Googleが実行するすべてのアプリケーションを許可、スケジュール、起動、再起動、および監視します。この論文ではその方法を説明します。 Borgには3つの主な利点があります。 リソース管理と障害処理の詳細を隠すため、ユーザーは代わりにアプリケーション開発に集中できます。 非常に高い信頼性と可用性で動作し、同じことを行
Googleが作った分散アプリケーション基盤、Borgの論文を読み解く -導入編- - inductor's blog
はじめに こんにちは。inductorです。 今日のエントリーはタイトルの通りです。 BorgはGoogleが持つアプリケーション実行基盤で、Google CloudにおいてはGKEのマスターノードやGoogle App Engineなどが実際に動くインフラとしても使われています。 また、話題のKubernetesの元になったGoogle Insideなプロジェクトとしても有名かとおもいます。 ツイッターで誰かが「Borgの論文を誰か日本語で解説してほしい」と言っていたのを見かけたのを見かけたので、論文を読んで実際に中身を紐解いてみたいなと思いました。 元論文はこちらです ai.google 何を書くのか 自分は実はBorgの論文をきちんと読み込んだことはないため、時間を掛けて何回かに分けてやってみようと思っています。 実は、Borgの解説自体は他の方々もやっているようで、僕が改めてやる意
Elasticsearchが広く普及した理由の1つは、数ノードの小規模なクラスターから数百ノードの大規模なクラスターへの拡張性が優れていることです。その中心にあるのが、クラスターコーディネーションサブシステムです。Elasticsearchバージョン7は、新たなクラスターコーディネーションサブシステムを備えており、これまでのバージョンと比べて多くの利点があります。この記事では、バージョン7においてこの新しいサブシステムに加えられた改善点について紹介し、その使い方、今回の変更がバージョン6からのアップグレードに与える影響、誤ってデータをリスクにさらしてしまうことを防ぐ新たな機能について説明します。そして最後に、新しいサブシステムの仕組みを説明する理論の概要を提示します。 クラスターコーディネーションとは Elasticsearchクラスターを使用すると、多数のノードの連携を必要とするさまざま
今更聞けないAR/VR,分散処理,AI/機械学習/ディープラーニング,データサイエンス,IoTにお役所、総務省の資料が使えた件 - Qiita
ありがとう総務省！ http://www.soumu.go.jp/ict_skill/ http://www.soumu.go.jp/ict_skill/pdf/ict_skill_c1_set.pdf で一括PDFダウンロード（463ページ）するのも手。 今日まで知らなかったが日本のお役所のIT事業で民間がまともに使えるシステム、資料を初めて見た気がする。 今更恥ずかしくて聞けないNoSQL、分散処理（hadoop, spark, ...）、マシンラーニングやディープラーニングの手法の根幹、 Rのお話まで登場。これは使える！ 最近時のテクノロジーの基本的事項の網羅性が高い！
大規模データ活用向けストレージレイヤソフトのこれまでとこれから（NTTデータ テクノロジーカンファレンス 2019 講演資料、2019/0…
大規模データ活用向けストレージレイヤソフトのこれまでとこれから（NTTデータ テクノロジーカンファレンス 2019 講演資料、2019/09/05）
主な確率分布の関連図 こんにちは、吉岡（@yoshiokatsuneo）です。 Webサービスを運営していると、利用状況を分析・予測したり、A/Bテストなどで検証したりすることがよくあります。 データを一個一個見ていてもよくわからないので、データ全体や、その背景の傾向などがまとめて見られると便利ですよね。そんなとき、データの様子を表現するためによく使われているのが「確率分布」です。 学校の試験などで使われる偏差値も、得点を正規分布でモデル化して、点数を変換したものです。 今回は、Webサービスなどでよく使われる確率分布18種類を紹介します。 それぞれ、Webサービスでの利用例やPythonでグラフを書く方法も含めて説明していきます。コードは実際にオンライン実行環境paiza.IOで実行してみることができますので、ぜひ試してみてください。 【目次】 正規分布 対数正規分布 離散一様分布 連続
『データ指向アプリケーションデザイン』を読んだ。たいへんおもしろかった。技術書でこんなにわくわくしながら一気に読んだのは『Androidを支える技術』以来かもしれない。 データ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理 作者: Martin Kleppmann,斉藤太郎,玉川竜司出版社/メーカー: オライリージャパン発売日: 2019/07/18メディア: 単行本（ソフトカバー）この商品を含むブログを見る 本書はソフトウェアシステムの設計について「データ」という観点からまとめたものだ。もちろんデータベースは登場するが、それだけでなくJSONなどのデータ形式、RPC、メッセージキュー、全文検索インデクス、バッチ処理やオンライン処理も等しく「データ」という観点から扱っている。特筆すべき点は、理論だけでなく実際のミドルウェア製品を引き合いに出しつつ具体例を
数年前から「Hadoopは終わった」と言われることがあります。 厳密なHadoopの定義は Apache Hadoop プロジェクトを指しますが、現在では異なる意味で使われていることも多いです。では、Hadoopは時代と共に消えたソフトウェアなのでしょうか？ @shiumachiの「Hadoopの時代は終わった」を正しく理解するの記事は、Hadoopを取り巻く環境の変化について書かれています。データ基盤の歴史に始まり、時代とともに変化し、現代におけるデータ基盤になっているという考察があり必見です。 Hadoop is Dead. Long live Hadoop. Arun C Murthy (Hortonworksの創業者であり、現在ClouderaのCPO）が本日公開したブログ、「Hadoop is Dead. Long live Hadoop」では、Hadoopは哲学（”Hadoop
There has been a resurgence of the “Hadoop is dead” narrative, and it seems like every so often this pops up in the form of a blog post or contributed article. For several years now, Cloudera has stopped marketing itself as a Hadoop company, but instead as an enterprise data company. And today, Cloudera is in the Enterprise Data Cloud market: hybrid/multi-cloud and multi-function analytics with co
We are happy to announce the open source release of Waltz. Waltz is a distributed write-ahead log. It was initially designed to be the ledger of money transactions on the WePay system and was generalized for broader use cases of distributed systems that require serializable consistency. Waltz is similar to existing log systems like Kafka in that it accepts/persists/propagates transaction data prod
分散システムのパターン
原文(投稿日：2019/06/29)へのリンク Mathias Verraes氏が一連のブログ記事を投稿して、自身が仕事で出会った、有用な分散システムのパターンについて説明している。目的は、パターンをその有用なコンテキストとともに識別し、命名し、文書化することだ。その中で氏は、誤った状況で使用することが、パターンをアンチパターンにする場合の多いことを強調している。 DDD Europeの創業者兼コンサルタントであるVerraes氏は、現時点で16のパターンを、デカップリング、汎用メッセージング、イベントソーシングという３分野に定義した上で、各パターンについての問題と解決策を、時には例や実装を含めて説明する。 "Completeness Guarantee"は、プロデューサから送信されるドメインイベントセットの定義を目標とする部分と、プロデューサの状態をコンシューマが再現可能であることを必要
AWSの各サービスを一行で把握する - Qiita
概要 AWSの主要な各サービスを一行でまとめてみました。全てのサービスを網羅しているわけではないです。 AWS認定資格試験テキスト AWS認定 ソリューションアーキテクト-アソシエイトの本の復習がてらです。 読んだら何のサービスか聞かれて答えられるようになるかも。 ちなみにアイコンは公式のAWS アーキテクチャアイコンから取得できます。 ネットワークとコンテンツ配信 全ての始まりはネットワーク構築から。 リージョン・・・AWSがサービスを提供している国と地域のこと。 アベイラビリティーゾーン(AZ)・・・データセンターの集まり。リージョン内に複数のAZが含まれている。 VPC (Virtural Private Cloud) プライベートなネットワークを構成するサービス。ゲートウェイ、サブネット、ルートテーブルなどを利用する。 CloudFront サーバのキャッシュを配信するCDN(Co
テンセントの広告技術が未来すぎる！AdKDD2019のテンセントAds招待講演まとめ - Gunosyデータ分析ブログ
研究開発チームインターンの北田 (shunk031) です。アメリカのアラスカにて行われたKDD2019に参加・発表してきました。 www.kdd.org KDD2019の広告分野のワークショップであるAdKDD2019では、世界を牽引するアドテク企業が複数招待講演を行いました。 www.adkdd.org その中でも Tencent Ads: Interesting Problems and Unique Challengesにおいて、テンセントの広告チーム(テンセント Ads)の取り組みが未来過ぎたため、資料に取り上げられている技術を中心にまとめて報告させていただきます。 特に驚くべきは動画に対して広告対象の商品画像を自動で合成する VideoIn Ads は眼を見張るものがありました。ぜひこの記事を一読していただき、一緒に未来を感じてほしいです （そしてそれ以上のものを作っていきたい
形式手法による分散システムの検証 #builderscon / builderscon tokyo 2019
builderscon tokyo 2019 で使用したスライドです。 本セッションでは、形式手法 (formal methods) を用いた分散アルゴリズムの検証について解説しました。形式手法は、数学的な表現を用いて対象となるシステムを定式化することにより、システムの挙動の「正しさ」を厳密に保証するための方法論です。 なお解説として取り上げたのは、AWS による事例論文でも有名なモデル検査器 TLA+ です。講演前半で形式手法の一般論に触れたのち、後半では分散トランザクションを実現するための TCC (Try-Confirm/Cancel) Pattern のモデリングと検証を行いました。 講演概要：https://builderscon.io/tokyo/2019/session/fa356ee3-6be9-4850-ac9e-037bd34aabaa 録画：https://www.y
Summary statistics such as the mean and variance are easily maintained for large, distributed data streams, but order statistics (i.e., sample quantiles) can only be approximately summarized. There is extensive literature on maintaining quantile sketches where the emphasis has been on bounding the rank error of the sketch while using little memory. Unfortunately, rank error guarantees do not precl
builderscon tokyo 2019で登壇した際の資料です。 Kyash Directのアーキテクチャについて - スクラッチ開発を決めた経緯 - アーキテクチャ決定までの試行錯誤 - 関連トピック - Microservices - DDD - AsyncMessaging - Choreography - EventDriven - EventSourcing - SagaPattern
Kafka Streamを使ったストリーム処理の概要と運用時の考慮点 - joker1007’s diary
最近、仕事で分散ストリーム処理に手を出していて、その基盤としてApache KafkaとKafka Streamsを使うことにしたので、動作概要とストリーム処理のイメージについてまとめておく。 kafkaそのものについては今更説明の必要は無いだろうと思う。 Kafka Streamsはkafkaを基盤にして分散ストリーム処理を簡単に書くためのDSLライブラリ。 https://kafka.apache.org/documentation/streams/ 延々流れてくるデータを変換して別のtopicに流したり、時間のウインドウを区切ってカウントした結果を流したり、みたいなのがサクっと書ける。 Apache Flinkなんかと似た様なことができる。 Kafka Streamsが良いのは以下の点。 ただのConsumer/Producerのラッパーなのでfat-jarファイル一つで簡単に動かせ
移り変わる「データサイエンティストの『常識』」について考える - 渋谷駅前で働くデータサイエンティストのブログ
(Image by Pixabay) 先日、こんな話題を見かけました。 【夏なので怖い話】 こないだ、いかにもエリートな男性と知り合ったんですよ 彼は年収1000万で飛ぶ鳥を落とす勢いのデータサイエンティストだっていうじゃないですか それでふとAICの話題を持ちかけたんです 「あー現実であまり使わない数学の話はわかりません」 …おわかりいただけただろうか？— ゆうな (@kawauSOgood) 2019年8月14日 で、悪ノリした僕はこんなアンケートをやってみたのでした。 データサイエンティストという肩書きで年収1000万円以上の高給取りが、知らなかったとしても許される項目はどれですか— TJO (@TJO_datasci) 2019年8月15日 このアンケート結果こそが、今回の記事を書こうと思ったきっかけです。ある程度知識のある方ならお分かりかと思いますが、ここで挙げた「AIC」「正則
ゆううきが開発しているlstfやtranstracerなどのツールを最近のObservabilityの流れから紹介した話です。 Kyoto.なんか #5, https://kyoto-nanka.connpass.com/event/141982/, 2019年8月24日.
2019年7月24日、ヤフー株式会社が主催するサーバーサイドエンジニア向けの勉強会「Bonfire Backend #3」が開催されました。第3回となる今回のテーマは「モバイル決済の裏側」。急速に成長するモバイル決済分野でサービスを展開する企業が一堂に会し、自社サービスの仕組みや技術スタックなど、知られざる裏側を語ります。プレゼンテーション「Payment as a Microservice 」に登壇したのは、PayPay株式会社のHarsh Prasad氏。数多くのマイクロサービスで構築されているPayPayの心臓部、ペイメントコアシステムの裏側を解説します。 PayPayの分散システムの裏側 Harsh Prasad氏：みなさん、こんばんは。PayPayのペイメントコアシステムを担当している、プラサド・ハーシュと申します。今日お話しさせていただきたいことは、ペイメントマイクロサービスと
2019年6月24日、Machine Learning Pitchが主催するイベント「Machine Learning Recommender Pitch #3」が開催されました。機械学習を業務に用いる中で培った知見や経験を共有することを目的に設立された本イベント。今回は「情報推薦」をテーマに、株式会社Gunosy、エムスリー株式会社、クックパッド株式会社の3社のエンジニアが、自社の取り組みにおける知見を語ります。プレゼンテーション「クックパッドにおける推薦システムの取り組み 」に登壇したのは、クックパッド株式会社の林田千瑛氏。講演資料はこちら クックパッドにおける推薦システムの取り組み 林田千瑛 氏（以下、林田）：最後の登壇になりますが「クックパッドにおける推薦（と検索）についての取り組み」について、発表させていただきます。ちなみに、前の2人はごりごり数式を出してくれていたのです
コラム - グーグルのクラウドを支えるテクノロジー | 第64回 サーチエンジンのロードバランシング・アルゴリズム（パート1）｜CTC教育サービス 研修/トレーニング
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes 第64回 サーチエンジンのロードバランシング・アルゴリズム（パート1） (中井悦司) 2019年8月 はじめに 今回からは、2019年に公開された論文「Cache-aware load balancing of data center applications」を元にして、サーチエンジンのロードバランシングに関するアルゴリズムを紹介します。検索対象の単語ごとに担当するサーバーを分けて、サーバー内部のキャッシュのヒット率を高めるというシンプルなアイデアですが、複数の単語を含む検索文に適用するには、すこしばかり数学的な考え方が必要になります。今回は、具体的なアルゴリズムを説明する準備として、システム全体のアーキテクチャーを整理しておきます。 サーチ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アプリケーションにおけるデータ不整合との戦い - blog.syfm
分散SNSを使って技術を覚える | IIJ Engineers Blog
PySparkはじめました - 分散処理デビューする前にやったこと - JX通信社エンジニアブログ
マイクロサービスとメッセージングのなぜ [疑問編] - 赤帽エンジニアブログ
The Amazon Builders' Library
LINE社内でのサービス横断データ活用の取り組み「Feature as a Service」の全体像
PostgreSQLの皮を被った次世代RDBMS - Project Tsurugi (劔) について
File systems unfit as distributed storage backends: lessons from ten years of Ceph evolution | the morning paper
【Kubernetes】1週間かかる処理を1.5時間で終わらせた【並列処理】 - ニートの言葉
新世代Elasticsearchクラスターコーディネーション
WebサービスのA/Bテストや機械学習でよく使う「確率分布」18種を解説 - paiza times
【森山和道の「ヒトと機械の境界面」】 PFNの大規模分散深層学習専用プライベートスパコン「MN-2」潜入レポート
『データ指向アプリケーションデザイン』を読んだ - hydrakecat’s blog
Hadoop is Dead. Long live Hadoop の所感
Hadoop is Dead. Long live “Hadoop.”
Waltz: A Distributed Write-Ahead Log
DDSketch: A fast and fully-mergeable quantile sketch with relative-error guarantees
ウォレットアプリKyashの先 〜 Kyash Directのアーキテクチャ
分散システム内の関係性に着目したObservabilityツール - Speaker Deck
PayPayはなぜマイクロサービスアーキテクチャを採用したのか？ 決済プラットフォームの構成と狙いを解説
クックパッドにおける推薦システムの取り組み