2020年8月27日のブックマーク (7件)

  • 次世代デジタル保険を支える監視・通知の技術

    監視・通知の仕組みの全体像また、弊社では Terraform を用いて IaC ( Infrastructure as Code ) を実現して、各AWSアカウント環境の状態をコードで一元管理していますが、 Datadog の監視項目も Provider が用意されているため、Terraform で管理をすることが可能です。現状はすべての Datadog の監視項目がコード化されているわけではないですが、こちらは随時対応を行っていきたいと思っています。 外形監視外形監視は、WebサイトやAPIエンドポイントが正常に動作していることを、定期的に特定のURLに対して問い合わせをして、期待されたステータスコードや要素を返すことを監視することを目的とします。 弊社では Datadog の Synthetic Monitoring という機能を利用して監視を行っていますが、この機能の特徴としては W

    次世代デジタル保険を支える監視・通知の技術
  • ZOZOTOWNを支えるリアルタイムデータ連携基盤 - ZOZO TECH BLOG

    こんにちは、SRE部MA基盤チームの谷口(case-k)です。私達のチームでは、データ連携基盤の開発・運用をしています。 データ基盤には大きく分けて2種類あり、日次でデータ連携してるものとリアルタイムにデータ連携しているものがあります。記事ではリアルタイムデータ連携基盤についてご紹介します。 既存のデータ連携基盤の紹介 リアルタイムデータ連携基盤の紹介 なぜ必要なのか 活用事例の紹介 データ連携の仕組みと課題 リプレイス後のリアルタイムデータ連携基盤 SQL Serverの差分データの取り方を検討 アーキテクチャ概要と処理の流れ Fluentdのプラグインを使った差分データの取得 Dataflowでメッセージの重複を排除 Dataflowで動的にBigQueryの各テーブルに出力 Pub/Subのメッセージ管理 イベントログ収集基盤 個人情報の取り扱い ビルド・デプロイ戦略 監視 データ

    ZOZOTOWNを支えるリアルタイムデータ連携基盤 - ZOZO TECH BLOG
  • GitHub/GitLab/Bitpocket統合、クラウドIDEの「Gitpod」がオープンソースに | OSDN Magazine

    Gitpodは、ブラウザ内コラボレーションできる開発環境を提供するKubernetesアプリケーション。Eclipseのクラウド/デスクトップIDEプラットフォームプロジェクト「Eclipse Theia」を共同作成したSven Efftinge氏が土台の設計を行ったもので、開発者はコードを書き進めながら開発環境のメンテナンスができる。Efftinge氏はTypefoxとGitpodの共同創業者兼CEOを務める。 GitLabGitHub、Bitbucketと密に統合することで、自動的かつ継続的にブランチ向けの開発環境を事前ビルドする。CI/CD(継続的インテグレーション/継続的デリバリー)コンセプトを応用し、ブランチ、イシュー、マージやプルリクエストからコーディングができる。そのため、プロジェクトのメンバーは開発ワークフローを合理化でき、生産性を高めることができるという。また遠隔からの

    GitHub/GitLab/Bitpocket統合、クラウドIDEの「Gitpod」がオープンソースに | OSDN Magazine
  • 【レポート】Amazon Pinpoint でユーザーを掴んで離すな #AWSSummit | DevelopersIO

    こんにちは、加藤です。 AWS Summit Tokyo 2019 3日目に行われたセッション「Amazon Pinpoint でユーザーを掴んで離すな」のレポートを書きましたのでご覧頂ければと思います。 登壇者 アマゾン ウェブ サービス ジャパン株式会社 技術統括部 ソリューションアーキテクト 塚田 朗弘 Amazon Web Services
Principal Solutions Architect John Burry 柔軟で高機能なカスタマーエンゲージメントサービス、Amazon Pinpoint を隅々まで、国内外の事例を交えて解説します。サービスの成長のためには、適切なメッセージを、適切なタイミング、ユーザー、チャネルに送信する必要があります。また、その結果を迅速に可視化し、解析することも重要です。 Amazon Pinpoint では、モバイルプッシュ通知やスケジューリ

    【レポート】Amazon Pinpoint でユーザーを掴んで離すな #AWSSummit | DevelopersIO
  • Amazon Pinpointの新機能「カスタムチャネル」を使って配信処理をLambda Functionで行う | DevelopersIO

    Amazon Pinpointとは? Amazon Pinpoint(以降、Pinpoint)は、モバイルアプリ利用者などの顧客との関わりを強固にするための機能を提供するサービスです。 リリース当初は「モバイルアプリのプッシュ通知」だけでしたが、現在は様々なチャネルのメッセージ送信が可能になっていることから 顧客セグメントに対して様々な方法でメッセージを送ることができるサービス となっています。 モバイルアプリにSDKを組み込むことで使用状況データを追跡できるため、実施したキャンペーンに対するリアクションなどを分析できます。 また、セグメントは使用状況データを元にした絞り込みルールを作る形で指定することもできますし、CSVなどのリストファイルをインポートする形で指定することもできます。 PinpointはAmazon Mobile Analyticsの機能の一部を持っている形でしたが、Mo

    Amazon Pinpointの新機能「カスタムチャネル」を使って配信処理をLambda Functionで行う | DevelopersIO
  • [初級編] なぜ「AWS で負荷分散は3AZ にまたがるのがベストプラクティス」と言われるのか 可用性の面から考えてみた | DevelopersIO

    水平分散のアーキテクチャを考えるときに、「負荷分散装置の下に並べる分散先 (サーバ) は3台以上がよい」「AWS であれば3 AZ にまたがるとよい」とはよく聞かれます。それがどういう意味をもつのか、主に可用性の面から考えてみました。 みなさん、AWS使ってますか!(挨拶 AWSに限らず、ある程度の規模の何かしらの番システムを組もうというときに、こういう言葉を聞いたことはないでしょうか。 「負荷分散装置の下に並べる分散先 (サーバ) は3台以上がよい」 「AWS であれば3アベイラビリティゾーン (AZ) にまたがるとよい」 負荷分散装置(ロードバランサー)は負荷を分散するのがお仕事です。分散するだけなら 2 台でもよさそうですよね? AWS の3 AZ に至っては、そもそも AZ 単位の障害なんてそうそうないし、あったとしてももう片方の AZ が生きていればなんとかなりそうに思えます。

    [初級編] なぜ「AWS で負荷分散は3AZ にまたがるのがベストプラクティス」と言われるのか 可用性の面から考えてみた | DevelopersIO
  • PayPayでのDynamoDB活用事例について

    Presented by: Tomoki Nishinaka, Yu Zhouxun PayPayの機能の一つとして2020年4月に新たにリリースされた通知サービスでは、スケーラビリティとパフォーマンスを重視し、数々のデータストアソリューションの中からDynamoDBを採用しました。通知センターの設計からリリースまでにおける検討プロセスや、DynamoDBを使った開発/運用手法、及びテーブル設計のtipsについてご紹介します。

    PayPayでのDynamoDB活用事例について