Eberhard Wolffさんのこのプレゼンの要約です https://www.youtube.com/watch?v=B3O-qYM-Kkw 共通のデータモデル 共通のデータモデルを通信に使う 各サービスで必要となるデータの内部モデルは異なるかもしれない データモデルが、共通ライブラリと同じ意味合いになる すべてのサービスが、最新のライブラリを使わなくてはならない 共通データモデルの変更は、す
なぜマイクロサービスは失敗するのか? - kawasima
Eberhard Wolffさんのこのプレゼンの要約です https://www.youtube.com/watch?v=B3O-qYM-Kkw 共通のデータモデル 共通のデータモデルを通信に使う 各サービスで必要となるデータの内部モデルは異なるかもしれない データモデルが、共通ライブラリと同じ意味合いになる すべてのサービスが、最新のライブラリを使わなくてはならない 共通データモデルの変更は、す
様々なrate limitアルゴリズム - Carpe Diem
概要 インターネットに晒されているWebサービスでは TV等で紹介されたことによる大量流入 悪意ある人物からの攻撃 クライアントのバグに依る大量リクエスト など、本来想定していた以上のトラフィックが来ることはよくあります。 単純にシステムを構築すると大規模トラフィックに対応できずシステムがスローダウンしてしまうため、何かしらrate limitをかけておいた方が良いです。 ただしrate limitと一口に入っても色々あるため、今回は主なrate limitアルゴリズムを紹介します。 Leaky bucket Leaky bucketはデータ転送レートを一定にする（＝上限を設定する）アルゴリズムです。 下の図のように、様々な流量の水流がそのバケツに流れ込んでも小さな穴からは一定の水流が流れ出す仕組みです。 ref: What is the difference between token
データ活用基盤の今 〜DWH外観図〜 - クックパッド開発者ブログ
こんにちは、今年の1月に会員事業部から技術部データ基盤グループへ異動した佐藤です。先日、京まふ2019前夜祭イベントに参加するために人生で初めてピカピカ光る棒を買いました。 新卒で入社してから2年ほど分析作業をしていた身から、データ活用基盤を作る側へ立場を変えました。今回は新たに身を移したデータ活用基盤の外観を説明したいと思います。 2017年にも同内容の記事が投稿されていますので、当時との違いを中心に説明していきます。 外観図 以下が2019年10月現在におけるクックパッドのデータ活用基盤の全体像です。 クックパッドのDWH外観図 masterデータのインポートがMySQL以外にも複数種対応し始めたことと、PrismとSpectrum（S3＋Glue）周りと、Tableau Serverが大きな変更点となっています。2017年の図にDmemoはありませんでしたが、記事本文にある通り当時か
世界一わかりやすいClean Architecture - nuits.jp blog
本項は「C# Tokyo オンライン「世界一わかりやすいClean Architecture」他」による発表の登壇原稿となります。過去に発表した.NET版の記事はこちらにアーカイブしています。 本稿のサンプルコード・PPTはこちらで公開しています。 「CC BY-SA 4.0」で公開していますので、気に入っていただけたら営利目的含め、ライセンスの範囲で自由に利用していただいて問題ありません。 github.com また動画を以下で配信しています。よろしければご覧ください。 世界一わかりやすいClean Architecture はじめに まず初めに、クリーンアーキテクチャの誤解されがちな二つのことについてお話させていただきます。 その上で、クリーンアーキテクチャの本質とは何か？押さえておくべき、本当に重要だと考えている三つの事について、お話しします。 注意事項 さて本題に入る前に、少し注意
秒間100万リクエストをさばく - Googleの共通認可基盤 Zanzibar - 発明のための再発明
はじめに Googleの提供するサービス郡が共通して利用している認可システムにはZanzibarという名前がついています。ZanzibarはGoogleDrive・Google Map・Youtubeなどの巨大なサービスにも使用されています。 そのため、利用量も凄まじく 数10億のユーザー 数兆のACL(access control list) 秒間100万リクエスト もの量をさばいています。 にも関わらず、Zanzibarはこれを10ミリ秒以内に返します(95パーセンタイル)。 この記事では、そんなZanzibarの内部構造に関する論文「Zanzibar: Google’s Consistent, Global Authorization System」の中から、主に大量のリクエストをさばくための工夫を紹介します。 ちなみに、以前Googleの社内システム用の認可システム「Beyond
On designing and deploying internet-scale services | the morning paper
the morning paper a random walk through Computer Science research, by Adrian Colyer Made delightfully fast by strattic On designing and deploying internet-scale services James Hamilton LISA ’07 Want to know how to build cloud native applications? You’ll be hard-pushed to find a better collection of wisdom, best practices, and hard-won experience than this 2007 paper from James Hamilton. It’s amazi
2019年のワークフローエンジンまとめ - Qiita
概要 データパイプラインの管理にワークフローエンジンを導入したいのですが、今の要件に対してどれが合っているのか判断しきれない部分があるので整理してみました 最近の導入事例や発表をみるかぎりAirflow, Argo, Digdagあたりが人気なのかなと思います ワークフローエンジンとは ワークフローエンジンとは定期的なバッチ処理をうまく処理できるように、バッチ実行を管理してくれるソフトウェアのことです 古典的な実現方法としては適当なlinuxサーバーの上でcron実行させることが考えられますが、以下のような問題があります ジョブごとの依存関係を表現できない。cronの時間指定で実現させようとすると、タスクAを１時に開始してそれが完了するとみなして依存するタスクBを２時に開始するというような書き方をすることになるが、実際にタスクAが２時までに終わらなかった場合に処理が上手く実行できない タス
Microservices時代の監視設計 - An Epicurean
前のエントリの続きです。思ってた以上に反響があったので、主語を控えることも検討しましたがこのまま行きます。前回同様、すでにMicroservicesでバリバリやっている人は読む必要ないと思います。 前回の最後にMicroservices時代になると、開発者がこれまで以上に監視に取り組んでいく必要があると言う話を書きました。多少重複するところもありますが、その辺りから話を始めます。 モノリシック世界観での監視 アプリケーション監視の浸透 Microservices時代の監視設計 開発者自身が監視する どう監視するか メトリクス設計 The Four Golden Signals USEメソッド REDメソッド USEとREDの補完関係 The Four Golden Signalsの素晴らしさ 例: ある認証コンポーネントの監視設計 まとめ モノリシック世界観での監視 Webサービスの構成が
Microservicesでなぜ作るのか - An Epicurean
「Microservices時代の監視設計」と言うエントリーを書きたいのだけど、そもそもなんでMicroservicesで作る必要があるのかというところを先に書く必要があると感じたので私見を述べてみる。すでにMicroservicesで作っている人からすると「何をいまさら」と言う内容も多いかもしれません。 Microservicesでなぜ作るのか ドメイン分割のレイヤーの変遷 今は成長段階 Microservicesのメリットとアーキテクト クラウドはフレームワークになった 共有データベースアンチパターンとMicroservices設計 Microservices時代の監視設計 参考図書など Microservicesでなぜ作るのか 身も蓋もないことを書いてしまうと、これはもう「潮流がそうなっているから」ということだと思う。業界がそういうアプリケーションの作り方をしてノウハウを貯めていく流
Mercari ML Ops Night Vol.1 を開催しました
こんにちは、機械学習エンジニアの @hurutoriyaです。 2018/05/23 にMercari ML Ops Night Vol.1というイベントを開催しました。 Mercari ML Ops Night Vol.1 – connpass 機械学習アルゴリズムそのものではなく、 システム構成や、モデルのデプロイ、データの収集など、 機械学習をプロダクションで運用するにあたって直面する課題やその解決方法などを、 ざっくばらんにお話できればと思います。 当イベントページは公開1時間で100人の定員枠が埋まり、最終的に申込者が296人!! に到達し、プロダクション環境での機械学習の運用に対する注目の高まりを感じ取ることができました。 プロダクション運用への壁 最近では国内でもMLSEやML Ops Studyなど機械学習のモデリング以外の部分に注目したイベントが開催されています。 ML
メルカリの写真検索を支えるバックエンド | メルカリエンジニアリング
メルカリのAI EngineeringでTech Leadを務めている中河です。今回は3/18に正式リリースされた「写真検索機能」を支えるバックエンド・インフラをシステム側からの視点でご紹介します。 写真検索とは 所謂、画像検索機能で商品名を知らなくても画像から商品を検索できる機能の事です。詳しくは下記の公式リリースをご覧ください。 about.mercari.com 基本的な写真検索の仕組みは、Deep Neural Networks (DNN)を使用して商品画像から特徴ベクトルを取得し、取得した特徴ベクトルをApproximate Nearest Neighbor Index(ANN Index)に追加して画像indexを構築。 検索時には同じく商品画像からDNNを介して特徴量ベクトルを取得し、ANN Indexから検索します。 アーキテクチャの概要 Figure1 上記がアーキテクチ
コンテナベースシステムのデザインパターンに関する論文紹介 - エムスリーテックブログ
エンジニアリンググループ AI・機械学習チームの笹川です。 今回は、コンテナベースシステムのデザインパターンに関する論文 Design patterns for container-based distributed systems について紹介します。 なお、この記事は、社内勉強会であるM3 tech talkで紹介した内容をまとめたものです。 M3 tech talkは、エムスリー赤坂オフィスで隔週で開催されている5-20分程度のLTを数件行う勉強会で、そのトークテーマの振れ幅は最近の数回でも筋トレ、型システム、3Dプリンタ、量子コンピュータなどこのブログの数段上で、個人的にも毎回楽しみにしています。 M3 tech talkは、外部からの参加・登壇も歓迎しています。興味のある方はぜひ以下からお問い合わせください。 jobs.m3.com 論文の概要 今回紹介する論文は、HotClou
DMMにおけるユーザーレビュー基盤の変革(データ駆動戦略を実現する『三種の神器』編)【Developers Summit 2019】 - DMM inside
DMMにおけるユーザーレビュー基盤の変革(データ駆動戦略を実現する『三種の神器』編)【Developers Summit 2019】
(翻訳) データエンジニアの始まり - satoshihirose.log
訳者まえがき 原著者 Maxime Beauchemin の許可を得て以下の記事を翻訳・公開しました。 medium.freecodecamp.org 原著者は、Apache Airflow や Apache Superset のクリエーターで、現在は Lyft で Data Engineer をしています。 データエンジニアの始まり（翻訳） 私は 2011 年にBIエンジニアとしてFacebookに入社しました。2013年に退職するときには、私はデータエンジニアでした。 昇進もしくは新しい役割に就いたわけではありません。そうではなく、Facebookは、私たちが行っていた仕事が伝統的なBIを超えていたことに気づいたのです。私たち自身のために作り出した役割は、まったく新しい専門分野でした。 私のチームはこの変革の最前線にいました。私たちは新しいスキル、新しいやりかた、新しいツール開発し、そ
サイボウズのログ基盤 2018年版 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。アプリケーション基盤チームの @ueokande です。 今日は、サイボウズの新しくなったログ基盤についてお話しします。 サイボウズのログ基盤の進化 リプレイス前のログ基盤 サイボウズのログ基盤はサービスの成長に合わせて、常に進化し続けてます。 そんななか2017年の夏に大きなリプレイス作業がありました。 サイボウズのサービスを支えるログ基盤 from Shin'ya Ueoka 以前のログ基盤は、ログを収集するホストがあり、各ホストからログを収集してました。 しかしログの転送システムが単一障害点であったり、スケーラビリティに欠けるのでサービスの成長に追いつかず、性能的にも限界に達してました。 また以前のログ基盤では、ログの解析がしにくく、ログはあるけどビジネスに役立てにくい状況でした。 そのため今後のサービスの成長や、より安定したログ基盤を運用できるように、ゼロから刷新するこ
チュートリアル: API Gateway で REST API を Amazon Kinesis のプロキシとして作成する - Amazon API Gateway
API の /streams リソースに対する HTTP GET メソッドを公開し、そのメソッドを Kinesis の ListStreams アクションと統合して、呼び出し元のアカウントでストリームを一覧表示します。 API の /streams/{stream-name} リソースに対する HTTP POST メソッドを公開し、そのメソッドを Kinesis の CreateStream アクションと統合して、呼び出し元のアカウントで指定したストリームを作成します。 API の /streams/{stream-name} リソースに対する HTTP GET メソッドを公開し、そのメソッドを Kinesis の DescribeStream アクションと統合して、呼び出し元のアカウントで指定したストリームを表示します。 API の /streams/{stream-name} リソース
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
冪等性を考慮したデータ連携ジョブの設計
事業成長をBoostさせるデータ基盤 #devsumi #devboost / 20181215
Amazon DynamoDB: 仕組み - Amazon DynamoDB
Logs vs Structured Events