AWSが落ちてもGCPに逃がすことで落ちないシステムを作る技術こんにちは、エンジニアのtarr [https://github.com/tarr1124]です。 KARTE Blocksは既存のサイトにタグを一行入れるだけで、そのサイトを簡単に書き換えたり、ABテストなどで最適化したりできます。 これは、サイトを読み込むときにタグによってBlocks内で設定された内容を反映させているのですが、既存のサイトの挙動に手を加えている以上、一定のリスクが存在します
大規模解析サービスを支える監視サービスと監視構成のポイント
大規模解析サービスであるKARTEでは、できるだけ「データの抜けがないこと」「リアルタイムに解析を行い、それを利用したアクションが提供できること」というシビアな要件が求められます。この要件を満たし続けるためには、素早く問題に気づき対応する仕組みがとても重要になります。KARTEでは複数のサービスを組み合わせて監視の仕組みを構築しており、本稿ではその監視構成とポイントについて紹介します。 何を監視するのか？ サービスを提供する際にはSLO（Service Level Objective）を設けることが一般的です。 KARTEではサービス利用者に向けたSLO（外部SLO）の他に、よりシビアに設定した内部向けのSLO（内部SLO）も定義しており、後者の内部SLOを基準に監視を行っています。 監視は以下の情報などを利用して、さまざまな角度から行っています。 OSから見えるサーバのメトリクス CPU
12.5億UUを解析する大規模解析サービスの監視構成 | PLAID engineer blog
12.5億UUを解析するKARTEを支える監視構成について記事を書きました。
GCPとAWSのマルチクラウドで構築する、大規模解析サービスのシステム全体像
大規模解析サービスの構成要素 大規模解析サービスは一般的に、以下の要素から構成されます。 ログ情報等のデータの送信 データの受信 データの保存 保存したデータの解析 解析データの閲覧などができる管理画面の提供 KARTEはユーザのWebアクセスデータをリアルタイムに解析し、アクションまでつなげることができるサービスであり、先ほど説明した5要素は、以下の5種類のコンポーネントによって実現しています。 trackerコンポーネント：エンドユーザで実行されるtracker[1]をエンドユーザに配布するためのコンポーネント trackコンポーネント：エンドユーザからデータを受信するコンポーネント。とくにKARTEでは解析データに基づいてエンドユーザへのアクションを返す役割も持つ dbコンポーネント：解析データなどのさまざまなデータを格納するコンポーネント analyzeコンポーネント：エンドユーザ
AWSとGCPのマルチクラウドインフラ検証の進め方
今回はGCPでの検証を行った際の進め方について説明していきます。インフラを作り込みすぎずに検証したことで、早めに想定外のボトルネックに気
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWSとGCPのマルチクラウドインフラにおけるVPN設計のポイント| PLAID engineer blog