1つのアプリケーションを機能別にAPIとして切り出したもの。大規模化・複雑化が進むにつれ、開発コストおよび新規メンバーの参入コストが高くなるため、2014年頃から流行りだした。対して、もともとの1枚岩のアプリケーションはmonolithicと呼ばれる。日本だとモノリスとも言われる。
小さくなったのは良いが、「連携設定」「APIのセキュリティ」「リトライ処理」などコストが増した。また、個数の増加に伴い、新しいMSを追加したときの影響範囲も分かりづらく、それらを解消するために「監視体制」「サーキットブレイク」なども必要となり、複雑性を増していった。
private def current_environment_from_env
ENV["SENTRY_ENVIRONMENT"]? || "default"
private def detect_release_from_env
ENV["SENTRY_RELEASE"]?
Let's consider some value holder. For example, Try monad. For simplicity, Let's assume it only works with Int32
.
record Success, value : Int32
record Failure, value : Exception
# some try object
try : Success | Failure = Success(1)
- Leaky bucket : キューイングして出力量(consume)で調節 (アルゴリズムというかキューを使って調節)
- Token bucket : 定期的に資源を追加し平均値を調節。バーストに強い (ソシャゲのスタミナ回復)
- Fixed window counters : 単位時間あたりの上限値を指定。キューを使わないLeaky bucket。境界の2倍問題あり
- Sliding window log : 総数(counters)でなくアクセス時刻(log)で管理。境界問題を解消する一方、消費増加がぱない(
Int
→Array(Time)
) - Sliding window counters : countersのままで、単位時間の割合計算によって境界問題を解消。これにしておけば間違いない
- https://christina04.hatenablog.com/entry/rate-limiting-algorithm
- 日本語。メリットとデメリットも解説されており、デメリットを克服する形で次のアルゴリズムの説明に入るので、全体がわかりやすい
- キューの最大本数:
Thousands (or even tens of thousands) of queues should be no problem at al
- https://dev.classmethod.jp/articles/fifo-sqs-exactly-onceon-tokyo/
- 高可用性を持った分散キューシステム
- at least once
- 順序保証なし
- メッセージdup (複数workerで同じメッセージを処理する可能性)
- https://dev.classmethod.jp/articles/sqs-new-fifo/
- exactly once
NewerOlder