【17-D-1】今どきのアーキテクチャを現場の立場で斬る

今どきのアーキテクチャを現場の立場で斬る
株式会社ワークスアプリケーションズ
井上誠一郎
デブサミ2017 【17-D-1】

© 2017 Works Applications Co., Ltd.
3
本日の趣旨
• B2B(企業向けシステム)の大規模クラウドサービスのシス
テム設計の経験から伝えたいこと
• 現在進行形なので、正解を神のように話すセッションでは
ありません
• ミドルウェアベンダーが喧伝するような恰好良い世界でも
ありません

4
ロータス株式会社に入社後、アメリカ・ボストンのIris Associates社に出向し、Lotus Notesの開発に従事。
その後、アリエル・ネットワーク株式会社の創業メンバーとして参画、CTOを務める。
現在は株式会社ワークスアプリケーションズのエグゼクティブフェローとして、製品横断のパフォーマン
ス改善、開発インフラの改善、グローバル採用、教育等に従事。また、同社の新製品である世界初の人工
知能型ERP「HUE」開発のアーキテクチャー責任者を務め、グローバルでの開発を指揮している。
NEW!
井上誠一郎（いのうえせいいちろう）
株式会社ワークスアプリケーションズエグゼクティブフェロー
本日の趣旨自己紹介

5
20代の頃の自分
• rms(ストールマン)が憧れ

6
30代の頃の自分
• 何の因果か会社(アリエルネットワーク)を設立
• なんとなく世俗にまみれる
が、
• ダークサイド(マネージャ)に落ちない、という強い思い

7
40代の自分
• rmsにはなれない悟り(そんな覚悟も才能もない)

8
今、HUEプロジェクト
• グローバルな多拠点に数百名の開発者
• マネージメントがないと非効率すぎる

9
目次
• 巨大システムのエンジニアリング
• ジレンマとの闘い
• 技術課題との闘い
• コミュニケーション課題との闘い

巨大システムのエンジニアリング

11
HUEプロジェクトの発端
• コンシューマライクなユーザビリティを
企業向けシステムへ、というCEOの鶴の一声
• イノベーションはトップダウンだと悟る
CEO

12
HUEの規模感
• 既存顧客1000社以上(今は大半がオンプレミス)が移行
してくるクラウドシステム
• 1社当たり従業員5000名(大企業中心)と仮定すると、
500万ユーザの想定(最低ライン)
-いきなりこの規模感にはなりませんが
• 顧客は日本限定ではない

13
トライアンドエラーによる機能開発
• B2Bと言っても
-普通の企業向けアプリを作るだけでは競争力がない
• マーケットを見ながらトライアンドエラー
-ソーシャル機能の統合
(あらゆる箇所にチャット機能やチャットボット)
-あらゆる入力項目にサジェスト
-スプレッドシートを中心にすえたビュー

14
アジャイル開発?
• 個人としても会社としても、
-本当の意味でのウォーターフォール開発の経験はない
• 一方、
-本当の意味でのアジャイル開発の経験もないかも

16
ロータス時代
• 数百人の開発者が、原則、アメリカ本社に集結
• 2年かけてメジャーリリース(牧歌的)
• チケット駆動
• 安定したビルド(デイリービルドが壊れた記憶なし)
• 安定したAPI(10年以上の成熟)

17
アリエルネットワーク時代
• 数人チームから始まり、最大でも50人弱ぐらいの開発体制
-あうんの呼吸で開発
-プロジェクト開始時からいる人達が牢名主のように君臨
• ソースコードもチームもプロセスも品質も極めて安定
-リズミカルな開発イテレーション
-心地よさ(ある種の保守化)

18
HUEプロジェクトの規模(開発者の人数)
• 最初期: 30名強
• 拡大期: 東京、大阪、上海、シンガポールに開発が拡大。
数百名規模へ
• 量産期: インドに開発が拡大。1000名越えへ

19
超巨大システムのエンジニアリングに思うこと
• ある種のいい加減さが必要かも
• 細部へのこだわり vs. フェールセーフやロバストさ
• 目的のために手段を選ばず
• トップダウンの意思決定 vs. 合議制

21
YAGNIのジレンマ
• YAGNI(今必要ないことはしない)はミクロには正しいことが多
いが、マクロにはただの想定不足が多い
が、
• すべてを見通せる時まで待ったら競争力のある製品は作れない
• そもそも、待っていてもすべてを見通せない

22
選択肢のジレンマ
• 今の世の中、技術的な選択肢は多い(特定ベンダーと
心中しない限り)
• 選択肢が多いと、人は不合理なまでに選択肢の間を迷
い続ける

23
合議制のジレンマ
• ソフトウェア開発に大事な開発者のモチベーション
• 合議制で全員の納得感を得られれば、モチベーションが最高に
保てる(はず)
が、
• 合議制は時間がかかる
• 一定の人数以上になると、全員が納得することは不可能に近い
(終わらない宗教論争)

24
決定者のジレンマ
• 一定規模を越えると、ひとりの人間がすべてを把握で
きない
• 決定者がボトルネックになると、大規模開発では大き
な損失
• 決定権限の委譲は不可避
• 不整合解消の鍵はコミュニケーション...言うは易し

25
ジレンマとの闘い
• 決定者を決めるミーティング
• 決定者が決めたことには従う
• 選択肢の間で迷う時間は作らない(迷う、というのが
既に結論)
• 決定が間違いだったら、適応して直すしかない

27
B2BがB2Cより大変な部分
多品種なシステム
• 常時従業員がアクセス: メール、ファイル共有、検索
• 決まったピークに多数の従業員がアクセス: 出退勤管理、
年末調整
• 決まったピークに計算リソースを消費: 給与計算、人事異動
• アクセス数は少ないがデータ量が莫大: 伝票処理

28
B2BがB2Cより楽な部分
• トラフィックやデータの増加の予測はしやすい(突発
的なピークはB2Cほどない)

29
HUEアーキテクチャの歴史
最初期:
低レイテンシのためのWebアプリのアーキテクチャに注力
• サーバサイドレンダリング
• 事前処理、投機実行
• 遅延ロード
• データ圧縮 etc.

30
HUEアーキテクチャの歴史
ここ3年ぐらい：
• 並列で色々

31
RDBMSからの脱却
• Cassandra
• Elasticsearch
• Kafka
• Spark

32
ユーザビリティ改善のための改善
• HTML5 Canvas
• WebSocket
• HTTP/2

33
スケーラビリティのための改善
• ステートレス化
• マイクロサービス
• Kubernetes

34
低レイテンシのための再改善
• 非同期I/O処理
• フロントエンド側のキャッシュ戦略の見直し

35
運用コスト低減のための改善
• Ansibleの採用
• モニタリングツール導入(有償)

36
コスト削減のための改善
• マルチテナント
• サーバレス
• マネージドサービス

37
セキュリティのための改善
• 多要素認証
• リスクベース認証
• 暗号化ストレージ
• 各種オペレーションツール
• たくさんの社内規程...

38
多くのトレードオフ
• 高性能(並行処理、非同期I/O処理、キャッシュ) vs.
開発生産性
• セキュリティ vs. 運用効率性
• ステートレス vs. 低レイテンシ
• 車輪の再発明の回避のためのOSS活用 vs. jar hell
• あらゆること vs. IaaSコスト

39
難しい技術課題が必ず残る
• 難しいことからやっていたつもりでも、難しいことは残る
• いつもそうなので、たぶん回避できない必然

40
全部見通せていたら決定者たちは神でしたが...
• 現実の制約の中で適応中
• マイクロサービス化で、部分的なアーキテクチャ見直
しをしやすくなるかも(希望的観測)

41
なぜ最初からマイクロサービス(MSA)にしなかったか?
• アプリの機能が固まらないうちから頭でっかちに形式的な
分割が進むのを恐れた
• という理由でMSA推進をしませんでした
が、
• 想定以上にモノリシックなまま大きくなりすぎ
• 開発途中にMSA化の大きな工数(3ヶ月ぐらい)をかけるこ
とになりました
• 判断ミスだったかも

42
教科書的な意味でのMSAには遠い
• 個人的に、教科書的なMSAへのこだわりは特にない
• バージョンアップしたいアプリの単位で分離される状態を目指す
-同じタイミングでバージョンアップできるサービス群なら、共有データ
ベースも許可
• サービスをまたがるロングトランザクションは?
-元々データベースに頼っていなかった(べき等処理、イベントソーシングパ
ターン、補償トランザクション(アプリレベルのundo処理)など)
-問題の難しさは変わらず(ラッキー?)
• 異なるプログラミング言語やフレームワーク採用はまだ許していない

43
なぜ最初からマルチテナント(MT)にしなかったか?
• データストアまわりは最初からMTで設計(Cassandra
の特性上、必然的に)
• フロントエンド(画面まわり)はキャッシュのローカリ
ティを重視してシングルテナントで設計
• ユースケースに対して、IaaSコストが上がりすぎて
方針転換
• ここは見通しが甘かったと反省

44
なぜ最初からAPサーバをステートレスにしなかったか?
• 重厚なビジネスロジックと低レイテンシの両立
-複雑なバリデーション: 事前処理(投機実行)
-アクセス制御: 事前処理
-ワークフロー: 事後処理
-派生データの生成: 事後処理
• フロントエンド処理のローカリティを重視してステートフルで
設計
• ユースケースに対して、IaaSコストが上がりすぎて方針転換

45
なぜ最初からマネージドサービスにしなかったのか?
• 特定クラウドベンダーへのロックイン回避のため
• IaaSコスト削減のために、今は利用範囲が増加中
• 自由度とのバランスがあるので模索中
-OSSにコントリビュートして必要な機能を自主的に
開発できる自由
-独自プラグインを開発できる自由

46
フロントエンドをサーバサイドレンダリングにした理由
• HUE開始時点は、AngularJS時代
• 社内の天才エンジニアが高速テンプレートエンジンを開発
-サーバサイドで並行にHTML生成して送信処理
(リアクティブの先取り?)
• スパゲティ状態のJavaScriptコードは絶望的という経験則から、
サーバサイドレンダリングを選択
• UIコンポーネントを量産済み。JSFを再発明した気分
• 複雑な画面(スプレッドシートや組織図などのツリーUI)はHTML5
Canvasベースで実装 (DOMベースでは不可能だった性能を達成)
• 何が正解かいまだわからず

47
• 両方、試し中
• HUE開発の中で一番難しい課題
無停止バージョンアップは mutable or immutable ?

コミュニケーション課題との闘い

49
世界規模のオープンソースへの憧れと現実
• コード中心のコミュニケーションを夢想
• 開発者同士がpull requestを送り合いコードレビュー
• 機能はチケットで議論
• ロータスでもアリエルでも普通にできていた世界なの
で、当然できると思っていた

50
世界規模のオープンソースへの憧れと現実(続)
• 局所的なコードの議論と大きな方向性の議論は別物
• 技術や手段が目的化してしまう落とし穴
• アリエルでできていたのは単に規模が小さかったから
• ロータスでできていたのは(たぶん)コアメンバーが見
えないところで意思疎通していたから

51
希望の光
• ワークス伝統のカタログ
• ワークスが日本最大のB2Bパッケージベンダーになっ
た力の源泉
• メリットベースで考えて、伝える

52
ダンバー数のジレンマ
• 150人ぐらい(±50人)
• 人間の関心の量は有限リソース
• コミュニケーション課題は、人数の量が質的変化をも
たらす

53
日本人のコミュニケーション下手も要因かも
• 自分も含めて
• 他人への関心が薄くて、ダンバー数が極端に低い?
• 英語への抵抗?

54
希望の光
• 異能の人材たち
-声がでかい
-態度がでかい
• たいして英語ができなくても異国の地へ飛び立つ行動力
• タフな精神力
• 超人的な体力
• 綺麗事よりも、こういう人たちの貢献がHUEを支えている

56
HUEというカオス -苦労と楽しさ-
• 天才プロダクトマネージャとの出会い
-競争力のある製品作り
• ダイバーシティな開発陣
-人種のるつぼ
-日本がヘッドクォータ
-事実上、英語が公用語

【17-D-1】今どきのアーキテクチャを現場の立場で斬る

【17-D-1】今どきのアーキテクチャを現場の立場で斬る

More Related Content

What's hot

Viewers also liked

Similar to 【17-D-1】今どきのアーキテクチャを現場の立場で斬る

More from Developers Summit

【17-D-1】今どきのアーキテクチャを現場の立場で斬る