分散キューという名の苦しみ - Software Transactional Memo
TL;DR 分散システムにおいてキューを導入する場合、本当にキューが必要なのか再考すべき。そこが地獄の入り口だから。 システムの抽象 コンピュータの世界は、本来は0と1の信号の羅列が飛び交う無機質なものである。でも人類は信号だけですべてを語らず、様々な喩えを定義してきた。それはデスクトップ・ウィンドウ・マウスカーソルといったグラフィカルな表現に留まらず、パケットやカプセル化といった用語にロック・キュー・リスト・木などのアルゴリズムやデータ構造の世界にも自然に溶け込んでいる。これらはすべて人間の理解を助けるための喩え話に過ぎず、この喩えこそが人間のより直感的な理解をもたらす一方で、発想の制約を生み出してきた。 人間が大きなシステムを作るときも何らかの喩えを用いてシステム全体を整理する。アーキテクチャの「ポンチ絵」を描いて情報共有をするのは企業に勤めていれば経験した人も多いだろう。パワーポイン
モノリス分割はこうやる！「How to break a Monolith into Microservices」を読んだ - kakakakakku blog
研修中に「マイクロサービス」の解説をしていると，たまに「モノリス分割」に関する質問が出てディスカッションをすることがある．当然ながら万能な分割アプローチはないけど，例えば DDD (Domain-driven design) などのアプローチを選択するなど，選択肢はいろいろある．そして最近「モノリス分割」に役立つアプローチを紹介した martinfowler.com の記事「How to break a Monolith into Microservices」を読んだ． 具体的には以下の「計8種類」のアプローチが紹介されている．原著を翻訳するのではなく，あくまで個人的なメモとしてまとめる．なお，日本語も個人的に載せているため，参考程度にしてもらればと！ Warm Up with a Simple and Fairly Decoupled Capability（シンプルかつ分離された機能で準
1000万件オーバーのレコードのデータをカジュアルに扱うための心構え - joker1007’s diary
自分が所属している会社のメンバーの教育用資料として、それなりの規模のデータを扱う時に前提として意識しておかなければいけないことをざっくりまとめたので、弊社特有の話は除外して公開用に整理してみました。 大規模データ処理、分散処理に慣れている人にとっては今更改めて言うことじゃないだろ、みたいな話ばかりだと思いますが、急激にデータスケールが増大してしまったりすると環境に開発者の意識が追い付かないこともあるかと思います。 そういったケースで参考にできるかもしれません。 弊社は基本的にAWSによって運用されているので、AWSを前提にした様なキーワードやサービス名が出てきます。後、句読点があったり無かったりしますが、ご容赦ください。 追記: 社内用の資料の編集なのでかなりハイコンテキストな内容だから誤解するかもしれませんが、これらはそもそもRDBの話ではありません。(関係無くは無いけど) 1000万オ
SPA+SSR+APIで構成したWebアプリケーションのセッション管理 - Pepabo Tech Portal
カラーミーショップ サービス基盤チームのkymmtです。この記事では、サーバサイドレンダリングするシングルページアプリケーションとAPIサーバからなるWebアプリケーションのセッション管理方法について紹介します。 アプリケーションの構成 構成の概要 今回は例としてEC事業部で提供するカラーミーリピートをとりあげます。構成としては、Railsで作られたAPIサーバ1と、Vue.jsで作られたシングルページアプリケーション(SPA)からなります。また、SPAはExpressが動くフロントエンドサーバでサーバサイドレンダリング(SSR)します。APIサーバはSPAかフロントエンドサーバだけが呼び出します。各ロールはサブドメインが異なります。 APIサーバでセッションIDを持つCookieを発行し、Redisを用いてセッション管理します。また、APIサーバへのセッションが有効なリクエストはフロント
「はじめてのAWS設計でやりがちな失敗パターンまとめ」について発表しました #devio2020 | DevelopersIO
西澤です。クラスメソッドに入社してからおよそ5年間クラウドの推進やAWS技術に関する支援をさせていただいております。この経験を何か形にしたいと思い、少し遅れてしまったのですが、Developers.IOイベントに乗じてまとめさせていただきました。 発表資料 資料はこちらにアップロードしております。 夜間に録音したので覇気が無い感じになってしまいましたが、動画はこちらです。 まとめ 「AWS設計でやりがちな失敗パターン」というタイトルで考え始めたのですが、もっともお伝えしたい点は、AWSを利用されるお客さまのマインドセットを変え、クラウドを活用できる組織に変わって欲しい、というところに集約できるかなと思います。技術的な問題以上に、考え方を変えられないこと、組織を変えられないことが、クラウド活用を阻害するアンチパターンになっていると思いました。 どこかの誰かのお役に経てば嬉しいです。
テストのためだけに`interface`を書きたくないでござる — KaoriYa
golangでテストのためだけにinterfaceを書くのが死ぬほど嫌だったので編み出した技を紹介します。 TL;DR テスト(=mock)のためだけにinterfaceは切りたくない 型エイリアスとビルドタグを組み合わせるとinterfaceがなくてもモックが作れる この手法に必要なモックを自動生成するプログラムを作った interfaceは本当に必要なシーンで使うべき Background 現在モックを使った単体テストは一般的です。 Javaでの例を挙げると、モックしたいコンポーネントについて予めinterfaceを定義しておき、モックではそのインターフェースを実装するのが定石です。 しかしgolangのinterfaceはJavaなどのそれとは若干性質が異なるため、テスト=モックのためだけにinterfaceを書くのはオーバーワーク気味です。 そうテストのためだけにinterface
マイクロサービスを形式的に見てみる - Juju-62q's blog
マイクロサービスについて考えていたら疲弊したので、少し技術者らしく形式的に見てダメのものを思考から削ぎ落としたいと思った。 グラフ理論などコンピュータサイエンスの基礎を交えて話をするが、基本的には当たり前のことしか言わないと思うのでここに書くことを意識せずとも暗黙的に実践している人も多いだろう。 なお、個人の意見でしかないのであっているか間違っているかはわからないし、筆者にこの記述に反した実装を否定する意図はない。 今回は適当に書き散らかすのでかなりテイストが違うが他のブログと同一人物が書いている。乗っ取り等ではないです。 TL;DR マイクロサービスはDAGとすると考えやすいしデプロイしやすい 閉路があるなら設計を見直した方がいい DAGかどうかはサブシステムレベルでそれぞれ考えると簡単 デプロイに関係するリポジトリでは閉路がないことを意識させる設計にするといい マイクロサービスと疲弊
クリーンアーキテクチャ(The Clean Architecture翻訳)
Robert Martin (a.k.a. ボブおじさん) による、 The Clean Architecture の翻訳です。似たようなアーキテクチャである ヘキサゴナルアーキテクチャ も翻訳したので参考にしてください。 この記事を翻訳して公開したことは 8th Light, Inc. に報告済みです。いまのところ苦情は来ていません。 ここ数年以上、システムのアーキテクチャに関する実にさまざまなアイデアを見てきた。これには、次のものが含まれる: Hexagonal Architecture (別名 Ports and Adapters) by Alistair Cockburn。Steve FreemanとNat Pryceが、Growing Object-Oriented Software というすばらしい本で採用した。 Onion Architecture by Jeffrey Pa
リーダブルアーキテクチャ - usecaseにおける時間軸と抽象度の統一 - Qiita
はじめに Clean Architectureやレイヤードアーキテクチャでは、どのようにレイヤーを定義するかついては言及されています。 そのような中usecase(レイヤードアーキテクチャではApplication層)をどのように実装するべきかについての議論は少ないです。 しかし私はリーダブルなアーキテクチャを実現するために、一番大切なことはusecaseを適切に実装することであると考えています。 そこでusecaseを実装する上で起こりがちな抽象度の問題を例に、リーダブルなアーキテクチャを考えいていきたいと思います。 サンプル 1:1のチャットアプリでUserとWorkerが存在して会話ができるアプリを例にあげます。 以下の図では青い背景はinfraの関数実行、緑色の背景はdomainの関数実行、赤い背景はusecaseの関数実行を示しています。 usecaseのCreateChat関数
Clean ArchitectureでAPI Serverを構築してみる - Qiita
この記事では、アーキテクチャを採用する理由、次にClean Architectureの概要、最後にアプリケーションの構築をしていきます。 この後詳しく見ていきますが、Clean architectureの概念は比較的シンプルでわかりやすいものだと思います。しかし実際コードに落とし込んだ時、これってどう実装すればいいのかな？と迷うことがあったので、自分の理解も深めるために実際にAPI Serverを構築していきたいと思います。 また、サーバーサイドでの採用事例をあまりみないので誰かの参考になればいいかなと思います。 サンプルコードは、Go言語です。 アーキテクチャを採用する理由 アーキテクチャに期待することは、関心の分離です。 関心の分離を正しく行うことで、次のようなメリットがあると思います。 再利用性の高い設計になり生産性が向上する コードの可読性が上がり、メンテナンスが容易になる 変化に
API サーバーを Clean Architecture で構築する - OPTiM TECH BLOG
はじめまして。オプティムのR&Dに所属している新卒2年目の板垣です。 普段は、AI の学習に必要な教師データを作成するためのアノテーションツールの設計・開発・運用を行なっています。 アノテーションツール自体は Web アプリで、クライアント側は React と TypeScript、サーバー側は Go で実装しています。 さて、先日 Clean Architecture 達人に学ぶソフトウェアの構造と設計 という本が ITエンジニアに読んでほしい！技術書・ビジネス書 大賞2019 の技術書部門ベスト10にノミネートされました。 本記事を読もうと思って下さった方の中には、この本を読もうと思っている、または、もう読んだという方が結構いらっしゃるのではないでしょうか。 かくいう私も、携わっているソフトウェアのソースコードがひどくて(というより、そのアーキテクチャでは耐えられなくなってきたと言った
実践クリーンアーキテクチャ │ nrslib
YouTube での解説 YouTube にて Java コードをベースに解説を行いました。 コードの雰囲気は C# とほとんど同じなので参考になるかと思います。 もしよければご覧ください。 Java コードの記事リンク：https://nrslib.com/clean-architecture-with-java/ その他解説もしています。もしよろしければチャンネル登録をお願いいたします。 Qiita 版 Qiita に CUI や GUI 向けのクリーンアーキテクチャの記事を書きました。 ボブおじさんのクラス図を模したものです。 Web とはまた異なった実装になるので、もしよければ合わせてご参照ください。 https://qiita.com/nrslib/items/a5f902c4defc83bd46b8 さらに PHP の Laravel 版も作ってみました。 https://qi
どうする？マイクロサービスでの認可と認証 後編 | cloud.config Tech Blog
はじめに 以前のブログにおいて、マイクロサービスにおける認証や認可の仕組みの実装の難しさについて説明しました。 モノリシックなアーキテクチャのサービスとは違い、マイクロサービスアーキテクチャではサービスが複数になるので、ユーザー情報や認証情報をどのように持つのかが問題になっていました。 認証に関する同じデータを全部のサービスに持たせると、どれか一つで情報に変更が加えられると残りのすべてのサービスに反映させなければならないのでデータベースの時と同じようにデータの整合性の問題が起きます。 これをどのように解決していけばいいのかについて、今回は解説したいと思います。 David Borsosによる４つのパターン Javaアプリケーション開発で8年の経験があるDavid Borsosという方が、「Authentication in Microservice Systems」というタイトルでマイクロ
どうする？マイクロサービスでの認可と認証 前編 | cloud.config Tech Blog
はじめに 何らかのサービスを作成するうえで、認証、認可の仕組みは必要不可欠です。 ログインができて、ログインしたユーザーしか特定のサービスを使えないようにするという機能は、実際ほとんどどんなサービスにも実装されています。 その機能のために必要なのが認証と認可の仕組みであり、その実装方法について様々な方法が開発され、使われてきました。 しかし、マイクロサービスなアーキテクチャでアプリケーションを作成しようとした場合、これらの機能はモノリシックなアーキテクチャと同じように実装しようとすると困難が生じます。 例えば、モノリシックアーキテクチャと同じようにサービスごとに認証機能を実装していると、一つのサービスにログインしてそのサービスを利用した後に別のサービスを使用しようとしたとき、そのサービスではログインしていないために再びログインを求められることになり不便になります。 そしてそもそも、認証や認
マイクロサービス アーキテクチャの設計 - Azure Architecture Center
このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。 マイクロサービスは、回復性があり、単独でのデプロイが可能で、迅速に展開できる非常にスケーラブルなアプリケーションを構築するための一般的なアーキテクチャ スタイルです。 しかし、マイクロサービス アーキテクチャが成功するには、アプリケーションを設計および構築するのためのさまざまなアプローチが必要です。 マイクロサービス アーキテクチャは、小さな自律サービスのコレクションで構成されています。 各サービスは自己完結型であり、境界付けられたコンテキスト内で 1 つのビジネス機能を実装している必要があります。 境界付けられたコンテキストは、ビジネス内の自然な区分であり、ドメイン モデルが存在する明示的な境界を提供します
マイクロサービスとは？基礎から事例までわかりやすく解説
web関係のことを調べていたり仕事で関わったりすると、一度ならず度々耳にしたり目にするのがAPIという言葉。 APIという言葉は知っていても、意外と意味そのものはあまり世間に知られていなかったりしていることもあり、APIという言葉だ... マイクロサービスのメリットとデメリット モノリシックアーキテクチャと大きく異なるマイクロサービス。 そのメリットとデメリットはどのようなものなのでしょうか。 マイクロサービスのメリット マイクロサービスのメリットには、 リソースを有効活用できる 局所化によって障害や影響の与えるリスクを抑えられる 新技術の採用が容易である 新規機能の追加、高頻度の軽微な変更が容易 更改が容易 という点が挙げられます。 1プロセスで1サービスというマイクロサービスの特性は、サービス同士の依存関係が薄く、特異性、独自性を一定程度保持できます。 そのため、障害が起きても局所にと
宣言的UIはReact Hooksで完成に至り、現代的設計論が必須の時代になる - Qiita
この記事は、ある程度以上の規模のGUI開発において、React Hooks以後の宣言的UIにより、大規模開発に用いられる設計論に完全に対応できるようになり「ビジネスロジックの変更や追加」に対応するコストを低く保つこと（技術的負債の抑制）ができるようになったことを解説するものです。 技術的負債の抑制には、技術的負債の原因となりがちな「広範囲の密結合」と「適切な疎結合を保つ仕組みの欠如」が欠かせません。それをカバーするのが、大規模開発をクリーンに行える設計論（ここでは「現代的な設計論」とよぶもの）です。クリーンアーキテクチャなんかでGUIによく適用されるHumble Object Patternのようにプレゼンテーションとビューを分離する必然性が無くなるでしょう。 ポイントは ある程度以上の規模で開発するなら設計論をうまく使い設計しないと、技術的負債を抱え込む（ビジネスロジックの変更や追加に対
Laravelのサービスコンテナとサービスプロバイダはどういうものなのか - Qiita
なぜこの記事を書いたのか 今社内で Laravel 本の読書会をしたり、公式マニュアルの日本語翻訳ドキュメントを読んだりしながら、Laravelの学習を進めているわけだが、どうもサービスコンテナとサービスプロバイダが重要であることは伝わってくるんだが、その説明がしっくりこない。 なぜなんだろうということで、ソースを読んでみたり、色んな人のまとめを見てみたり、チュートリアルの動画を見てみたりしていて、「あー、こういうものかー」ということで自分的に納得がいったので、それを書いてみたというのがこれになります。 この記事の内容は、あくまでもサービスコンテナとサービスプロバイダの役割のほんの表面をなぞっただけで、全然深堀りしてるものではないです。サービスコンテナとサービスプロバイダは本当にいろいろなことをしていて、これで書いているのはごくごく入り口の部分の理解ということになります。 サービスコンテナ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
2020-05-13 RailsとJSON:APIによるマイクロサービス構築事例
マイクロサービス時代の認証と認可 - AWS Dev Day Tokyo 2018 #AWSDevDay
