みんなの銀行：日本初の「デジタルバンク」として Google Cloud に勘定系を構築。Cloud Spanner で銀行基幹システムで求められる可用性を実現 | Google Cloud Blog
みんなの銀行：日本初の「デジタルバンク」として Google Cloud に勘定系を構築。Cloud Spanner で銀行基幹システムで求められる可用性を実現 2021 年 5 月にサービス提供を開始した「みんなの銀行」は、デジタル ネイティブ世代をターゲットとしたスマートフォン専業銀行。金融にまつわる煩わしさを排除し、ゼロベースでこれからの銀行に求められる機能を開発・提供していくと打ち出しています。そんな同行の大きな技術的トピックの 1 つが、勘定系システムにパブリッククラウドを採用したこと。これはもちろん国内初*の試みです。ここではサービス開始後の手応えをシステム構築をリードしてきた皆さんにお伺いしました。 利用している Google Cloud ソリューション： Google Cloud Databases、Stream Analytics 利用している Google Cloud
【ZOZOTOWNマイクロサービス化】API Gatewayの可用性を高めるノウハウを惜しみなく大公開 - ZOZO TECH BLOG
はじめに こんにちは。ECプラットフォーム部のAPI基盤チームに所属している籏野 @gold_kou と申します。普段は、GoでAPI GatewayやID基盤（認証マイクロサービス）の開発をしています。 先日、【ZOZOTOWNマイクロサービス化】API Gatewayを自社開発したノウハウ大公開！ を公開したところ、多くの方からご好評いただきました。ありがとうございます。まだ読まれていない方はぜひご覧ください。 techblog.zozo.com 今回はその記事の続きです。API Gatewayは単にリバースプロキシの役割を担うだけでなく、ZOZOTOWN全体の可用性を高める仕組みを用意しています。本記事では、それらの中でカナリアリリース機能・リトライ機能・タイムアウト機能に関して実装レベルの紹介をします。 マイクロサービスに興味ある方や、API Gatewayを自社開発する方の参考に
[初級編] なぜ「AWS で負荷分散は３AZ にまたがるのがベストプラクティス」と言われるのか 可用性の面から考えてみた | DevelopersIO
水平分散のアーキテクチャを考えるときに、「負荷分散装置の下に並べる分散先 (サーバ) は３台以上がよい」「AWS であれば３ AZ にまたがるとよい」とはよく聞かれます。それがどういう意味をもつのか、主に可用性の面から考えてみました。 みなさん、AWS使ってますか！（挨拶 AWSに限らず、ある程度の規模の何かしらの本番システムを組もうというときに、こういう言葉を聞いたことはないでしょうか。 「負荷分散装置の下に並べる分散先 (サーバ) は３台以上がよい」 「AWS であれば３アベイラビリティゾーン (AZ) にまたがるとよい」 負荷分散装置（ロードバランサー）は負荷を分散するのがお仕事です。分散するだけなら 2 台でもよさそうですよね？ AWS の３ AZ に至っては、そもそも AZ 単位の障害なんてそうそうないし、あったとしてももう片方の AZ が生きていればなんとかなりそうに思えます。
![[初級編] なぜ「AWS で負荷分散は３AZ にまたがるのがベストプラクティス」と言われるのか 可用性の面から考えてみた | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/876809e40a16193d45c580a01a3f67fc9a50a044/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F05%2Felastic-load-balancing.png)
クレジットカード決済システムの可用性向上とそれに伴うサービス共通利用規約の改定について - pixiv inside
こんにちは、CTOのharukasanです。私が担当しているファイナンシャルサービス本部ではピクシブが運営している各サービス(pixiv、BOOTH、pixivFACTORY、pixivFANBOX、pixivコミック、Pastelaなどなど)においてご利用頂く、決済・送金といったお金のやりとりに関するシステムの構築・運用を行っています。 ピクシブでは決済に関する手続きを変更することを目的に、2024年8月1日にサービス共通利用規約の改定をします。この記事では今回の規約改定を行う理由である、クレジットカード決済システムの可用性向上のために行うクレジットカード決済の転送サービス導入について、クレジットカード決済の仕組みも踏まえてご説明します。 ピクシブのサービスにおけるカード決済の仕組み ピクシブでクレジットカード決済を使った場合のお金の流れを簡単に図示してみました。実際にはもうちょっと複雑
Amazon RDS MySQL/PostgreSQLのトランザクション性能が2倍に、可用性とスケーラビリティも高める新「マルチAZ配置オプション」登場
Amazon RDS MySQL/PostgreSQLのトランザクション性能が2倍に、可用性とスケーラビリティも高める新「マルチAZ配置オプション」登場 Amazon Web Servicesは、Amazon RDSのトランザクションの処理速度を最大で2倍にし、3台のクラスタ構成で可用性を高め、リードのスケーラビリティも向上する、新たな「Multi-AZ Deployment Option」（マルチAZ配置オプション）を発表しました。 New AWS News post by @sebsto: New Amazon RDS for MySQL & PostgreSQL Multi-AZ Deployment Option: Improved Write Performance & Faster Failoverhttps://t.co/sffr5boYlU — AWS Blogs (@AW
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog みなさん、こんにちは！ ヤフーでデータベースエンジニアをしている松浦です。 以前、不揮発性メモリに最適化したMySQLのストレージエンジン開発についてのブログ記事を執筆いたしました。 今回のブログ記事は、その続報です。不揮発性メモリ上のデータベースにおける、高可用性構成やその監視・運用に関わる研究開発成果をご紹介します。 前回記事の振り返り さて、本題に入る前に、まずは、前回のブログ記事の簡単な振り返りをさせてください。 前回のブログ記事では、DRAMのようにバイト単位でアクセスが可能だが、DRAMとは異なり、サーバの電源遮断後もデータが残り続け、また、NVMe SSDよりも高速な記憶デバイスである「不揮発性メモリ」の紹介をしまし
数値上はこうなるものの、意図的な短期的メンテナンスや、意図しない障害でも１回あたりの期間が短ければ、その期間に積まれるはずだった売上は、その復帰後に売り上がる場合も多いでしょう。その辺りは、ユーザーの信頼を損なわない方法や運用を心がけることで、十分に埋められる可能性を含む性質です。 しかしこれが、あまりに高頻度であったり長期間になると、その復帰後に停止期間分を含めた売り上げにならず、そのまま機会損失となる可能性が高まります。いわゆるユーザー離れというやつです。その損失だけで済めばまだマシで、普通に考えればその後に想定していた売上も減少し続け、元に戻すには相応の時間と労力を伴うでしょうから、数値以上の痛手となるはずです。 こう考えていくと、運用関係者が健全であれば、無理に100％の可用性を目指さず少なくとも合計99％以上となる停止猶予を持たせた運用とし、数日を跨ぐような連続した長期間の停止だ
可用性や安全性を高めつつ、ソフトウェアをシンプルにすることは不可能だ。カオスエンジニアリングから継続的検証へ（中編）。JaSST'23 Tokyo基調講演
可用性や安全性を高めつつ、ソフトウェアをシンプルにすることは不可能だ。カオスエンジニアリングから継続的検証へ（中編）。JaSST'23 Tokyo基調講演 Netflixが始めた「カオスエンジニアリング」は、現在では大規模なシステムにおける可用性向上の手法のひとつとして確立し、広く知られるようになりました。 そのカオスエンジニアリングという手法を定義したのが、元Netflixカオスエンジニアリングチームのエンジニアリングマネージャーを務めていたCasey Rosenthal（ケイシー ローゼンタール）氏です。 そのローゼンタール氏が、ソフトウェアのテストに関わる国内最大のイベント「ソフトウェアテストシンポジウム 2023 東京」（JaSST'23 Tokyo）の基調講演に登壇し、「Chaos Engineering to Continuous Verification」（カオスエンジニアリ
カオスエンジニアリングを導入したクックパッドの挑戦 マイクロサービス化に伴う可用性の低下に対応 - エンジニアHub｜Webエンジニアのキャリアを考える！
カオスエンジニアリングを導入したクックパッドの挑戦 マイクロサービス化に伴う可用性の低下に対応 料理のレシピ投稿・検索サービスのクックパッドでは2年前からカオスエンジニアリングに取り組み、さまざまな事例やノウハウを蓄積しています。クックパッドの技術部・SR（Site Reliability）グループの小杉山拓弥さんとDX（Developer Productivity）グループの鈴木康平さんに、導入の理由やさまざまな知見を伺いました。 カオスエンジニアリング（Chaos Engineering）とは、稼働中のサービスにあえて擬似的な障害を発生させることで、システムの耐障害性を検証する手法です。動画配信サービスを提供するNetflix社が2011年ごろから実践し、ソフトウェアや情報を積極的に公開したことで世界中から注目されるようになりました。 国内ではまだ導入事例も少ないなか、料理のレシピ投稿
低コストで高可用性を実現する
自社製品の SaaS をリリースしたのですが、自分の中でのテーマは「低コスト高可用性を実現する」でした。設計に入る前にいろいろ検証して、なんとか自分がやりたかったことができたので雑に書いてみます。雑に読んでください。 低コスト単純に「低価格でサービスを提供したいから」です。維持や運用コストが高くなればなるほどサービスの価格も高くなります。 サービス自体の低コストを実現すれば、価格面での競争力を得ます。もともとの自社パッケージ製品は機能や性能、可用性では負ける要素はないので、勝負は価格面という認識し、そこをどう実現するかを設計の第一としました。 少人数関わる人間が増えれば増えるほど人件費も増え、さらにサービスの価格は高くなります。 そのため、今回はとにかく少人数で開発、運用できることを目標にしました。目指すのはサーバーが 100 台規模になったとしても片手で足りる人数でなんとかなるサービスで
TIGの伊藤真彦です。 最近会社のPodCastであるFuture Tech Castに出演させていただきました。聞いていただけると嬉しいです。 先日クラウドサービスの障害について社内で体系的に説明する機会があり、0から全体的なイメージがつかめるような情報を整理してみました。 まえがき、良質なクラウドサービスWebサービス、ITソリューションが自前のサーバーではなくクラウドサービスを利用して構築されるようになって久しいですが…と語っていきたい所ですが、私がITの世界に足を踏み入れた時には、既にAWSを使う事が当たり前の時代になっていました、世の中の変遷を語るだけの含蓄を私は持っていません。 私のようにIT技術に触れた瞬間からクラウドサービスが存在していた世代が産まれる程度に長い時間をかけ、AWS、GCP、Azure各種クラウドサービスは業界に浸透し、使いこなすためのノウハウは一朝一夕では身
※この投稿は米国時間 2020 年 7 月 16 日に、Google Cloud blog に投稿されたものの抄訳です。 多くの組織が Google Kubernetes Engine（GKE）環境などのシステムの稼働を継続するために、さまざまなリスク管理とリスク軽減の戦略を採用しています。こうした戦略は、予測可能なシステム停止時でも予測不可能なシステム停止時でもビジネスの継続性を確保するものです。特に、パンデミックによるビジネスへの影響を抑制するために取り組んでいる現在こそ重要です。 この 2 回にわたるブログ投稿の最初の記事では、可用性の高い GKE クラスタを、いわゆる Day 0 の段階で設定する方法についての推奨事項とベスト プラクティスをご紹介します。そして 2 回目の投稿では、クラスタを稼働させた後の、Day 2 の高可用性のベスト プラクティスについて説明します。 GKE
マルチAZ DBクラスター、RDS(MySQL,Postgres)の新しい高可用性オプションを試してみた | DevelopersIO
AWSチームのすずきです。 Amazon RDS でプレビューリリースされたマルチAZ DBクラスター (3−AZ DBクラスター)、 3つのアベイアビリティゾーン(AZ)に3つのインスタンスを配置、1台のライターと、2台のリーダーの構成を試す機会がありましたので、紹介させていただきます。 Readable standby instances in Amazon RDS Multi-AZ deployments: A new high availability option マルチAZ DBクラスターの作成 リージョン マルチAZ DBクラスターをサポートするオレゴン(us-west-2)を利用しました。 DBエンジン MySQL バージョン 8.0.26、PostgreSQL バージョン 13.4 が マルチ AZ DB クラスターをサポートします。 今回は MySQL 8.0.26 を
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
不揮発性メモリに最適化したMySQLの高可用性構成
ITシステムの可用性と損失を考える | 外道父の匠
AWSクラウドの耐障害性、可用性を高めるための前提知識 | フューチャー技術ブログ
GKE のベスト プラクティス: 高可用性クラスタの設計と構築 | Google Cloud 公式ブログ