[SA-3-1] The anti pattern (ジ・アンチパターン)

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

The Antipattern
（ジ・アンチパターン）
Katsuya Uehara, Eiji Yamamoto
[ S A - 3 - 1 ]
YRGLM Inc.

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

自己紹介

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

広告効果測定とは？

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

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

アンチパターンのパターン

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

アンチパターンの事例

1.よく検討しとけよパターン
（Amazon Aurora DB作りすぎた件）

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

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

• 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で
回収されない

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
前に手動回収

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

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

2.アンチパターン
許容したつもりパターン
（ Elastic Load Balancing 作りすぎた件）

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

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台

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

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

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

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

3.ベストプラクティスの解釈
間違えてるよパターン
（ Amazon Virtual Private Cloud
切りすぎて失敗した件）

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
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

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

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

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

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

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

まとめ

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

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

Thank you!

Please complete
the session survey

[SA-3-1] The anti pattern (ジ・アンチパターン)

More Related Content

Similar to [SA-3-1] The anti pattern (ジ・アンチパターン)

[SA-3-1] The anti pattern (ジ・アンチパターン)