【毎月更新・日本の AWS エンジニアがクラウド解説】 初心者向け解説、最新のクラウドネイティブな開発手法・利用シーン別ハンズオンを学ぶ »
はじめに マーティンファウラーがmicroservicesの記事で、小さな役割をもったサービス群にアプリケーションを分割することを提案しています。 cookpadが、サービスをマイクロサービス群に分割していることの記事が注目を浴びており、最近急速にバズワード化しているように感じます。 バズワード化して、ポイントが損なわれる前にいくつかの注意点をまとめておきます。 1.インフラコストは基本的に増大する microservicesは、今まで単一のアプリケーションコードで行われていたことを複数のサービスサーバーに分割して管理・運営していくことです。ですので、プロセスを跨いだ通信が大量に発生します。その結果、サーバー台数は増大します。 つまり、インフラコストの増大と開発速度の高速化のコスト感覚をバランスして判断していく必要があります。疎結合性が高まり、アーキテクチャとしては美しく感じますが、実施に
LINEのインフラプラットフォームの裏側 スケーラビリティを確保しつつ運用コストを小さくするためにやったこと LINEのインフラプラットフォームはどのように大規模サービスをスケールさせ運用コストの小さなインフラを提供しているのか 2018年11月21日、LINE株式会社が主催するエンジニア向け技術カンファレンス「LINE DEVELOPER DAY 2018」が開催されました。4度目の開催となる今回のテーマは「Next LINE」。メッセージアプリだけでなく、さまざまなサービスの開発や新たな技術領域への投資を行っているLINEが目指すビジョンについて、エンジニアたちの技術的知見や挑戦を通して紹介します。プレゼンテーション「LINEのインフラプラットフォームはどのように大規模サービスをスケールさせ運用コストの小さなインフラを提供しているのか」に登場したのは、インフラプラットフォーム室の三枝慶
依存がなく、テスト可能であり、クリーン。 Uncle Bobのクリーンアーキテクチャの概念を読んだので、これを私はGoで実装してみたいと思います。このアーキテクチャは、自分たちの会社である Kurio – App Berita Indonesia で使っていたものに似ていますが、少し違っています。大きな違いはなく、概念は一緒なのですが、フォルダ構造が違っています。 サンプルのプロジェクトとして、記事をCRUDで管理するリポジトリを https://github.com/bxcodec/go-clean-arch にpushしてあります。 * 免責条項 ここで使われているどのライブラリあるいはフレームワークも、利用を特別推奨しているものではありませんので、ご自身あるいはサードパーティによる同じ機能のものと入れ替えることが可能です。 基本的な考え方 ご存知のように、クリーンアーキテクチャで設計
こんにちは。「Neco」の @ueokande です。 サイボウズでは、cybozu.comのアーキテクチャ刷新プロジェクト「Neco」を実施してます。 その思いについては以下の記事からどうぞ。 アーキテクチャ刷新プロジェクト「Neco」の紹介 運用本部長を退任して Neco プロジェクトに専念します 今回は、Necoにおけるネットワーク設計についてお話します。 ネットワークの方針 ネットワークの耐障害性は必須の条件です。 Necoでも同様で、ネットワーク機材の単一障害点が無いネットワーク構成にする必要があります。 具体的には以下のような要件です。 ホストマシンのNICを二重化して、片方のNICが故障しても通信が行えること ネットワークスイッチを冗長化して、スイッチが故障してもスイッチ下のホストが停止しないこと スイッチを冗長化する方法は、以下のような選択肢があります。 STP (Span
License: CC-BY-SA 3.0 © Zalando SE 2020 & CC-BY-SA 3.0 © kawasima 2020 Zalandoのソフトウェアアーキテクチャは、疎結合なマイクロサービスを中心としており、 それらはJSONペイロードをもつRESTful API群によって、機能が提供されています。 小さなエンジニアのチームは、自分たちでAWSアカウントにこれらのマイクロサービスを デプロイしたり運用したりしています。 私たちのAPIは、その多くが私たちのシステムが何をするのかを完全に表現しており、 それゆえに貴重なビジネス資産となっています。 Zalandoがとあるオンラインショップから価値あるファッションプラットフォームへと変貌を とげるために、私たちは新しいオープンプラットフォーム戦略の展開をはじめました。 なので、高品質で長持ちするAPIの設計は、私たちにとっ
ここでは5つの世界における「パッケージ」の中でも「商用Webベースソフトウェア」、主に小・中規模での場合についての私見を述べます。なお、ここにおけるレガシーコードとはテストの無いコードや、不吉な臭いのするコードを指します。 人間の話 以下ではその規模毎に処方箋案を記載していますがその規模に関わらず、レガシーでありながらも苦痛を伴いながらもメンテナンスが行われているコードというものは、基本的には価値を生み出し続けてきた偉大なコードです。一般的にあなたが日曜日に書く最高にcoolなコードの、一万倍(※)以上の価値を会社や社会へ提供してきた偉大な存在であるというコードと作者への敬意は心のどこかに置いておきましょう。 また世の中には「作者とコードを完全に分けて考えられる人」「ある程度分けて考えられる人」「完全に自分の一部だと考えている人」の3種類がいます。つまりレガシーコードを痛烈に非難する時、6
2023年03月31日追記:この記事を基に、@sadnessOjisanさんより、コードレベルにより踏み込んだ、かつ、グリーンスレッドベースの新しいWebサーバアーキテクチャも含めて整理された記事 Webサーバーアーキテクチャ進化論2023 | blog.ojisan.io が公開されました。 主に新卒のWebエンジニア向けに、古典的なWebサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介します。 この辺りの話題がWeb界隈で流行っていたのは数年以上前というイメージですが、Webサービスは相変わらずWebサーバの上で動いているので、流行り廃り関係なく学ぶべき内容だと思っています。 また、HTTP/2がいよいよRFC化し、既にh2oやtrusterdなどのHTTP/2のサーバ実装があり、今後Webサーバアーキテクチャを再訪することが増えるような気がしています。 ところが、We
【追記 2018/01/06】現在Mackerelは、時系列データベースという概念をクラウドの技で再構築する - ゆううきブログの時系列データベース実装へ移行しています。 サーバモニタリングサービス Mackerel で採用している時系列データベース Graphite を用いたシステムの構築と運用事情を紹介します。Graphiteについては、プロビジョニングやアプリケーションからの使い方、Graphite自体のモニタリングなど様々なトピックがありますが、特に大規模ならではのトピックとして、Graphiteの内部アーキテクチャ、パフォーマンスチューニングおよびクラスタ構成についての知見を書きます。 背景 Graphiteシステム概観 データ構造とアーキテクチャ whisperのデータ構造 carbon-cacheのアーキテクチャ パフォーマンス特性 パフォーマンスチューニング ミドルウェアレ
QConTokyo ( http://www.qcontokyo.com/KotaUENISHI_2015.html ) の発表スライド
大規模プッシュ通知基盤大解剖(終): 24時間途切れないサービスで有効なImmutable Infrastructureの運用方法 大規模プッシュ通知基盤について、「Pusna-RS」の実装事例を基にアーキテクチャや運用を解説する連載。今回は、Pusna-RSの運用面や発生した課題について、使用している技術やツール「AWS Elastic Beanstalk」「Jenkins」「Amazon CloudWatch」「GrowthForecast」「fluentd」「Elasticsearch」「Kibana」などの説明を交えながら紹介します。(2015/3/19) 大規模プッシュ通知基盤大解剖(3): Node.jsのStream APIで大量プッシュ通知を高速化するテクニック 大規模プッシュ通知基盤について、「Pusna-RS」の実装事例を基にアーキテクチャや運用を解説する連載。今回は、
連載目次 プッシュ通知とは? なぜ開発者はアプリにプッシュ通知機能を搭載するのか スマートデバイスにおける「プッシュ通知」はアプリにとって欠かせない機能の一つであり、メールマガジンと同様に重要な集客ツールです(図1)。スマートフォンをお使いの方でしたら、一度はプッシュ通知を受け取ったことがあるのではないでしょうか。 プッシュ通知はユーザーがスマートデバイスを起動していなくても通知を送ることができる仕組みであり、以下の特徴があります。 開くと直接アプリを起動するためアクションにつながりやすい アプリをインストールしているユーザーのみに届くため開封率が高い 上記のような特徴から、プッシュ通知は以下の用途で使うことが多くなります。 リアルタイムな情報配信 直接アプリ起動につながるため、ニュースなどリアルタイム性の高い情報の配信に向く ユーザーのアクティブ率向上 開封率が高いため、定期的にアプリを
5月に開催されたBacon Conferenceで,bitlyのアプリケーション開発リーダのSean O’Connor氏は,毎月600億クリックを処理する分散システムの開発を通じてbitlyの開発者たちが学んだ,最も価値ある教訓について説明した。 分散システムとは何か? 分散システムを定義する3大特性は,氏によれば,Wikipediaで簡単に見付けることができる。 コンポーネントノードの真の並行性。これによってノード間の同調に関連するコストと複雑性が発生する。 共通クロックの不在。このため,異なるノードで発生したイベントを時間順に並べることは不可能になる。 障害の独立性。これはノード障害がシステム内の他のノードに影響を与えない,という能力として理解されるべきだ。 従って分散システムの構築では,これらの特性を扱うことを目標にする必要がある。 ただし氏の意見として,システムの分散的特性に起因す
(Monitoring Casual Talk in Kyotoで発表してきたので、ブログエントリにまとめ直しました) 2013年はインフラ周りの技術的な進化が大きく、いくつかのエポックメイキングな概念と実装が産まれました。個人的には特に以下の2つが大きいと思っています。 AWSの本格普及期 DockerとImmutable Infrastructure これらを踏まえて、2014年のウェブシステムの進化の方向性を考えてみます。また、それによるモニタリングへの影響もあわせて考えます。だいぶ長くなってしまったので、急ぐ人は最後に結論をまとめましたので、そちらからどうぞ! 2013年という時代背景 AWSが本格普及期を迎えているのは、言わずもがなのことで、Re:Inventでの246件という膨大のセッション数などにその勢いが表われています。 また、DockerはLXC (LinuX Conta
ある日ふと思い立って調べてみた、イケてるしヤバい*1言語REBOLについて紹介します。 REBOLは、 Relative Expression Based Object Language 「相対的な表現をベースにするオブジェクト言語」の略です。よく意味わからん。 Wikipediaによると、 1997年にリリースされたREBOLは、カール・サセンラスが20年に渡って設計したものである。サセンラスは AmigaOS の主要アーキテクトであり、REBOLの設計にあたっては、表示的意味論の知識に基づいて、LISP、Forth、LOGO、Self といったプログラミング言語の概念を利用した。 引用元:REBOL - Wikipedia 大雑把にいうと、LispやForthやLOGOやSelfに似たスクリプト言語です。ここからダウンロードできます。最新バージョンはオープンソースライセンスになっていま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く