SoR系 分散業務処理システムでのもろもろ考慮点（勢い版 2017.07
•Transferir como PPTX, PDF•
1 gostou•2,281 visualizações
業務系バリバリな SoR な分散させる業務処理システムでの、バグ踏みがちな、運用で困りがちな、スケールしていく際に汗と涙になっていくもろもろを、運用保守と実装考慮点の観点で。これから業務系に踏み込む若手に向けて。 2017年07月版
Recomendados
Recomendados
Mais conteúdo relacionado
Semelhante a SoR系 分散業務処理システムでのもろもろ考慮点（勢い版 2017.07
Semelhante a SoR系 分散業務処理システムでのもろもろ考慮点（勢い版 2017.07 (20)
Mais de Arichika TANIGUCHI
Último
Último (11)
SoR系 分散業務処理システムでのもろもろ考慮点（勢い版 2017.07
- 1. SoR-System-Architecture & Operations-Managements - 2017.07 SoR系分散システムでの もろもろ考慮点（勢い版 2017/07/12.01 CC BY-SA 4.0 1
- 3. プログラムの話題：意外とクラウドデザイン ◦ メッセージンほか非同期化は前提 ◦ 画面系はメモリ・スレッドの消費がきつくGC負荷も高い ◦ 安定的な動作を狙うと、外部系との送受信は非同期メッセージングに ◦ 結果的にモジュール切り替えを容易にする運用可用性も向上 • 特定通信だけ別にキューに投げる、止めるなども ◦ DB はすぐに厳しくなるけど、やっぱり便利なRDB ◦ JOIN やストプロは注意 • トランザクションのテーブル範囲を考慮しないと後で分割大変 ◦ 結果として NoSQLなりメモリ処理なり必要になる ◦ 新規開発で画面単位で責任と開発を分担すると失敗の元 ◦ モデル側が画面を意識してデータ構造を設計するしかない 3CC BY-SA 4.0 そんなあなたに Azure Cosmos DB？ ウフフ？なのか？
- 4. 基盤の話題： SoR＝Tx単位をどこで割るか ◦ L7スイッチで割るか ～ DBで割るか + 口座 または 機能で割る L7/DNSで口座単位/機能で Webを割る Webで口座単位/機能で AP/DBを割る APで口座単位で DBを割る DBを口座単位/機能で割る HTTP HTTP/EJB/COM/TCP JDBC/etc. JDBC/etc. 4CC BY-SA 4.0 ＝規模がでかいと、マイクロサービスが視野に入ってくる
- 5. 運用の話題：運用保守の設計はレイヤーでチェック CC BY-SA 4.0 5 ◦ 運用：システムの日々の正常な稼働を担保する業務 ◦ 保守：脆弱性対応や機能改善を図りシステムのビジネス上の効能を維持強化する業務 運用 保守 正常性監視 Fire Wall / WAF サーバー証明書 アクセス管理設計 業務プログラム ライブラリ環境 ランタイム環境 ミドルウェア環境 OS 仮想サーバー 物理サーバー ネットワーク Data Center 自分達で決めるんよ ＝情報セキュリティ3要素の観点で、 見るべきもの、 運用保守のマッピングも変わる クラウドを使うと、運用保守の設計が 変わってくる。 グローバルレベルのパブリッククラウドなら、 彼らにオフロードしたほうが良いことも多々。
- 8. G.C. (CPU時間 ＋ I/O待ち時間) x 処理数 ◦ I/O待ちが asynchronous / 同期 でも非同期でも推測は可能 ◦ （バッチ処理並列数などの）同時要求数と実行時間の割合、 コア数で、その規模のシステムがどう振る舞うかは見積が可能 CC BY-SA 4.0 8 各種 ディスパッチ CPU演算処理 DB等 外部 I/O CPU演算処理 レスポンス 送り出し .Open() .Close() CPU割り当て中 ユーザーモードで実行 応答待ちでCPU処理は 一部カーネルやランタイムへ モダン非同期処理の場合、 この時間のCPU時間消費は低減 CPU割り当て中 カーネルモード （例えばLL言語等の） DB接続の生存期間例 （コンパイル系言語の） DB接続の生存期間例 Windows ライクな例：
- 9. 大半は口座の一貫性での問題 ◦ ステートレス処理系でありたい vs. メモリキャッシュ実装 ◦ e.g. 入金処理 → 口座状態変化 → 口座単位キャッシュどう破棄する？ ◦ 〃 マスタに情報追加→マスタキャッシュどう更新する？ ◦ バッチ中の日付参照、マスタ参照をどこでこなすか • オンライン分離しバッチ処理プロセス内部で持たせるテクニックも ◦ KVSでpub/subなど類似の通知機能？ 整合性観点で銀の弾丸ではない CC BY-SA 4.0 9 Web Tier AP Tier Ext. Cache Tier In Proc. Ext Proc. file In Proc. Ext Proc. OutputCache. DB/KVS 当然だけど（接続プール前提として） RDBMS参照前提で動くモノ作って 負荷を見ながら調整したほうが楽。 その際、モノシリックに書かず 役割・機能で多層化しておく。 SQL Server だと クエリ通知とかあるが… Pub/Subで通知する？ 変更時外部キャッシュを 消してしまう？ 口座情報だと結構しんどい話になる
- 10. （例えばI/Oを）リアルタイムで反映させるとき ◦ 並列平行で入りうる処理での順序を維持した実行はどうするか ◦ 有名商品の注文開始や拘束などのレースコンディション ◦ （初歩的だけど）2ブラウザからの同時発注のトランザクション制御 ◦ 結局は口座単位を軸に処理をシリアライズするしかないが… • ロック粒度を小さく（口座単位でさらに商品毎など）すればするほど大変に • RDBMS/キャッシュの場合は、ダーティーリード＋執行時の再チェック＋ロック CC BY-SA 4.0 10 口座状態日中マスタ 更新作業 注文操作 外部I/O応答 リアルタイム 入出金 バッチ 入出金 事務・オペ 操作 バッチ 帳票 口座状態 参照 外部処理系 取り込み
- 11. トランザクションの順序の問題 ◦ 現状復帰が可能なトランザクジョン順序になっているか ◦ DBトランが使えない範囲（メモリキャッシュ・KVS・メモリ）を含む トランザクションの一貫性確保をどう設計するか ◦ 復旧モデルを愚直に設計、実装するほかないが… CC BY-SA 4.0 11 DBトランを保持するロングトランは命取り キャッシュ飛ばしシグナルだけを同トラン？ 不可視期間設定ムズい注文時状態のログ必須 ログ取り過ぎて 性能出ないなんてのも
- 12. 異常終了した際のリカバリが容易な設計か ◦ バッチの並列平行実行、異常終了時と再実行の可用性 ◦ 速度向上を目指し並列平行化、あるジョブが異常終了→再実行可能？ ◦ バッチ処理直前直後の状態を何かしらの方法で復元可能？ CC BY-SA 4.0 12 バッチ処理 #X 下一桁が 0 下一桁が 1 下一桁が 2 下一桁が 3 下一桁が 4 下一桁が 5 下一桁が 6 下一桁が 7 下一桁が 8 下一桁が 9 口座を分割処理して実行していた 単一ジョブが途中の口座の状態不正で異常終了した！！ トランザクションは処理時点までコミット？全ロールバック？ 全てのバッチ処理が終わるまで再実行不可能？ 異常終了ジョブだけ再実行可能？ 全体ジョブの振る舞いは？ 冪統制があるジョブ設計か？ （そもそもで分割して性能が出る設計なのかという話も。）
- 13. データ群の状態推移をどうキャプチャする？ ◦ 過去のある時点での状態をどのように推測可能にするか ◦ ひたすらにログする？（それも手）ヒストリカルデータ化？ ◦ 機密情報までもログするとあとで大問題に（e.g パスワードなど CC BY-SA 4.0 13 財布のお金 1,500,000 その時点でホントにその計算額を表示していたのか その時点でその計算は正しかったのか 買えない、買いすぎた、立替追証原因で話題になりがち かといって参照を全てロギングするのは非現実 注文時点での各種関連パラメータはどこかで保持したい けどパスやセキュリティコード取得で死亡するよ クラウドだと無闇矢鱈なログ取りでも、まだ楽だけど 財布のお金 1,650,000 財布のお金 1,320,000
- 14. プログラムを部分的に動的に差し替えたい ◦ その設計、無停止・瞬断レベルでの切替は可能？ ◦ クラウド時代はブルーグリーンデプロイは視野に • とはいえ、コンテナ型ならともかく、単なる IaaS では厳しい現実 ◦ 部分デプロイを可能にするミドルウェア？基盤設計で担保？ • Windows での DLL 環境や .NET 環境なら、やりようは結構ある CC BY-SA 4.0 14 Front サイド Front サイド Front サイド Front サイド Front サイド Front サイド Load Balancer外部 Load Balancer 内部LB Front サイド Front サイド Front サイド Front サイド Front サイド AP サイド ここは ^^^ 比較的楽な事が多い Ngix/ HAProxy でも Big IP でも機能あるし クラウドLBでも対応可能だったりする （というか InProc セッションは使わない前提） ここは ^^^ 設計が難しい A/A構成が理想だけどキャッシュ・ステート管理次第 AP正副構成を設計するけど状態異常が起こりやすい （死んでると誤認して双方に投げてキャッシュ状態異常）
- 17. 前提となる用語のメモ ◦ 「非同期」の表現 ◦ メッセージング によるノード間やプロセス間「非同期通信」 • 業務上、結果セットの応答が非同期になりがち ◦ async / await なスレッド「非同期実行」 • 業務上は、同期的な体験に ◦ 結局はコアを「がめる」のをどこで防ぐか＝スループット指向 ◦ ショートトランへの拘りと並列共存する ◦ UIのブロッキングからI/Oのブロッキングまで ◦ 同時に捌ける処理を増やす＝仮に遅くても死ににくいシステムへ ◦ この資料では、それぞれの文脈にあわせて暗黙的に使い分け CC BY-SA 4.0 17
- 18. 結局は、突合をどう実現するかにつきる ◦ 計算処理が正しいか、サブシステム間でどう担保するか ◦ ログの遅延サマリとDBのダーティリードサマリを定期的に見る ◦ サブシステム間でそれぞれ同じ意味を表す別の計算を付き合わせる ◦ 金回りはシビアに、〆まで待っての照合では、今は遅いぐらい ◦ 一方で、参照メイン情報系は結構てきとーなところも ◦ 結果整合性で問題ある？全て同期で送りきれるの？ ◦ 遅延もあるので TCP で送ってると間に合わないけども ◦ 四捨五入の丸め誤差（JIS丸め？四捨五入？顧客有利？）注意 ◦ 通常フロント側で丸めるのは概算が大半だけども1円ちがったりする CC BY-SA 4.0 18
- 19. 注文系処理の概要 ◦ 注文という行為は外部処理系と自システムで非同期なので… ◦ すれ違いは普通に起きる⇒ 取消が無効などは当然起こる ◦ 注文行為中にバック側で状態調整することさえ起こるのが当然 ◦ 外部系シグナル（含むWebHook）を系に通知する方法は… ◦ キャッシュやメモリの更新＋ツールへの更新シグナルの送信 ◦ 状態を都度同期するか、注文状態を個別に整合するかはアプリ次第 ◦ アーキ上は設計が楽しいところ。 ◦ 結局はベタな条件判定な業務トランになりがち ◦ トランザクションスクリプトとOOPの使い分けが楽しいところ CC BY-SA 4.0 19
- 20. 注文系処理の概要 ◦ キュー/メッセージ非同期を挟む位置で個性（実装設計次第） ◦ 黄色：G/Wの能力に依存せず投げられる / 振る舞い決定は AP に集約 • 分散の自由度がある / Web側のコーディングに一貫性がある ◦ 橙色：APが自分の役割に応じてキューを取得 / Web 側Returnが速い • APの性能を逃がしやすいが偏る場合も / AP 障害でGWにバッファ必須 ◦ 緑色：業務処理を挟みやすく既存の通信プロトコルを利用可能 • でもAPが死んだら残存キューを取りに行けない CC BY-SA 4.0 20 Web AP 外接 G/W 外部 処理系 上り下り非同期 非同期 非同期 非同期
- 21. 情報系処理の概要 ◦ CQRS パターン的な観点必須 ◦ 更新と参照でアクセスパターンが違うので ◦ 順序整合性を保つのも、処理系によっては必須で業務依存 ◦ 配信/受信でよくあるのはハシゴなシステムデザイン ◦ e.g. ロンドン取引所（事例をロスト…） ◦ 複数のノードで同様の処理をばらして、負荷を分散していく ◦ 高負荷SoRはGC・遅延との戦い ◦ 金があるなら、FPGAでフィルタ処理してメモリに書きたいぐらい ◦ 任せられる配信基盤があるなら、任せたほうが楽 CC BY-SA 4.0 21
- 22. 情報系処理の概要 ◦ 期待する処理能力にあわせてひたすらばらす ◦ TCP同期的でもソケットバッファで調整は可能 ◦ 外部ストレージIOがある非同期だとキツい ◦ 非同期メッセージング使っても滞留してたら負け、同期的処理で勝て るように作る CC BY-SA 4.0 22 Data Store (永続的) 配信 管理 受信 G/W 外部 処理系 受信 G/W 配信 管理 Data Writer Data Writer Data Store (メモリ) Data Writer Data Writer エレメントをフィルタリングしたり配信先を変えたり ストリーミング的な処理も担う ↓ ケースもある 多段実装ケースが 大半
- 23. バッチ処理の概要 ◦ 結局はジョブ管理（機能を持つ/自作含む）アプリが必須 ◦ 無いなら無いで再実行 Interface や状態管理の一元管理は必須に ◦ 営業日の管理や特殊日の設定、スキップ保留も必須 • 特に金融はマスタの更新など多々細かい考慮があるもの ◦ 商用は Agent License がなかなかに…（一部作り込みになるよね） ◦ よくある課題：オンラインへの影響をどう評価するか ◦ バッチ専用サーバーでも処理が出来ること、できないことを意識 ◦ バッチ負荷を限定する管理設計が出来れば、同一ノードでも可 ◦ APやWebで優先度を下げたプロセスで処理するのも可能だけど、まぁ がっさり分けたほうが楽で安全ではある CC BY-SA 4.0 23
- 24. バッチ処理の概要 ◦ ヘビーI/Oとスレッドヘビーループの塊なので設計は重要 ◦ AP側で実行する＝スレッドがコアを「がめる」のでI/O非同期必須に CC BY-SA 4.0 24 AP (e.g. 12core) AP (e.g. 12core) AP (e.g. 12core) Batch (e.g. 12core) Batch (e.g. 12core) Batch (e.g. 12core) Batch Control Batch Control 冗長化必須！！ 案外わすれがち Batch 向け？ 商品別？ オンライン向け？ スレッド数のマネジメントと CPU割り当ての制限管理 ⇒ 実装上しんどい・優先制御が見えにくい メモリ上の預かりキャッシュに依存 ⇒またぐ系のバッチや異常終了でしんどい 相応の設計しないとなにかとアレ ぶん投げてCPU負荷など見るだけ マスタや日付などキャッシュ化必須 データストアが外部なので非同期I/Oで ⇒不具合は起きにくいけど… APのInProcメモリが正の場合には困る 口座ロックの手段と 外部ノードのキャッシュクリアが必要なことも
- 25. バッチ処理の概要 ◦ 夜間のバッチに頼ったら「負け」な時代 ◦ 24時間何かしらオンラインになってるサービス水準が当然に ◦ 銀行も24時間オンライン決済を目指す（全銀協2018年目処） ◦ いつでも入金されうる時代になった ◦ ⇒ 全口座のバッチが終わらないと入金が出来ないの？（前時代的 ◦ 帳票の扱い＝バックオフィスで対応？オンライン側の日記帳は？ ◦ 結局、口座単位、商品単位での締め時刻の概念が必須 ◦ 25時や30時という概念も視野に入れていい CC BY-SA 4.0 25
- 26. バッチ処理の概要 ◦ ストリーミング・バッチへの挑戦 ◦ 口座単位で処理される、整合性が担保可能な、口座単位で30秒程度で 終わるミニマムなバッチ処理を分散して実行するのであれば… ◦ ⇒ オンライン中に、顧客が指定した時刻に、または夜間の一定時間の 範囲で、その口座のI/Oを瞬間止めて、順次処理していいのでは？ ◦ クラウドチックなこの概念でシステム実装が出来るとベスト。 ◦ ここは夢が膨らむところだけど、業務活用の観点では規模を待 つので Stay Tuned. CC BY-SA 4.0 26
- 27. 運用・リリース・メンテナンス・監視 ◦ 業務運用の観点 ◦ 財布の整合性はリアルタイムに把握していくべき ◦ 入出金などの外部サブシステムからの更新処理はデッドロックになり やすい ◦ 過日の訂正は絶対に発生するものとして設計する • 注文レコード、取引結果のレコードの部分を修正ってのは絶対に発生する • ＝それは帳票に更新が入ることになる • 訂正せずに総量や金で解決し、結果の帳尻を合わせる手立ても視野に ◦ システム運用・システム監視の観点 ◦ 基本に忠実に、見続けるだけ、王道なし • ただし、閾値判定は物事を見誤る傾向あり • マルチコアでのCPU負荷とは（e.g. 8コアでシングルスレッド全力＝12%） CC BY-SA 4.0 27
- 28. 運用・リリース・メンテナンス・監視 ◦ リリース ◦ 従来は、夜間や休日メンテでの切替が大半 ◦ 本番同様データを用いて処理するステージング環境も視野に ◦ 理想は、本番環境を利用した口座単位のルーティングなどで、 パーシャル・リリースを実現する実行環境の実現 • フロントレイヤーでの分散処理を活用したいところ ◦ 大規模ソーシャルなCI/DI事例を参考に高度化していきたいところ ◦ 結局は、企業文化・リーダーに依存する部分は大きいが • リリース後の不具合を素早く見つけるために人がいる時間のほうが好ましい傾向 • 金曜の障害＝土日に直せる⇒なら木曜夜に切り替える、というパターンも CC BY-SA 4.0 28
- 29. 運用・リリース・メンテナンス・監視 ◦ 基盤側のメンテナンス ◦ OS基盤やミドルウェアへのパッチ適用は必須の時代 • 小さいシステムでも、ホントにあっさり改ざん・感染しますんで ◦ 対応が出来ないなら、バーチャルパッチ観点でWAFの導入必須 • クラウドで最低限の動作で安いものもあるよ ◦ せめてフロントエンドでは定期的な更新を行うこと ◦ データ側のメンテナンス ◦ RDBのインデックス・リビルドは環境にあわせて設計・運用 • 今はオンライン中でも可能なので、業務時間外をターゲットに実施でも ◦ RDBはテーブルの行数をコントロールする視点をもって • いつかは誰かがどこかで移動したり消したりする必要がある、を前提に CC BY-SA 4.0 29
- 30. 入出金処理の概要 ◦ 入金取り込み、名寄せ、預りへの反映、出金の拘束、… ◦ 全ての状態遷移に、その状態変更が有効になる日時が存在する ◦ 入金処理、出金処理する際には、キャッシュが問題になりがち ◦ 口座単位ロック・口座単位シリアライズは必須 • 入金出金処理だけロックせずに別のバッチサーバーで処理すると…（怪談） • 注文など計算の最中に入金された場合？ トランザクションの切れ目でブロックされる？可用性の設計次第 ◦ ロックフリー設計なら、ヒストリカルな挿入限定DBでいける！ • って、設計が複雑で、規模と費用対効果で判断（普通はそこまで出来ない） ◦ ダメ例： • CSV取り込み操作と、RDBへの反映作業が同一トランで、長時間全ロック CC BY-SA 4.0 30
- 31. 通知処理 ◦ 通知先で実装が違うので、通知の定義を決めること ◦ ブラウザへの通知フロント画面へのプッシュ • 役割的には、キャッシュ更新のトリガになることが多い • 低負荷ならDB＋画面更新でもいい / 負荷次第でKVSなりに逃がす ◦ メールやスマホなど非同期通信チャネルへの通知 • ピーク負荷に合わせるとでかいシステム実装になるので、クラウドを適材適所で 使うことも視野に • 非同期処理だとはいえAPI上で直接外部 API を叩くのは規模に合わせて要考慮 • メッセージング/キューでAP外に滞留させた上で、外部システムのAPIを叩くと楽 • クラウド側にオフロードしてもいいと思う • 実装が甘いとDB参照しがちなのでご注意部分 CC BY-SA 4.0 31
- 32. 通知処理 ◦ 多チャンネル化視野に ◦ 非同期後に役割毎に処理する、ザ・普通の設計 ◦ キャッシュクリアは専用システムで同期的に処理する場合も多々あり CC BY-SA 4.0 32 AP 分散化 前処理 非同期 非同期 Web CRM etc 非同期 チャン ネル チャン ネル チャン ネル DB更新 電子 メール API アプリ 通知 キャッシュ クリア 非同期 非同期 非同期
- 33. 認証処理 ◦ 今求められる当たり前の事を当たり前に ◦ パスワードは（初期パス以外は）ソルト追加しハッシュ化で保持 ◦ セカンド・パスワードよりも多要素認証（OTP）併用にシフト ◦ OAuth2.0 な 構成視野に、Idp/Sp を実装上、分けることを意識 ◦ 認証と認可は別の概念だとして設計すること ◦ セッション用トークンの自作時（非推奨）は類推を困難にすること • トークンの妥当性判断にDB/KVSを使わない設計の場合（復号可能タイプ） • 口座番号＋時刻[＋…] とかだと、ブロック暗号の場合に類推が容易 • Random＋時刻＋口座番号[＋…] とかだと、暗号文字列からの類推がやや困難に • トークンの妥当性判断にDB/KVSを使う設計（GUID発行系） • DBが死にやすいので負荷設計に注意（API化で瞬死するのでお勧めしない • 適当に叩いて偽装もし易いので設計考慮上、大変センシティブなところ ◦ ログインエンドポイントと業務処理基盤は別にしておくと気持ちが楽 CC BY-SA 4.0 33
- 34. 認証処理 ◦ ログイン処理を外部化する設計例 ◦ Idp で認証するイメージ CC BY-SA 4.0 34 ストア ID Provider ログイン処理系 Service Provider 業務処理系 IDパスチェック OTPチェック リスクベース カウンティング トークンチェック 認可チェック メモリ上の鍵 メモリ上の鍵 仕組み上DBはちょくちょく 見る必要がある 強制的な制御 I/Oでスレッドを「がめる」のが勿体ない 出来るだけメモリ上で完結させたい DDoSや侵入系の攻撃を分散する利点も ログイン前に制御