なぜMicroservicesか?
現職においてMonolithアーキテクチャからMicroservicesアーキテクチャへの移行とその基盤の構築に関わって2年近くが経った．未だ道半ばであるがこれまでの経験や日々のインプットをもとにいろいろ書いておこうという気持ちになった．本記事ではそもそもMicroservicesアーキテクチャとは何かを整理し，なぜやるべきか?・なぜ避けるべきかを整理する． Microservices? Microservicesアーキテクチャとは「Single purpose，High cohesion，そしてLoosly Couploedなサービスを組み合わせてシステムを構築する」アーキテクチャ手法である．それぞれの原則をまとめると以下のようになる． Single purpose: 一つのことに集中しておりそれをうまくやること Loose coupling: サービスは依存するサービスについて最小限の
冗長化の難しさとNetflixの答え｜こんぴゅ
この世には、ダウンすることが許されないシステムが存在する。金融機関の基幹系、原子力発電所や鉄道の制御システム、流通業の物流管理システムなどはもちろんであるが、最近ではtoCのサービスでもダウンタイムが長くなると大事件として騒がれ、ヤフトピに載ってしまったりする。 ではダウンへの対策はどうするかというと、いくつか手法はあるのだけど代表的なのは「冗長化」である。簡単に言うと、全く同じシステムを裏側に待機系として用意して、有事の際は自動的に切り替わるようにしておくのである。素朴だが、殆どのシステムではこの種の仕組みを用意している。 それでうまくいけばいいのだけどじつは、この待機系への切り替えというのは鬼門であり、高確率で失敗する事になる。 ［続報］東証のシステム障害、原因はハードウエア故障後の切り替えミス http://itpro.nikkeibp.co.jp/article/NEWS/2012
クラウドのリージョンを丸ごと落とす過酷な試験を実現する「Chaos Kong」、Netflixが発表。「カオスエンジニアリング」の指針も表明
クラウドのリージョンを丸ごと落とす過酷な試験を実現する「Chaos Kong」、Netflixが発表。「カオスエンジニアリング」の指針も表明 動画配信サービスのNetflixが、Amazonクラウド上のサーバをランダムに落とすことでシステムの堅牢性をチェックするという画期的な考え方のツール「Chaos Monkey」を発表したのは2012年でした。 サービス障害を起こさないために、障害を起こし続ける。逆転の発想のツールChaos Monkeyを、Netflixがオープンソースで公開 Netflixは普段からChaos Monekeyでシステムをテストし続けていたおかげで、昨年10月にAmazon EC2の全インスタンスの約10％がリブートされるという大規模メンテナンスも難なく乗り切ることができたと報告しています。 そしてこのChaos Monkeyの成功に基づき、さらに過酷な状況をシミュレ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
