並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 207件

新着順 人気順

scalabilityの検索結果1 - 40 件 / 207件

scalabilityに関するエントリは207件あります。 開発databaseデータベース などが関連タグです。 人気エントリには 『Webアプリ負荷試験ガイド - withgod's blog』などがあります。
  • Webアプリ負荷試験ガイド - withgod's blog

    Webアプリ負荷試験ガイド 目次 Webアプリ負荷試験ガイド 目次 前置き 時間がない人向け要約 about me 何故負荷試験を行うのか 負荷試験ツール 負荷掛けるツール 負荷計測 負荷の可視化 負荷試験の流れ 負荷試験スケジュールについて 注目すべきポイント シナリオ作成 アカウント情報は自動生成出来るようにする DB分割を行ってる場合はDB分割を意識したシナリオを用意する。 負荷試験元 http or https サーバ1台 サーバ単体での負荷 アプリの正常性の確認 サーバ複数台 KVS Memcached Redis RDB 問題になりやすいDB キャッシュの話 大前提 注意すべき点 CDNやProxyレベル local cache or remote cache local cache or memory cache(in app cache) references 更新情報 前

      Webアプリ負荷試験ガイド - withgod's blog
    • 新NISAは年初に一括購入した方が効率的。それでも分散購入する理由

      前提◯株式(世界の経済)は全体として成長する。 ◯購入するものはインデックス投信とする。ただし、為替ヘッジなし(円ベースと書いてあるもの)とする。 理想と現実下落したときに一括購入することが理想だが、以下の理由にによりなかなか上手くいかない。 ◯一旦下落が始まると、「もっと下がってから買おう」という心理が働いてなかなか購入に踏み切れない。筆者の例でいうと、今年8月〜10月の下落基調のときに、NASDAQが12000まで落ちたら余剰資金突っ込むつもりで待ち構えていたが12500で反発してするすると上がっていってしまった(その機会損失だけで数百万円分くらいある。)。 ◯下落したときの株価が一括購入時を下回らないときが往々にしてある。例えば今年のeMAXIS Slim全世界株式(オール・カントリー)を見てみると、年始早々、5%ほど下落したもののその後は一貫して上昇傾向だ。機を待っていては結局高値

        新NISAは年初に一括購入した方が効率的。それでも分散購入する理由
      • 2020年現在のNewSQLについて - Qiita

        Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Disclaimer 当記事はNewSQL開発ベンダの技術ブログや各種論文、その他ニュースサイト等の内容を個人的にまとめたものです。 そのため、理解不足等に起因する誤解・誤認を含む可能性があります。更なる理解が必要な方はリファレンスに挙げた各種文献を直接参照下さい。技術的な指摘は可能であれば取り込み修正しますが、迅速な対応はお約束できません。 NewSQLの解説は二部構成 当記事は前編でNewSQLの概要編となる。 全体の目次は下記である。 NewSQLとは何か NewSQLのアーキテクチャ NewSQLとこれまでのデータベースの比較

          2020年現在のNewSQLについて - Qiita
        • 同期エンジンの心臓部を書き換える

          0 0 719 0 この 4 年間、Dropbox では、デスクトップ クライアントの同期エンジンを白紙の状態から再構築しようと懸命に取り組んできました。同期エンジンは、デスクトップ パソコン上の Dropbox フォルダの陰に隠れた魔法です。これは、Dropbox で最も長く使われているコード部分であり、最も重要なコード部分の 1 つでもあります。今回、新しい同期エンジン(コードネーム「Nucleus」)をすべての Dropbox ユーザー向けにリリースさせていただくことを、ここに発表いたします。 同期エンジンの書き換えは本当に大変な作業で、多くの環境でマイナスともなりうる構想であったことに鑑みると、手放しで祝う気持ちにはなれません。結果的には Dropbox にとって素晴らしいアイデアであったわけですが、それは、私たちがこのプロセスにどのように取り組むべきかを熟考したからこそ、たどり着

            同期エンジンの心臓部を書き換える
          • Twitter を作るのはなぜ難しいのか

            Fumihiko Shiroyama @fushiroyama 父、博士課程 Software Development Engineer @Adobe / ex-@Microsoft, ex-@amazon All opinions are my own. note.com/fushiroyama/ Fumihiko Shiroyama @fushiroyama Twitterみたいな緩いつながり、TLひとつ実装するだけでも普通のウェブシステムみたいなクエリでは取れなくてちょっと考えれば非常に複雑なシステムであることは明白だし、システムアーキテクチャの試験の定番トピックだったりするので「誰でも作れる」とか「簡単」みたいなのはご指摘申し上げたくなる Fumihiko Shiroyama @fushiroyama 昔つぶやきましたが例えばこの記事を読むと分かりやすいです。 twitter.co

              Twitter を作るのはなぜ難しいのか
            • Tumblr、マストドンと接続へ。分散型SNS標準プロトコルを採用し、Twitterからの脱出受け入れ強化(CloseBox) | テクノエッジ TechnoEdge

              ブログサービスのTumblrが、分散型SNSサービスの標準プロトコルであるActivityPubを採用すると明らかにしました。 ▲Tumblr ActivityPubは、Twitter代替を目指すマストドン(Mastodon)、Pleroma、GNU social、PeerTube、Misskeyなどの分散型SNSのサーバ同士が投稿やユーザー情報をやり取りするための標準で、2018年1月にW3C推奨となっています。 関連記事:Twitter代替目指す分散型SNS「マストドン」、翻訳機能など追加。ブラウザメーカーのVivaldiも参入表明 TumblrはTwitterのリツイートに似たリブログという伝播性の高い仕組みが特徴で、かつては著作権的・性的に問題のある画像が次々と掲載されていることを問題視する声があったことでも知られています。 Twitterと並び立つテキスト・画像投稿サービスとして

                Tumblr、マストドンと接続へ。分散型SNS標準プロトコルを採用し、Twitterからの脱出受け入れ強化(CloseBox) | テクノエッジ TechnoEdge
              • 東京の人口 初めて1400万人超える コロナ禍でも一極集中続く | NHKニュース

                東京都の人口が先月1日現在の推計で、初めて1400万人を超えました。新型コロナウイルスの感染が拡大していた4月も就職や進学などの転入があり、人口の東京一極集中が続いています。 合わせると、前の月よりおよそ2万人増えて1400万2973人となり、初めて1400万人を超えました。 新型コロナウイルスの感染が拡大していた4月に、就職や進学などで他の道府県から転入した人が転出した人よりも上回るなどしたためです。 前の年の同じ時期と比べても8万人余り増加していて、人口の東京一極集中が続いています。 東京都の人口は、昭和37年に1000万人の大台を超え、昭和42年に1100万人に達して以降、およそ30年間は横ばいで推移していました。 その後、バブル経済崩壊後の平成9年から再び増加に転じ、平成12年に1200万人を突破し、その後20年かけて1400万人に達したことになります。 都の担当者は「バブル経済の

                  東京の人口 初めて1400万人超える コロナ禍でも一極集中続く | NHKニュース
                • よわよわエンジニア😪 on Twitter: "強強エンジニアの人曰く、駆け出しバッグエンドエンジニアのほぼ100%がシステム障害時、とくに負荷上昇時の課題の切り分けができない説。逆にインフラ領域まで踏み込んだ調査ができると市場価値が一歩上がるらしい。 自分が読んで良かった記事をまとめる👇"

                    よわよわエンジニア😪 on Twitter: "強強エンジニアの人曰く、駆け出しバッグエンドエンジニアのほぼ100%がシステム障害時、とくに負荷上昇時の課題の切り分けができない説。逆にインフラ領域まで踏み込んだ調査ができると市場価値が一歩上がるらしい。 自分が読んで良かった記事をまとめる👇"
                  • 「割り込みタスクが多くて困ってます」と相談を受けたらマネージャーはどうするか - るさんちまん

                    はじめに @dora_e_m さんのエントリがあまりに素敵だったので、僕も感化された "割り込みタスク × マネージャー" のネタを書くことにしました。 note.com このエントリでは、エンジニアとデザイナーのマネージャーをしている筆者が、メンバーから「割り込みタスクが多くて困っているんですがどうしたらよいでしょう」と相談されたときにするアドバイスをまとめました。ちなみに全て実際に体験したことです。 ※必ずしもこれら2職種でしか適用できない内容ではないですが、発想・解決のしかたが開発に依るところが大きいです。 なお、アドバイスの内容は個人でできるライトなものからタスクの依頼主に働きかけが必要なヘビーなものまであり、実際にアドバイスする順に並べるとこのようになります。 [個人] 割り込みタスクの優先度を過剰に高くしすぎていませんか [個人] 割り込みタスクにかけている時間はどれくらいです

                      「割り込みタスクが多くて困ってます」と相談を受けたらマネージャーはどうするか - るさんちまん
                    • Git の最新アップデートから考える開発手法の潮流

                      2022.11.15に発表した内容になります。 https://www.youtube.com/watch?v=ScNN3uGXFd0

                        Git の最新アップデートから考える開発手法の潮流
                      • 1000万ユーザに耐えるサーバを作ってみた

                        概要 スケーラビリティが高く1000万ユーザに耐えるAPIサーバを作成しました。TwitterのようなSNSです。実装はGitHubで公開しています。 開発環境は次の通りです。 Node 16.14 Express 4.17.3 DynamoDB 2012-08-10 機能要件は次の通りです。 ツイート機能 ツイートに対してコメント機能 フォロー機能 タイムライン機能 導入 Facebook、Amazon、Youtubeのような数億人のユーザを抱えるサービスでは大量のトラフィックを捌く必要があります。大量のトラフィックを捌くためのアプローチとして一般的に使われるのはスケールアップではなくスケールアウトです。スケールアップは性能の高い機器を使うためにコストが高いです。また、1つのサーバで運用するためにパフォーマンスの限界が存在します。 スケールアウトについて考えます。アプリケーションは大きく

                          1000万ユーザに耐えるサーバを作ってみた
                        • PayPayでのDynamoDB活用事例について

                          Presented by: Tomoki Nishinaka, Yu Zhouxun PayPayの機能の一つとして2020年4月に新たにリリースされた通知サービスでは、スケーラビリティとパフォーマンスを重視し、数々のデータストアソリューションの中からDynamoDBを採用しました。通知センターの…

                            PayPayでのDynamoDB活用事例について
                          • (翻訳) GitLab 社で働くのはどのようなものだったか - forest book

                            本稿は Yorick Peterse 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。 yorickpeterse.com また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Yorick Peterse 氏ではなく、本稿のコメント欄にお願いします。 ここから本文です。 GitLab 社で働くのはどのようなものだったか 私は2015年10月に GitLab 社に入社し、6年あまり働いて2021年12月に退社しました。 前に GitLab 社を辞めて Inko に取り組んでいることは書きましたが、2015年から2021年までの間、GitLab 社で働いていたことがどのようなものであったのかについては触れませんでした。理由は2つあります。 燃え尽き症候群に苦しんでいて、(当時は) 自分の人生の最後の6

                              (翻訳) GitLab 社で働くのはどのようなものだったか - forest book
                            • 分散型金融システムのトラストチェーンにおける 技術リスクに関する研究 研究結果報告書

                              • W3C、中央集権的な管理を不要にする「Decentralized Identifiers (DIDs)」(分散型識別子)の仕様が勧告に到達

                                W3C、中央集権的な管理を不要にする「Decentralized Identifiers (DIDs)」(分散型識別子)の仕様が勧告に到達 World Wide Web Consortium (W3C)は、「Decentralized Identifiers (DIDs) 」(分散型識別子)バージョン1.0(以下、W3C DID)の仕様が勧告に到達したと発表しました。 W3C press release: "Decentralized Identifiers (DIDs) v1.0 becomes a W3C Recommendation" "This new type of verifiable identifier... will enable both individuals and organizations to take greater control of their onl

                                  W3C、中央集権的な管理を不要にする「Decentralized Identifiers (DIDs)」(分散型識別子)の仕様が勧告に到達
                                • マルチテナントの実現におけるDB設計とRLS / Utilizing RSL in multi-tenancy

                                  # 実装の参考資料 - https://soudai.hatenablog.com/entry/2022/11/11/110825 # 類似の登壇内容の動画 - https://www.youtube.com/watch?v=PXy6I-AeI-I

                                    マルチテナントの実現におけるDB設計とRLS / Utilizing RSL in multi-tenancy
                                  • 自作RDBMSやろうぜ!(Zenn出張版)

                                    Disclamer 本記事は自作DBMSやろうぜ! のページの 22/05/27 JST 22:38 の時点での内容をZenn記事向けに修正して作成したものです 元コンテンツのライセンスについては以下をご参照ください LICENCE 元コンテンツの方は更新が継続されていますので、よろしければそちらもご覧ください この記事の目的 RDBMS(いわゆるリレーショナルデータベース)というものはプログラミング言語の処理系や、OSなどと同様に、世の中で広く使われているソフトウェアであるにも関わらず、いざ自作してみようと思うと日本語で記述されている必要な情報・情報源がまとまったサイトやブログ記事がないことに気づきました そこで、叩き台として、筆者および数名のコミッタで開発している自作RDBMSである SamehadaDB が軌道に乗るまでの経験をベースに、自作RDBMSに関する情報をある程度整理して書

                                      自作RDBMSやろうぜ!(Zenn出張版)
                                    • 無料の分散型フォルダー同期ツール「Syncthing」v1.15.0が公開/不正なリレープロトコルメッセージを送るとクラッシュする脆弱性を修正

                                        無料の分散型フォルダー同期ツール「Syncthing」v1.15.0が公開/不正なリレープロトコルメッセージを送るとクラッシュする脆弱性を修正
                                      • AWS Lambda×Fargate×PlanetScaleを組み合わせれば、超絶スケールするWebアプリを作れる 約2ドルから作れる“ニッチで俺得な”環境の布教 | ログミーBusiness

                                        遠藤氏の自己紹介遠藤大介氏:今日は「AWSのLambdaとPlanetScaleを組み合わせると、超絶スケールするWebアプリを作れちゃうぜ」という話をしていこうと思っています。 最初に自己紹介です。遠藤と申します。SonicGardenという会社で、プログラマーと執行役員をやっています。インフラと機械学習などが好きで、趣味もプログラムで仕事もプログラムな感じの人間なんですが、最近は機械学習周りが盛り上がっているので、そっちもいろいろやっています。 あと、ロードバイクに趣味で乗っているのですが、最近ちょっと乗れていません。それからゲーマーで、最近は『FF16』にどっぷり浸かっています。 (スライドを示して)ささっと2個ほど宣伝したいのですが、SonicGardenで無料のオンラインプログラミング合宿をやろうと思っていて、今、夏のキャンプの申し込み受付をしています(登壇時点)。 学生や第2新

                                          AWS Lambda×Fargate×PlanetScaleを組み合わせれば、超絶スケールするWebアプリを作れる 約2ドルから作れる“ニッチで俺得な”環境の布教 | ログミーBusiness
                                        • 分散型SNS「Misskey」、それを支える技術スタック | gihyo.jp

                                          本連載は分散型マイクロブログ用ソフトウェアMisskeyの開発に関する紹介と、関連するWeb技術について解説を行っていきます。第1回はMisskey、ひいては分散型SNSの簡単な紹介とその内部実装の概略を説明します。 はじめまして! はじめまして、Misskey(みすきー)のプロジェクトリーダーをしている、しゅいろ(@syuilo)です! この度連載の機会をいただきましたので、ちょっと仰々しい気もしますが「Misskey & Webテクノロジー最前線」と題して、今後Misskeyやそれに関わる最新のWeb技術について解説をしていく予定です。 今回はMisskey、ひいては分散型SNSの簡単な紹介とその内部実装の概略を説明します。 対象読者は、後半の実装解説の部分においてはある程度のWeb開発の知識がある人を想定しています。 Misskeyとは⁠、そして分散型とは Misskeyは、オープン

                                            分散型SNS「Misskey」、それを支える技術スタック | gihyo.jp
                                          • 分散型SNS「Misskey」への開発支援に関するお知らせ

                                            このたびエックスサーバー株式会社は、 分散型SNSのオープンソースソフトウェア(OSS) 「Misskey」の開発を支援することとなりました。 開発環境の提供や開発資金の援助を通じて、「Misskey」の開発・運営をサポートし、 弊社運営のVPSサービス『Xserver VPS』のインフラサービスとしての、利便性の向上へも取り組んでまいります。 ---------------------------------------------------------------------- ■開発支援の目的 エックスサーバー株式会社は、日本のインターネットの未来を支えることを理念に掲げ、 国内シェアNo.1(※1)のレンタルサーバーサービス『エックスサーバー』をはじめとした、 インターネットサービスを展開してまいりました。 「Misskey」は、「X(旧Twitter)」に替わるSNSとして昨今

                                              分散型SNS「Misskey」への開発支援に関するお知らせ
                                            • 理解して拡げる分散システムの基礎知識

                                              20200725の #JTF2020 セッションスライド。 (資料内で説明した資料へのリンク) ・昨年のJTF発表資料 https://speakerdeck.com/tzkoba/cloud-nativekai-fa-zhe-falsetamefalsedatabase-with-kuber…

                                                理解して拡げる分散システムの基礎知識
                                              • AWSで障害に強いシステムを構築する方法 - Qiita

                                                はじめに 2011年の東日本大震災、これから来ると言われる南海トラフ地震などの大規模な災害や事故に備えるために、災害復旧(DR)が可能なシステムと、その実現手段としてAWSを始めとしたクラウドが長年注目されています。 このDRに関連して、近年「レジリエンス」という言葉が注目を集めるようになりました。 レジリエンスとは、回復力、復元力、弾力などの意味を持つ英単語。IT分野では、情報システムがシステム障害や災害、サイバー攻撃などの問題に直面したとき、迅速に被害からの回復を図り正常な状態に復旧・復元する能力(の大きさ)をこのように呼ぶ。 https://e-words.jp/w/%E3%83%AC%E3%82%B8%E3%83%AA%E3%82%A8%E3%83%B3%E3%82%B9.html AWSでは、2019年8月に大規模障害が発生したことがあり、この時もAZ障害が起きた時に取り得る対策

                                                  AWSで障害に強いシステムを構築する方法 - Qiita
                                                • 秒間 10,000 リクエストを "簡単に"いなすゲームサーバーを Laravel で作る設計

                                                  1秒間に PHP が受信する HTTP リクエストが最大 10,000 回以上——— そんな世界が存在します。その一つが 「ソーシャルゲーム」 です。メンテナンスが明けた瞬間、イベントが始まった・終わる瞬間、様々なタイミングでゲームサーバーは瞬間的に高負荷になります。もちろん、サービスをリリースし P…

                                                    秒間 10,000 リクエストを "簡単に"いなすゲームサーバーを Laravel で作る設計
                                                  • モノリスの分解において、マイクロサービスは必然ではない - QCon LondonにおけるSam Newman氏の講演より

                                                    Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

                                                      モノリスの分解において、マイクロサービスは必然ではない - QCon LondonにおけるSam Newman氏の講演より
                                                    • 日本はキャッシュレス化が遅いと言われるが、地震があるたびに『そら中々ならんよ…』となる→キャッシュレス化が進んでいる国にも事情が

                                                      ミィミル @Fontaine_XVIII @STEALBER @okmtsn115 銀行があると強盗に襲われるから警備のコストも考えて銀行は必要最低限にしてるとか、通貨流通させるには安全に通行できる道路の整備が必要だけどそんなお金無いから僻地は問答無用でキャッシュレス、とかもありますね… 2021-02-14 12:58:46 酔いどれずんだもんの経済談義 @Raptority そりゃ電子マネーやキャッシュレスは物理的に停電やネット回線が駄目になったりしたら使えないってデメリットがあるからな。 キャッシュレスが進んだ国というのも偽札があまりにも出回りすぎて現金が信用できないって事情があったりもするから現金とどっちが優れてるかは状況次第だわな。 twitter.com/okmtsn115/stat… 2021-02-14 18:07:41

                                                        日本はキャッシュレス化が遅いと言われるが、地震があるたびに『そら中々ならんよ…』となる→キャッシュレス化が進んでいる国にも事情が
                                                      • リアクティブは難しいが役に立つ - kubell Creator's Note

                                                        お久しぶりです、かとじゅん(@j5ik2o)です。テックブログを書くのは何年ぶりか…。 サービスが停止したり応答性が低下すると、お叱りや逆に励ましをいただきますが、エンジニアとして設計レベルからそういった問題に対処するにはどうするか、日々精進しているところですmm。この記事はそういう論点で注目されている「リアクティブ原則」についてまとめてみたいと思います。 それなりのボリュームになってしまったので、時間があるときに読んでいただければと思います。 さて、Linux Foundation内の新たなトップレベルプロジェクトであるReactive Foundationが主催する、Reactive Summit 2020が11月10日にオンラインで開催されたので参加しました。 www.reactivesummit.org 参加されていたスピーカーはLightbendをはじめ、Netflix, Fac

                                                          リアクティブは難しいが役に立つ - kubell Creator's Note
                                                        • RDBの限界とNoSQLの登場

                                                          事実世界のインターネット人口が増えたのは1990年代からだ。 [引用] http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h10/html/98wp2-3-1f.html [引用] http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h29/html/nc144210.html __NoSQL__の登場 1990年に入るとインターネットの利用人口が急激に増加することになる。 この頃からトランザクションに最適化されて設計されたDBでは性能劣化が始まり、システムはデータベースに対しスケール性能を必要とし始める。 多くの開発者は、単一の強力なサーバーでリレーショナル・データベースを実行するのではなく、リレーショナル・データベース管理システム (RDBMS) のパーティショニング (シャー

                                                            RDBの限界とNoSQLの登場
                                                          • ネットワークに基づく分散型+中央集権SNS一覧(damus, nostr, Bluesky, AT Protocol, Mastodon, Misskey, Threads, ActivityPub ...) - Qiita

                                                            ネットワークに基づく分散型+中央集権SNS一覧(damus, nostr, Bluesky, AT Protocol, Mastodon, Misskey, Threads, ActivityPub ...)mastodonmisskeythreadsnostrBluesky はじめに Twitterの動乱に巻き込まれ、移住先に選ばれつつある Threads が5日で1億人を突破した今日このごろ、皆様いかがお過ごしでしょうか。 Alt Twitterとしての各種サービスに注目が集まりつつありますが、それらに関しての解説記事も乱立しており、一方で、その正確性や内容には必ずしも正確ではないものもあります。 プロトコルとアプリとサービスの区別がついていなかったり、相互接続できないものが接続できると宣伝されていたり、その逆もあります。 本記事では、特にネットワークに基づいて、各種SNSを分類して説

                                                              ネットワークに基づく分散型+中央集権SNS一覧(damus, nostr, Bluesky, AT Protocol, Mastodon, Misskey, Threads, ActivityPub ...) - Qiita
                                                            • Kubernetesの負荷試験で絶対に担保したい13のチェックリスト - Qiita

                                                              概要 ※この記事は弊ブログ記事(はてな)、Kubernetesの負荷試験で絶対に担保したい13のチェックリストと同内容です ここ最近、Kubernetesクラスタを本番運用するにあたって負荷試験を行ってきました。 Kubernetesクラスタに乗せるアプリケーションの負荷試験は、通常の負荷試験でよく用いられる観点に加えて、クラスタ特有の観点も確認していく必要があります。 適切にクラスタやPodが設定されていない場合、意図しないダウンタイムが発生したり、想定する性能を出すことができません。 そこで私が設計した観点を、汎用的に様々なPJでも応用できるよう整理しました。 一定の負荷、スパイク的な負荷をかけつつ、主に下記の観点を重点的に記載します。 Podの性能 Podのスケーラビリティ クラスタのスケーラビリティ システムとしての可用性 本記事ではこれらの観点のチェックリスト的に使えるものとして

                                                                Kubernetesの負荷試験で絶対に担保したい13のチェックリスト - Qiita
                                                              • CockroachDB はどのくらい「しぶとい」のか? / How tough is CockroachDB?

                                                                CockroachDB はどのくらい「しぶとい」のか? / How tough is CockroachDB?

                                                                  CockroachDB はどのくらい「しぶとい」のか? / How tough is CockroachDB?
                                                                • “わずか10分”で「負荷試験環境」の構築が可能に クイックにチェックできる状況をサクッと作れる、Linode活用法 | ログミーBusiness

                                                                  Linodeのメリットが得られやすいユースケースとは?佐藤裕行氏(以下、佐藤):後半は、Linodeのユースケースについて、少し岡本さんと話を進めていきたいと思うんですけども。今回はアプリケーションの負荷試験にフォーカスして、デモなども見せていきます。 その前に、負荷試験以外のサービスでいうと、こういうのに向いているとか、こういうのに向いてそうなところって、なにか感覚として持ってたりしますか? 岡本英輝氏(以下、岡本):前半に続いて、ちょっと転送量コストの話ばっかりになってしまうんですけど、やはりアウトバウンド転送量を大きく消費するようなアプリケーションに非常に向いてると思っていて。映像の配信であったり、音楽の配信であったり、そういったものにはすごく向いてるんじゃないかなと思います。 もしくは音声通話やビデオ会議、そういったデータ通信量が多く発生しやすいものは、他社との比較ですごくコストメ

                                                                    “わずか10分”で「負荷試験環境」の構築が可能に クイックにチェックできる状況をサクッと作れる、Linode活用法 | ログミーBusiness
                                                                  • 未ログインでも叩けるAPIエンドポイントにレートリミットを導入する

                                                                    先日だれでもAIメーカーというWebサービスをリリースしました。このサービスは例によってOpenAI APIを使っており、トークンの使用量がランニングコストに大きく影響します。 また、気軽に使ってもらえるよう未ログインでも使用できる仕様にしているため、気をつけないと悪意のある人に大量にトークンを使用されてしまう可能性があります。 ノーガードだとどうなるか 例えば、POST /api/askという「リクエストbodyのpromptの値を取り出し、OpenAI APIのChat Completionsに投げる」という単純なエンドポイントを作ったとします。 「未ログインでも使ってもらいたいから」と認証を一切しなかった場合どうなるでしょうか? 悪意のある攻撃者に見つかれば、promptを上限ギリギリの長さの文章に設定したうえで、/api/askに対してDoS攻撃するかもしれません。 トークンを大量

                                                                      未ログインでも叩けるAPIエンドポイントにレートリミットを導入する
                                                                    • Nostr. Nostrという新しい分散型のソーシャルプロトコルを試してみています。 | by Fumi | Feb, 2023 | Medium

                                                                      Nostrという新しい分散型のソーシャルプロトコルを試してみています。 私の公開鍵 はこちらです。 npub1zkquutx5q7c3f8pv5ad2wgszrwxkmnmj9769dxf7r3uvnf92mn0sas5dnh NostrとはNotes and Other Stuff Transmitted by Relays、略してNOSTR。 こちらがGitHub。 The simplest open protocol that is able to create a censorship-resistant global “social” network once and for all. It doesn’t rely on any trusted central server, hence it is resilient; it is based on cryptographic

                                                                        Nostr. Nostrという新しい分散型のソーシャルプロトコルを試してみています。 | by Fumi | Feb, 2023 | Medium
                                                                      • あなたの知らないKubernetesのServiceの仕組み | IIJ Engineers Blog

                                                                        Kubernetesの主要なリソースの一つにServiceリソースがあります。ServiceリソースとはKubernetes上のPodへクラスタの外からアクセスするために使うもの、という理解をしている人が多いかもしれません。確かにそのような役割を担っているのですが、実際にはクラスタ内部に閉じた通信にも利用されていますし、実はもっといろいろな機能を持っています。 端的に説明すれば、Serviceとは「ロードバランサとDNSサーバを設定するためのリソース」です。意外に聞こえますか? もし意外に思えたなら、ぜひこのまま読み進めてみてください。 インターナルなロードバランサを制御する Kubernetesにはクラスタ内部に閉じた通信を制御するロードバランサが内蔵されています。Kubernetesを利用するということは、ほぼ例外なくこのロードバランサを利用しているのですが、あまり意識せずに利用されて

                                                                          あなたの知らないKubernetesのServiceの仕組み | IIJ Engineers Blog
                                                                        • Cloud Native時代のデータベース

                                                                          2021/6/11 #InfraStudy 2nd Season

                                                                            Cloud Native時代のデータベース
                                                                          • [速報]「Amazon Aurora DSQL」プレビュー公開、事実上無限にスケールする高性能なPostgreSQL互換の大規模分散データベース

                                                                            Amazon Web Services(AWS)は、米ラスベガスで開催中のイベント「AWS re:Invent 2024」で、PostgreSQL互換の分散データベース「Amazon Aurora DSQL」のプレビュー公開を発表しました。 Amazon Aurora DSQLは、地理的に離れた複数のリージョンでデータベースが稼働する大規模分散データベースです。 分散処理による高いスケーラビリティ、複数のリージョンによる冗長構成による高可用性の両方を実現するだけでなく、分散データベースにおいてトランザクション処理による強い一貫性を実現する際の弱点とされていたレイテンシの大きさを克服し、小さなレイテンシによる高速性も兼ね備えたPostgreSQL互換のデータベースだと説明されています。 分散データベースの弱点はレイテンシの増大 一般に分散データベースは、複数のデータベースのノードが分散してリ

                                                                              [速報]「Amazon Aurora DSQL」プレビュー公開、事実上無限にスケールする高性能なPostgreSQL互換の大規模分散データベース
                                                                            • 分散モノリスとWebAssemblyランタイムを用いた新しいアプリプラットフォーム「Wasmer Edge」登場。オーケストレーションもサービスメッシュも不要

                                                                              分散モノリスとWebAssemblyランタイムを用いた新しいアプリプラットフォーム「Wasmer Edge」登場。オーケストレーションもサービスメッシュも不要 WebAssemblyランタイム「Wasmer」の開発元であるWasmer社は、エッジロケーション上のデータセンターにWebAssemblyランタイムを展開し、分散モノリスなアーキテクチャを用いたサーバレス型の新しいアプリケーションプラットフォーム「Wasmer Edge」を発表しました。 The Cloud is dead, long live the Cloud! Announcing Wasmer Edgehttps://t.co/VjGsbMwopy pic.twitter.com/5mTtKBBjsZ — Wasmer (@wasmerio) June 15, 2023 上記のツイートに示されているように、Wasmer E

                                                                                分散モノリスとWebAssemblyランタイムを用いた新しいアプリプラットフォーム「Wasmer Edge」登場。オーケストレーションもサービスメッシュも不要
                                                                              • ハッカーのおもちゃとしてのNostrのススメ - Qiita

                                                                                Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに Nostrという、SNSのようなものはご存知でしょうか? ご存知でなければ、ぜひまず一度触ってみることをお勧めします。 割と普通にSNSっぽく使えます。 分散系SNSっぽいシステム Nostrは、分散系のSNSっぽいネットワークです。 図で表すとこんな感じ。普通に想像するWebサービスとは随分形が違うと思います。 各所のリレーサーバーに、ユーザーは投稿をばらまき、ユーザーがそれを見る形です。 分散の責任がユーザー(クライアント)側にあって、リレーサーバーが落ちたり消えたりしても影響が起きにくい仕組みです。 より詳しい説明は上記

                                                                                  ハッカーのおもちゃとしてのNostrのススメ - Qiita
                                                                                • Goodbye to sequential integers, hello UUIDv7!

                                                                                  Scale-Out Delivery Platform→Complexity is inevitable. Tame it and gain your competitive advantage.

                                                                                    Goodbye to sequential integers, hello UUIDv7!

                                                                                  新着記事