みずほ、基幹システムを東阪に分散へ 障害復旧は完了 - 日本経済新聞みずほフィナンシャルグループは2022年度以降、みずほ銀行の基幹システムのデータセンターを東阪に分散する方針だ。現在は東京・多摩にあるメインのデータセンターと、千葉県内の災害対策拠点の2カ所だった。多摩拠点は8月のシステム障害で一部が使えなくなっていたが、15日までに復旧を終えた。今後、災害対策拠点を地理的に離れた関西圏に移して備えを強める。22年度までに大阪府内に設備を整え、翌年度から機器を
AWS での Apache Kafka の実行のためのベストプラクティス | Amazon Web Services
Amazon Web Services ブログ AWS での Apache Kafka の実行のためのベストプラクティス この記事は Intuit とのパートナーシップに基づいて書かれ、AWS で Apache Kafka クラスタを実行するための学習、ベストプラクティス、推奨事項を共有するものです。Intuit の Vaishak Suresh と同氏の同僚の方々の貢献とサポートに感謝いたします。 Intuit の概要: Intuitは、AWS のエンタープライズ顧客のリーダーであり、ビジネスと財務管理ソリューションのクリエーターです。Intuit の AWS とのパートナーシップに関する詳細については、以前のブログ記事 Real-time Stream Processing Using Apache Spark Streaming and Apache Kafka on AWSを参照し
Apache ZooKeeper - Wikipedia
Apache ZooKeeper（アパッチ ズーキーパー）は Apacheソフトウェア財団のオープンソースプロジェクトで、大規模分散システムでよく利用される、設定情報の集中管理や名前付けなどのサービスを提供するソフトウェアである。最初はHadoopのサブプロジェクトの一つであったが、現在はトップレベルプロジェクトの一つになっている。 ZooKeeperのアーキテクチャでは、高可用性を冗長サービスにより提供している。つまり、クライアントはあるZooKeeperノードへの問い合わせが失敗したら、他のノードに問い合わせることができる。 データの更新は一つのマスターノードだけが行うようになっているので、データがノード間で矛盾した内容になることはない（ただし、最新のデータでない可能性はある）。 更新を担当するマスターノードが何らかの理由で停止した場合には、各ノード間でリーダー選出を行い、新たな更新ノ
Ceph - Wikipedia
コンピューター科学の分野において、Ceph（[ˈsɛf]または[ˈkɛf]と発音する）は、単一の分散コンピュータ・クラスター上でオブジェクトストレージを実装したフリーソフトウェアのストレージプラットフォームである。オブジェクト、ブロック、ファイルレベルのストレージインタフェースを提供し、単一障害点がなく、エクサバイトレベルまで拡張可能な、フリーで利用できる完全な分散オペレーションを主な目的としている。 Cephは、特別なハードウェアサポートを必要としない汎用ハードウェア（英語版）を使用して、データを複製することで耐障害性を持たせている[7]。管理時間やその他のコストを最小にすることを目指す設計の結果として、Cephのシステムは、自己修復機能と自己管理機能（英語版）の両方を備える。 2016年4月21日、Cephの開発チームは、CephFSが安定したと思われる最初のバージョンである「Jewe
無限ストレージ
以下イベントの発表資料です https://kernelvm.connpass.com/event/209105/
CSE 138: Distributed Systems
From the beginning of this year, I started to take lecture courses of undergrad distributed systems course at UC Santa Cruz (CSE 138) by Lindsey Kuper. It consists of 23 lectures (you can see the schedule of topics from here) and recently I’ve finished all of them. I’m not a student at UCSC but due to the COVID-19 situation, all these lectures were delivered online and are available on YouTube. So
Apache Hive 紹介
Hadoop/Spark で Amazon S3 を徹底的に使いこなすワザ / Hadoop / Spark Conference Japan 2019 講演者： 関山 宜孝 （Amazon Web Services Japan） 昨今 Hadoop/Spark エコシステムで広く使われているクラウドストレージ。本講演では Amazon S3 を例に、Hadoop/Spark から見た S3 の動作や HDFS と S3 の使い分けをご説明します。また、AWS サポートに寄せられた多くのお問い合わせから得られた知見をもとに、Hadoop/Spark で S3 を最大限活用するベストプラクティス、パフォーマンスチューニング、よくあるハマりどころ、トラブルシューティング方法などをご紹介します。併せて、Hadoop/Spark に関係する S3 のサービスアップデート、S3 関連の Hadoop
EC2のプレイスメントグループを活用するとネットワークパフォーマンスを向上したりハードウェア障害を軽減できます | DevelopersIO
Amazon EC2にはプレイスメントグループと言う概念があり、ネットワークパフォーマンスの向上や物理サーバ障害時の影響範囲を限定させるために、インスタンスをグループ化することができます。 今回は、3種類あるプレイスメントグループ戦略について、説明します。 3種類の戦略 プレイスメントグループにはクラスター・分散・パーティションの3種類の戦略があります。 クラスター(cluster) ※ 図は公式ドキュメントから HPC のようなワークロード向け インスタンス群を高バイセクションバンド幅セグメントに配置 ノード間通信で低レイテンシー、高スループットなネットワークパフォーマンスを実現 利用可能なインスタンスタイプに制限あり(対応インスタンス一覧)。例えば、T系インスタンスは利用不可。 AWS ParallelClusterを利用してHPCクラスターを構築している場合、設定ファイルで次の様に指
プレイスメントグループ - Amazon Elastic Compute Cloud
ワークロードのニーズを対応するために、相互に依存する EC2 インスタンスのグループをプレイスメントグループ内に作成して、そのプレイスメントに影響を与えることができます。 ワークロードのタイプに応じて、以下のいずれかのプレイスメント戦略によりプレイスメントグループを作成できます。 [クラスター] – アベイラビリティーゾーン内でインスタンスをまとめます。この戦略により、ワークロードは、ハイパフォーマンスコンピューティング (HPC) アプリケーションで典型的な緊密に組み合わされたノード間通信に必要な低レイテンシーネットワークパフォーマンスを実現できます。 パーティション – インスタンスを複数の論理パーティションに分散させ、1 つのパーティション内のインスタンスのグループが基盤となるハードウェアを別のパーティション内のインスタンスのグループと共有しないようにします。この戦略は、Hadoop
理解して拡げる分散システムの基礎知識
20200725の #JTF2020 セッションスライド。 （資料内で説明した資料へのリンク） ・昨年のJTF発表資料 https://speakerdeck.com/tzkoba/cloud-nativekai-fa-zhe-falsetamefalsedatabase-with-kubernetes ・「2020年のNewSQL」 https://qiita.com/tzkoba/items/5316c6eac66510233115 ・「NewSQLのコンポーネント詳解」 https://qiita.com/tzkoba/items/3e875e5a6ccd99af332f ・Saga https://www.infoq.com/jp/news/2018/03/data-consistency-microservices/ ・「マイクロサービスとは分散システムである」 https://
PayPayの1秒あたり1000決済への道のり
パフォーマンス・チューニングに関するブログの第１回目です PayPayは、日本でもっともよく知られているQR決済サービスとなりました。2018年10月5日のローンチ後、2018年12月より実施した100億円あげちゃうキャンペーンは、その後のプロダクトの急成長に合わせたシステムのスケール拡張という長い道のりのスタート地点でもありました。 ここ数ヶ月の新規ユーザーの増え方[1]を見るにつけても、PayPayが驚異的な成長を続けていることは間違いありません。スタートアップ企業はまるで竹のように成長するとはこのことではないでしょうか。（竹は24時間で最大約90cmも伸びるそうです） PayPayの成長速度は？ ユーザー数の伸び 2018年10月に初めてユーザーが増え、キャンペーンや日々メディアで報道されることによるユーザー数の増加もあり、1年後には1500万人を突破しました。2020年5月現在、サ
Amazon MSK - Amazon Web Services (AWS)
Amazon Managed Streaming for Apache Kafka フルマネージド型で可用性が高い Apache Kafka サービスでデータを安全にストリーミングする
Database Internals
Have you ever wanted to learn more about Databases but did not know where to start? This is a book just for you. We can treat databases and other infrastructure components as black boxes, but it doesn’t have to be that way. Sometimes we have to take a closer look at what’s going on because of performance issues. Sometimes databases misbehave, and we need to find out what exactly is going on. Some
形式手法による分散システムの検証 - builderscon tokyo 2019
Abstract 本セッションでは、形式手法 (formal methods) を用いた分散システムの設計および実装について解説します。形式手法は、数学的な表現を用いて対象となるシステムを定式化することにより、システムの挙動の「正しさ」を厳密に保証するための方法論です。受講対象は予備知識を持たない初心者を想定しており、具体例を通して形式手法の基本的なアイデアを知ることを目標とします。 分散システムのメリットとデメリット 近年、複数のコンポーネントが非同期的に連携して動作する分散システムは決して珍しいものではなくなりました。正しく設計された分散システムは、集中システムとは比較にならないフレキシビリティとスケーラビリティを発揮します。人気 OSS の中にも分散型の設計を取るものは多数見られ、一昔前のように一部の専門家だけに任せておくだけでなく、すべてのエンジニアにとって一種の基礎教養になってい
複雑なゲームサービス基盤の刷新でgumiが直面した壁――マイクロサービス化実現の鍵とは？【デブサミ関西2017】
2007年に設立され、世界各国でソーシャルゲームを開発、提供しているgumi。同社ではゲームに必要な「認証」「課金」などの機能を、モノリシックな設計からマイクロサービスに移行し、基盤を新しく設計している。マイクロサービス化するメリットとしては、疎結合であるため、適した技術を選択できることや再利用しやすいこと、障害を限定的にできること、置き換えしやすいこと、少人数で開発でき、品質が良くなることなどが挙げられる。しかし、デメリットもある。gumiではマイクロサービス化するにあたり、数々の地雷を踏んできたという。マイクロサービス化する際の落とし穴とは？ また気をつけるべきポイントなどについて、株式会社gumi CTOの幾田雅仁氏が解説を行った。 株式会社gumi CTO 幾田雅仁氏 講演資料：gumiのゲームを支えるアーキテクチャ設計思想～モノリシックからマイクロサービスへの変遷 gumiがマイ
マイクロサービスにおける決済トランザクション管理 | メルカリエンジニアリング
この記事はMERPAY TECH OPENNESS MONTHの15日目の記事です。 こんにちは。メルペイのPayment PlatformチームでPaymentServiceの開発を担当するエンジニアの @foghost です。 メルペイではマイクロサービスのアーキテクチャで決済システムを開発しています。その中でPaymentServiceは決済トランザクション管理の基盤サービスとして、下位層のサービス（外部サービスも含め）が提供する各種決済手段を利用して、上位層のサービス（メルカリ、NFC，コード払いなど）に必要な決済フローを共通APIとして提供しています。PaymentServiceが提供する決済処理に複数のサービスを跨いでお金の動きを正確に管理する必要があるので、作り始めた頃から決済トランザクション管理を最も重要な課題として、サービスを跨いでもデータの整合性が取れる仕組みを作ってき
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWSが落ちてもGCPに逃がすことで落ちないシステムを作る技術
Identity at Ignite: Strengthen resilience with identity innovations in Azure AD
Computation offloading - Wikipedia
Consensus_Demo.thy