Repository navigation
Expand file tree
/
Copy patharchitecture.html
More file actions
691 lines (524 loc) · 52.9 KB
/
Copy patharchitecture.html
File metadata and controls
691 lines (524 loc) · 52.9 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<title>アーキテクチャ | SOCKET-MANAGER Framework For PHP</title>
<meta name="description" content="SOCKET-MANAGER Framework の CUEI/CUEI/O アーキテクチャを解説。通信抽象化・共有基盤・非同期処理・IPC を統合したプロトコル非依存のリアルタイム基盤を構築。ITIL v4 に対応した運用モデルを内蔵し、DevOps/ChatOps によるサービス管理・監視・自動化を実現。" />
<meta name="keywords" content="PHP, ソケット通信, アーキテクチャ, CUEI, CUEI/O, プロトコル抽象化, 非同期処理, ステートマシン, UNIT, Queue, CycleDrivenManager, IPC, マルチサーバー, ノンブロッキング, リアルタイム通信基盤, プロトコル非依存, 高負荷環境, スケーラブル設計, DevOps, ChatOps, 運用統合, サービス管理ランチャー, リソース監視, 管理者チャット, 内蔵型チャット, ITIL v4, 技術版 ITIL, サービスマネジメント, SVC, プラクティス, 運用ガバナンス, 継続的改善" />
<link rel="canonical" href="https://socket-manager.github.io/document/architecture.html" />
<script async src="https://www.googletagmanager.com/gtag/js?id=G-LF9W695NNW"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', 'G-LF9W695NNW');
</script>
<link rel="icon" href="https://socket-manager.github.io/document/favicon.ico" type="image/x-icon" />
<link type="text/css" rel="stylesheet" href="./css/common.css" media="all" />
<script src="./js/jquery-3.7.1.min.js"></script>
<script type="text/javascript" src="./js/common.js"></script>
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "TechArticle",
"headline": "SOCKET-MANAGER Framework - アーキテクチャ解説",
"description": "SOCKET-MANAGER Framework のアーキテクチャは、CUEI(Communication / Union / Event / IPC)を基盤とし、プロトコル非依存のリアルタイム処理を実現する統一レイヤー設計を採用しています。TCP・UDP・WebSocket・REST-API を同一モデルで扱える通信抽象化、FIFO バッファと UNIT/Queue モデルによる非同期イベント処理、CycleDrivenManager による状態遷移制御、マルチサーバー構成を前提とした IPC など、高負荷環境で安定稼働するための仕組みを体系化しています。
さらに、CUEI を運用領域まで拡張した CUEI/O モデルは、ITIL v4 のサービスマネジメント構造(価値・リスク・コスト、プラクティス、SVC)と対応しており、開発から運用までを一貫して扱える技術版 ITIL として機能します。SOCKET-MANAGER Launcher により、サービスの起動・停止・監視・設定管理を GUI/CLI から統合的に操作でき、運用ガバナンスと継続的改善を実現します。
加えて、Launcher には管理者間チャット機能をビルトインしており、Slack や Microsoft Teams のような外部サービス連携を必要としない内蔵型 ChatOps を提供します。接続・切断イベントの共有、操作ログとチャットログの分離管理、プライベートメッセージ対応など、リアルタイム連携と運用統制を強化する仕組みを標準搭載しています。
本ページでは、CUEI/CUEI/O アーキテクチャ、DevOps 環境、ChatOps 機能を図解付きで詳細に解説し、SOCKET-MANAGER Framework が提供する統合運用モデルの全体像を紹介します。",
"keywords": "PHP, ソケット通信, アーキテクチャ, CUEI, CUEI/O, プロトコル抽象化, 非同期処理, ステートマシン, UNIT, Queue, CycleDrivenManager, IPC, マルチサーバー, ノンブロッキング, リアルタイム通信基盤, プロトコル非依存, 高負荷環境, スケーラブル設計, DevOps, ChatOps, 運用統合, サービス管理ランチャー, リソース監視, 管理者チャット, 内蔵型チャット, ITIL v4, 技術版 ITIL, サービスマネジメント, SVC, プラクティス, 運用ガバナンス, 継続的改善",
"articleSection": [
"Architecture Overview",
"CUEI Model (Communication / Union / Event / IPC)",
"ITIL v4 Alignment and Technical Architecture",
"Protocol Abstraction Layer",
"Unified Foundation (Union)",
"Event-driven Processing and FIFO Queue",
"State Machine: UNIT / Queue Model",
"CycleDrivenManager and Non-blocking Execution",
"IPC and Multi-Server Architecture",
"CUEI/O: Development to Operation Integration",
"DevOps Environment and Service Management",
"ChatOps and Collaborative Operation",
"PHP-based Realtime Framework Design"
],
"image": "https://socket-manager.github.io/document/img/architecture/CUEIO.png",
"author": {
"@type": "Person",
"name": "SOCKET-MANAGER開発チーム"
},
"publisher": {
"@type": "Organization",
"name": "SOCKET-MANAGER",
"logo": {
"@type": "ImageObject",
"url": "https://socket-manager.github.io/document/logo.png",
"width": 355,
"height": 50
}
},
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://socket-manager.github.io/document/architecture.html"
},
"url": "https://socket-manager.github.io/document/architecture.html",
"breadcrumb": {
"@type": "BreadcrumbList",
"itemListElement": [{
"@type": "ListItem",
"position": 1,
"name": "Framework Top",
"item": "https://socket-manager.github.io/document/"
},{
"@type": "ListItem",
"position": 2,
"name": "アーキテクチャ",
"item": "https://socket-manager.github.io/document/architecture.html"
}]
},
"isPartOf": {
"@type": "WebSite",
"name": "フレームワークのご紹介",
"url": "https://socket-manager.github.io/document/"
}
}
</script>
</head>
<body>
<div class="layout">
<div class="menu" role="navigation" aria-label="ページメニュー">
<h2 class="menu-title">SOCKET-MANAGER</h2>
<h4 class="menu-reference menu-page-title-bottom"><a href="./reference/" target="_blank" rel="noopener">>> Reference</a></h4>
<h2 class="menu-label">MAIN-MENU</h2>
<div class="menu-text">
<h3 class="menu-page-title-link"><a href="./">▶フレームワークのご紹介</a></h3>
<h3 class="menu-page-title-link"><a href="./event-handler.html">▶イベントハンドラについて</a></h3>
</div>
<h3 class="menu-label-sub">IMPLEMENT</h3>
<div class="menu-text">
<h3 class="menu-page-title-link"><a href="./init-class.html">▶初期化クラス</a></h3>
<h3 class="menu-page-title-link"><a href="./unit-parameter.html">▶UNITパラメータクラス</a></h3>
<h3 class="menu-page-title-link"><a href="./protocol-unit.html">▶プロトコルUNITクラス</a></h3>
<h3 class="menu-page-title-link"><a href="./command-unit.html">▶コマンドUNITクラス</a></h3>
<h3 class="menu-page-title-link"><a href="./main.html">▶メイン処理クラス</a></h3>
<h3 class="menu-page-title-link"><a href="./setting.html">▶設定ファイル</a></h3>
<h3 class="menu-page-title-link"><a href="./message.html">▶メッセージファイル</a></h3>
</div>
<div class="menu-line"></div>
<div class="menu-text">
<h3 class="menu-page-title-link-for-runtime-manager"><a href="./runtime-manager/" target="_blank" rel="noopener">>> ランタイムライブラリ</a></h3>
<h3 class="menu-page-title-link-for-runtime-manager"><a href="./simple-socket/" target="_blank" rel="noopener">>> シンプルソケット機能</a></h3>
</div>
<h3 class="menu-label-sub">ADVANCED</h3>
<div class="menu-text">
<h3 class="menu-page-title-link"><a href="./concept.html">▶設計コンセプト</a></h3>
<h3 class="menu-page-title">▼アーキテクチャ</h3>
<ul>
<li><a href="./architecture.html#begin">はじめに</a></li>
</ul>
<ul>
<li><a href="./architecture.html#cueio">CUEI/O(開発から運用まで)</a></li>
</ul>
<ul>
<li><a href="./architecture.html#operation">Operation(運用モデル)</a></li>
</ul>
<ul>
<li><a href="./architecture.html#devops">DevOps運用統合</a></li>
</ul>
<ul>
<li><a href="./architecture.html#chatops">ChatOps運用連携</a></li>
</ul>
<ul>
<li><a href="./architecture.html#philosophy-architecture">アーキテクチャ思想</a></li>
</ul>
<ul>
<li><a href="./architecture.html#outline">レイヤー概念図</a></li>
</ul>
<ul>
<li><a href="./architecture.html#que_and_unit">キューとUNITの関係</a></li>
</ul>
<ul>
<li><a href="./architecture.html#unit-implementation">UNIT定義クラス</a></li>
</ul>
<ul>
<li><a href="./architecture.html#init">初期化クラス</a></li>
</ul>
<ul>
<li><a href="./architecture.html#main">メイン処理クラス</a></li>
</ul>
<ul>
<li><a href="./architecture.html#last">おわりに</a></li>
</ul>
<h3 class="menu-page-title-link"><a href="./communication.html">▶通信抽象化</a></h3>
<h3 class="menu-page-title-link"><a href="./union.html">▶共有基盤</a></h3>
<h3 class="menu-page-title-link"><a href="./event.html">▶イベント駆動アーキテクチャ</a></h3>
<h3 class="menu-page-title-link"><a href="./ipc.html">▶IPC(プロセス間通信)</a></h3>
<h3 class="menu-page-title-link"><a href="./multi-server.html">▶マルチサーバーの構成</a></h3>
<h3 class="menu-page-title-link"><a href="./tcp-and-udp.html">▶TCP/UDP通信について</a></h3>
<h3 class="menu-page-title-link"><a href="./laravel.html">▶Laravelと連携する</a></h3>
<h3 class="menu-page-title-link"><a href="./system-setting.html">▶システム設定ファイル</a></h3>
<h3 class="menu-page-title-link"><a href="./custom-command.html">▶カスタムコマンド作成機能</a></h3>
<h3 class="menu-page-title-link"><a href="./high-performance.html">▶ハイパフォーマンスモード</a></h3>
<h3 class="menu-page-title-link"><a href="./scale-test.html">▶WebSocket スケール性能</a></h3>
<h3 class="menu-page-title-link"><a href="./pure-tcp-scale.html">▶純粋 TCP スケール性能</a></h3>
<h3 class="menu-page-title-link"><a href="./itil.html">▶技術版 ITIL としての CUEI/O</a></h3>
</div>
<h3 class="menu-label-sub">OTHER-PROJECT</h3>
<div class="menu-text">
<h3 class="menu-page-title-link"><a href="./new-project.html">▶新規開発環境</a></h3>
<h3 class="menu-page-title-link"><a href="./websocket.html">▶Websocketサーバー開発環境</a></h3>
<h3 class="menu-page-title-link"><a href="./dev-ops.html">▶フレームワークのDevOps環境</a></h3>
</div>
<div class="menu-line"></div>
<div class="menu-text">
<h3 class="menu-page-title-link-for-minecraft"><a href="./minecraft-contents/" target="_blank" rel="noopener">>> マインクラフト専用環境</a></h3>
<h3 class="menu-page-title-link-for-launcher"><a href="./launcher/" target="_blank" rel="noopener">>> GUI & CLI ランチャー</a></h3>
<h3 class="menu-page-title-link-for-rest-api"><a href="./rest-api/" target="_blank" rel="noopener">>> REST-APIサーバー開発環境</a></h3>
</div>
<h2 class="menu-label">EXTRA-MENU</h2>
<div class="menu-text">
<h3 class="menu-page-title-link"><a href="./extra-demo.html">▶デモサーバーの種類</a></h3>
<h3 class="menu-page-title-link"><a href="./extra-demo-command.html">▶デモのコマンド仕様</a></h3>
<h3 class="menu-page-title-link"><a href="./extra-demo-setting.html">▶デモの設定ファイル</a></h3>
<h3 class="menu-page-title-link"><a href="./extra-minecraft.html">▶マインクラフトの通信仕様</a></h3>
<h3 class="menu-page-title-link"><a href="./extra-close-frame.html">▶切断フレームの検証</a></h3>
</div>
<h2 class="menu-label">PHP-TECHNIQUE</h2>
<div class="menu-text">
<h3 class="menu-page-title-link"><a href="./php-pass-by-reference.html">▶参照渡し</a></h3>
<h3 class="menu-page-title-link"><a href="./php-phpdoc.html">▶PHPDocのフォーマット</a></h3>
</div>
<div class="menu-dummy-for-framework"></div>
</div>
<div class="main" role="main">
<h1>【アーキテクチャ】</h1>
<a id="begin"></a>
<h2 class="subtitle">はじめに</h2>
<div class="text-block">
SOCKET-MANAGER Framework は、<strong>CUEIアーキテクチャ(キューイ、通称キュー)</strong> をビルトイン採用した、軽量で拡張性のある通信フレームワークです。<br />
CUEIアーキテクチャは、以下の4つの要素を統合した設計思想を指します。<br />
<ul>
<li><strong>Communication(通信抽象化)</strong>:多様なプロトコルを統一的に扱う</li>
<li><strong>Union(共有基盤)</strong>:処理全体を束ねる共有基盤</li>
<li><strong>Event(非同期処理)</strong>:イベント駆動型の非同期処理</li>
<li><strong>IPC(サーバー間通信)</strong>:マルチサーバー構成・分散処理</li>
</ul>
これら4つの柱をビルトインで備えることにより、外部ライブラリや追加サーバーに依存せず、効率的でスケーラブルな通信アプリケーションを構築できます。<br /><br />
CUEI アーキテクチャは、<strong>ITIL v4 のプラクティス体系を技術的に再構成したもの</strong> として設計されています。<br />
Communication / Union / Event / IPC の 4 要素は、ITIL v4 が定義する <strong>サービスマネジメント構造(価値、プラクティス、役割、改善モデル)と対応</strong> しており、リアルタイム通信システムに求められる複雑性・高負荷・分散性を統制するためのガバナンスを提供します。<br /><br />
この構造により、CUEI は <strong>設計段階から運用段階まで一貫した品質保証</strong> を可能にし、通信方式の抽象化、共通基盤の統制、非同期イベント処理、分散スケールといった要素を統合的に扱うことができます。<br />
ITIL v4 が掲げる「価値・リスク・コスト」の最適化を、<strong>ソケット通信領域に特化した技術アーキテクチャ</strong> として実現することで、将来の拡張性と運用の再現性を高いレベルで維持します。<br /><br />
これにより CUEI は、単なる通信アーキテクチャではなく、サービスマネジメントの観点からも一貫性を持つ「<strong>技術版 ITIL</strong>」として機能します。<br /><br />
CUEIは以下の4つの柱で構成されます。<br />
<div class="img-block">
<figure class="center-figure">
<a href="./img/architecture/CUEI.png" target="_blank" rel="noopener"><img src="./img/architecture/CUEI.png" width="700px" loading="eager" alt="四象限モデル(CUEIの4大要素)" title="CUEIアーキテクチャを構成する4大要素" /></a>
<figcaption><strong>CUEIアーキテクチャを構成する4大要素</strong></figcaption>
</figure><br />
</div>
<br />
<h3 class="underline">四象限モデル(CUEIの4要素)</h3>
CUEIアーキテクチャは、<strong>Communication / Union / Event / IPC</strong> の4要素を四象限モデルとして整理できます。<br />
それぞれが独立しつつも相互に連携し、フレームワーク全体を支える基盤を形成しています。<br />
<h4>当フレームワークで置き換えると…</h4>
<dl>
<dt>・Communication(通信抽象化)</dt>
<dd>
TCP・UDP・WebSocket・独自プロトコルなど多様な通信方式を抽象化する事でビジネスロジックとのシームレスな分離が可能。<br />
詳細は <font><a href="./communication.html">▶通信抽象化</a></font> を参照。<br /><br />
</dd>
<dt>・Union(共有基盤)</dt>
<dd>
UNITパラメータによる統合コンテキスト。イベント処理全体のハブとして機能し、接続情報や送受信データを一元管理。<br />
送受信データに関してはFIFO方式バッファを採用する事でイベント多重起動を防止。<br />
詳細は <font><a href="./union.html">▶共有基盤</a></font> を参照。<br /><br />
</dd>
<dt>・Event(非同期処理)</dt>
<dd>
独自のイベントループとコルーチンによる軽量なイベント駆動処理を実装する事で、動的なプロセスやスレッドに頼らない設計が可能。<br />
FIFOバッファの送受信データを順次取り出し、ビルトインの状態遷移制御により処理順序を保障。<br />
詳細は <font><a href="./event.html">▶イベント駆動アーキテクチャ</a></font> を参照。<br />
UNIT / Queue を用いたイベント処理の具体的な実装方法については、<font><a href="./event-handler.html">▶イベントハンドラについて</a></font> にて詳しく紹介しています。<br /><br />
</dd>
<dt>・IPC(サーバー間通信)</dt>
<dd>
サーバー間通信を前提としたマルチサーバー構成とスケーラビリティの確保。<br />
INETソケットを使う事でスケールアップ/スケールアウト時も統一的なインターフェースを提供する事が可能。<br />
詳細は <font><a href="./ipc.html">▶IPC(プロセス間通信)</a></font> を参照。<br /><br />
</dd>
</dl>
<strong>これらの4大要素を体系化する事で、自作によらないCLIコマンドによるスキャフォールディングのビルトイン実装を可能にしています。</strong><br />
</div><br />
<a id="cueio"></a>
<h2 class="subtitle">CUEI/O(開発から運用まで)</h2>
<div class="text-block">
SOCKET-MANAGER には <strong>SOCKET-MANAGER Launcher</strong> というサーバーリソース監視付きのサービス管理ランチャーを用意しています。<br />
これを組み合わせることで、<strong>CUEI/O(キューアイオー)</strong> として「開発から運用まで」を一貫してカバーできます。<br /><br />
<ul>
<li><strong>CUEI</strong> = 開発思想(通信・共有基盤・非同期処理・サーバー間通信)</li>
<li><strong>CUEI/O</strong> = 開発+運用(Operation)を含む完全版</li>
</ul>
「/O」を付けることで、運用まで含めた包括的な基盤であることを明示できます。<br /><br />
SOCKET-MANAGER Launcherを組み合わせることでCUEIはCUEI/Oへ拡張されます。<br />
<div class="img-block">
<figure class="center-figure">
<a href="./img/architecture/CUEIO.png" target="_blank" rel="noopener"><img src="./img/architecture/CUEIO.png" width="700px" fetchpriority="high" loading="eager" alt="CUEI/O──開発と運用を統合する拡張モデル" title="CUEI/O──開発と運用を統合する拡張モデル" /></a>
<figcaption><strong>CUEI/O──開発と運用を統合する拡張モデル</strong></figcaption>
</figure>
</div><br />
<p>
REST-API 環境における CUEI の実装レベルでの関係については、<font><a href="./rest-api/cuei.html" target="_blank" rel="noopener">▶CUEIとの実装レベルでの関係</a></font>を参照してください。<br />
CUEI/O の運用面での位置づけについては、<font><a href="./itil.html">▶技術版 ITIL としての CUEI/O</a></font>にて補足しています。
</p>
</div><br />
<a id="operation"></a>
<h2 class="subtitle">Operation(運用モデル)</h2>
<div class="text-block">
CUEI/O の「O(Operation)」は、SOCKET-MANAGER Framework における運用モデルを表します。<br />
開発時に構築した CUEI アーキテクチャを、そのまま運用フェーズへ拡張し、<strong>サービスの起動・停止・監視・設定管理・コミュニケーション</strong> を統合的に扱うための基盤です。<br /><br />
Operation レイヤーでは、以下の要素が中心となります。<br />
<ul>
<li><strong>サービス管理ランチャー</strong>:GUI/CLI ランチャーによるサービスの起動・停止・スケーリング</li>
<li><strong>リソース監視</strong>:CPU/メモリ/ディスクなどのリソース状況の可視化</li>
<li><strong>運用ガバナンス</strong>:操作ログ・チャットログによる透明性と追跡性の確保</li>
</ul>
これらにより、CUEI で構築した通信アプリケーションを、<strong>実運用スケールで安全に動かすための運用モデル</strong> として CUEI/O が完成します。<br />
</div><br />
<a id="devops"></a>
<h2 class="subtitle">DevOps環境:開発と運用を統合する基盤</h2>
<div class="text-block">
DevOps は「開発(Dev)」と「運用(Ops)」を統合する文化・仕組みです。<br />
SOCKET-MANAGER Framework の DevOps環境は、CUEI/Oモデルに準拠して設計されており、<strong>同一のランチャー環境で開発と運用をシームレスに接続</strong> できる点が特徴です。<br /><br />
SOCKET-MANAGER Launcher は、単なるサービス起動ツールではなく、<strong>リソース管理・監視機能・設定管理・新規開発環境</strong> を兼ね備えた統合基盤です。<br />
これにより、以下のような DevOps 実践が可能になります。<br />
<ul>
<li><strong>開発環境で運用を見据えたテストが可能</strong><br />
→ ローカル環境でも本番に近い条件で検証でき、リリース後のトラブルを未然に防止。</li>
<li><strong>本番環境へそのまま移行可能</strong><br />
→ 開発・検証環境と本番環境の差異を最小化し、デプロイ時のリスクを軽減。</li>
<li><strong>CLI/GUI ランチャーによるサービス管理</strong><br />
→ app:cli / app:gui コマンドを通じて、サービスの起動・停止・監視を一元化。</li>
</ul><br />
DevOps環境の詳細な導入手順やコマンド一覧については、<font><a href="./dev-ops.html" target="_blank" rel="noopener">▶フレームワークのDevOps環境</a></font>をご覧ください。<br />
</div><br />
<a id="chatops"></a>
<h2 class="subtitle">ChatOps:運用の会話主導化とリアルタイム連携</h2>
<div class="text-block">
ChatOps は、チャットを中心に運用情報・操作・通知を集約し、
チームの状況把握とインシデント対応を高速化する運用モデルです。<br />
SOCKET-MANAGER Launcher には、管理者同士がリアルタイムにやり取りできる
<strong>管理者間チャット機能</strong> がビルトインされており、
この ChatOps の考え方を取り入れた内蔵型の運用連携機能として機能します。<br /><br />
特筆すべき点として、本チャット機能は
<strong>Slack や Microsoft Teams のような外部サービスとの連携を必要としません</strong>。<br />
ランチャー内部にチャット基盤が組み込まれているため、
外部 API や Bot の設定を行うことなく、
<strong>導入直後から即座に ChatOps を実践できる軽量な運用環境</strong> を提供します。<br /><br />
管理者チャット機能では、以下のような運用上のメリットを提供します。<br />
<ul>
<li><strong>接続/切断イベントの共有</strong>:誰がいつ参加・離脱したかをチャットログとして記録</li>
<li><strong>操作ログとチャットログの分離管理</strong>:サービス操作履歴と会話履歴を別ファイルで管理し、監査性を向上</li>
<li><strong>プライベートメッセージ/全体メッセージ</strong>:宛先指定による個別連携と、全管理者への一斉通知</li>
<li><strong>GUI上でのリアルタイム連携</strong>:リソース監視・サービス一覧・チャットを同一画面で確認可能</li>
<li><strong>外部連携不要の内蔵型 ChatOps</strong>:外部チャットサービスの障害や認証トラブルの影響を受けない安定した運用基盤</li>
</ul><br />
これにより、SOCKET-MANAGER Launcher は、
<strong>DevOps環境における運用ハブ兼 ChatOpsプラットフォーム</strong> として機能し、
運用ガバナンスと即時性を両立します。<br /><br />
管理者間チャット機能の詳細な画面構成やログ管理の仕組みについては、
<font><a href="./chat.html" target="_blank" rel="noopener">▶管理者間チャット機能(ChatOps)</a></font>をご覧ください。<br />
</div><br />
<a id="philosophy-architecture"></a>
<h2 class="subtitle">アーキテクチャ思想</h2>
<div class="text-block">
SOCKET-MANAGER Framework のアーキテクチャは、
<strong>CUEI(Communication / Union / Event / IPC)</strong> を中心に構築されています。<br />
これは単なるイベントループや非同期処理の実装ではなく、
異なる通信方式を統一的に扱うための <strong>基盤レイヤー</strong> を提供するものです。<br /><br />
特に重要なのは、プロトコル部とコマンド部が
<strong>UNIT / Queue モデル</strong> によって接続されている点です。<br />
この構造により、WebSocket・TCP・UDP・REST-API といった
通信方式の違いを越えて、すべての処理が同じレイヤー構造で動作します。<br /><br />
また、CycleDrivenManager による状態遷移制御により、
非同期処理中でも <strong>状態破壊が起きない堅牢な実行環境</strong> を実現しています。<br />
これは一般的な非同期ランタイムでは難しい特徴であり、
本フレームワークが「実運用スケール」を重視する理由でもあります。<br /><br />
CUEIアーキテクチャは、通信方式やサーバー構成の違いを吸収し、
<strong>統一されたリアルタイム基盤(Unified Realtime Layer)</strong> として機能します。<br />
</div><br />
<a id="outline"></a>
<h2 class="subtitle">レイヤー概念図</h2>
<div class="text-block">
CUEIアーキテクチャの思想を具体的に実装した構造が、以下の「レイヤー概念図」です。<br />
ここではプロトコル部とコマンド部の分離、UNITパラメータの役割、CycleDrivenManagerによる制御など、ノンブロッキングモードによる実装を前提とした仕組みを詳しく解説していきます。<br />
<div class="img-block">
<a href="./img/architecture/outline.png" target="_blank" rel="noopener"><img class="img-zoomout" src="./img/architecture/outline.png" loading="lazy" alt="SOCKET-MANAGERフレームワークのレイヤー構造図" /></a>
</div>
サーバーのアプリケーションの部分はプロトコル部とコマンド部に大きく分かれています。<br />
最初にそれらをライブラリ内の <code>CycleDrivenManager</code> のプロトコル部とコマンド部へ取り込ませてから使う事になります。<br /><br />
プロトコル部とコマンド部に分けているのは、それぞれを自由に入れ替える事ができるようにするためです。<br />
作成したクライアントのプロトコルに合わせてプロトコル部を入れ替えたり、サーバーサイドのコンテンツを切り替えるためにコマンド部を入れ替えたりする事で様々な組み合わせのサーバーを構築する事が可能です。
</div><br />
<a id="que_and_unit"></a>
<h2 class="subtitle">キューとUNITの関係</h2>
<div class="text-block">
まずは <code>CycleDrivenManager</code> の動きを理解するためにキューとステータスUNITの関係を知る必要があります。<br />
図にすると以下のようなイメージになります。
<div class="img-block">
<a href="./img/architecture/que-and-unit.png" target="_blank" rel="noopener"><img class="img-zoomout" src="./img/architecture/que-and-unit.png" loading="lazy" alt="SOCKET-MANAGERフレームワークのイベント処理部分であるキューとUNITの関係図" /></a>
</div>
通信データの送受信の特徴として送りたいデータ、あるいは欲しいデータが一度に全て送信/受信できるとは限らないためこのような構成になっています。<br />
また、WAIT が発生するような処理(送信/受信をセットにしている動作など)を UNIT で分ける事で、キューの処理を待たせる事なく次の UNIT 処理へと進む事ができるようになります。<br /><br />
例えば Websocket の opening ハンドシェイクの場合はクライアントからヘッダ情報を受信した後は同じようにヘッダ情報をサーバーから送り返さないといけませんが、これをブロッキングモードで送信が完了するまで待っていると他の接続も巻き込んで処理が待たされる事になってしまいます。<br /><br />
この回避策として当ライブラリでは以下の UNIT 処理のようにノンブロッキングモードで送信が行えるようにしています。<br />
<pre color-change="php" aria-label="UNIT処理の一部を抜粋">
// CREATEステータスのUNIT
{
// 送信データの設定
$p_param->protocol()->setSendingData(<送信データ>);
return ProtocolStatusEnumForWebsocket::SEND->value;
}
// SENDステータスのUNIT
{
// データ送信
$w_ret = $p_param->protocol()->sending();
// 送信中の場合は再実行
if($w_ret === null)
{
$sta = $p_param->getStatusName();
return $sta;
}
return null;
}
</pre><br />
実際にデータを送信する <code>SEND</code> ステータスのひとつ前のUNIT処理( <code>CREATE</code> ステータス)であらかじめ送信したいデータを設定しておき、送信を実行するUNIT処理( <code>SEND</code> ステータス)で <code>sending</code> メソッドの戻り値が null 以外になるまで繰り返しています。<br /><br />
※ <code>sending</code> メソッドは設定された送信データを送信しきるまで null を返す処理です。<br />
※ <code>getStatusName</code> メソッドは現在実行中のステータス名を取得するものです。<br /><br />
受信の場合も同じように受信サイズを設定するメソッド <code>setReceivingSize</code> と受信しきるまで null を返すメソッド <code>receiving</code> に分けています。<br /><br />
このように UNIT の処理の実装は極力処理の停滞(ブロッキング)がおきないように構成する事が求められます。<br /><br />
また、UNIT ステータスはリターン値によって遷移していきます。そしてキューの処理が全て完了したら null を返すルールとなっています。<br />
処理の流れはリターン値で制御できるので、同じような処理を繰り返し行ったり、分岐したいケースがある場合には処理を構造化しながらコントロールする事が可能になります。<br /><br />
このようなキューとステータスUNITをコントロールする役割を <code>CycleDrivenManager</code> が担っています。<br /><br />
<h3 class="underline">throwブレイク</h3>
このシステムでの throw ブレイクは、UNIT のステータスを維持したまま処理を中断して待ち受け状態に戻る事を意味します。<br />
ステータスUNIT内で <code>UnitException</code> クラスを用いて例外( throw )を発行する事で throw ブレイクとなります。
</div><br />
<a id="unit-implementation"></a>
<h2 class="subtitle">UNIT定義クラス</h2>
<div class="text-block">
UNIT の処理はプロトコル/コマンド部を問わず <code>IEntryUnits</code> インターフェースに従って実装する必要があります。<br />
プロトコル部を作成する時は <code>craft:protocol</code> コマンドを、コマンド部を作成する時は <code>craft:command</code> コマンドを実行してファイルを生成します。<br />
生成されるファイルの種類は以下の通り。<br />
<ul>
<li>UNIT 定義クラス</li>
<li>キュー名定義の Enum</li>
<li>ステータス名定義の Enum</li>
</ul>
UNIT 定義クラスの実装イメージは次の通りです。<br />
<div class="img-block">
<a href="./img/architecture/unit_class.png" target="_blank" rel="noopener"><img class="img-zoomout" src="./img/architecture/unit_class.png" loading="lazy" alt="SOCKET-MANAGERフレームワークのイベント処理部分であるキューとUNITを定義するクラスの内部構造イメージ" /></a>
</div>
プロトコル部のキュー名は <code>ProtocolQueueEnum</code> で予約されているので、作成された Enum ファイルにはこの予約された Enum 値がエイリアス名として定義されます。<br /><br />
コマンド部のキュー名の定義は自由です。UNIT 定義クラスの実装に合わせてキュー名を追加していく事になります。<br /><br />
<dl>
<dt>■ getQueueList メソッドの実装</dt>
<dd>プロトコル部、コマンド部それぞれで定義されたキュー名の Enum 値をピックアップしてリストに追加します。</dd>
<dt>■ getUnitList メソッドの実装</dt>
<dd>引数で渡されたキュー名と一致するリストを返します。プロトコル部、コマンド部それぞれで定義されたステータス名定義の Enum 値をピックアップしてステータス名に対応する UNIT メソッドとセットでリストを作成します。各キューの処理は <code>START</code> ステータスから始まるので必ず含める必要があります。</dd>
</dl>
</div><br/>
<a id="init"></a>
<h2 class="subtitle">初期化クラス</h2>
<div class="text-block">
初期化クラスは <code>IInitSocketManager</code> インターフェースに従って実装する必要があります。<br />
インターフェース実装に必要な内容は以下の通りです。<br /><br />
<h3 class="underline">UNITパラメータクラス</h3>
<code>SocketManagerParameter</code> クラスやそれを継承しているクラスの事を UNIT パラメータクラスと呼びます。<br />
このインスタンスは UNIT 処理の引数として渡されるもので、<code>SocketManager</code> との橋渡し役を担っています。<br /><br />
<code>SocketManagerParameter</code> クラスを継承する事でデータの送受信やディスクリプタ(クライアント接続子)の操作を行うための機能を提供すると同時に、アプリケーションで利用するグローバルエリアを管理する役割も担っています。<br />
プロトコル部・コマンド部・コマンドディスパッチャー間で同じグローバルエリアの利用が可能です。<br />
接続子単位でのグローバル管理が必要なデータに関しては、UNIT パラメータクラス内の <code>getTempBuff/setTempBuff</code> メソッドで取得・設定が可能です。<br />
これを図にすると以下のようになります。<br />
<div class="img-block">
<a href="./img/architecture/global.png" target="_blank" rel="noopener"><img class="img-zoomout" src="./img/architecture/global.png" loading="lazy" alt="SOCKET-MANAGERフレームワーク内でのグローバル管理領域のアクセス概念図" /></a>
</div>
初期化クラス内の <code>getUnitParameter メソッド</code> でインスタンスを返す必要がありますが、インスタンス化するタイミングは初期化クラスの内側/外側を問いません。<br /><br />
プロトコル部では UNIT パラメータクラス内でインプリメントされた <code>IProtocolParameter</code> インターフェースを返す <code>protocol</code> メソッドを介して送受信用のメソッドを使う必要があります。<br />
これに対してコマンド部では UNIT パラメータクラス内でインプリメントされた <code>getRecvData</code> メソッドを使って受信データを取得し、<code>setSendStack</code> メソッドを使って送信データを設定する流れが基本となります。<br /><br />
このような構成になっているのは以下の処理を前提としているからです。<br />
<dl>
<dt>・受信処理</dt>
<dd>受信データはプロトコル部で組み立てたものをコマンド部に渡します(コマンド部では <code>getRecvData</code> メソッドを通して受信データを取得します)。</dd>
<dt>・送信処理</dt>
<dd>コマンド部で組み立てた送信データはプロトコル部で必要に応じて分解され、送信されます(コマンド部では <code>setSendStack</code> メソッドを通して送信データを引き渡します)。</dd>
</dl>
この為コマンド部の処理では、ノンブロッキングの処理を意識する事なく通信データの送受信の実装が可能となります。<br /><br />
※ protocol メソッドをコマンド部で呼び出すと <code>UnitExceptionEnum::ECODE_METHOD_CALL_FAIL</code> 例外が発生してエラー終了しますのでご注意ください。<br />
※ 具体的にどんなメソッドが存在するのかについては <code>SocketManagerParameter</code> クラスの<font class="code"><a href="./reference/classes/SocketManager-Library-SocketManagerParameter.html" target="_blank" rel="noopener">>> Reference</a></font>をご覧ください。<br /><br />
<h3 class="underline">シリアライザー/アンシリアライザー</h3>
この処理はディスクリプタ内で管理された先入れ先出し方式である送受信スタックエリア(メモリ上のスタック領域とは無関係です)と深く関わっています。<br />
送受信スタックエリア内ではシリアライズ化されたデータが保持されるため、データ取得時にはアンシリアライザーが、データ設定時にはシリアライザーが呼び出されます。<br />
これを図にすると以下のようになります。<br /><br />
<div class="img-block">
<a href="./img/architecture/data_stack.png" target="_blank" rel="noopener"><img class="img-zoomout" src="./img/architecture/data_stack.png" loading="lazy" alt="クライアントごとに管理している送受信データスタック領域とアクセス概念図" /></a>
</div>
<h3 class="underline">コマンドディスパッチャー</h3>
プロトコル部で受信したデータは UNIT パラメータクラスの <code>setRecvStack</code> メソッドを使って受信スタックへ格納する必要があります。<br />
コマンドディスパッチャーはその受信データを解析してコマンド部に処理を振り分ける役割を担っています。<br /><br />
コマンド部から送信するデータは UNIT パラメータクラスの <code>setSendStack</code> メソッドを使って送信スタックへ格納する必要があります。<br />
送信時はコマンドディスパッチャーの介入はなく、送信スタックに溜まったものをプロトコル部を経由して順次クライアントへ送信されます。<br /><br />
これを図にすると以下のようになります。<br /><br />
<div class="img-block">
<a href="./img/architecture/recv_flow.png" target="_blank" rel="noopener"><img class="img-zoomout" src="./img/architecture/recv_flow.png" loading="lazy" alt="受信データを解析してコマンドディスパッチャーが処理を振り分ける概念図" /></a>
</div>
<div class="img-block">
<a href="./img/architecture/send_flow.png" target="_blank" rel="noopener"><img class="img-zoomout" src="./img/architecture/send_flow.png" loading="lazy" alt="コマンドディスパッチャーを介さずに送信データが送出されるまでの概念図" /></a>
</div>
<h3 class="underline">緊急停止時のコールバック</h3>
以下の場面で呼び出されます。<br />
<ul>
<li>アライブチェック処理のタイムアウト</li>
<li>コマンドディスパッチャーで例外キャッチ時</li>
<li>相手先による強制切断</li>
</ul><br />
<h3 class="underline">ログライター</h3>
ライブラリ内を含めアプリケーションレイヤー内からも呼ばれるログ出力ハンドラーです。<br />
アプリケーションレイヤーからは UNIT パラメータクラスを通して呼ばれます。<br />
</div><br />
<a id="main"></a>
<h2 class="subtitle">メイン処理クラス</h2>
<div class="text-block">
実装イメージは以下の通りです。<br />
<div class="img-block">
<a href="./img/architecture/main_class.png" target="_blank" rel="noopener"><img class="img-zoomout" src="./img/architecture/main_class.png" loading="lazy" alt="メイン処理クラスの内部構造イメージ" /></a>
</div>
このうち初期設定ブロックは <code>SocketManager</code> の準備処理として必要な部分です。<br />
ポート設定ブロックではマルチサーバーの子サーバーとして起動する場合、親サーバーへの接続を行うための <code>connect</code> メソッドが使用される事があります。<br />
ノンブロッキングループブロックは以下のイメージで動作します。<br />
<div class="img-block">
<a href="./img/architecture/main1.png" target="_blank" rel="noopener"><img class="img-zoomout" src="./img/architecture/main1.png" loading="lazy" alt="クライアント接続単体でのノンブロッキングループ動作イメージ" /></a>
</div>
1つの接続に対してプロトコル部とコマンド部が連携し合って動作します。<br />
このうち1回の周期(ループ)で実行されるのはプロトコル/コマンド部のそれぞれ1 UNIT ずつとなります。<br />
これが複数の接続になると以下のイメージになり、1つのサーバーで処理する単位になります。<br />
<div class="img-block">
<a href="./img/architecture/main2.png" target="_blank" rel="noopener"><img class="img-zoomout" src="./img/architecture/main2.png" loading="lazy" alt="複数のクライアント接続時のノンブロッキングループ動作イメージ" /></a>
</div>
そして複数のサーバーを起動している場合は以下のイメージになり、プロセスが順当に割り当てられると1つのサーバープロセスが CPU の各コア(このケースではコアが4つの場合)に割り当てられてデュアルで動作します。<br />
<div class="img-block">
<a href="./img/architecture/main3.png" target="_blank" rel="noopener"><img class="img-zoomout" src="./img/architecture/main3.png" loading="lazy" alt="複数のサーバープロセス稼働時のノンブロッキングループ動作イメージ" /></a>
</div>
※ 実際にサーバーをスケーリングする際には上記のイメージを基に計算/設計していく事になりますが、サーバー上の個々のプロセスを OS が必ずしも別々の CPU に割り当てるとは限らないため、リソースや処理時間等の実測値を見ながら調整していく事になります。通常は OS が自動的に CPU 割り当てを行いますが、<a href="./launcher/" target="_blank" rel="noopener">SOCKET-MANAGER Launcher</a> を利用することで任意の CPU にプロセスを割り当てることが可能となり、プロセス間の競合を抑制しながらより効率的なリソース活用が行えます。
<br /><br />
</div>
<a id="last"></a>
<h2 class="subtitle">おわりに</h2>
<div class="text-block">
ここでご紹介した内容は特に新規プロジェクト開発をする時に必要になる情報ばかりですが、Websocket 開発環境でもより高度な実装をするために必要な情報でもあります。<br />
サーバー間通信を伴うマルチサーバーを構築する際の基礎的な内容でもありますので<font><a href="./multi-server.html" target="_blank" rel="noopener">▶マルチサーバーの構成</a></font>のページも合わせてご覧ください(マルチサーバーの構築を予定していない場合は読み飛ばしてもらっても構いません)。
</div>
</div>
</div>
</body>
</html>