増刊号この広告は、90日以上更新していないブログに表示しています。2014-08-02電子マネー決済ゲートウエイ雑ちょっと前に、ある機器での電子マネー決済サービスがはじまりました(・ω・)そのサービス用の、ゲートウエイサーバを作ったりしたわけですが。決済サービス自体のサーバ群は元々あるものを使い、サーバ向けのプロトコルと機器向けのプロトコルの変換を行うだけのものなので大したものではないんですが、そのアーキテクチャについてなんか少し雑記。基本構造ゲートウエイはJava*1でてきています(・ω・)Webサービスとかではなくて、パフォーマンスが要求されるAPサーバー/ミドルというと、速度の観点からC/C++でみたいなイメージがあったりしますが。今回のゲートウエイ開発の前にも、Android向け決済でのミドルやサーバー開発なんかをしており、その段階でC++での性能検証なんかもしていて。C++だと開発環境面などでの面倒さなどもあり、若干の工夫は必要ですがJavaでも十分な性能を出せることを検証した上で、Javaを選択しています。*2通信のI/Oモデル構成とししては、非同期I/Oとスレッドプールの合わせ技です。ゲートウエイの特性として、機器側の通信と上位サーバ側の通信という、2方向/複数のTCP及びUDP通信を非同期I/Oで処理しています。非同期I/Oなのは、性能面での工夫もありますが、プロトコルがリクエスト/レスポンスのような単純なものではなく、双方向から任意の時点でデータ受信が発生するものであるので、それを処理するためでもあります。セッションはステートフルであり、非同期I/Oとステートフルという点については、プロトコルスタックや変換レイヤをそれぞれステートマシンとして実装し、ステートマシンを大小さまざまな歯車を組み合わせるようなイメージでセッションの処理を構成しています。GoFのデザパタ的に言えば、十数個のパターンを使用していますが。Injectionパターンなんかも使用しています。これも、よく聞くように、DIはテストのためとか言ってみたり、わけもわからずインターフェースと実装を分離しているというような話ではなくて、問題解決に適した手段だから使用しているのであり、本当にプロバイダーもでるが必要なところでしかインターフェースと実装は分離していません。́д`;)必要なケースでは普通にオブジェクト指向の知識は必要になるので、LOBアプリ開発者も、一度はエディタ、言語(スクリプト含)、サーバーミドル、ゲーム等を開発してみるべきだ、っというのが私の持論です。そんな知識はなくてもLOBアプリを作ることはできる、っというのは単に見識の狭さと自分が土方作業者であることを露見させる発言でしかなく、こういった知識を応用して問題を解決するのが本当のSIだと自分は考えます、なんつって(・∀・)なお、ドメイン的な話や、ファンクショナル的な話については、変換部分については割とドメインドメインしていたり(なんのこっちゃ)、Action/FunctionインターフェースやMaybe的な実装も普通にあるのですが、そこは今回はたいした話は無いので省略します。...っと、その一方で、OOとは少し違う工夫をしている部分もあります。JavaらしくないJava?パフォーマンスについて、基本的な部分についてはJavaの速度で問題無いのですが、それでもアプリケーションの特性的に注意が必要な部分もあります。決済という特性上、カードとの通信、ユーザへのインタラクション、非同期I/OやUDP通信とタイムアウト等を考慮した場合、処理の遅延はなるべく排除したい所です。́)ただし、細かい部分までチューニングした作りにしているわけではなく、プロファイルによる分析をしたうえで、影響の大きいオブジェクトについてのみ工夫を行い、JavaらしくないJava、CみたいなJava、っという所まではチューニングしていません。感覚的に言うと、負荷100%の状態になった状態で、結構な頻度で100msの遅延が発生する、は許せないが、まれに10msの遅延が発生する、くらいなら許容できる、っというくらいには工夫をしている、っという所でしょうか。CPUバウンドなの?負荷100%という話が出ましたが、ゲートウエイがCPUバウンドな作りなのかというと、そうです(・ω・)機器側及び上位側に対して、1決済につき複数回の暗号化/署名が発生するため、CPUバウンドな処理になっています。4770な環境で450決済/sといった程度でしょうか。通信について言えば、1決済あたり50パケットと前述しましたが、単純に計算して1秒あたり22000〜23000パケットを捌いているわけで、通信性能的にはたいしたことはありません。reqres/sくらいは普通に処理可能です。*4その他の工夫や周辺ツールについて後は、その他のトピックについて少し。́)今時だと、Webアプリなどにおいても、運用の改善や問題の兆候を捉えるため、アプリケーション固有のメトリクス値の提供等は必須であるともいえるかと思います。ログについても、メトリクス値同様、収集して分析することで、問題の兆候の発見や設定値の改善に役立てることが可能な情報を出力するようにしています。ログの粒度、項目、形式などについては、昨今のログ分析等におけるトレンドを踏まえ、最適な形とはどのようなものなのかについて、もう少し学んでみたいところです(・ω・)ところで、ゲートウエイ自体はJava製なんですが、テストツール等、周辺ツールはC#で作っていたりします。機器の変わりのダミークライアントは普通のWPFアプリでMVVMとかしてますし、機器のクライアントミドル相当品もC#で作ってあって、それを使えば機器の決済と同様の事ができるものにはなっています。*5あとは、ベンチマーク用の疑似クライアント、疑似サーバなんかも、C#で作ってそれをMono上で動作させたりもしています。これら疑似クライアント、疑似サーバの通信I/Oモデルについては、Java側の作りと共有できる部分は共有した作りにするため(単に手抜きのため)、libeventモドキな抽象化機構で作っていたりします。そげな感じ(・ω・)*1:開発時期は一年前くらいから去年の末までくらい。Forms用だけど、まだ使う人も居るかもしれないので、0.7に更新しておきました(・ω・)更新内容は以下。使えるようになったら、規約で禁止系のネタとかがありますが。8構文へなかなか対応しない状況が続くのではないかというあたりだったりもして(・ω・;)その問題がクリアされれば、8構文の導入にGoを出すし、逆にラムダを使っていなかったらレビューで指摘も飛びますが。́・ω・`).NETとか、使える言語ではロジックを書くときにラムダを使うのは普通になってきていると思うのよ。あるプロジェクトのロジック層における「=>」の出現率(非ドメイン層を含まないドメイン層の中だけの数値)はNCSS:3376に対して360で、約11%、今時だとまあこんなもんかしら(・ω・)?もにゃど(。)ニャーンとかを意識したコードはまだそれほどでも無い感があるので、それが入ってくるともう少し数値はあがる気もしますが。Objects)さんとかが活躍するのは、コアドメイン層のロジックの他に、データストアモデルの構造からレゼンテーション用に変換するプレゼンテーションモデルのあたりとか(・ω・)プレゼンテーションモデルについても、ぶつぶつつぶやいている気がするので、それもそのうち再録するる。「DI嫌い」っていう話をよく聞くと、「IFと実装の対応が分かりにくい」みたいな理由は多いけど(・ω・)それって、なにも考えずに「全ての要素はIFと実装はセットで用意すべき」だと思い込んでるアホな設計の話とか、DIパターン及びコンテナの話を混同しているだけだったりすることも(・ω・)?なんでもIFと実装分離パターンに対するイライラを、DIやデータアクセスパターンのせいにするケースを未だに見るけど、それってDIやパターンの問題じゃ無いと思うのよ。自分んらの所の、設計と(使っている)実装の問題にすぎねーからな、なんつったりもして(・∀・;)あと、未だにDIとAOPを混同しているケースがあるのはどうしたもんかしらん。Injectionパターンと、AOPの話と、コンポーネント管理(アプリケーション固有の設計方針)の話を混同した、割とありがちな話じゃないかと思うの(・ω・)コンポーネント管理としてのDIは必要、AOPが出てくるのは拡張ポイントが不十分な証拠、もしくは対象の前後に処理を挟みたいものはRAII的な手法でスコープを使ってやれ、...っという考えは前から変わっていないんだけど、最近はなにか変ってきているところもあるのかしら(・ω・)?DIを使う目的として、テストを引き合いに出されるのはどうも違和感があるノ(・ω・)テスタビリティの話は、コンポーネントのモジュラリティの話で、DIを使うかはどうでも良いし。コンポーネントの組み立てに使うためにDIを使う、っというだけじゃイカん崎(・ω・)?テストのために、ControllerやServiceみたいなものまでIFと実装を分離するとか、単に何も考えていない証拠だと思うのよ。設計的に、本来プロバイダーモデルを用いるべき所だけモックに差し替えられれば、テストで困ることもない、っとも前から思っているのだけど(・ω・)テストというと、Webだけやっていて、ユニットテストがピンと来ないというのは分らんでもないけど(・ω・)単純に言ってしまえば、「ステート」も無ければ「ロジック」も無いからで(・ω・)対象がステートやロジックを持っていないとユニットテストの価値は感じにくいわけで、ユニットテストのお勉強で自販機なんかがよく例題に出されるのも、その観点から適当な題材ということだし(・ω・)シンプルなWebアプリの場合、バウンダリから永続化までが単純な呼び出しになるので、ルート、コントローラー、データストアとかのテストにたいした意味を見いだせないというのは、まあそうかなと。́)これはCIで都度走らせるにはコストが高くなるので、Dailyでとか、コード/コンポーネントの検証というよりリリース状態を保てているかの検証になりますが(・ω・)Webアプリの場合、ユニットというより、回帰テストという点を全面的に打ち出して、ユースケースの単位で、モックの代わりにVMを使い、ステートはDBとかにパーシストされたものを検証、っという方が良いと思うのよ(・∀・)テスト内の処理の呼び口は、サービスファサードで、コストメリットがあると思えばコントローラー層に対する疑似リクエストからやっても良いけど。UIレベルのテスト?、コストメリットがあると思えばね...。́・ω・`)そもそも、モックの多いテストというものについては、そのテストに意味があるのかという以前に、そもそも構成が正しいのかという疑念があり(・ω・)テストの話というか、責務の設計とかの話については、Webアプリを例にしても、たいした議論にならんだろうと思う面もあったりするけれど(・ω・;)Webアプリの場合、アーキテクチャを単純化された公式に当てはめちゃっても、ぶっちゃけ困らないことも多いので、それで何か語るって言ってもな〜、つって(・∀・;)テストの価値とか、責務の設計、機能の分割というよりオブジェクト間の契約について議論するのであれば、Web以外のドメインを例にしないと価値が伝わりずらいよね、っと(・ω・)まあ、Webのアーキテクチャは単純だとかなんとか言うと、ちょっと反感を覚えないでもないけど。言うなら、注力するポイントはそこではないというべきかしら(・ω・)?じゃあ、注力するポイントはどこなのかと言うと、あんまり良い回答じゃない気もするけど、ビュジュアリゼーションとか、スケーラビリティ、モニタリングとか(・ω・)?まあ、テストを含め、責務の設計とか語るのは、他のドメインのソフトウエア開発を色々やってからでも良いと思うのよ(・ω・)組み込み(といっても低レイヤの意味ではなく、ステートを持ったものの意味、自販機もこの範疇)とか、人のメンタルモデルのシミュレーションをして結果を得るようなアプリケーションだとか。それまで、ステートと複雑なロジックの組み合わせによる決済系の処理をやっていた若者が、Webアプリケーションをやりはじめて、「Webアプリケーションって簡単ですね」っと言った言葉を、おじさん、忘れられなくて(・∀・;)閑話休題、話をDIに戻して。゚д゚)アーキテクトのテクニカルリードがヘボなだけで無駄が多いとか、そんな話も(・ω・;)そういうものまでも、上手くいっていかないことの免罪符として「大規模」という言葉を使われることは多い気もするので、あまり人の言う「大規模」という言葉を信じるのはどうかなあと思ったりして(・∀・;)あと、単純なものが、数が多いだけのものを大規模というのか?、という話もありますが。これが僕たちのリアルTweet広告を非表示にするもっと読むコメントを書く2013-11-07SI屋のWebなLOBアプリ再録SI屋がやってるLOBアプリと、Web屋がやっているシステムは、使っているテクノロジーは似ていても、やっていることは大きく違うという話もありますが。本当にそうか(・ω・)?、っというのが最近の自分の認識。ぎょーむシステムなので、フォームやグリッドが量産できればそれで良いのかというと、そんなものに価値があるの(・ω・)?、っというわけで。́)、っと言うのはチト恥ずかしい。本当に価値のあるもの、その構築に必要なノウハウや技術って、Web系の先端スキルとそんなに差異ってないよね(・ω・)?、っといのが現時点でのとりあえずの結論。使い勝手にしても、業務系なWebアプリでも、結局ソーシャルなWebアプリと同じようなものが求められるよね(・ω・)?、っというのが自分の観測範囲の結論で。これは、利用者が、ソーシャル系のWebアプリみたいなものの使い勝手に慣れてきているから、っというのが大きいんだと思いますが。その一方で、世の中には汎用機的なUIを求められているWebシステムとかもあるんでしょうが(・∀・;)LOBシステムにおけるJavaScriptの使い方とかも、時代とともにニーズは変わってきていて。゚д゚)っという感じで。́д`;)JSのフレームワークは勝ち馬に乗っかりたいものの。APIとかコントローラー周りはあまり困っていないというか、今はクライアントサイドを作る技術の方が重要なので。困っていないのは、あくまでアプリケーションのレイヤ内の話であって、外部サービス/データストアの先については悩むことも多いですが。́・∀・`)よくインフラ層とアプリ層のスキルは独立して見られがちだけど、インフラ/ミドルの設計スキルがあると無いとではアプリ層の設計にも大きな差異が現れるし、LOBアプリだから分岐や繰り返しが書ければOKといまだに思っているのはサッカリンの10倍くらい甘い考えよね(・ω・)LOBアプリはパッケージを使え、それで満足できないものはエンドユーザが自分で特化した用途で生産性の高いツールを作って作れ、本物のプログラマはアドホックな課題を解決するために働け。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。