マイクロサービスアーキテクチャにおける「サービス配置」の考え方
マイクロサービスアーキテクチャを用いてシステム開発をする場合、アプリケーションをどのように分割して配置すればいいのか。アプリケーション間の通信はどのような点に留意すべきかを、オイシックス・ラ・大地の川上徹氏が解説します。 サービス分割の考え方 マイクロサービスアーキテクチャを用いてシステムを構築する際に頭を悩ませるのは、アプリケーションをどのように分割するかだ。サービスの分割は正解のない分野かもしれないが、ECサイト「Oisix」のマイクロサービス化に約1年取り組んできた経験を基に考え方を共有したい。 本記事は、マイクロサービスアーキテクチャにおけるサービス分割の方法を、ビジネス側とシステム側の視点で分けて整理する。ただ、それぞれの考え方は共存しないわけでなく、整理して適切に組み合わせる必要がある。どのような考え方を採用するとしても、「何のためにマイクロサービスアーキテクチャを採用するのか
HBaseの概要とアーキテクチャ
はじめに ネットワークに接続されたセンサ機器の普及により、IoT（Internet of Things）が注目を集めています。IoTでは様々なセンサ機器が膨大なデータを生成するため、システムが管理するデータ量は急激に増加しています。このような膨大なデータを管理するためのデータストアとして、RDBと比較して高い性能とスケーラビリティを持つNoSQLが注目を集めています。 「Apache HBase」（以降、HBase）はNoSQLの1つで、センサ機器が生成する時系列データを管理するための有力なデータストアとして注目されています。本連載では、HBaseを用いたシステム設計のノウハウと、1,000万個のスマートメータから収集したデータによる性能検証の結果を紹介します。 今回は、まずNoSQLにおけるHBaseの位置付けを説明し、その後でHBaseの概要とアーキテクチャについて説明します。 NoS
これなら分かる！ マイクロサービス（入門編）～モノリスと比較した特徴、利点と課題
IT用語の解説サイトや書籍は世にたくさんありますが、何だか難しいものばかりだと思いませんか？ 知らない単語を検索したけれど、どのサイトを読んでも理解できずブラウザを閉じてしまった、なんて経験を持つ方も多いと思います。本連載はそんな事態に苦しむITエンジニアの皆さまに向けて、まわりくどい原典の説明や冗長な周辺情報を取り払い、できるだけシンプルで、ポイントを掴める解説を目指しました。第一回のテーマに選んだのは、「マイクロサービス」です。一時期「バズワード」と言えるほどもてはやされ、昨今ではシステム部門／ユーザー部門を問わず知っておくべき基礎項目にまで格上げされた感のあるこの用語。これから学ぼうとしていた方も、過去に調べて挫折した方も、改めて基本を確認したい方も、ぜひこの機会に知識を整理いただければ幸いです。 はじめに：自己紹介 西野大介（@nishino_chekhov）と申します。SOMPO
サーバレスでスケーラブルかつ堅牢なシステムを構築するためのデザインパターンとアーキテクチャ。Serverlessconf Tokyo 2017 － Publickey
サーバレスコンピューティングは新しいシステム開発手法である。Serverlessconf Tokyo 2017で紹介された、スケーラブルで堅牢かつ高性能なアプリケーションの構築に役立つ6種類のデザインパターンを紹介する。 2017年11月2日、3日の2日間、東京都内でサーバレスコンピューティングのイベント「Serverlessconf Tokyo 2017」が開催されました。 サーバレスコンピューティングもしくはサーバレスアーキテクチャと呼ばれるアプリケーション実行環境は、一般にサーバのことを意識せずにアプリケーションを実行できる環境のことを指します。 そのサーバレスコンピューティング環境の実装として一般的なのが、あらかじめアプリケーションとして実行したいコードを関数として登録しておくと、指定されたイベントによって自動的に関数が呼び出されて実行されるという、いわゆるFunction-as-
Apache Kafkaを使ったアプリ設計で反省している件を正直ベースで話す
Apache Kafka: Producer, Broker and Consumer2017年は生まれて始めてApache Kafkaを本格的に業務利用（PoCではなく本番運用）した年でした。Apache Kafka的なメッセージングミドルウェアそのもののは、社内的な事情でよく使っていたのでその使い勝手に対して困惑はほとんど無かったですし、ミドルウェアとして非常に安定しているため、Kafkaクラスタそのものでの不具合らしい不具合が発生したことは一度もありませんでした。 しかし、Kafkaのトピック設計などに関してのベストプラクティスは事例ベースでもあまり見かけたことがなく、チームメンバーと悩むことも多かったです。このストーリーでは、主にKafkaを利用したアプリ設計で考えたことや失敗したことを振り返りつつ共有します。なお、パーティション数や各種バッファサイズなどのチューニング要素は今回取
MSA化レベル定義 - 低レベルなマイクロサービスはただのファイル連携と見分けがつかない - arclamp
「低レベルなマイクロサービスアーキテクチャ（MSA）」というのは「ただの基幹システムとのファイル連携」でいいんだよ、という話。 Level 5 | Richmond, Virginia | Rebecca Morgan | Flickr MSAというのは「どこかに存在する完成されたシステム」ではなく、現状のシステムを不断の努力によって進化させていった結果です。MSAに決まった構成はありません。あくまでもプラクティスやパターンがあり、それらの実現を手助けするソフトウェア製品（OSS）があるだけです。 というわけで、「MSAに取り組む」というのは道は遠くても（見えなくても）「目の前のシステムの継続的な改善に取り組む」ことでしかないのですが、最先端の話しかないと差が大きすぎてどう取り組めばいいのか分からない、あるいは再構築しか道はないと感じてしまうのだと思います。そこで段階的なレベル上げができる
アーキテクチャ設計のアンチパターン集～44のアンチパターンに学ぶDBシステム - プログラマの思索
「44のアンチパターンに学ぶDBシステム」を読んでみて、とても優れたアーキテクチャ設計のアンチパターン集に思えた。 過去の経験上、あるあると思う箇所がたくさんあった。 感想をラフなメモ書き。 【元ネタ】 44のアンチパターンに学ぶDBシステム - give IT a try あなたの現場にも必ずあるDBシステムの"悪い例"が満載！「44のアンチパターンに学ぶ DBシステム」 | oracletech.jp 『44のアンチパターンに学ぶDBシステム』 - 虎塚 44のアンチパターンに学ぶDBシステム : 賢者の図書館 (Under Construction) : livedoor Blog（ブログ） 【本】SQLをしっかり学習したい人におすすめミック本。 | ﾌﾟﾗﾌﾟﾗ式技術系 Access流! 【本まとめ】44のアンチパターンに学ぶシステム構築時の失敗パターン。もっとはやく言ってよーとな
【上級者向け】基幹業務をAWSクラウドで実現する勘所 ～ 高可用性システム/バックアップのためのアーキテクチャ設計 ～（AWS Summit Tokyo | Tech-03）
講師: 北迫 清訓（アマゾン データ サービス ジャパン株式会社 ソリューションアーキテクト） エンタープライズアプリケーション領域でのクラウド利用が注目される中、基幹業務システムを含む社内系システムのクラウド化が拡大してきています。 業務系システムを稼働させるうえで、システムの可用性、バックアップを含めた耐障害性の向上をいかに効率的に実現するかが重要な要素になるかと思います。 本セッションでは、簡単に始められるクラウドバックアップから、高可用性システムの構築例まで、インフラの観点からAWSクラウドを活用したアーキテクチャ、システム設計に関するプラクティスをご紹介いたします。 AWS に関する詳細は、aws.amazon.com/jp/ もご覧ください。
マイクロサービスの最難関、どうするDB分割？
「マイクロサービスアーキテクチャー」はどれくらい世に広まっているだろう。小さなサービスを疎結合に組み合わせ、一連のアプリケーションを構成するマイクロサービス。ソフトウエアの改変しやすさに強みがあり、米ネットフリックスや米アマゾン・ドット・コムといった、サービス改善のスピードを突き詰めたいネット企業を中心に導入が進んできた。 日本でも活用事例は増えている。日経SYSTEMSの特集記事「マイクロサービスの現実解」では、全日本空輸（ANA）や楽天トラベル、モノタロウなどを取り上げた。メリットが大きい半面、特に既存システムからの移行は一筋縄では行かないという印象だ。マイクロサービスの難しさを考えてみたい。 従来型システムに比べたマイクロサービスのメリットは明らかだ。現在主流のWebアプリは、プレゼンテーションと業務ロジック、データアクセスの3レイヤーを一体で開発するのが一般的。こうしたモノリス（一
マイクロサービスアーキテクチャの設計 - JUG2015
2015/8/28に開催された「Spring in Summer ~ 夏なのにSpring 」での講演「R1-2 マイクロサービスアーキテクチャの設計」の講演資料です。Read less
レガシーシステムのモダナイゼーションとマイグレーションはどうあるべきなのか
レガシーシステムのモダナイゼーションとマイグレーションはどうあるべきなのか：基幹業務のSoRはどこまでクラウド化できるのか（終）（1/2 ページ） 基幹業務がメインフレーム上で稼働している企業は多くあり、レガシーシステムとクラウドを組み合わせた「ハイブリッドIT」の実現が必要です。今回は、その課題と対応について考察します。 「基幹業務をはじめとする既存アプリケーションを、どのような観点でクラウドプラットフォームへ移行すべきか」を探る本連載「基幹業務のSoRはどこまでクラウド化できるのか」。これまで3回の連載では、基幹業務のクラウドにおける稼働に向けて、アーキテクチャ、移行、運用の観点で論じてきましたが、一方で、基幹業務がメインフレーム上で稼働している企業は多くあり、レガシーシステムとクラウドを組み合わせた「ハイブリッドIT」（※）の実現が必要です。今回は、その課題と対応について考察します。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Auto Scaling x Spot Instances によるスケーラビリティと コストカット