[AWSDevDay2023] The anti pattern (ジ・アンチパターン)

© 2023, Amazon Web Services, Inc. or its affiliates. All
rights reserved. 0 6 2 2 , 2 0 2 3

rights reserved. 1. 自己紹介 2. 広告効果測定とは？ 3. アンチパターンのパターン 4. アンチパターン事例 5. まとめアジェンダ

rights reserved. 自己紹介略歴上原賢也 2006年日本発ECオープンプラットフォーム「EC-CUBE」の開発 2009年広告運用「THREe」のインフラ基盤の設計・構築 2012年全社の品質管理・インフラの導入・運用をメインで実施 2015年ベトナム子会社へ出向し、オフショア開発拠点の立ち上げ 2019年日本に帰国し、主にインフラ面から基盤戦略全般を担当コスト最適化大好き人間。開発から組織運営などなんでも屋 2020年岡山大学大学院自然科学研究科電子情報システム工学専攻卒業 2020年株式会社イルグルム入社以後、インフラエンジニアとして業務に従事。オンプレ、クラウド問わずインフラの設計、構築、運用等を担当。好きなサービス：Amazon Simple Storage Service (Amazon S3) 略歴 Katsuya Uehara 山本瑛治 Eiji Yamamoto

rights reserved. 広告効果測定とは？ • マーケティングの効果をメディア・デバイス・代理店を横断して測定、マーケティング活動の成果最大化をサポートするサービスです。計測広告効果測定アクセス解析 View計測 LPO クリック計測/SEO計測経路分析動画広告記事広告ディスプレイ広告コンテンツマーケティング純広告自然検索アフィリエイト広告リスティング広告リターゲティング広告ダイレクト SNS LP TOP コンテンツ CV 活用外部連携 BI/レポーティング MR/CRM/SFA 広告配信/運用管理リサーチ/モニター 3rd Party Data EC/通販支援ツール TV/オフライン施策分析レポーティング施策軸ユーザー軸デモグラフィックカスタマージャーニー分析チャネル別集計アトリビューション分析

rights reserved. 広告効果測定とは？ • 広告効果測定ツール売上シェアNO.1「アドエビス」

rights reserved. アンチパターンのパターン • アーキテクチャのアンチパターンが生まれる3つのシチュエーション 1. よく検討しとけよパターン 2. アンチパターン許容したつもりパターン 3. ベストプラクティスの解釈間違えてるよパターン

rights reserved. 1.よく検討しとけよパターン：背景 • オンプレPostgreSQLのAWSへマイグレーション • 1,000超データベースをAmazon Auroraへそのまま集約サーバーデータベーススキーマサーバーデータベーススキーマデータベーススキーマサーバーデータベーススキーマデータベーススキーマインスタンスデータベーススキーマデータベーススキーマデータベーススキーマデータベーススキーマデータベーススキーマ Amazon Aurora

rights reserved. 1.よく検討しとけよパターン：課題 • 運用開始後暫くして、Copy文データ投入のRead IOPSが爆増・・・ 12/14 12/15 12/16 12/17 12/18 12/19 12/20 Read IOPS

rights reserved. • Catalog情報のXID回収にAutovacuum (XID回収により)が滞り、肥大化・統計がズタズタに・・・ 1.よく検討しとけよパターン：原因 0 100 200 300 400 12/10 12/11 12/12 12/13 12/14 12/15 12/16 12/17 12/18 12/19 12/20 12/21 Max XID Count(M) 閾値200Mで回収されない

rights reserved. 1.よく検討しとけよパターン：対処 • 手動で定期的にXIDを回収する VACCUM FREEZE; (Autovaccum発生前に) • コスト面では I/O-Optimizedストレージも検討 0 100 200 300 400 12/22 12/23 12/24 12/25 12/26 12/27 12/28 12/29 12/30 12/31 1/1 1/2 Max XID Count(M) 閾値200M 前に手動回収

rights reserved. 1.よく検討しとけよパターン：教訓 • ベストプラクティスをもとに事前に模索しよう！ • ホワイトペーパーにも「一番メンテコストかかる」って書かれてるよね出典：https://www.slideshare.net/AmazonWebServicesJapan/20220107-multi-tenant-database

rights reserved. 1.よく検討しとけよパターン：教訓 • もちろんそれぞれのメリデメがある • データベースエンジンの特性も踏まえて運用は検討する必要がある出典: https://www.slideshare.net/AmazonWebServicesJapan/20220107-multi-tenant-database

rights reserved. 2.アンチパターン許容したつもりパターン：背景 • プライバシーの観点からWeb広告の計測は年々複雑化 ▪ 3rd party cookieだと計測不可 ▪ 1st party cookieの場合は計測可能 • CNAMEレコード方式という機能を開発 ▪ 以下が必要 – CNMAE レコードに設定する顧客ドメイン – 顧客ドメインに対する証明書出典: https://support.ebis.ne.jp/s/article/29550

rights reserved. 2.アンチパターン許容したつもりパターン：背景 • 結果、7台の Amazon EC2 に対して数十台の Elastic Load Balancing を構築 ▪ ∵ 25証明書 / 1 Elastic Load Balancing ▪ 1000ユーザで利用する場合、40台必要 • アンチパターンではあるが、あえて選択 ▪ 迫る納期 ▪ マネージドサービスに寄せたいという方針 ▪ 機能の利用ユーザ数も不明 ▪ etc… Elastic Load Balancing : 数十台 Amazon Elastic Compute Cloud (Amazon EC2) : 7台

rights reserved. 2.アンチパターン許容したつもりパターン：課題 • 固定費用の増加 • 運用工数の増加 • サーバの負荷増加 ▪ なぜかメモリが大量に消費されている。。

rights reserved. 2.アンチパターン許容したつもりパターン：原因 • Elastic Load Balancing の数だけ Keep Alive が発生 ▪ Keep Alive: ロードバランサとサーバ間のセッション維持用プロセス ▪ これにより、無駄なハンドシェイクなどをスキップできる Elastic Load Balancing: 数十台 Amazon Elastic Compute Cloud (Amazon EC2): 7台 Keep Alive: 数十プロセス / 1 Amazon EC2

rights reserved. 2.アンチパターン許容したつもりパターン：対処 • 暫定対処 ▪ Keep Alive の無効化（アンチパターン） ▪ アンチパターン（数十台の Elastic Load Balancing ）がさらなるアンチパターン（Keep Alive の無効化）を生み出してしまった。 • 根治対処 ▪ 根本のアンチパターンの是正（＝別の手段でリプレイス） ▪ が、優先度、工数から現実的ではない。。 ▪ -> 実質塩漬け。。

rights reserved. 2.アンチパターン許容したつもりパターン：教訓 • 当然、様々なトレードオフを考慮した結果、あえてアンチパターンを選択するという場面はありうる。 • ただし、その場合は、「さらなるアンチパターンを生む可能性」も含めて選択したほうがいい。 ▪ 「納期がきついから仕方なく。。」だけで選ぶと、未来の運用負荷（技術的負債）はどんどん増えることになる。 • -> 今だけでなく未来も見据えた上で、PoCが必要

rights reserved. 3. W-A の解釈間違えてるよパターン：背景 • アドエビス管理画面のクラウドシフトを実施 • 基本設計： AWS Well-Architected を意識 ▪ 密結合の分離[1][2] – プロダクトを「サブシステム」の集合と定義 – サブシステム単位でアプリ&インフラを分割（≒ マイクロサービス） ▪ ブルーグリーン・デプロイメント[3] ▪ 多層防御[4] [1]: https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/reliability- pillar/rel_service_architecture_monolith_soa_microservice.html [2]: https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/reliability- pillar/rel_service_architecture_business_domains.html [3]: https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/operational-excellence- pillar/ops_mit_deploy_risks_deploy_to_parallel_env.html [4]: https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/security- pillar/sec_network_protection_layered.html

rights reserved. 3. W-A の解釈間違えてるよパターン：背景 • 詳細設計 ▪ サブシステム単位で Amazon VPC を分割すればいいのでは!? – 密結合の分離：〇 • ∵ Amazon VPC は最も大きなインフラの粒度 – ブルーグリーン・デプロイメント：〇 • ∵ Amazon VPC 単位で分けておけば、並列デプロイ可能 – 多層防御：〇 • ∵ Amazon VPC 単位で分けておけば、L3レイヤの制御も簡単 ▪ Amazon VPC の作成と利用に追加料金は発生しないから、コスト面もok!?

rights reserved. 3. W-A の解釈間違えてるよパターン：課題 • 運用工数 & 固定費用増えまくり。。 ▪ VPC Endpoint, Transit Gateway VPC Attachment …

rights reserved. 3. W-A の解釈間違えてるよパターン：原因 • Amazon VPC 分割の多用がアンチパターンだった。。 • 上述の W-A をみても、 Amazon VPC 分割を多用せよとは書いていない。 ▪ W-Aに従ったのはよかったが、解釈を間違えた。

rights reserved. 3. W-A の解釈間違えてるよパターン：対処 • 暫定対処 ▪ これ以上 Amazon VPC は増やさないようにする。 ▪ つまり、 Amazon VPC ではなくSubnet 分割で代用 – 最終的には、Subnet 分割も控えるのがベスト。 • 根治対処 ▪ Amazon VPC を集約していく。 ▪ 数年かけてのリプレイス計画、検討中です！

rights reserved. 3. W-A の解釈間違えてるよパターン：教訓 • W-Aに従ったのはよかったが、解釈を間違えた。 ▪ モノリシックアーキテクチャはできるだけ避ける必要があります。代わりに、どのアプリケーションコンポーネントをマイクロサービスに分けられるかを注意深く考慮します。[1] – マイクロサービス最強！なんて記載はない。 – ましてや「 Amazon VPC 分割しましょう」なんて一言も言及されていない。 • -> 一人で最適解を出すのは難しいので、セカンドオピニオンが必要 ▪ ex. AWS SA さんからのレビュー [1]: https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/reliability- pillar/rel_service_architecture_monolith_soa_microservice.html

rights reserved. まとめ • ３つの事例から考えるアンチパターンとの付き合い方 1. 定石を知って、よく検討しよう 2. PoCをしよう 3. レビューをしよう（セカンドオピニオン）

rights reserved. まとめ • でも恐れずにチャレンジしよう！ • こんな私たちでも20年近くSaaSサービスを運用して来れました！ • なんとかなる！ならば楽しもう！

[AWSDevDay2023] The anti pattern (ジ・アンチパターン)

[AWSDevDay2023] The anti pattern (ジ・アンチパターン)

More Decks by katsuya uehara

Other Decks in Technology

Featured

Transcript