SaaS をアーキテクトをするにあたって、どのような事を考えればよいのか？をまとめました。
SaaS アーキテクチャ概要
SaaS をアーキテクトをするにあたって、どのような事を考えればよいのか？をまとめました。
Dropboxが新開発した「非同期処理フレームワーク」はどのように構築されているのか？
複数のプログラムを順番に処理していく同期処理システムでは、どこかひとつの処理に時間がかかると後続の処理がまるごと遅れてしまいます。そんな同期処理に対し、ある処理の完了を待たずに次の処理を実行できるのが非同期処理。重たい処理によるボトルネックを回避できるため、ウェブサイトの応答速度改善などに役立てられています。クラウドストレージサービスのDropboxで開発が進められていた大規模な非同期処理フレームワークについて、同社のエンジニアであるArun Sai Krishnan氏が解説を行っています。 How we designed Dropbox’s ATF - an async task framework - Dropbox https://dropbox.tech/infrastructure/asynchronous-task-scheduling-at-dropbox これまでDropb
Introducing Domain-Oriented Microservice Architecture
You’re seeing information for Japan . To see local features and services for another location, select a different city. Show more Introduction Recently there has been substantial discussion around the downsides of service oriented architectures and microservice architectures in particular. While only a few years ago, many people readily adopted microservice architectures due to the numerous benefi
認可のアーキテクチャに関する考察（Authorization Academy IIを読んで）
みなさま、認可の設計に苦しんでいるでしょうか？私は苦しんでいます。苦しまなかった瞬間などありません。昔「アプリケーションにおける権限設計の課題」を執筆しましたが、あれから3年以上が経ちます。 当時は認可の設計に関する情報がうまくまとまっている記事などほとんど無く、調べに調べて得たナレッジを書き記したのが上記の記事です。3年以上経ちますが、苦悩が今も特に変わっていないことが驚きです。 ただし、世の中的には認可のライブラリであったりサービスというのは少しずつ増えてきている印象があります(Auth0の OpenFGA であったりOsoの Oso Cloud 、Asertoの Topaz )。 認可の設計に関する記事も少しずつ増えている印象があり、その中でも本記事で紹介したいのがAuthorization Academyです。 これは認可サービスである Oso Cloud やOSSのライブラリ o
回復性の高いMicroservicesアーキテクチャを支える技術 - Mercari Engineering Blog
メルカリバックエンドエンジニアの@yagi5です。 Mercari Advent Calendar 2018の23日目を担当します。 モノリシックなシステムは、障害が発生するとシステムが全停止してしまうことが一般的です。 しかし、Microservicesアーキテクチャでは様々なテクニックを用いて、サービス全体が停止するような障害に対処することができます。 この記事では、Microservicesにおけるシステムの回復性を高めるための技術について書いていきます。 回復性とは、障害が起こらないことを意味しません。 高い回復性を備えたシステムは、障害が発生するということを前提に、システム全体のダウンを避け、データのロスが回避されるように設計されています。 Microservicesの世界では、システムは自律的に動作する複数のサブシステムによって構成されます。 ひとつのサービスに障害が発生しても
アーキテクチャの進化を支える適応度関数の活用 - 10X Product Blog
はじめに こんにちは！ モジュール開発部の yamakazu (@yamarkz) です。 あけましておめでとうございます。2023年もよろしくお願いします。 本記事が新年最初のプロダクトブログになるのですが、何を書こうかとても迷いました。笑 抱負的な何かが無難だと思いつつ、1年先のことまでは見通すことができない。10Xはドラスティックに事業や組織が変わるので、中長期な目線で1つのテーマを説くのは難しいなと。そう色々と考える中で、ちょうど足元で成果が出始めている具体の取り組みを紹介したい！というモチベーションが生まれてきました。 なので今回は、半年先までの将来的な抱負の意図を交えながら、直近の取り組みで手応えを感じ始めている、アーキテクチャ改善のプラクティスを紹介しようと思います。 具体的にはタイトルにもある”適応度関数”と呼ばれるプラクティスで、巷では概念としては認識されているものの、ま
バッチ処理 プラクティス
バッチ処理は既に先人の方々が多くのナレッジを公開してくれていますが、それでもなお難しさが変わらないテーマだと思っています。 この記事は、筆者がこれまでの開発経験で気づいたバッチ処理の実装ナレッジを整理し、体系化を目指して文章にしました。 ここでの内容が、より良い課題解決に貢献できれば幸いです。 自身の断片的な思考整理(メモ書き)の延長で内容を整理したため、一部書き振りが統一されておらず、読みにくいかもしれません。ご了承ください。🙏 バッチ処理の難しさバッチ処理は難しい。 人によっては簡単なテーマかもしれませんが、自分は難しいテーマだと思っています。 「難しさの根源は何か？」を考えると、1. 考慮点が多様にあること 2. 解決する課題によって答えが大きく変わること に整理できました。 この2点は、どのソフトウェア開発にも当てはまる項目ではありますが、ことバッチ処理においては顕著に現れます。
メルカリWebのマイクロサービス化、その4年 | メルカリエンジニアリング
Author: @urahiroshi, Engineering manager of Web Platform team 2022年8月4日、メルカリで “web-2” と呼ばれるサーバがシャットダウンされました。これはメルカリWeb版の開発に携わっているチームにとって、一つの区切りとなる出来事でした。 web-2はPHPで記述されたwebサーバで、2015年から https://www.mercari.com/jp/ 配下のコンテンツを配信していましたが、現在では複数のWebマイクロサービスがその機能を担っており、 https://www.mercari.com/jp/ 配下のページは後継となるWebマイクロサービスが配信するページへリダイレクトされています。 メルカリWebのマイクロサービス化に向けた開発が始まり、最終的にweb-2がシャットダウンされるまで、実に4年以上の期間がかか
マイクロサービスに失敗する7つの方法
次の問題は、CV駆動開発(CV-driven development)です。自分のCV(Curriculum Vitae、職務経歴書)を見ます。すると、"マイクロサービス"に関する部分が大きく空いていることに気付きます。これでは都合が悪いので、"自社のスタックを再構築して解決しよう"、と考えるのです — 読者の皆さんは、"Holly、それは皮肉が過ぎるよ"、と思うかも知れません。"自分の履歴書の都合でアーキテクチャを決めるやつがどこにいるんだ？" それが実は ... いるのです。 Red Hatは先日、コンテナベース開発を導入したおもな動機に関する調査を行いました。その結果、最も多かったものは"キャリアアップ"でした。"キャリアアップ"は、CV駆動開発の体のよい言い換えに過ぎません。 現在のマイクロサービスは"新正統派"と言ってもいいものですから、経歴書にマイクロサービスが欠けているのは大
Building Uber’s Fulfillment Platform for Planet-Scale using Google Cloud Spanner
You’re seeing information for Japan . To see local features and services for another location, select a different city. Show more Introduction The Fulfillment Platform is a foundational Uber domain that enables the rapid scaling of new verticals. The platform handles billions of database transactions each day, ranging from user actions (e.g., a driver starting a trip) and system actions (e.g., cre
How Uber Achieves Operational Excellence in the Data Quality Experience
Uber delivers efficient and reliable transportation across the global marketplace, which is powered by hundreds of services, machine learning models, and tens of thousands of datasets. While growing rapidly, we’re also committed to maintaining data quality, as it can greatly impact business operations and decisions. Without data quality guarantees, downstream service computation or machine learnin
魔窟と化した全文検索サーバーとふっかつのじゅもん - Cybozu Inside Out | サイボウズエンジニアのブログ
サイボウズのクラウド黎明期から運用し続けていたSolrサーバーを Elasticsearchに置き換えるプロジェクトが先日完了しました。 プロジェクト完了報告もかねてプロジェクトのあらましを公開したいと思います。 はじめに このプロジェクトの主軸は『魔窟と化したレガシー技術をどう捌くか？』になります。 このプロジェクトの報告をする前に、いくつかエクスキューズをさせていただきます。 クラウド黎明期を支えてくれたSolrには畏敬の念に近い感謝をもっています レガシーな技術に対してマウントやディスリスペクトの意図はありません 魔窟にかかわることになってしまった人に対して負の感情は一切ありません 今回の採用している構成はElasticsearchのあるべきアーキテクチャではありません 今後、Neco 環境への移行を通して継続的に改善していきます サイボウズでのSolrの使い方と用語説明 サイボウズ
Rettyのデータ基盤の歴史と統合 - Retty Tech Blog
書き手：@takegue (分析チーム) Rettyのデータ活用の多くにはBigQueryが現在利用されており、その活用の方法についてこれまでこのブログでもいくつかとりあげさせていただきました。 engineer.retty.me そのほか分析チームの記事一覧 これらの記事はおかげさまで好評いただいております。いつもありがとうございます。 しかしながら、我々が初期からこのようにBigQueryを使い続けてきかというと、実はそうではありません。 事業の成長とともにデータ基盤を変化させてきた経緯があり、今の成果は過去のトライアンドエラーの賜物であり、数多くの苦労を背景にしてできあがっています。 ほんのつい最近まで、Rettyで構築されていたデータ基盤は表立って見える実態よりもかなり複雑なパイプラインで構成されていました（以降で触れますが、4種類のデータパイプラインが共存しているカオスな状態でし
GraphQLが解決する問題とその先のユースケース
サーバーサイドからみたGraphQL Serverlss Meetup#19 2021/03/31 に行われた Serverlss Meetup#19 で上記のタイトルで登壇してきました。サーバーサイドの話をしようと思ったけどGraphQLの解決している話をしようと思ったらクライアントの事もかなりはいってしまったので記事のタイトルは変えました。 以下内容です。記事の最後に資料を書くにあたって参考になった資料のリンクを置いてます。 GraphQL and me この1年書いたQiita記事 GraphQLの特徴を分解する ~API インターフェース・Universal BFF・API Gateway~ GraphQLはサーバーサイド実装のベストプラクティスとなるか GraphQLの全体像とWebApp開発のこれから 今回話す事 そもそもGraphQLはなんで作られたのか、何を解決しようとして
バックエンド Web API に管理画面/管理機能を追加するアーキテクチャパターン - valid,invalid
プレゼンテーションレイヤ、いわゆるフロントエンドがクライアントサイドで実装・実行されるアーキテクチャ (注 1) において、管理画面/管理機能をあとから追加する際にどのような実装パターンがあるのかを整理してみます。 注 1: Presentation Domain Separation の実践の中でも、物理的にプレゼンテーションロジックとドメインロジックを分離しているアーキテクチャです。 用語の整理 プレゼンテーションレイヤ 三層アーキテクチャにおける、システムの利用者へユーザインターフェイスを提供する層です。本記事では"フロントエンド"とほぼ同義で使います。 OSI 参照モデルの第六層ではないです。 バックエンド Web API とは プレゼンテーションを持たない Web API (HTTP プロトコルを用いてネットワーク越しに呼び出すアプリケーション) とします。 プレゼンテーションレ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Feature FlagsのDX/UXの 頂点「 DevCycle 」に 辿り着くまでの道のり
Beyond API Compatibility: Understanding the Full Impact of Breaking Changes
freee会計からマイクロサービスを切り出すのに4年かかりました / 4 Years for Carving Out A Micro Service from freee Accounting.
system-design-primer#system-design-interview-questions-with-solutions
カートリプレースPJの全体像と技術選定
