マイクロサービスアーキテクチャにおけるオーケストレーションとコレオグラフィ - Qiita
マイクロサービスアーキテクチャの4章にオーケストレーションとコレオグラフィという話があります。 マイクロサービスを使ってアプリケーションを組み立てる側の、サービスの呼び出し方の違いです。 「マイクロサービス的に作ってるよー」というシステムでも、ここに特に疑問を持たず、ふつうにWeb APIたちを呼び、受け取ったデータでHTMLをレンダリングするというオーケストレーション方式で作られているのが多いのではないでしょうか? Sam Newmanは、それだと呼び出されるサービス側がドメインモデル貧血症になりがちで、呼び出す側にロジックが集まっていくことになると、書籍の中で述べています。 いったいどういうことでしょうか? 書籍中の例をちょっと変えて考えてみます。 マイクロサービスアーキテクチャでECサイトを作る(オーケストレーション編) ECサイトをマイクロサービスアーキテクチャで作ることを考えてみ
ウェブアプリケーション開発に新言語を採用したときにインフラで考えたこと - ゆううきブログ
この文章は、サーバサイドのウェブアプリケーション開発において、社内実績の少ない新しい言語を採用したときにインフラ面で考慮したことを社内向けにまとめたものです。 はてなでは、長らくPerlでウェブアプリケーション開発を続けてきた一方、ここ数年で社内でScalaまたはGoの採用事例も増えてきました。 今後開発が始まるプロダクトにおいても、Perl、Scala、Goもしくは他の言語を採用するかどうかを開発開始時に選ぶことになるでしょう。 新言語を採用するときに、考慮すべきことの一つとして、「インフラ」への影響があります。 新言語に関する雑談をしていると、ウェブアプリケーションエンジニアに「インフラ」への影響について聞かれます。 もしくは、ウェブオペレーションエンジニアから考慮するポイントを伝えることもあります。 ScalaやGo以外に、Node.jsやサーバサイドSwiftはどうかというのも雑談
AWSスポットインスタンスの真髄
Gedow style how to use aws spot instance.Read less
2015年Webサーバアーキテクチャ序論 - ゆううきブログ
2023年03月31日追記：この記事を基に、@sadnessOjisanさんより、コードレベルにより踏み込んだ、かつ、グリーンスレッドベースの新しいWebサーバアーキテクチャも含めて整理された記事 Webサーバーアーキテクチャ進化論2023 | blog.ojisan.io が公開されました。 主に新卒のWebエンジニア向けに、古典的なWebサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介します。 この辺りの話題がWeb界隈で流行っていたのは数年以上前というイメージですが、Webサービスは相変わらずWebサーバの上で動いているので、流行り廃り関係なく学ぶべき内容だと思っています。 また、HTTP/2がいよいよRFC化し、既にh2oやtrusterdなどのHTTP/2のサーバ実装があり、今後Webサーバアーキテクチャを再訪することが増えるような気がしています。 ところが、We
Game BaaS Implemented in Ruby
2015年2月9日第四回DeNAゲーム開発勉強会資料 ※当日頂いたQ&Aを追加しました（2015/2/10） Read less
シンプルなVPC設計を考える - Around the World
この記事はAWS Advent Calendar 2014の24日目の記事です。メリークリスマス！ 今日は、最近イチから構成を考える機会があったVPCの設計について、その一部を晒してみたいと思います。 前提 以前からAWSは運用していましたが、今後複数アカウントが乱立したり、利用する人がより増えることが想定されたため、以下のような要件を前提に見直しました。 Web/Appサーバとデータベースで構成されるWebサービスがメイン 複数アカウントで汎用的に利用できること なるべくNWレベルの意識をしなくても良いこと 運用の発生する部分を減らすこと シンプルでわかりやすいこと 基本構成 Functional Firewallパターンをベースにしました。Functional Firewallパターンは、各レイヤーのセキュリティルールをグループ化して適用することで煩雑になりにくく、シンプルに管理するこ
トレタのシステムアーキテクチャと恵比寿のメシと酒 : TORETA（トレタ） ブログ
ちわす。11月にサーバサイドエンジニアとしてジョインした佐野です。前職ではウェブサービスやソーシャルゲームのサーバ管理、DBA、運用ツール開発など主にインフラ面を担当していました。入社一ヶ月のペーペーでございます。 「ブログ書けやー」とのお達しが出たのですが、ノリがイマイチわからんので、軽い記事(恵比寿のメシと酒)と真面目な記事(トレタのシステム)を両方書きます。真面目な話の合間にメシの話でもしながら...。真面目な記事はエンジニア職向けの内容になります。 ではよろしくお願いします。 トレタのシステムは種々のクラウドサービスで成り立っています。この一ヶ月で僕がシステムに手を加えた部分としては、監視周りの整備(Pingdom, PagerDuty導入, 監視用hubotを書く)、ログ解析基盤の構築(fluentd -> BigQuery連携)、ちょっとした負荷分散(リバースプロキシを少々)を
監視アーキテクチャ(Sensu,Pingdom,Mackerel,StatusPage.io,PagerDuty)についてまとめてみる(2014年12月版) - Glide Note
Sensu Advent Calendarに便乗して、Kaizen Platform, Inc.の2014年12月現在の監視アーキテクチャの話をちょっとしてみようと思う。 モニタリング領域 サービスを監視している領域 Pingdom Pingdom - Website Monitoring 外部ネットワークからのサービスの死活監視。アメリカ、ヨーロッパ、アジアなどの拠点からサービスの死活監視が出来るため、特定の地域からアクセス出来ない場合なのが検知出来る。 後述するstatuspage.ioとの連携で、障害を検知すると、サービスのステータス状況が自動で変わるようになっている Sensu Sensu | The open source monitoring framework. 監視フレームワーク サーバを内部ネットワークから監視するために利用 サーバのプロセス監視、サーバ間の疎通監視、エラ
クラウド環境の設計指針をどう決めるか - たごもりすメモ
クラウドに限らず、データセンタの設計全般に言えることだけど。 コンピューティング基盤をどのように設計するかには根本から異なるアーキテクチャが様々あって、ある特定の方向のアーキテクチャについても実現するためのソフトウェアやハードウェアに様々なものがある。 合議制で決めてはいけない。何を採用するか、どのように設計するかについては、誰かが英知をもって決断するべきだ。それも可能な限り素早く。 今更言うまでもないことだが、この世界は技術の変化が非常に速い。おそらく3年経てば優位な技術は入れ替わっていて、何か新しいトレンドとか技術要素だとかいったものが登場しているだろう。 そんな中で何を採用するかについて、長い時間をかけるのは簡単だ。3年かけて実機を多数揃えて比較検討すれば、検討開始からの3年間で何が優位だったかが確実にわかるだろう。 おそらくその頃には別の技術が登場し、更に3年の比較検討が必要になっ
Twitterのキャッシュを支えるRedis - ワザノバ | wazanova
https://www.youtube.com/watch?v=rP9EKvWt0zo 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 TwitterのYao Yuが、大規模サービスのキャッシュにおいてRedisを活用する取組みについて紹介しています。 1) Redisを採用している理由 キャッシュだけで、ストレージとしては利用していない。 主なところでは、Twitterのタイムラインで利用している。ホーム画面であれ、ユーザ画面であれ、タイムラインはTweetのインデックスなので、key/valueストア型のRedisを利用するケースとして最適。 以前はmemcachedを使っていたが、問題になったのは、タイムラインでおきるread/writeは、（ユーザが閲覧している範囲に追加反映するということなの
AWSにおける静的コンテンツ配信パターンカタログ（アンチパターン含む） | DevelopersIO
独自ドメインSSLだとCloudFront使えないから横綱無理だよねー、という話がありました。うん、確かにそうでした、執筆時点では…！ 本日2013/06/12、CloudFrontの独自ドメインSSL対応が発表（英語・日本語）されましたので、みなさん揃って横綱になればいいと思います。 よく訓練されたアップル信者、都元です。AWSを利用して構築した環境から、クライアント（モバイルやブラウザ等）に対してHTTPを使って静的なコンテンツを配信したいケースって、多いですよね。多いというか、むしろどんなシステムにも多かれ少なかれ、静的なコンテンツ配信があると思います。 スケーラビリティ・柔軟性・可用性・パフォーマンス・コスト 静的なコンテンツというのは、コンテンツをリクエストに応じて生成したりせず、完成品としてのファイルが手元にある状態です。例えば、多くのWebシステムにおいて、ほとんどの画像やJ
AWS-CloudDesignPattern CDP2.0候補
AWSクラウドデザインパターンとは？ AWSクラウドデザインパターン (AWS Cloud Design Pattern, 略してCDPと呼ぶ)とは、AWSクラウドを使ったシステムアーキテクチャ設計を行う際に発生する、典型的な問題とそれに対する解決策・設計方法を、分かりやすく分類して、ノウハウとして利用できるように整理したものである。 これまで多くのクラウドアーキテクト達が発見してきた、もしくは編み出しきた設計・運用のノウハウのうち、クラウド上で利用が可能なものをクラウドデザインのパターンという形式で一覧化し、暗黙知から形式知に変換したものであるといえる。 パターンの中には、クラウドでなくても実現できるもの、今まででも実現されていたものも含まれているが、クラウド上でも今まで通りのアーキテクチャが実現でき、かつクラウドを利用する事で、より安価にそしてより容易に実現できるものは、CDPとして収
Evernote サービスのアーキテクチャ概要 | Evernote
まずは、Evernote サービスを実現している、システムの物理的構成に関して、その概要を解説します。構成図の左上から始めましょう。 ネットワーク Evernoteとやり取りされるトラフィックは実質的にほぼすべて、HTTPS 443番ポートを通じてwww.evernote.comに届きます。これにはすべての「Web」関連の通信が含まれますが、それに加えてThriftベースのサービス APIを通じた、全てのクライアントとの同期通信も含まれます。これらすべてを合わせると、一日に最高1億5000万回のHTTPSリクエスト、トラフィックはピーク時で250 Mbps程度になります。（このピークはだいたい太平洋標準時間の午前6:30ごろ訪れるのですが、夜行性の Evernote 運用チームにとってはあいにくの時間です。） Evernote では Border Gateway Protocol(BGP)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
BrainWarsのアーキテクチャ（OpsWorks & DynamoDB編）
1000万DL突破！BrainWarsのアーキテクチャ
AWS クックパッドの運用事例
WebサービスStartUP向け AWSスケーラブルな構成例