Amazon ES に移行をしたら幸せになれるのか？ / Moved to Amazon ES

Transcript

1. Amazon ES に移行をしたら 幸せになれるのか？ 2017.09.11 CA.io @kakakakakku

2. 吉田 慶章 @kakakakakku - プレゼン芸人 - 7/05 : AWS Solution

   Days 2017 登壇 - 7/21 : JAWS-UG コンテナ支部 登壇 - 8/27 : July Tech Festa 2017 登壇 - 9/08 : CROSS 2017 登壇 - 9/11 : CA.io 登壇 - 9/16 : XP 祭り 2017 登壇 ＼喋りすぎ／ 今日ココ →

3. 僕はマッチングサービスに関係ないです → プレゼン芸人枠

4. さて

5. EC2 で運用されていた とある Elasticsearch を 最近 Amazon ES に移行してみた

6. つらかった

7. 移行をして 幸せになれたのかな？

8. まず, 移行前の状況をザックリと

9. 総ドキュメント数 3億 調べてみたら, 2億ドキュメントは不要だった

10. 総インデックス数 1200 3年間以上も永続化している

11. バージョン Elasticsearch 1.4 比較的古め

12. 構成 非クラスタ1台 つらい

13. open_file_descriptors ぐんぐん成長 そろそろ “too many open files” 出そう

14. Amazon ES ＼救世主？／

15. m3.xlarge 移行前

16. データノード c4.large x 5台 専用マスターノード c3.medium x 3台 Amazon ES

    移行後

17. データノード c4.large x 5台 専用マスターノード c3.medium x 3台 Amazon ES

    移行後 ＼圧倒的成長／

18. ハマりポイントなどを紹介

19. スプリットブレインの問題を考慮して 専用マスターノードは3台にする (AWS は奇数台数を推奨している) https://docs.aws.amazon.com/ja_jp/elasticsearch-service/latest/ developerguide/es-createupdatedomains.html

20. 単純に, コスト3倍

21. 試しに専用マスターノードを t2.small にして リロケーションをしてみたら

22. ＼ クラスタ死亡 ／ 本当に何もできなくなって サポートにクラスタを削除してもらった 専用マスターノードだとしても, t2 は控えましょう

23. 次に

24. シャード数 インデックスサイズが 30GB 以下なら シャード数を 1 にする ( デフォルト設定は 5

    ) デフォルトのまま 運用してませんか？

25. https://aws.amazon.com/jp/blogs/news/get-started-with-amazon- elasticsearch-service-how-many-shards-do-i-need/

26. アプリケーション側も苦労した

27. Elastica v3.1.1 以降なら AwsAuthV4 トランスポート 対応 https://github.com/ruflin/Elastica ＼PHP Client／

28. AwsAuthV4 「IAM Role + 署名付きリクエスト」 アプリケーション側に実装が必要だった Amazon ES App

29. Amazon ES のダメな点 ＼良い点もたくさんあるけど／

30. - VPC 内に配置できない - リロケーション (クラスタ再構成) が遅すぎる - リロケーションに失敗すると, サクッと死亡する

    - 自動スナップショットからリストアできない - サポートに依頼する必要がある - 札束で殴るしかない - まだまだ他にも...

31. まとめ

32. Amazon ES に移行をして 幸せにはならなかったけど 安定稼働したから良しとする (EC2 のままスケールさせても良かったかも)

33. 移行フローで苦労した話などは また別途どこかで話せればと！ Elasticsearch on EC2 → Amazon ES

34. http://kakakakakku.hatenablog.com/entry/2016/12/20/000612 運用面のコツは去年まとめた資料参照で！