アーキテクチャを突き詰める Online Conference サービス立ち上げを終えて 追い求める美しいアーキテクチャ 株式会社スリーシェイク 手塚 卓也 Copyright © 3-shake, Inc. All Rights Reserved.

Copyright © 3-shake, Inc. All Rights Reserved. 自己紹介 Google Cloud / AWS / kubernetes / ServiceMesh など様々な 技術的アプローチを駆使し、 大手からベンチャー等規模を問わず様々な組織に対して SREのコンサルティングを実施。 現在は セキュリティ診断サービス 【Securify 】、クラウド型データ 連携サービス【Reckoner】の事業統括を行っている X Account： https://x.com/tt0603 手塚 卓也 Takuya Tezuka

Copyright © 3-shake, Inc. All Rights Reserved. 3 アジェンダ 01. 「Reckoner」 のサービス概要と特徴について 02. 現行アーキテクチャの課題と技術的負債 03. 一挙両得の新アーキテクチャの実現と今後の展望 04. 教訓とまとめ

Copyright © 3-shake, Inc. All Rights Reserved. 「Reckoner」 のサービス概要と 特徴について

社名 設立日 代表取締役社長 所在地 従業員数 資本金 事業内容 株式会社スリーシェイク 2015年1月15日 吉田 拓真 本社：東京都新宿区大京町 22-1 グランファースト新宿御苑 3-4F 119名（2023年3月時点） 1億円 SREコンサルティング支援事業「 Sreake」の運営 セキュリティ診断サービス「 Securify」の運営 データ連携プラットフォーム事業「 Reckoner」の運営 フリーランスエンジニア紹介プラットフォーム「 Relance」の運営 5 会社概要 Copyright © 3-shake, Inc. All Rights Reserved.

6 Copyright © 3-shake, Inc. All Rights Reserved. 事業紹介 事業者が抱える セキュリティリスクを無くす ワンストップで実現する セキュリティ対策 セキュリファイ Security 良いエンジニアに 良い案件を フリーランスエンジニアに 「今よりいい条件」を リランス HR（Engineer Hiring） あらゆるサービスを 連携するハブになる クラウド型ETL/データパイプ ラインサービスの決定版 レコナー Data Engineering 日本のSREをリードする SRE総合支援からセキュリティ 対策を全方位支援 スリーク SRE エンジニアリング内製化 ソリューション（モダナイゼーション）を包括的に提供

7 Copyright © 3-shake, Inc. All Rights Reserved. データ連携・加工最適化ツール「 Reckoner」 SaaSをつなぐ。 業務が変わる。 ビジネスが進化する。 Reckonerはクラウド型ETL/データパイプラインサービス とことん使いやすさを追求 「仕様策定（プログラム設計） → 実装 → テスト → 基盤構築 → 運用」と通常だと非常 に煩雑なデータ連携を、 Reckonerは全てGUIで完結。 データ活用をこれまでにない直感的な方法で実現可能。

8 Copyright © 3-shake, Inc. All Rights Reserved. Reckonerの機能概要 ● ハッシュ・暗号化 ● 文字列変換 ● 結合・グループ化 ● プログラム変換 ● カラム変換 データパイプライン ファイル データベース &ストレージ SaaS 広告・SNS 外部API Source Analytics / Transform Sink ● バリデーション ● フィルター ● 外部API連携 ● フォーマット変換 データベース &ストレージ SaaS SNS 外部API メール ファイル Salesforce Salesforce

9 Copyright © 3-shake, Inc. All Rights Reserved. Reckoner の全体処理イメージ

1 0 Copyright © 3-shake, Inc. All Rights Reserved. Reckoner の全体ETL処理イメージ 1.対応コネクタやAPI連 携を通じてデータの取得

1 1 Copyright © 3-shake, Inc. All Rights Reserved. Reckoner の全体ETL処理イメージ 2.データソースのデータ に対して出力したいデー タに加工・変換

1 2 Copyright © 3-shake, Inc. All Rights Reserved. Reckoner の全体ETL処理イメージ 2.加工されたデータを対 応コネクタやAPI連携を 通じて出力

13 Copyright © 3-shake, Inc. All Rights Reserved. Reckoner の処理における特徴 1. スケジュールやWebhook起動をベースとしたバッチでのデータ処理がメインである ○ 定期的なデータ処理を行う大規模データ処理基盤としても使われる一方で業務効率のための データ連携処理も多い ○ その為、データソースによってデータ量は数KB ~ 数TBまで様々 ○ データソースや連携先によって合わせないといけない仕様も多い 2. その一方でリアルタイム性のある処理も要求される ○ データ連携開発にとって辛いのは「試せない」こと ○ そのため即座に検証できる「プレビュー機能」を提供しており、リアルタイムに少量のデータ処 理を行いユーザーにレスポンスを変えす機能も同時に必要となる

Copyright © 3-shake, Inc. All Rights Reserved. 現行アーキテクチャの課題と 技術的負債

Copyright © 3-shake, Inc. All Rights Reserved. Reckoner の概要アーキテクチャ Architecture of Reckoner Gen1.0 Cloud Load Balancing WF実行履歴 Cloud SQL データ量計算 Cloud Datastore Cloud NAT API Server Cloud Run タスクスケジューラー Cloud Scheduler Cloud Armor データ処理 BigQuery 3rd party Tools Public Cloud SaaS Console Cloud Run Client Cloud Monitoring Cloud Logging RDAP Tasks Job Argo Workflows Deployment Scheduler Cloud Run Google Kubernetes Engine Contents Cloud Storage 15

Copyright © 3-shake, Inc. All Rights Reserved. コンポーネントの紹介： Argo Workflows とは Argo Workflows Argo Workflows は、Kubernetes 上で実行されるワークフローエンジンです。ワークフ ローは、複数のステップからなるタスクの集合であり、Argo Workflows を使用すると、こ れらのタスクを定義し、実行し、監視することができます。 Argo Workflows は、以下のようなユースケースに適しています。 - アプリケーションのデプロイメント - データの処理 - 機械学習のトレーニング - CI/CD パイプライン Kubernetes ネイティブ： Argo Workflows は Kubernetes ネイティブであり、Kubernetes の機能をフルに活用することができます。 ● 宣言型：ワークフローは YAML ファイルで記述されるため、宣言型であり、メンテ ナンスが容易です。 ● スケーラブル： Argo Workflows はスケーラブルであり、大規模なワークフローを 処理することができます。 ● 可視化：Argo Workflows は、ワークフローの実行状況を可視化することができま す。 16

Copyright © 3-shake, Inc. All Rights Reserved. コンポーネントの紹介： RDAPとは RDAP は Reckoner 独自の処理エンジンです。 Scala で開発しており ETL 処理に必要な コネクタ の連携や様々な変換処理を担う Reckoner の根幹 となるコンポーネントとなります。 Reckoner 独自の ETL処理エンジン 17

Scheduler Cloud Run 1 8 Copyright © 3-shake, Inc. All Rights Reserved. Reckoner の概要アーキテクチャ Architecture of Reckoner Gen1.0 Cloud NAT データ処理 BigQuery 3rd party Tools Public Cloud SaaS Console Cloud Run Cloud Monitoring Cloud Logging RDAP Tasks Job Argo Workflows Deployment Google Kubernetes Engine Contents Cloud Storage Cloud Load Balancing API Server Cloud Run タスクスケジューラー Cloud Scheduler Cloud Armor 1. Workflowの生成/変更 2. スケジューリングの設定 WF実行履歴 Cloud SQL Client １ データ量計算 Cloud Datastore ２

1 9 Copyright © 3-shake, Inc. All Rights Reserved. Reckoner の概要アーキテクチャ Architecture of Reckoner Gen1.0 Cloud Load Balancing Cloud NAT タスクスケジューラー Cloud Scheduler Cloud Armor Console Cloud Run Client Cloud Monitoring Cloud Logging Google Kubernetes Engine Contents Cloud Storage Argo Workflows Deployment Scheduler Cloud Run WF実行履歴 Cloud SQL 1. スケジューリングに応じてArgo WorkflowsのYAMLを生成し、Argo Workflowsが処理内容毎に RDAPタスクを生成 2. RDAP TaskがETL処理を実行し、1に戻って次の処理へ。 3. Workflows 終了後、ユーザーに通知等で実行結果返却 RDAP Tasks Job 3rd party Tools Public Cloud SaaS データ処理 BigQuery １ ２ データ量計算 Cloud Datastore API Server Cloud Run ３

Copyright © 3-shake, Inc. All Rights Reserved. 現行アーキテクチャの課題 1. リアルタイム処理実行が遅い 1. Argo Workflowsから毎回コンテナを立ち上げるアーキテクチャになっている 2. このため数十秒から1分程度かかってしまう 2. インフラコストが高い 1. VMが待機している状態でリソース効率が非常に悪い 2. まさに二兎追うものは一兎も得ずのアーキテクチャ 現行アーキテクチャのココがツライ！ 20

Copyright © 3-shake, Inc. All Rights Reserved. ワークフローにおけるタスク処理実行の流れ RDAP Tasks(処理タスク実行) Argo Workflows (WFの全体管理) GKE Node 起動 2~3min Pod起動 2~3sec health check(Readiness Probe) 5 ~ 10sec RDAP処理(データ処理)開始 タスク生成 RDAP処理(データ処理)終了 次タスクへ 21

Copyright © 3-shake, Inc. All Rights Reserved. ワークフローにおけるタスク処理実行の流れ タスクごとに都度コンテナを立ち上げる仕組みとなっている為、リアルタイム処理には合わない RDAP Tasks(処理タスク実行) GKE Node 起動 2~3min Pod起動 2~3sec health check(Readiness Probe) 5 ~ 10sec RDAP処理(データ処理)開始 タスク生成 RDAP処理(データ処理)終了 次タスクへ この処理がそもそ も無駄 Argo Workflows (WFの全体管理) 22

Copyright © 3-shake, Inc. All Rights Reserved. ワークフローにおけるタスク処理実行の流れ タスクごとに都度コンテナを立ち上げる仕組みとなっている為、リアルタイム処理には合わない RDAP Tasks(処理タスク実行) Argo Workflows (WFの全体管理) GKE Node 起動 2~3min Pod起動 2~3sec health check(Readiness Probe) 5 ~ 10sec RDAP処理(データ処理)開始 タスク生成 RDAP処理(データ処理)終了 次タスクへ この処理がそもそ も無駄 現時点の Argo Workflows の機能で は常時起動型(Deployemnt)へ処理を 投げるなどが出来ないため、 処理時間の短縮は極めて難しい 23

Copyright © 3-shake, Inc. All Rights Reserved. ワークフローにおけるタスク処理実行の流れ GKE Node 起動 2~3min Pod起動 2~3sec health check(Readiness Probe) 5 ~ 10sec RDAP処理(データ処理)開始 RDAP処理(データ処理)終了 暖機運転がされていないと本来の性能が発揮できない ❖ JVMの性質上、暖機運転必要となるため初動の処理 が遅い ❖ GraalVMと選択肢も出てきたが、現状は使えていな い。技術的に枯れてもいない為重要な基盤として選定 するのは避けている状況 ❖ その他JVMのチューニング含めて k8s で利用する上で の考慮事項も多いのも辛いポイント JVM Java Virtual Machine JVMをk8sで動かす際の考慮事項はこちらが参考になります > KubernetesでJVMアプリを動かすための実践的ノウハウ集 / JVM on Kubernetes https://speakerdeck.com/hhiroshell/jvm-on-kubernetes RDAP Tasks(処理タスク実行) 24

GKE NodePool Copyright © 3-shake, Inc. All Rights Reserved. 処理系統毎に考えなければいけないアーキテクチャ像について リアルタイム系処理においてあるべき姿(当たり前の話) Kubernetes Node Layer： ● 常駐 Node を配置しておく ● リアルタイム性のある処理が求められる為、 Scale out のオー バーヘッドを極力発生させなように配置する Container Layer： ● 常時起動型で素早く処理 /レスポンスできるようにする ● Deploymentで Container を展開し、HPAなどを駆使してス ケーラブルな状態にしておく 一時起動 常時起動 25

GKE NodePool Copyright © 3-shake, Inc. All Rights Reserved. 処理系統毎に考えなければいけないアーキテクチャ像について Kubernetes Node Layer： ● 常駐 Node は配置しない or 最低限の配置にしてリソースを浮 かせない ● Node 不足時にはAutoScaling を活用し Scale outする Container Layer： ● 都度起動にして必要なリソースを必要な分だけ利用 ● 利用が終了したらコンテナも停止して不要になった Nodeを浮 かせる 一時起動 常時起動 バッチ系処理においてあるべき姿(当たり前の話) 26

GKE NodePool Copyright © 3-shake, Inc. All Rights Reserved. 「リソース効率」こそが真のコスト課題 Kubernetes Node Layer： ● プレビュー用に常駐Nodeが待機 ● スケジュール実行だけでなく 突発的に発生するPreview機能 用にNode数は多めに担保している ● 利用されていない時間帯は ほとんどリソースが空いている Container Layer： ● タスク処理要求に応じてコンテナは都度起動するため、前述 の通り起動までに時間がかかる状態 現状の Reckoner の姿 単一のアーキテクチャで処理しているため、リアルタイム系では処理要求に合わない為性能 ネックに。バッチ系ではリソース効率が悪く、コストネックに。 一時起動 常時起動 27

Copyright © 3-shake, Inc. All Rights Reserved. 「リソース効率」を最適化するのが FinOps の第一歩？ RI の活用などを通じてコストダウンを行うのがクラウド活用 するのがメソッドではある一方でリソース効率されていないう ちにクラウドの全体利用費やインスタンスのコミットメントの購 入は危険性が伴う 特にKubernetesを利用している場合は Node側の余剰リ ソースが十分にあるケースがあるためそこの最適化からはじ めるのも重要かもしれない GKE NodePool Kubernetes 常時では余剰な リソース Reckoner において上記は小手先では解決出来ない課題 一時起動 常時起動 28

2 9 Copyright © 3-shake, Inc. All Rights Reserved. 現行アーキテクチャの課題 1. リアルタイム処理実行が遅い 1. Argo Workflowsから毎回コンテナを立ち上げるアーキテクチャになっている 2. このため数十秒から1分程度かかってしまう 2. インフラコストが高い 1. VMが待機している状態でリソース効率が非常に悪い 2. まさに二兎追うものは一兎も得ずのアーキテクチャ 現行アーキテクチャのココがツライ！ これらの課題を解決するためには アーキテクチャのリプレイスしかないと判断

Copyright © 3-shake, Inc. All Rights Reserved. 一挙両得の新アーキテクチャの 実現と今後の展望

Copyright © 3-shake, Inc. All Rights Reserved. 新アーキテクチャで目指す理想像と考慮した事項について 1. 処理系統に応じたアーキテクチャに分離 2. アプリケーションレベルは同一のロジックとし、処理系統の分離はインフラレ ベルで行う 3. 手間とコストを天秤にかけたうえで「枯れた」技術選定を重視する 31

Copyright © 3-shake, Inc. All Rights Reserved. Reckoner の概要アーキテクチャ ※ Before Architecture of Reckoner Gen1.0 Cloud Load Balancing WF実行履歴 Cloud SQL データ量計算 Cloud Datastore Cloud NAT API Server Cloud Run タスクスケジューラー Cloud Scheduler Cloud Armor データ処理 BigQuery 3rd party Tools Public Cloud SaaS Console Cloud Run Client Cloud Monitoring Cloud Logging RDAP Tasks Job Argo Workflows Deployment Scheduler Cloud Run Google Kubernetes Engine Contents Cloud Storage 32

Copyright © 3-shake, Inc. All Rights Reserved. シン Reckoner の概要アーキテクチャ ※ After Architecture of Reckoner Gen2.0 Cloud Load Balancing WF実行履歴 Cloud SQL データ量計算 Cloud Datastore Cloud NAT API Server Cloud Run タスクスケジューラー Cloud Scheduler Cloud Armor データ処理 BigQuery 3rd party Tools Public Cloud SaaS Console Cloud Run Client Cloud Monitoring Cloud Logging RDAP Tasks Deployment Scheduler Cloud Run Google Kubernetes Engine Workflow Controller Deployment RDAP Task Queue Pub/Sub 33

3 4 Copyright © 3-shake, Inc. All Rights Reserved. シン Reckoner の概要アーキテクチャ(for Streaming / Preview) Architecture of Reckoner Gen2.0 データ量計算 Cloud Datastore Cloud NAT データ処理 BigQuery 3rd party Tools Public Cloud SaaS Console Cloud Run Cloud Monitoring Cloud Logging RDAP Tasks Deployment Scheduler Cloud Run Google Kubernetes Engine Workflow Controller Deployment RDAP Task Queue Pub/Sub Cloud Load Balancing WF実行履歴 Cloud SQL API Server Cloud Run タスクスケジューラー Cloud Scheduler Cloud Armor Client 1. Workflowの生成/変更 2. スケジューリングの設定 ２ １

3 5 Copyright © 3-shake, Inc. All Rights Reserved. シン Reckoner の概要アーキテクチャ(for Streaming / Preview) Architecture of Reckoner Gen2.0 Cloud Load Balancing データ量計算 Cloud Datastore Cloud NAT タスクスケジューラー Cloud Scheduler Cloud Armor データ処理 BigQuery 3rd party Tools Public Cloud SaaS Console Cloud Run Client Cloud Monitoring Cloud Logging Google Kubernetes Engine RDAP Tasks Deployment Scheduler Cloud Run Workflow Controller Deployment RDAP Task Queue Pub/Sub 1. スケジューリングに応じて Workflow Controllerが処理内容毎にPub/Subにキューを投げる 2. Deployment で展開されている RDAP TaskがPub/Subのキューを取得し、ETL処理を実行。結果を Workflow Controllerに返却し次の処理へ。 3. Workflows 終了後、Workflow Controllerが実行結果を保存し、ユーザーに結果返却 WF実行履歴 Cloud SQL １ ２ API Server Cloud Run ３

Copyright © 3-shake, Inc. All Rights Reserved. シン Reckoner の概要アーキテクチャ(for Batch) Architecture of Reckoner Gen2.0 Cloud Load Balancing データ量計算 Cloud Datastore Cloud NAT API Server Cloud Run タスクスケジューラー Cloud Scheduler Cloud Armor データ処理 BigQuery 3rd party Tools Public Cloud SaaS Console Cloud Run Client Cloud Monitoring Cloud Logging Google Kubernetes Engine RDAP Tasks Job Scheduler Cloud Run Workflow Controller Deployment RDAP Task Queue Pub/Sub WF実行履歴 Cloud SQL 36

3 7 Copyright © 3-shake, Inc. All Rights Reserved. シン Reckoner の概要アーキテクチャ(for Streaming / Preview) Architecture of Reckoner Gen2.0 データ量計算 Cloud Datastore Cloud NAT データ処理 BigQuery 3rd party Tools Public Cloud SaaS Console Cloud Run Cloud Monitoring Cloud Logging RDAP Tasks Deployment Scheduler Cloud Run Google Kubernetes Engine Workflow Controller Deployment RDAP Task Queue Pub/Sub Cloud Load Balancing WF実行履歴 Cloud SQL API Server Cloud Run タスクスケジューラー Cloud Scheduler Cloud Armor Client 1. Workflowの生成/変更 2. スケジューリングの設定 ２ １

3 8 Copyright © 3-shake, Inc. All Rights Reserved. シン Reckoner の概要アーキテクチャ(for Streaming / Preview) Architecture of Reckoner Gen2.0 Cloud Load Balancing データ量計算 Cloud Datastore Cloud NAT タスクスケジューラー Cloud Scheduler Cloud Armor データ処理 BigQuery 3rd party Tools Public Cloud SaaS Console Cloud Run Client Cloud Monitoring Cloud Logging Google Kubernetes Engine RDAP Tasks Deployment Scheduler Cloud Run Workflow Controller Deployment RDAP Task Queue Pub/Sub WF実行履歴 Cloud SQL １ ３ API Server Cloud Run ４ 1. スケジューリングに応じて Workflow Controllerが処理内容毎に Pub/Subにキューを投げる且つ RDAP Tasksをk8s の Jobとして生成する 2. 3. RDAP TaskがPub/Subのキューを取得し、 ETL処理を実行。結果を Workflow Controllerに返却し次の処理へ。 処理終了後コンテナ停止 4. Workflows 終了後、Workflow Controllerが実行結果を保存し、ユーザーに結果返却 ２

Copyright © 3-shake, Inc. All Rights Reserved. 新アーキテクチャで目指す理想像と考慮した事項について 1. 処理系統に応じたアーキテクチャに分離 2. アプリケーションレベルは同一のロジックとし、処理系統の分離はインフラレ ベルで行う 3. 手間とコストを天秤にかけたうえで「枯れた」技術選定を重視する 39

Copyright © 3-shake, Inc. All Rights Reserved. 処理系統に応じた適切なアーキテクチャに変更 実現したい用途が異なるものをどちらかに寄せて無理やりやると結局は破綻してしまう。性能とコスト面を踏まえた 判断の元分離し、アーキテクチャレベルでコストネックとなりうる構造を作らない事を目指した 大容量データについては大規模バッチ処理 用で実行 少量で即時性の必要な処理はリアルタイ ム処理系統の基盤で処理実行 UIは同一でデータ処理の用途に応じて処理系統を選択 40

Copyright © 3-shake, Inc. All Rights Reserved. 新アーキテクチャで目指す理想像と考慮した事項について 1. 処理系統に応じたアーキテクチャに分離 2. アプリケーションレベルは同一のロジックとし、処理系統の分離はインフラレ ベルで行う 3. 手間とコストを天秤にかけたうえで「枯れた」技術選定を重視する 41

Copyright © 3-shake, Inc. All Rights Reserved. 同一のアプリケーションコードで2つの用途を実現する ● バッチ系とストリーミング系で2系統に分離することによるデメ リットは管理工数が莫大になってしまうこと ● 特にアプリケーションレベルでの乖離が大きいと混乱の要因 にもなり、チーム規模を考慮しても破綻してしまう ● そのため、アプリケーションレベルは同一のロジックで組み、 極力インフラレベルで吸収出来るようなアーキテクチャを実 現 RDAP Tasks Deployment RDAP Tasks Job 同一のアプリケーションコードで用 途によって分離 42

Copyright © 3-shake, Inc. All Rights Reserved. 新アーキテクチャで目指す理想像と考慮した事項について 1. 処理系統に応じたアーキテクチャに分離 2. アプリケーションレベルは同一のロジックとし、処理系統の分離はインフラレ ベルで行う 3. 手間とコストを天秤にかけたうえで「枯れた」技術選定を重視する 43

Copyright © 3-shake, Inc. All Rights Reserved. 様々な選択肢の中からチーム規模やサービスに必要なことを選択 様々な観点で上記を考慮し Argo Workflows から自作エンジンに切り替えを選択 Argo Workflows ベースにOSSコミットし改 修する Workflows Managed サービスを活用する 自作で独自開発 自作を選択 44

Copyright © 3-shake, Inc. All Rights Reserved. 無茶をしない「枯れた」技術選定を重視 ● マネージドサービスを利用するのは重要なのは大前提 ● その一方で「責任共有モデル」と言えば聞こえは良いが、何 の責任の共有なのか？ ● 少なくとも停止した時のビジネスインパクトや評価、顧客から の信頼低下の責任を取ってくれるわけではない ○ 設定する SLO によって異なる部分だが、感度高く設 計する事は非常に重要 ● 仕様が固まってなかったり都度変更がバンバン走ったりする のがPublic Cloudの世界 ● そのため、どこまで「依存」して良いのか？振り回されて良い のか？を適切に考慮した上での技術選定は重要 ● サポートもイマイチで「おいooo」みたいな時もある... 以下より引用 https://cloud.google.com/architecture/framework/secur ity/shared-responsibility-shared-fate?hl=ja 責任共有モデルは魅力的だが何の責任を 取ってくれるのか？は理解しておきたい 45

Copyright © 3-shake, Inc. All Rights Reserved. 教訓とまとめ

Copyright © 3-shake, Inc. All Rights Reserved. 教訓とまとめ ~「大事なのはアーキテクチャだ」と言い続けているのだが、私が ＣＥＯを務めた３社が成功できたのは、結局のところ優れたアーキ テクチャに起因する。~ フランク・スルートマン 元 Snowflake社 CEO 元 ServiceNow社 CEO AMP IT UP 最高を超える (ダイヤモンド社) 47

Copyright © 3-shake, Inc. All Rights Reserved. 教訓とまとめ 特に新規事業などは不確実性も高く、不明瞭なことも多い。最適解や取れる選択肢もそのフェーズや状況で全く 異なる。だからこそ、 1. 技術選定や一つ一つのロジックに明確な「 背景」がある、「意味」がある、「理由」がある。 2. 懸念事項が明確である。そのため起きる事故も将来的な課題も「 想定内」に留める。 これらの条件を満たす為に取り組み尽くすことがアーキテクチャ設計において重要である。 例えば、ある時点で技術的負債があったとしても、それ自体がアーキテクチャの品質を決める決定要因ではな い。その負債が想定通りに起きているのか、そうではないのかがアーキテクチャの美しさを決める はず。 難しいけど、そんな当たり前の事を追い続けてエンジニアリングをし続けていきたい 。 アーキテクチャは美しく在りたい 48

No content