It's common for software systems to make remote calls to software running in different processes, probably on different machines across a network. One of the big differences between in-memory calls and remote calls is that remote calls can fail, or hang without a response until some timeout limit is reached. What's worse if you have many callers on a unresponsive supplier, then you can run out of
Tom Wilkie shares Weaveworks monitoring philosophy and the three most important metrics to use in your microservices architecture. In previous blog posts and talks I’ve alluded to The RED Method, our monitoring philosophy at Weaveworks. In this blog I’ll outline what The RED Method is, why we use it, and where it comes from. What is The RED Method? The RED Method defines the three key metrics you
Mercari Advent Calendar 2018の24日目はメルカリBackendエンジニアの@sota1235がお届けします。 現在、私はWebのシステムをリプレースしMicroservicesアーキテクチャに移行するチームで働いています。 メルカリのMicroservicesアーキテクチャでは各Microserviceチームが責任を持ってSLI/SLOを定め、運用する必要があります。 このSLI/SLOを決める過程でいくつかの学びや難しさがあったのでそれをお話しようと思います。 SLI/SLOとは SLI(Service Level Indicator)とはサービスの品質を測るための指標です。 そしてSLO(Service Level Objective)とは各SLIに対しての目標数値です。 例えばSLIを全リクエストの50xエラー以外の割合として、SLOは99.99%とする、
Mercari Advent Calendar 2018 の 25 日目はメルカリ JP の Microservices Development Team の @codehex がお送りします。 これまで私達は Microservices を開発している旨を様々なテックイベントやカンファレンスで話してきました。中でも Mercari Tech Conf 2018 で Monolith なアプリケーションから Microservices へ移行するために、私達がどうしているかという話が目立っていたと思います。 そのうちの一つである Listing Service という出品機能の Microservice の話がありました。 資料の内容をまだ知らない方のために、本記事を理解するために補足します。 メルカリでは Microservices を基本的に Google Cloud Platform
Mercari Advent Calendar 2018 の14日目はメルペイ DataPlatform チームの @syu_cream がお送りします。 本記事では表題の通り、メルカリとメルペイにおける、マイクロサービスのログ収集に関する課題と取り組みについて記載します。 メルカリとメルペイでは、現在クライアントアプリやサーバサイドのログを効率的に収集してサービスの他機能で活用するための基盤の開発を共同で行っています。 メルカリ・メルペイ間では、一部提供するサービスの差異やデータ管理のポリシーの都合によりインフラ構成が異なる部分はありますが、少なくとも思想や設計、実装は共有しています。 これの具体的な内容については、今回の Advent Calendar の 3 日目の記事に掲載しています。 本記事では、サービスを提供するサーバサイドアプリケーションから、この構成図における “A Ser
SRE で Microservices を推進している @b4b4r07 です。 メルカリでは全社 (US/UK/JP) 的に Microservices に舵を切る経営指針が打ち出されており、Microservices Platform Team では Microservices として切り出すにふさわしいサービスの再編のサポートや、新規サービスの Microservices 化のサポート、およびそのスタンダードなインフラ基盤の開発などをしています。 本記事ではその中で開発した Developer Productivity の向上につながる小さなツールを、メルカリでの Terraform の活用事例に交えてご紹介します。 メルカリでの Terraform 活用 冒頭に挙げたとおり、少しずついろいろなサービスが立ち上がり始めていますが、そのインフラとして主に GCP (GKE) が使われて
こんにちは、qsonaです。マイクロサービス愛好者(?)です。活動としては、Microservices Meetup というイベントを、所属している株式会社FiNCにて運営しています。 初日ということで、「マイクロサービスとは何なのか」と風呂敷を広げたテーマで書いてみたいと思います。 幸いなことに、原典に近い文章を、日本語に翻訳していただいている記事があります。 Microservices / James Lewis, Martin Fowler @kimito_k さんによる翻訳 ある程度マイクロサービスでの開発を経験した後で読むと、この記事は驚くほど網羅性があると感じます。たまに読み返すと毎度新しい発見があります。 さて、マイクロサービスを初めて知るような人のために、あえてマイクロサービスを「一言」で表すなら、自分の考えは以下です。 マイクロサービス = 「超」疎結合 自分がマイクロサ
2013年から2017年のあいだ、スタートアップを含む2000以上の組織に対して、いかに組織のパフォーマンスを加速するかという聞き取り調査を行い、その調査結果をまとめたものです。 その調査結果のひとつにこのグラフがあります。 これは組織のエンジニアの人数とそのパフォーマンスを、組織の違いによって示したものです。 横軸がエンジニアの人数、縦軸はエンジニアあたりの1日のデプロイ数を指標としたパフォーマンスです。 これによると、パフォーマンスの低い組織はエンジニアが増えるとデプロイ数も減少しています。普通のパフォーマンスの組織はエンジニアが増えてもデプロイ数に変化はありません。 一方でパフォーマンスの高い組織はエンジニアが増えるほど指数関数的にデプロイ数が増えていきます。メルカリが目指しているのはここです。 これは単純にアーキテクチャをモノリシックからマイクロサービスへ移行するだけでは実現できま
がちがちのエンタープライズ系で既存システムのマイクロサービス化に取り組むときに注意したいこと。 儲かる機能をマイクロサービス化する マイクロサービスの最大の目標は「サービス化された機能のリリースサイクルを、その機能を管理するチームが独自に決定できるようにする」ことです。つまり、システム内の他の機能や他システムとの調整をしないで、いつでも好きなようにリリース可能であることが大事です。もちろん、日中に。 それは何のためかというと「機能をどんどん改善して儲けたい」からです。これまでは、儲かる機能を改善をしようとしても、その他の機能や他システムとの調整や影響範囲調査やリグレッションテストに時間がかかってリリーススピードをあげることができませんでした。この問題が解決できればウハウハできるはずです。 マイクロサービスのサービス分割点について聞かれることが多いですが、それは「ビジネス部門が『早くリリース
Service Discoveryとは ここでは、マイクロサービスアーキテクチャなどで作成したサービスを登録するして検索出来るようにするようなミドルウェアを指す。 なぜ必要かであるが、 動的にサービス稼働しているノードが増えたり、減ったりするのにClient側が追従する 各ノードへのアクセスを負荷分散させるため などが大きな理由として挙げられる 役割的なものを軽く図にまとめておく Javaで使えるもの 探せばたくさんあると思うが、メジャーなものとして Zookeeper etcd Consul Eureka がある。このうちEurekaはJavaだけに向けた設計になっている。 今回はConsulとEurekaを見てみる。2つとも管理画面があるのと、Client向けライブラリが一応あったためという理由。 他の2つについては、 etcdはKVSを拡張したような感じと見受けられたので、直接マイク
伊藤直也氏が語る、モダンなWebテクノロジーに共通する傾向とは？（前編） Chef、Docker、MicroservicesからReact、FRPまで。QCon TOkyo 2015 最新のITと関連技術をエンジニアの視点で掘り下げるイベント「QCon Tokyo 2015 Conference」が4月21日に都内で開催されました。 そのセッションの1つとしてKAIZEN platform Inc.の伊藤直也氏が行ったのが、「モダンWebシステム開発」と題して、最近のWebアプリケーションに関する技術に共通する傾向を探った講演です。 ChefやPuppetなどによるInfrastructre as CodeからImmutable Infrastructureなどのインフラ周りからReactなどのフロントエンドにまで共通する考え方とは何か、示唆に富むその内容をダイジェストで紹介します。 モダ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
