”機能” 要件 だけではない︕ o 解決したいビジネス課題 → Webアプリ → 様々な要件 o 機能要件 o 実装する機能についての要件 o 例) ボタンAをクリックした場合、処理Xが実⾏されること o ローカル環境での実装は主に機能要件を⾒ることが多いが、 この場合はサーバー1台あれば⼗分に⾒える o ⾮機能要件 o 機能以外の、品質に関わる要件 o 例) 可⽤性、スケーラビリティ、パフォーマンス、運⽤、セキュリティ等 o 運⽤期間中のサービス停⽌時間を年間計10時間以内に抑えられること o アクティブユーザーが10万⼈の場合も、1秒以内にレスポンスを返却すること o ⾮機能要件やプロジェクト上の様々な制約を満たすことを考えると、 システム全体のアーキテクチャ設計が重要になる
アーキテクチャ設計（※）とは o 機能・⾮機能要件、制約条件を満たすシステム全体の設計を、ソフトウェア だけでなくインフラの観点も含めて⾏うこと 本セッションでは、 o ⼀般的なWebアプリに求められる品質の要件を確認しつつ、 特にインフラの観点に重きを置いたアーキテクチャ設計のコツをお伝えします ※ システムアーキテクチャ設計、アーキテクティング、 system design 等 呼び⽅は⾊々ある
o クラウド上での アーキテクチャ設計 がどのようなものなのかお伝えします o アーキテクチャ設計で意識すべき観点と取りうる選択肢を知ろう o 検討する上で叩き台となる⼀般的な構成とはどのようなものなのか o アーキテクチャ設計の始め⽅ o できるだけ AWS (クラウド) に限らない、より⼀般的な話をします
o どれほどの信頼性を求めるのか o どれほどのスケーラビリティ・パフォーマンスを求めるのか o 効率良く開発や運⽤を⾏えるのか o コストは最適化できているのか o セキュリティ観点での検討 ※ AWS Well Architected Frameworkを参考に記載。IPAの非機能要求グレードなどを利用する場合もある
o ロードバランサを前段に配置し、複数のサーバーにリクエストを分散させる o ロードバランサは定期的にサーバーの⽣死を確認し (=ヘルスチェック)、 正常に動作しているサーバーにのみリクエストを渡す ロード バランサー Web サーバー Web サーバー Web サーバー HTTPリクエスト HTTPリクエスト 負荷を複数のサーバーに 分散する仕組み ❌
o DBサーバーの障害時には、レプリケーション先に切り替えることで、 短いダウンタイムでサービスを復旧させることができる MySQL (Source) MySQL (Replica) レプリケーション Web Web Web サーバー MySQL MySQL Web Web Web サーバー フェールオーバー （切り替え） ❌ ❌ 読み書き 読み書き
o まずは災害時にビジネス的に許容可能な RPO / RTO を検討する o RTO = 障害発⽣時に「どのくらいの時間で」 復旧させるか o RPO = 障害発⽣時、過去の「どの時点まで」のデータを復旧させるか o バックアップ戦略に従って、⼀括で漏れなくバックアップが取れられるよう ⾃動化しておくことを推奨 o AWSの場合、各種サービスの⾃動バックアップ機能やAWS Backupの活⽤ ※ RTO・RPOはできる限り最⼩ににしたいという要件のままだとコストや⼯数 が跳ね上がるので、ビジネス側と適切な落とし所を話し合うこと https://aws.amazon.com/jp/blogs/news/top-10-security-best-practices-for-securing-backups-in-aws/
o Webアプリでは、書き込みに比べ読み込みの処理が中心となる場合が多い o DBの観点では、リードレプリカを複数台⽴てることで、 読み込みのパフォーマンスを向上することができる MySQL (Source) MySQL (Replica) MySQL (Replica) 読み書き可能 読み込み専用 … 非同期レプリケーション (反映に少し時間が掛かる点は注意) Web サーバー SELECT文 SELECT文 INSERT/UPDATE/DELETE文 Web サーバー Web サーバー
o インメモリデータストアとは、メモリ上にデータを格納することで非常に 高速なやり取りが可能なデータストア (Redis, Memcached等) o 例えば、頻繁に必要となる情報をキャッシュしておく用途に利用される o キャッシュに乗っているデータへのアクセスは非常に高速 Redis MySQL Web サーバー ※ キャッシュ戦略については、Cache-AsideやWrite Throughなどを調べてみてください Web サーバー Web サーバー Web サーバー インメモリデータストア
o 問題が発⽣した際の速やかな対応や、データドリブンなサービスの改善を 効率よく⾏う上ではメトリクスやログを収集して活⽤する仕組みは重要 o 取得するメトリクスやログ、アラートを上げる対象、適したツールを検討 o クラウドの場合、各種サービスやリソースの増減に対応したツールが便利 o システムが複雑化するにつれ、「どこで問題が⽣じているか」を確認する ためのトレースの仕組みへのニーズも徐々に増加している https://speakerdeck.com/track3jyo/startup-monitoring-aws2022
o より⾼速なサイクルで価値提供を⾏うためには、システム側でも 頻繁に安全な⽅法でサービスをリリースする仕組み作りが重要となる o CI（継続的インテグレーション） o ソフトウェアの変更を⾃動でビルド・テストし、本番にデプロイ可能な 状態かをこまめに検証する o CD（継続的デリバリ / デプロイメント） o デプロイの準備や、デプロイ作業⾃体を⾃動化する レポジトリ ビルド テスト デプロイ 本番 ステージング 開発 GitHub等 コードの 変更 CI CD
(Infrastructure as Code) o 以下ようなニーズがある場合、インフラのコード化を検討する価値がある o 環境の複製を容易にしたい o インフラ構成についてもデプロイ前にチームでコードレビューしたい o インフラもテストからデプロイまで⾃動化したい o コードを読むだけで容易に構成を把握可能な状態にしておきたい EC2: Type: AWS::EC2::Instance Properties: ImageId: ami-xxxxxxxxxx InstanceType: t2. AWS CloudFormationで仮想サーバーを立てる例
o やりたいことはビジネスの成功 o ビジネスの成果と、実際に掛かるコストを定量的に把握して、 今どれぐらいインフラに投資すべきか、コスト削減すべきかを⾒直すと良い o 全体のコスト概算だけでなく、その中で⽀配的な要素を把握することが⼤切 Web ロード バランサー Web Web サーバー データベース 30% 40% 5% ストレージ 10% その他の サービス群 15% この辺りから 確認すると効果的 ※コストの割合のイメージ
※ 例えばAWSでは o 最新世代のサーバーを選択することでコストパフォーマンスが向上 o DB・ストレージについても、ユースケースに合ったサービス、クラス、 オプションを選択することでコスト削減可能 o ⼀定期間利⽤をコミットすると安価に利⽤できる料⾦モデルも検討 o 本番運⽤後に実際の使われ⽅を確認して、不要なリソースを減らすことも可能
o まずはリスク分析を⾏い、 「何をどこまで守るか」を検討しよう o ベースラインアプローチ o ⾃社に合うガイドラインを選定して、ギャップ分析を⾏う o ISO 27001 / PCI-DSS / AWSのWell Architected Framework等 o 詳細リスク分析 o 情報資産の洗い出し（例: 漏洩時のインパクトの⼤きい情報は何か） o 資産ごとの脅威・脆弱性の洗い出し o リスクの定量化 o 対策予算や⼈的リソースも加味しつつ、リスクへの対策や優先度を検討 o 定期的なリスクの確認と対策のアップデート（PDCAを回す）
- Well Architected Framework o SEC 1. ワークロードを安全に運⽤するには、どうすればよいですか? o SEC 2. ユーザー ID とマシン ID はどのように管理したらよいでしょうか? o SEC 3. ⼈とマシンのアクセス許可はどのように管理すればよいでしょうか? o SEC 4. セキュリティイベントをどのように検出し、調査していますか︖ o SEC 5. ネットワークリソースをどのように保護しますか? o SEC 6. コンピューティングリソースをどのように保護していますか? o SEC 7. どのようにデータを分類していますか? o SEC 8. 保管時のデータをどのように保護していますか? o SEC 9. 転送時のデータをどのように保護していますか? o SEC 10. インシデントの予測、対応、復旧はどのように⾏いますか?
o 情報資産︓DBに格納された顧客情報（⽒名、住所、商品購⼊履歴） o 脅威︓悪意のある社外ユーザーからの不正アクセス o 脆弱性︓ファイアウォールの設定の不備、XSS、SQLインジェクション o リスク o 個⼈情報の漏洩により、原因究明・謝罪費の発⽣やブランドイメージの毀損 o 対策 o ファイアウォールの設定を⾒直し、必要最⼩限のアクセスのみ許可する o 主要な脆弱性を理解し、脆弱性を残さない実装をする o 保険的対策としてWAF(Web Application Firewall)を利⽤する
短縮URLサービスAPIの例 POST /shoten {“url”: “https://amazon.co.jp”} o urlをハッシュ化 o DBにハッシュと元URLを格納 o 短縮URL /{hash値} を返却 GET /{hash値} o DBから元URLを取得 o 存在した場合、301で元URLにリダイレクトする ※ アクセスログも保存
(本セッションの振り返り) o クラウド上での アーキテクチャ設計 がどのようなものなのかお伝えします o アーキテクチャ設計で意識すべき観点と取りうる選択肢を知ろう o 検討する上で叩き台となる⼀般的な構成とはどのようなものなのか o アーキテクチャ設計の始め⽅ アーキテクティングのイメージは湧きましたか？
o System Designについては⽇本語だとこのあたり o 🔍 「system-design-primer ⽇本語」 o https://github.com/donnemartin/system-design- primer/blob/master/README-ja.md o AWSのアーキテクチャ設計については o 🔍「1人から1000万人までの道のり: AWS におけるスケールする インフラ設計とは？」 o AWSでのシステム構築で意識すべき点をより包括的に記載しているのは o 🔍 「 AWS Well-Architected フレームワーク」
初期から複雑な構成を組んでしまう o 将来⽣じうるあらゆる要件に初期から備えすぎてしまうのがこのパターン o アーキテクチャを複雑にすると、運⽤、改善のコストが増すことを理解する o サービスが⼤きく成⻑し、機能が増えてきた段階では、 当初想定していなかった課題が⾒えてくる。そのタイミングで改善しよう o (近い将来を含め)明らかに⾒えている課題を解決できる 最もシンプルなアーキテクチャを選ぶべき
他社の成功事例に引っ張られる o 銀の弾丸はない o その技術はどういう背景からどういう課題を解決するために登場したのか。 メリットは何で、デメリットは何かを理解しなければならない o 特性のトレードオフにも気を配る o 可⽤性、パフォーマンス、スケーラビリティ、料⾦、 学習コスト、運⽤コスト等 o 上⼿く⾏った事例は、本当に⾃分たちの置かれている状況でも有効か︖
運⽤が上⼿く回らない o 最新の技術を取り⼊れたものの、構築後に運⽤が上⼿く回らないという話 を定期的に聞く o ある技術を採⽤する場合は、 o 直近だけでなく数年後の運⽤も⾒据えて選定する o 運⽤チームが分かれている場合は、運⽤チームへのスキルトランスファー も⼯数に含める o スキルの属⼈化を避ける（その⼈が抜けると誰も触れない状況を避ける）
kiiwami
philnash
moore
productmarketing
smashingmag
sergeychernyshev
pedronauck
shpigford
wjessup
tammyeverts
chriscoyier
kastner
gr2m
