ScalyrブログのMicroservices Logging Best Practicesの抄訳に、いくつか補足を加えたものです。 一意のIDをリクエストと関連付ける 複数のサービスの呼び出し関係をトレースできるように一意のIDをリクエストに含めます。 ZalandoのRESTful APIガイドラインをみると、X-Flow-IDというHTTPリクエストヘッダを付けるように規約化されています。 Microsoftにも「マイクロサービスの設計: ログ記録と監視」というガイドがあります。 一意のIDをレスポンスに含める レスポンスのペイロードにも一意のIDを持っておけば、問題が発生したときに、カスタマからの連絡にも即座に対応できるようになります。 Spring Cloud Sleuthは、それらのコンセプトと実装も提供しています。 https://github.com/spring-clou

対象読者 2つの疎結合なシステム間を、メモリを大量に使っちゃうような大がかりな仕組みなしで、ほぼリアルタイムにデータロスなしに同期させたい、そういうアーキテクチャが欲しい方。 動機 Microservicesを疎結合に保ちつつ、バッチ処理やレポート機能でのクエリの高速化のため、データを同期させたいことがままあります。このあたりの話は、テキストの「5章 モノリスの分割」に載っています。 あるサービスから、データを定期的に吸い上げて、別のサービス、ツールに送るデータポンプという仕組みがあります。 イベント駆動でメッセージを関連サービスに送るイベントデータポンプや、バックアップツールを使って高速にデータ転送するバックアップデータポンプが紹介されていますが、結果整合性だけどなるべくリアルタイム(Near Real-Time)で同期させたいとなると、イベントデータポンプな仕組みしか選択肢にはならない

セッションIDやアクセストークン、はたまた業務上で使う一意の識別子など、いろんなところで一意のIDを生成しなきゃいけないケースが存在します。 そこで世間で使われているIDの生成方法について調べてみました。 選択基準 ID生成における要求として、以下の観点が上げられるかと思います。 生成の速度 大量にデータを短期間で処理し、それらにIDを付与する場合、ID生成そのものがボトルネックとなることがあります。 推測困難性 IDを機密情報と結びつける場合、IDを改ざんされても、機密データが見れないようにできている必要があります。 順序性 採番した順にデータをソートする必要がある場合は、IDがソートキーとして使えないといけません。 それぞれについて各生成手段を評価します。 ID生成の手段 データベースの採番テーブル 採番用のテーブルを作り、そこで番号をUPDATEしながら取得していくやりかたです。古い

Cognitect社のNygardさんが10年ぶりに改訂したRelease It! 2nd Editionがまもなくリリースされます。内容は現在のベータ5版で全て書ききっておられるようなので、是非読んでみてください。 https://pragprog.com/book/mnee2/release-it-second-edition その中から4章の安定性パターンの概要をご紹介し、実際JavaのFailsafeライブラリを使った実装例を示したいと思います。 安定性のパターン Stability Patterns 分散システムや後続をブロッキングしてしまう重い処理は、システム全体がスローダウンしたり、無応答になってしまう危険にさらされています。クラウド時代になって、これらの安定性を保つための設計はより強調されるようになりましたが、わりと昔から様々な工夫がされてきたものでもあります。以下、Rel

GitHub上の実際のコミットメッセージやIssueのやりとりをみて、チートシート作りました。 共通的なこと コミットメッセージやIssueのタイトルは、主語省略し、1文で書き行末ピリオドは付けない 動詞は現在形・過去形のどちらも同じくらいの頻度で見られるが、どちらかに揃える。 コミットメッセージを書く Japanese English

The DevOps Handbookが2016年10月に発売になりました。これを読んで、SIerが開発対象とするようなエンタープライズ領域において、DevOpsは価値があるのかどうか、考えてみます。 The DevOps Handbookでは、DevOpsの目的を以下のように定めています。 開発者は生産性向上というとプロセスタイムの短縮にばかり目がいきがちだが、リードタイムをいかに短縮するかの方が、顧客にとっての価値であり、それがDevOpsの目的である。#DevOpsHandbook — :SIer/kawasima (@kawasima) 2016年10月19日 リードタイムとプロセスタイムの違いは、以下のような定義です。 実際にDevやOpsのタスクを実行している時間は、プロセスタイムです。それ以外の時間も短くする努力が必要です。 SoRとSoE SoRとSoEというシステム分類が

マイクロサービスアーキテクチャの5章は、モノリスをどうやって分割していくかが焦点です。サービス間での依存関係をできるだけ断つために、共有データや共有テーブルを避け、分割していくやり方が書かれています。 モデリングの観点からは、記述が不足なところがあって、現場のモデルに照らし合わせて考えることが難しいので、これをもう少し掘り下げて考えてみます。 データモデリングの手法としては、拙作のイミュータブルデータモデルが前提となりますので、未見の方はそちらをまずご参照ください。 エンティティは、リソース系とイベント系の2種類に大別するので、これらの関連の種類で言うと、R-R, E-R, E-Eの3つあります。これを順に分割するとどうなるかを考えます。 これらの呼び方はTM手法に準じます。 http://tmdmaker.osdn.jp/doc/ch08.html リソース-リソース(R-R) 強い依存

Antifragileは、タレブが2012年に書いた本で、社会経済学の分野の内容ですが、他の分野においてもその考え方は有効ではないかと多くの記事や論文があります。ソフトウェア開発やアーキテクチャにどういう影響を与えていきそうかを考えてみます。 アンチフラジャイルの投資的側面 もともとはアンチフラジャイルとは、相場が動いたときに悪い方に転んでも損失はそこそこに抑えられるが、良い方に転ぶと指数関数的に大きな利益を得るということを意味します。 アンチフラジャイルな投資方法としては、プットオプションが鍵と言われています。 伝説の投資家シリーズ16－Nassim Taleb 私もこの辺りは門外漢なので、記事中の例を引用すると、通常時に50ドルのシティバンクの株式を3ドルで売る権利(プットオプション)を10セントで買います。これはシティバンク株が3ドル以下になることなど、ほとんどありえないと考えられる

マイクロサービスアーキテクチャの4章にオーケストレーションとコレオグラフィという話があります。 マイクロサービスを使ってアプリケーションを組み立てる側の、サービスの呼び出し方の違いです。 「マイクロサービス的に作ってるよー」というシステムでも、ここに特に疑問を持たず、ふつうにWeb APIたちを呼び、受け取ったデータでHTMLをレンダリングするというオーケストレーション方式で作られているのが多いのではないでしょうか? Sam Newmanは、それだと呼び出されるサービス側がドメインモデル貧血症になりがちで、呼び出す側にロジックが集まっていくことになると、書籍の中で述べています。 いったいどういうことでしょうか? 書籍中の例をちょっと変えて考えてみます。 マイクロサービスアーキテクチャでECサイトを作る(オーケストレーション編) ECサイトをマイクロサービスアーキテクチャで作ることを考えてみ

現在ではSpring Bootの手軽さに軒並み飲み込まれた感がありますが、Javaのマイクロフレームワークはちょっとしたブームでした。 Javaのマイクロフレームワーク ― この新トレンドは見逃せない enkanは、RackやExpress.jsで実装されているミドルウェアパターンをJavaで実装した、現在ファーストリリースへ向け開発中の新しいマイクロフレームワークです。 Java9のREPLを活用して開発・運用を楽にする機能も実装(予定)です。 なぜ今さら新しいWebフレームワークを? Spring BootやJava EEは、高度なDIとたくさんのアノテーションでフレームワーク内部の動きはブラックボックス化されます。これを完全にブラックボックスのまま、実用的なWebアプリケーションを完成させるのは、実際のところ難しく、フレームワークの内部を覗きにいかなくてはなりませんが、これが結構ハマ

本番と開発の環境の違いで、本番障害を起こしてしまった…という経験がないシステムエンジニアなど存在しないと思います。 どういう点で問題が起こり、どういう対策をすべきだったのか、経験をもとに書きだしてみます。 (ここで開発と呼んでいるのは、一応本番以外のステージング、テスト環境も含みます) ミドルウェア設定 Webサーバ 同時接続可能数(MaxClients) 開発環境では、あまり気にしないパラメータですが、本番では慎重に設定しないと次のようなトラブルを起こします。 MaxClientsが小さすぎて、システム間連携APIがタイムアウトしてしまった。 MaxClientsが大きすぎて、サーバのメモリが枯渇した。 本番でのトラフィックが正確に予測できなければ、デフォルトのままにしておいて、様子をみながらチューニング、の方が下手に設定するより事故が少ないように思います。 リライト コンシューマ向けの

RBACの基礎 業務システムの権限制御の基本形はロールベースアクセスコントロール(RBAC)です。簡単化すると、以下のようなモデルです。 Subject(システムユーザ)は、複数のRole(ロール)を持っている。 Role(ロール)は、Permission(権限)のセットからなる。 Permission(権限)は、オペレーション(許可される操作)のセットからなる 具体的に、Redmineでの例をみてみましょう。 ユーザにはデフォルトで「管理者」「開発者」「報告者」のロールが割当可能である。 「報告者」ロールは、「Add Issues」の権限をもつ。 「Add Issues」の権限をもつユーザは、「Issueの新規作成」ができる。 このモデルをRedmineでは、以下のように表現しています。 Redmineは1人のユーザを、複数のプロジェクトに異なるロールでアサインすることができるので、上記

3日目で息切れしてきたので、今日は軽めな内容です。 データベース更新とメール送信の一貫性 商品購入の完了ページなど、よくデータベースを更新して、メールを送信してデータベースをコミットするという仕様があります。 データベース登録出来てないのに、完了メールを送るわけにはいかないので、これらを1トランザクションにできなきゃいけません。が、SMTPプロトコルにコミット/ロールバックの概念はありません。 さて、どう設計しましょうか、というお話です。 方式 A.DBトランザクション後にメールを送る 同一トランザクションはあきらめ、データベースを先にコミットし、その後でメールを送る、という設計です。 メール送信でエラーになったら、データベースには書き込めているので、メールだけ再送するように仕組みを作ったりします。 以下のようなイメージです。 public class OrderController {

最近はエンタープライズのシステムでも、Web APIによるシステム間連携が増えてきました。そうしたときに、1リクエストで複数の連携先APIを実行し、結果をクライアントに返すということがままあります。 どう作りましょうか、という問題です。 前提として、サーバサイドでHTMLレンダリングせずに、Web APIの中継することとします。中継する意義は、流量やキャッシュをサーバサイドでコントロールできるところにあります。 クライアントから直接連携先のAPIにアクセスする設計にすると、リロードボタン連打などのDDoS攻撃うけたときに、自分たちでは対処できず、連携先に迷惑をかけてしまいますよね。特に「課金の関係などで直接APIをアクセスしなきゃいけないんだ」、とかでなければ、中継するように設計しておいた方がベターです。 Web APIの呼び出し 業務システムで使う場合は、ちゃんとリクエスト、レスポンスが

レガシーなJavaで書かれたシステムのコードを見ていると、以下のようにInputStreamでファイルを開いて、OutputStreamでコピー先のファイルに書き込むみたいなものがあったりします。 try(InputStream input = new FileInputStream(srcFile); OutputStream output = new FileOutputStream(dstFile)) { byte[] buffer = new byte[BUFFER_SIZE]; int size = -1; while ((size = input.read(buffer)) > 0) { output.write(buffer, 0, size); } } 他にはどういう方法があるのでしょうか。ファイルコピーの歴史が詰まっている、commons-ioの実装の変遷をふりかえり、そ

システムエンジニアにとって頻出機能のひとつで、要件がモリッとしがちなファイルアップロードについてです。アップロードファイルもただの画像やPDFではなく、ExcelやCSVファイルをアップロードして、中身を読み取ってデータベースに格納する、あれを対象とします。 標準的なファイルアップロードでの設計ポイント ファイルのアップロード機能を実装しようとなると、以下のような点の設計を考える必要があります。 同期? 非同期? タイムアウトのリスクがあれば、非同期にする ブラウザのタイムアウト 通信経路(プロキシやファイヤウォール)でのタイムアウト Webサーバのタイムアウト ユーザがレスポンス返ってこないので、処理を中止するリスク 非同期の場合の実行方式 Webサーバ内でスレッドを新規に作る or 別プロセスへ処理をディスパッチする 流量制御のためリクエストをキューイングする Progress 長時間

アップロードと比較するとタイトルは釣り気味なのですが、ダウンロードにまつわるパターンをまとめます。 ふつうのダウンロード アップロードほど考えなきゃいけないことは多くないですが、ハマりポイントはいくつかあります。 ファイル名 何も対策せず日本語をファイル名にすると、当然のように化けます。

システムAの更新内容を、別のサーバにあるシステムBにも反映させるためにデータ送る、というケースを考えます。 主流はWeb APIかMOMを使う方法かと思います。(俯瞰的な話は、20日目のこざけさんが書いてくれる、はず) しかし、A,B間で同時に一貫性を保たなくても良いケースは、企業間システム連携ではよくあります。 CAP定理でいうところの可用性＋分断耐性をとりにいくパターンです。が、最大数秒程度で結果整合性は保ちにいきます。 システム間の接続 非同期ながら、ほぼリアルタイムでデータを反映していくので、応答性の高い接続手段が求められます。だが中間経路をHTTPでないプロトコルを通すハードルが高かったり、ファイヤーウォールなどで長時間接続を切られたりする問題があるので、私はよくWebSocketを使います。 だいたいの構成は以下のようになります。同期エージェント間をWebSocketでつなぎ、

アプリケーションエンジニアの多くは、眠れない夜を過ごしたことがあるでしょう。特に月に一度の…「月末締めバッチ」の日は。 そんなデータ量の多い日や、初モノのバッチが動く日でも安心して眠れるためのバッチ設計を考えてみます。 ログの設計 まず何はなくともログです。きちんとしたメッセージを出せていれば、専任の人がリカバリ可能にもなるってものです。 Audit用のログなど業務要件の強いものを除いては、だいたい3種類に分けるようにしています。 プログレスログ リカバリログ 例外ログ(調査のため) この分類でファイル単位も分けます。ログを必要とする人が、それぞれ異なるからです。 プログレスログ プログレスログは、特に長時間かかるバッチに対して、現在どのくらいまで処理が出来ているのかを目的として出力します。 トラブル発生時や、大規模移行作業時には、バッチの定期的なモニタリングと報告の必要が出てきます。「あ