Complete Guide to Japanese System Design Presentation Expressions for IT Engineers

本日は、新規決済システムのアーキテクチャ設計についてご説明いたします。
(Today, I will explain the architecture design of the new payment system.)

インフラチームの金と申します。本日のプレゼンは約30分を予定しております。
(I am Kim from the Infrastructure Team. Today's presentation is scheduled for about 30 minutes.)

本日のアジェンダは3点です。まず現状の課題、次に提案アーキテクチャ、最後にロードマップです。
(Today's agenda has 3 points. First, current issues; next, the proposed architecture; and finally, the roadmap.)

まず、現行システムの課題からご説明します。
(First, let me explain the issues with the current system.)

現在のモノリシックアーキテクチャには、以下の3つの課題があります。
(The current monolithic architecture has the following 3 issues.)

レスポンスタイムが年々悪化しており、P99で3秒を超える状況です。
(Response time has been worsening year by year, exceeding 3 seconds at P99.)

デプロイに平均4時間かかっており、リリース頻度のボトルネックになっています。
(Deployments take an average of 4 hours, becoming a bottleneck for release frequency.)

提案するアーキテクチャの全体像をご覧ください。
(Please look at the overall picture of the proposed architecture.)

システムは大きく3つのレイヤーに分かれています。
(The system is broadly divided into 3 layers.)

フロントエンドからAPIゲートウェイを経由して、各マイクロサービスに振り分けられます。
(Requests are distributed from the frontend through the API gateway to each microservice.)

データ層はPostgreSQLをメインDBとし、Redisをキャッシュとして配置しています。
(The data layer uses PostgreSQL as the main DB and Redis as the cache.)

次に、各コンポーネントの詳細をご説明します。
(Next, let me explain the details of each component.)

認証サービスはOAuth 2.0とOIDCを採用しており、Keycloakで実装します。
(The authentication service adopts OAuth 2.0 and OIDC, implemented with Keycloak.)

メッセージキューにはKafkaを採用し、サービス間の非同期通信を実現します。
(Kafka is adopted for the message queue, enabling asynchronous communication between services.)

コンテナオーケストレーションにはKubernetesを使用し、EKS上で稼働させます。
(Kubernetes is used for container orchestration, running on EKS.)

技術選定にあたり、3つの候補を比較検討しました。
(In selecting the technology, we compared and evaluated 3 candidates.)

RDBMSの選定では、PostgreSQL、MySQL、Aurora の3つを比較しました。
(For the RDBMS selection, we compared PostgreSQL, MySQL, and Aurora.)

総合的に判断して、PostgreSQLを採用することを推奨します。
(Based on a comprehensive evaluation, we recommend adopting PostgreSQL.)

PostgreSQLを選定した理由は主に3点あります。
(There are mainly 3 reasons for selecting PostgreSQL.)

第一に、JSONBサポートにより柔軟なスキーマ設計が可能です。
(First, JSONB support enables flexible schema design.)

第二に、パーティショニング機能が充実しており、大量データの管理に適しています。
(Second, the partitioning features are robust, making it suitable for managing large volumes of data.)

第三に、社内にPostgreSQLの運用ノウハウが蓄積されています。
(Third, operational know-how for PostgreSQL has been accumulated in-house.)

MySQLを不採用とした理由は、ウィンドウ関数のサポートが限定的なためです。
(The reason for not selecting MySQL is the limited support for window functions.)

Auroraはコスト面で現時点では過剰と判断しました。
(Aurora was deemed excessive in terms of cost at this point.)

ただし、トラフィックが10倍に増加した場合は、Aurora への移行を検討します。
(However, if traffic increases tenfold, we will consider migrating to Aurora.)

この設計にはトレードオフがあります。率直に共有させていただきます。
(There are trade-offs in this design. Let me share them candidly.)

マイクロサービスの利点は独立デプロイと技術スタックの自由度ですが、
運用の複雑性が増す点がデメリットです。
(The advantages of microservices are independent deployment and flexibility in the technology stack,
but the downside is increased operational complexity.)

結果整合性（Eventual Consistency）を採用するため、
強整合性が必要な決済処理には別途対策が必要です。
(Since we adopt eventual consistency,
separate measures are needed for payment processing that requires strong consistency.)

この点については、Sagaパターンで補完する設計としています。
(For this point, we have designed it to be supplemented with the Saga pattern.)

非機能要件についてもご説明いたします。
(Let me also explain the non-functional requirements.)

可用性は99.95%をSLOとして設定しています。月間ダウンタイムは約22分です。
(Availability is set at 99.95% as the SLO. Monthly downtime is approximately 22 minutes.)

スケーラビリティについては、HPAにより秒間10,000リクエストまで自動スケールします。
(For scalability, HPA enables auto-scaling up to 10,000 requests per second.)

セキュリティは、mTLSによるサービス間暗号化とOPA によるポリシー制御を実装します。
(For security, we implement inter-service encryption via mTLS and policy control via OPA.)

災害復旧については、マルチAZ構成とし、RPOは5分、RTOは30分を目標とします。
(For disaster recovery, we use a multi-AZ configuration, targeting an RPO of 5 minutes and an RTO of 30 minutes.)

実装にかかる工数と期間をご説明します。
(Let me explain the effort and timeline for implementation.)

Phase 1は基盤構築で3ヶ月、Phase 2はサービス移行で4ヶ月を見込んでいます。
(Phase 1 is 3 months for infrastructure setup, and Phase 2 is estimated at 4 months for service migration.)

必要なリソースはバックエンド4名、インフラ2名、QA1名の合計7名です。
(The required resources are 4 backend engineers, 2 infrastructure engineers, and 1 QA engineer, totaling 7 people.)

月額の運用コストは現行比で約20%増加しますが、開発効率の向上で年間では回収可能です。
(Monthly operational costs will increase by about 20% compared to the current system, but can be recovered annually through improved development efficiency.)

ここまでで何かご質問はございますか？
(Are there any questions so far?)

ご不明な点がございましたら、お気軽にお聞きください。
(If anything is unclear, please feel free to ask.)

ご質問ありがとうございます。〜についてですが...
(Thank you for the question. Regarding ~...)

良い指摘ですね。その点については検討段階で議論しました。
(That's a good point. We discussed that during the evaluation phase.)

おっしゃる通りです。そのリスクに対しては、フォールバック機構を用意しています。
(You are absolutely right. For that risk, we have prepared a fallback mechanism.)

正直に申しますと、その点はまだ検討中です。次回までに調査いたします。
(To be honest, that point is still under review. I will investigate it by the next meeting.)

鋭いご指摘ですね。確かにその観点は考慮に入れるべきでした。
(That's a sharp observation. Indeed, that perspective should have been taken into consideration.)

その点については、持ち帰って詳細に検討させていただきます。
(Regarding that point, I will take it back and examine it in detail.)

現時点では仮説ベースですが、PoC で検証してから最終判断したいと考えています。
(At this point it is hypothesis-based, but I would like to make the final decision after validating it with a PoC.)

以上が新規決済システムのアーキテクチャ提案となります。
(That concludes the architecture proposal for the new payment system.)

本日のまとめです。マイクロサービス化により、デプロイ頻度を10倍に向上させ、
レスポンスタイムを50%改善できると見込んでいます。
(Here is today's summary. Through microservices transformation, we expect to improve deployment frequency by 10x
and reduce response time by 50%.)

ご清聴ありがとうございました。ご検討のほど、よろしくお願いいたします。
(Thank you for your attention. We look forward to your consideration.)