InfoQ ホームページ スケーラビリティ に関するすべてのコンテンツ
-
QCon London: Trainline社における、マイクロサービスアーキテクチャと技術組織のスケーリング
先日開催されたQCon Londonカンファレンスにて、Trainline社のCTOが、過去5年間における同社のシステム・アーキテクチャと組織構造の進化について講演した。同社は、テクノロジー・プラットフォームの性能と信頼性を向上させることで、市場の変化と顧客からの期待の高まりに応える必要があった。
-
HashnodeがStep Functions、EventBridge、RedisでAWS上にスケーラブルなフィードアーキテクチャを構築
Hashnodeは、数千人のユーザーのフィードデータを構成するためのスケーラブルなイベント駆動アーキテクチャ(EDA)を構築した。同社は、Lambda、Step Functions、EventBridge、Redis Cacheを含むAWS上のサーバーレスサービスを使用した。このソリューションは、Step Functionsの分散マップ機能を活用し、高度な並行処理を可能にしている。
-
Uber、GraphQLサブスクリプションとKafkaでマイクロサービスを使用したスケーラブルなチャットを構築
Uberは、WAMPプロトコルを使用して構築されたレガシー・アーキテクチャを、GraphQLサブスクリプションを活用した新しいソリューションに置き換えた。新しいアーキテクチャを構築した主な要因は、信頼性、スケーラビリティ、オブザーバビリティ/デバッグ可能性、そして既存のソリューションを維持するチームの能力を妨げている技術的負債にまつわる課題であった。
-
Zendesk、DynamoDBからMySQLとS3へ移行し、コストを80%以上削減
Zendeskは、DynamoDBからMySQLとS3を使用した階層型ストレージソリューションに移行することで、データストレージのコストを80%以上削減した。同社は様々なストレージ技術を検討したが、コストを抑えつつ、クエリ性とスケーラビリティのバランスを取るために、リレーショナルデータベースとオブジェクトストアを組み合わせることにした。
-
Discord、単一サーバーで100万人以上のオンラインMidJourneyユーザーに拡大
Discordは、応答性の高いユーザー体験を維持しながら、単一サーバーで100万人以上のオンライン・ユーザーにサービスを提供するためにプラットフォームを最適化した。同社は、システム観測可能性とパフォーマンスチューニングに支えられた一連のパフォーマンスとスケーラビリティの改善で、何十億ものメッセージ通知を扇状に流す役割を担うギルドコンポーネントを進化させた。
-
LinkedInがREST+JSONではなくgRPC+Protobufを選んだ理由:Karthik Ramgopal氏とMin Chen氏とのQ&A
LinkedInは、Microservices platformのサービス間通信にProtocol Buffersを使ったgRPCに移行すると発表した。従来は、オープンソースのRest.liフレームワークが主要なシリアライゼーションフォーマットとしてJSONと共に使われていた。
-
Amazon Aurora Limitless Databaseによる自動水平スケーリング
AWSは最近、Amazon Aurora Limitless Databaseのプレビューを発表した。この新機能は、毎秒数百万の書き込みトランザクション処理し、一つのAuroraデータベースでペタバイトのデータを管理し、自動水平スケーリングをサポートする。
-
HubSpotがワークフロー・アクションをタイムリーに処理するためにApache Kafkaスイムレーンを使用する方法
HubSpotは、コンシューマーグループの遅延の蓄積を回避し、リアルタイムのトラフィックの処理を優先するために、同じプロデューサーの複数のKafkaトピック(スイムレーンと呼ばれる)上でメッセージをルーティングすることを採用した。トラフィック急増の自動検知と手動検知を組み合わせて使用することで、同社は顧客の大半のワークフローが遅延なく実行されるようにしている。
-
LinkedIn、EspressoをHTTP2に移行し、接続数を88%、待ち時間を75%削減
LinkedInは、EspressoデータベースをHTTP/1.1からHTTP/2に移行することで、接続数、待ち時間、ガベージコレクション時間を削減し、性能と拡張性を劇的に向上させた。これらを改善するために、チームはNettyのデフォルトHTTP/2スタックを最適化し、ニーズに合わせる必要があった。
-
Wave: アーキテクチャの複雑性低減に関するケーススタディ
Dan Luu氏は、単純で退屈なアーキテクチャが最適なビジネスモデルのケーススタディとして、Waveを紹介する記事を公開した。Waveは、最先端を行くサービスベースの非同期アーキテクチャではなく、データベースの支援によって統合的なAPIを提供する同期モノリスを採用している。
-
継続的な負荷テストをSlackパイプラインに統合
Slackは、パフォーマンスに焦点を当てているエンジニアだけでなく、すべてのエンジニアにとって負荷テストが注力すべき関心事になるよう取り組んできた。そして、パフォーマンスに対するリアクティブなアプローチから、より統合された取り組みに移行していると、SlackのエンジニアShreya Ramesh氏とMelissa Khuat氏は述べている。
-
NetflixのRENOがデバイス間で一貫したエクスペリエンスを実現する
Netflixは、多種多様なプラットフォームやデバイスにおいて一貫したユーザエクスペリエンスを実現するために、Rapid Event Notification System(RENO)を開発した。RENOは、タイトルの視聴からプロファイル情報の更新に至るまで、ユーザの実行したアクションに対して、従来の要求/応答モデルよりも迅速かつ確実に応答する。
-
Zesty DiskがAWS EBS向けの自動スケーリングを提供
Zestyは最近、Zesty Diskをリリースした。これは、AWS EBSの自動スケーリングソリューションである。Zesty DiskはEBSパフォーマンスメトリックを監視し、それらのメトリックに基づいてクラスターサイズを自動的にスケーリングできる。これは、システムの使用状況に基づいて必要に応じてアタッチまたはデタッチできるEBSボリュームの���ラスターを作成することによって行われる。
-
サーバレスアーキテクチャとCDNを使用した2.5倍のトラフィックへのKhan Academyのスケーリングストーリー
Khan Academyのエンジニアリングチームは、Google App Engineと静的コンテンツ配信プロバイダーであるFastlyとYoutubeのサーバレスアーキテクチャを活用して、通常のトラフィックの2.5倍にスケーリングするというストーリーを公開した。
-
COVID-19のGoogle Meetのスケーリングの課題
Googleは、COVID-19の大流行により、より多くの人々がGoogle Meetを使用するようになったため、使用量の増加によるGoogle Meetのスケーリングの課題について書いた。GoogleのSREチームは、今年初めに始まったトラフィック増加の課題に取り組むために、既存のインシデント管理フレームワークを変更して使用した。