"Nintendo Switch™ 向けプッシュ通知システムのリプレイス事例" の感想
AWS については利用していないのでよくわからない。あくまで Erlang/OTP で書かれたミドルウェアのリプレイス事例として感想を雑に書く。ちなみに、現地で発表を聞いている。 一般的な感想 自分のような AWS 素人が見てもわかりやすいシンプルなシステムになっていた HTTP/2 を利用した独自プロトコルでの双方向通信が気になる TCP/IP を利用した大量の常時接続は本当に大変だとおもう カーネルパラメーターチューニング！ 少ないリソースで、たくさんの接続を担う ゴールが素晴らしい デプロイの自動化を GitHub Actions でやってるのやっぱりいい 負荷試験にて1億台の接続を維持した状態で挙動が問題ないことを確認 最高 Graviton ベースの Fargate の活用 Go であれば arm64 向けバイナリがサクッと生成されるのは良い Erlang/OTP から Go へ
食べログノートでWebSocket不要の(ほぼ)リアルタイム更新を実現した話 - Tabelog Tech Blog
目次 目次 はじめに リアルタイム化の必要性 解決策の検討 予約状況の更新に必要な速度を検討 実装案のブレスト 採用するアーキテクチャの決定 実装の詳細 リリース戦略 リリースによる効果 まとめ 最後に おまけ（メディア掲載の紹介） はじめに こんにちは！ 食べログ開発本部 ウェブ開発1部 FEチームの佐々木です。 私たちが開発している食べログノートは、レストラン向けのオンライン予約台帳です。ネット予約、電話予約、ウォークインの管理、顧客管理、卓管理などを一元的に行えるツールです。 その中でも特に重要な機能がタイムスケジュール画面です。この画面は、食べログノートの中でも最もよく使われる機能です。登録された卓と予約時間を表示し、ドラッグアンドドロップで卓や時間の変更が簡単に行えます。 今回の記事では、このタイムスケジュール画面において、WebSocketを使用せずに（ほぼ）リアルタイム更新を
身近なBtoCサービスを支えるアーキテクチャ大解剖 技術選定のポイントと今後の展望 - Findy Tools
公開日 2024/06/19更新日 2024/07/25身近なBtoCサービスを支えるアーキテクチャ大解剖 技術選定のポイントと今後の展望 多くのIT企業では、ユーザーに対してより高品質で安定した体験を提供するために、システムアーキテクチャを進化させ続けています。 本特集では、日常生活の中で多くのユーザーに利用されているサービスのアーキテクチャ設計に携わるエンジニアの方々から、技術選定の背景や意図、そして現在のアーキテクチャの課題から未来への展望まで、詳しく伺いました。この記事を通じて、各企業のエンジニアたちがどのように技術的な課題を克服し、システムの柔軟性と効率を高めているのか、知見を得ていただければ幸いです。 ※ご紹介は企業名のアルファベット順となっております アソビュー株式会社 アソビュー株式会社では「遊び」という領域に対し、マーケットプレイス型EC「アソビュー！」やD2C型SaaS
分析基盤のテーブルと連携方式｜zono
分析基盤においては様々な連携手法があります。 これは、データ量が多いか少ないか、データソースが最新か履歴か、によって変わってきます。 今回は、連携手法を紹介しながら、その連携に必要なテーブルの特徴について話したいと思います。 連携元と連携先のテーブル連携元のテーブルは、最新テーブルになっている場合も履歴テーブル（インサートオンリー）の場合もあります。これはアプリ側の仕様によって異なります。多くの場合は、UPDATEができて、データ量が少なくなる最新テーブルになります。 基本的に連携先のテーブル（データレイクやレイクハウス）は、履歴テーブルになっています。これは、分析する上で時系列データを扱えたり、集計時に多くのデータを扱えることができるためです。 最新テーブルや履歴テーブルの作り方や必要なカラムについての詳細は下記の記事をご覧下さい。 連携方式全件連携全件連携とは、データソースから全てのデ
SQSを用いたクレジットカード決済の非同期化 - ZOZO TECH BLOG
こんにちは、カート決済部カート決済サービスブロックの林です。普段はZOZOTOWN内のカートや決済の機能開発、保守運用、リプレイスを担当しています。 弊社ではカートや決済機能のリプレイスを進めており、これまでにカート投入のキャパシティコントロールや在庫データのクラウドリフトを実現しています。 techblog.zozo.com techblog.zozo.com 本記事では新たにクレジットカード決済処理を非同期化したリプレイス事例を紹介します。 はじめに 背景・課題 非同期化のシステム構成 パターン1 - 完全非同期化パターン パターン2 - 非同期・同期切り替えパターン パターン3 - ポーリングパターン システム構成の決定 メッセージングサービスの選定 効果 今後の展望 まとめ さいごに はじめに 本章では、非同期化前のZOZOTOWNのクレジットカード決済を用いた注文処理の流れを説明
キャッシュを活用するために必要な知識と勘所 - そーだいなるらくがき帳
どうもキャッシュバスターズ、 id:Soudai です。 Cache（以下、キャッシュ）は特定の場面に置いて劇的な効果を発揮し、様々な問題を解決する反面、新たなコンポートやミドルウェアが追加され、複雑性が上がり、運用のレベルが上がるため、扱いに注意する必要があります。 キャッシュを活用することで、パフォーマンスの改善や負荷軽減が行われ、コンピュータリソースの最適化によるサーバコストの削減や、レスポンスの改善によるユーザエクスペリエンスの改善がされます。 反面、その劇的な効果に毒され安易に多用すると、サービスが強くキャッシュに依存してしまい、非常に壊れやすくなり、運用が難しくなってしまいます。これをWeb界隈では「キャッシュは麻薬」と比喩されて、戒められてきました。 そのためキャッシュを使わずにサービスが運用できるのであれば使わないに越したことはないのですが、ある一定以上の規模になった際にコ
Software Requirements Essentials（2023）をざっと読む - 勘と経験と読経
「ソフトウェア要求 第3版」の著者であるKarl Wiegersの新著が出ていたので、ざっと読んでみる記事（あるいは読んだ記録）。 「私はかつて、過去10年間でベストセラーになった要件エンジニアリングの本を10 冊を読んだことがあります。この1冊には、それらの10冊を合わせたものよりも有益な情報が簡潔に記載されています」-- Mike Cohn ここまで言われたら読むしかない。 Software Requirements Essentials: Core Practices for Successful Business Analysis 作者:Wiegers, Karl,Hokanson, CandaseAddison-Wesley ProfessionalAmazon もくじ もくじ 全体的な感想 ソフトウェア要求 第3版から何が省略されたのか 20のコアプラクティス #1: 解決策を
システム移行戦略「レガシーミミックパターン」＆「ストラングラーフィグパターン」とは？ - Qiita
AWS Summit Tokyoが4年ぶりに現地開催！ この週末、日本で年一回のAWSの祭典「AWS Summit Tokyo」が幕張メッセにて開催されました。 4年ぶりの現地開催ということもあり、2日間ともものすごい数の人々が来場し、会場の熱気は大変なものでした！ 大人気セッション「アーキテクチャ道場！」 2日間の中でも特に人気を博していたのが、AWS Japanのチーフテクノロジスト内海さんによる「アーキテクチャ道場2023！」。 昨年もオンライン開催にて好評を集めていたセッションで、30分という限られた時間内でAWS JapanのSAさんがお題に基づいてガチのアーキテクティングを行い、内海さんからその講評を受けるという流れを2本連続で実施する、大変濃密なコンテンツです。 私も最前列でガチ受講していましたので、自社ブログにて詳細なレポートを投稿しております！ 実はこのアーキテクチャ道場
The Architecture of Uber's API gateway
You’re seeing information for Japan . To see local features and services for another location, select a different city. Show more API gateways are an integral part of microservices architecture in recent years. An API gateway provides a single point of entry for all our apps and provides an interface to access data, logic, or functionality from back-end microservices. It also provides a centralize
カオスエンジニアリングとは、実験を通してシステムの弱みを明確にすることである。カオスエンジニアリングから継続的検証へ（後編）。JaSST'23 Tokyo基調講演
カオスエンジニアリングとは、実験を通してシステムの弱みを明確にすることである。カオスエンジニアリングから継続的検証へ（後編）。JaSST'23 Tokyo基調講演 Netflixが始めた「カオスエンジニアリング」は、現在では大規模なシステムにおける可用性向上の手法のひとつとして確立し、広く知られるようになりました。 そのカオスエンジニアリングという手法を定義したのが、元Netflixカオスエンジニアリングチームのエンジニアリングマネージャーを務めていたCasey Rosenthal（ケイシー ローゼンタール）氏です。 そのローゼンタール氏が、ソフトウェアのテストに関わる国内最大のイベント「ソフトウェアテストシンポジウム 2023 東京」（JaSST'23 Tokyo）の基調講演に登壇し、「Chaos Engineering to Continuous Verification」（カオスエン
可用性や安全性を高めつつ、ソフトウェアをシンプルにすることは不可能だ。カオスエンジニアリングから継続的検証へ（中編）。JaSST'23 Tokyo基調講演
可用性や安全性を高めつつ、ソフトウェアをシンプルにすることは不可能だ。カオスエンジニアリングから継続的検証へ（中編）。JaSST'23 Tokyo基調講演 Netflixが始めた「カオスエンジニアリング」は、現在では大規模なシステムにおける可用性向上の手法のひとつとして確立し、広く知られるようになりました。 そのカオスエンジニアリングという手法を定義したのが、元Netflixカオスエンジニアリングチームのエンジニアリングマネージャーを務めていたCasey Rosenthal（ケイシー ローゼンタール）氏です。 そのローゼンタール氏が、ソフトウェアのテストに関わる国内最大のイベント「ソフトウェアテストシンポジウム 2023 東京」（JaSST'23 Tokyo）の基調講演に登壇し、「Chaos Engineering to Continuous Verification」（カオスエンジニアリ
複雑なシステムでは、すべての要素が正しくても障害が起きる。カオスエンジニアリングから継続的検証へ（前編）。JaSST'23 Tokyo基調講演
複雑なシステムでは、すべての要素が正しくても障害が起きる。カオスエンジニアリングから継続的検証へ（前編）。JaSST'23 Tokyo基調講演 Netflixが始めた「カオスエンジニアリング」は、現在では大規模なシステムにおける可用性向上の手法のひとつとして確立し、広く知られるようになりました。 そのカオスエンジニアリングという手法を定義したのが、元Netflixカオスエンジニアリングチームのエンジニアリングマネージャーを務めていたCasey Rosenthal（ケイシー ローゼンタール）氏です。 そのローゼンタール氏が、ソフトウェアのテストに関わる国内最大のイベント「ソフトウェアテストシンポジウム 2023 東京」（JaSST'23 Tokyo）の基調講演に登壇し、「Chaos Engineering to Continuous Verification」（カオスエンジニアリングから継続
本当は怖い、逆コンウェイ戦略 | フューチャー技術ブログ
アーキテクチャの議論でよく出てくるのが、コンウェイの法則と、逆コンウェイ戦略です。これについては、うっかりIT用語をバズらせてしまう達人のマーチン・ファウラーのブログにも詳しい説明があります。角さん、いつも翻訳ありがとうございます。 「逆コンウェイの法則」が持ち出された議論が苦手なんどけど、なんでなのかな。コンウェイの法則はよく理解できるんだがー。 — Kazunori Otani (@katzchang) February 28, 2023 この@katzchangさんのツイートもそうですが、逆コンウェイ戦略に関しては僕も少しモヤモヤするところが個人的にあり、そのあたりを周りの人（@katzchangさんや@tokoroten、@__garsue__氏）と議論したらいろいろ自分が思っていなかった知見も得られたりしたので、まとめてみます。 コミュニケーションがかえって増える問題コンウェイの
ヤフーショッピングのフロントエンドを支える共通配信技術
本記事は2022年11月に開催した「Tech-Verse 2022」で発表したセッションを要約したものです。アーカイブ動画を文末に掲載しています。質疑応答の様子も収録されていますのでぜひご覧ください。 ヤフーショッピングのフロントエンドを支える共通配信技術について、「共通UI配信サービス誕生までの経緯」と「共通UI配信サービスを支える技術」の2部構成で紹介します。 共通UI配信サービス誕生までの経緯 ヤフーショッピングには、トップ、検索、商品詳細、カート、レビュー、問い合わせ、製品、キャンペーン、ランキング、注文履歴などさまざまな画面があり、それに合わせてさまざまな開発チームが存在しています。 各チームでアプリケーションは独立していて、それぞれリンクで接続されています。共通UIのHTMLもアプリケーションが異なれば、それぞれに記述されます。同じアプリケーション内で共通UIを実装するのは簡単
フロントエンドアーキテクチャの話: Resource Setの紹介
こんにちは、よしこです。 この記事は 2020年に立ち上げたWebフロントエンド構成の振り返り の「Applicationのアーキテクチャ」項の詳細記事です。単体でも読めますが、よければ元記事もあわせてどうぞ！ この記事では、わたしの所属する株式会社ナレッジワークで開発・運用しているWebアプリケーションのドメインロジックやAPI通信部分のアーキテクチャについてご紹介していきます。いわゆるフロントエンドの中でも裏側の部分。 一番設計っぽい話になると思いますが、そのぶん「△△ライブラリの便利な使い方」「◯◯のベストプラクティス」というような具体的で汎用的な話とは異なり、うちではこうやってますという事例の共有以上の何物でもないです。 社内資料を社外にも公開するぐらいのイメージで共有していきます！ 前提:アプリケーションの構成要素の4分類 前段として、大元の思想から話します。 まず、フロントエン
イベント駆動アーキテクチャの勘所 - エムスリーテックブログ
こちらはエムスリーAdvent Calendar 2022の24日目の記事です。 こんにちは、デジスマチームの田口(id:ken-tunc)です。 私達のチームではQRコードによる受付や自動後払いなど、新しい診療体験を提供するデジスマ診療というサービスを開発しています。 開発メンバー6人と小規模のチームですが、毎週のように新機能をリリースしています。 また、ユーザー数も非線形的な成長を遂げており、システムのトランザクションは日に日に増加しています。 IR資料「2023年3月期第2四半期決算発表資料」より このようなスピード感のある開発を実現できている要因はいくつかありますが、この記事ではそのうちの1つであろうデジスマチームで採用しているアーキテクチャについてまとめていきます。 デジスマ診療のアーキテクチャ デジスマチーム紹介資料 イベント駆動アーキテクチャの設計で気を付けていること イベン
GraphQL Client Architecture Recommendation 社外版 | メルカリエンジニアリング
この記事は、Merpay Advent Calendar 2022 の15日目の記事です。 こんにちは。メルペイのvvakameです。 最近、社内向けにGraphQL Client Architecture Recommendationというドキュメントを書きました。社内のiOS/Android、そしてバックエンドのエンジニア向けにGraphQLをやるならこの辺りの条件を満たしておかないと恩恵を感じられなくなっちゃうかもよ、と伝えるためのものです。嬉しいことに、今までに100名弱の人たちがこのドキュメントを閲覧してくれたようです。 これをAdvent Calendarで公開するために、ちょっと調整したものがこの社外版です。 すでにGraphQLをやっているけどあまり便利じゃないな…なんでだろ？とか、これから導入したいんだけど何を気をつけるべきかな…と考える時の材料にしてください。 併せて、
The Distributed Computing Manifesto
The Distributed Computing ManifestoNovember 16, 2022 • 3941 words Today, I am publishing the Distributed Computing Manifesto, a canonical document from the early days of Amazon that transformed the architecture of Amazon’s ecommerce platform. It highlights the challenges we were facing at the end of the 20th century, and hints at where we were headed. When it comes to the ecommerce side of Amazon,
再考: アプリ開発と状態遷移の管理 - ninjinkun's diary
自分が開発しているLaunchableのWebアプリがローンチされて1年半ほどになる。このWebアプリにはReduxのような状態管理ライブラリを入れないまま開発してきたのだが、今のところ困らずに開発できている。そういえば昔自分は状態管理について何か考えていたような…とブログを掘り起こしてみた。 ninjinkun.hatenablog.com このエントリは2016年にネイティブアプリを対象にして書かれているが、この後自分は2018年ごろにWebフロントエンドに軸足を移し、ネイティブアプリ開発から離れた。なのでこのエントリはWebフロントエンドエンジニアが2022年に再考した話になる。 結論としては、当時自分が管理したかった状態のほとんどは現在ApolloClientのキャッシュによって解決されている。 繰り返しになるが、自分が開発しているLaunchableのWebフロントエンドには状態
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
UberのCacheFront：レイテンシーを大幅に削減し、毎秒4000万件の読み取りを可能に
