Please enable JavaScript.
Coggle requires JavaScript to display documents.
IT72_自社マイキーワードのサーバインフラ構築 (FastlyにBingのキャッシュが残っていて、それが返されてしまう…
IT72_自社マイキーワードのサーバインフラ構築
FastlyにBingのキャッシュが残っていて、それが返されてしまう
キャッシュから予期せぬデータが返されたときに、クライアントが正しく動作するか
BingのキャッシュをPurgeしたら、ゴミがきれいになる
API別のPurgeはしたことがないので、要確認
作業ボリュームが見えないので、1Itrで終わらないかもしれない
ElasticSearchの技術・監視方法の調査に時間がかかり、工数が圧迫される
ElasticSearchは3台で冗長化されているが、障害時に自動で切り替わらない
ElasticSearchにアクセスできなくても、SMPの動作に問題ないか (データの整合性など)
Elastic Searchへのアクセスでエラーになったときにどういうデータを返せばよいかの検討が必要
(古いデータをFastlyのキャッシュから返す、エラーにするなど)
Bingからの切り替え時に、障害なくやれるのかどうかわからない
自社マイキーワードからBingにロールバックできない
切り替えのタイミングでFastlyのキャッシュが正しく返せない
データの可視化が必要になるかもしれない
(ロケールごとのデータ、キーワードごとデータなど)
性能が出ないなどの理由によりコストがBingより安くならない
リリース後の運用に手間がかかるような設計になってしまっている (ブラックリストなど)
セキュリティレビューの指摘により、作業ボリュームが想定よりも増える
TTLを延長するスクリプトがSaaS化でやっている実装のやり方とマッチしない
GBASのログが追加で必要になるかもしれない
耐障害性を高めるには、Route53で新しいElastic Searchに切り替えられた方がよい