星野(@con_mame)です。クックパッドでは、AWSを活用してサービスを行っています。現在クックパッドでは、各種キャッシュにMemcachedやRedisを使用しています。用途の多様化やアクセス数の増加などでこれらのサーバのインスタンス数が増加し管理コストが増加してきています。Redisへの置換えを検討しています。2.6.13と2.8.6が使用出来ます。URLが発行され、このEndpointにクライアントから接続することで現在Masterになっているノードに接続することが出来ます。(ReplicationでもこのEndpointのアドレスが使用されています)SlaveになっているノードはPromoteを行なうことで、Masterへと昇格し、他のノードは自動的に新MasterのSlaveになります。--apply-immediatelyこれを実行すると、Replicationのつなぎ替えが完了します。nodeの性能が劣化、もしくは接続が失敗するという事象が確認出来ました。これは、ElastiCacheだから発生するというものでは無く、Redisを使用している場合は起こりうる問題です。弊社では保存するデータ量を少なくするなどして回避しています。onlyになるのですが、アプリケーション側ではhaproxy・twemproxyやミドルウェアの機能などを使用し、Slaveの振り分けを行なう必要があります。Sentinelを使用したFailoverもあります。ElastiCache自体に、自動Promoteや、Slave共通の1つのEndpointがあり、よきに負荷分散してくれると嬉しいところです。試用してみた感想や注意点をまとめておきます。http://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/Welcome.htmlSnapShotリリース時から、Redisのdbファイルをインポートし移行を簡単に行える機能はありましたが、今回は障害時などにRecoveryを簡単に行えるように、バックアップ・リストア機能が実装されました。自動・手動でsnapshotを取得することが出来ます。(cache.t1.microではバックアップ機能は使えません)snapshotを作成する場合は、ドキュメントにも記載がありますが、BGSAVEが発行されるため、データ容量によっては性能劣化が発生する可能性があります。何回かベンチマークを行いましたが、データサイズが大きい場合に若干の性能劣化が発生しました。ユースケースに応じて事前にパフォーマンステストを行なう事を推薦します。nodeでスナップショットを取得するといいかと思います。このへんも、自前でRedisを運用しているのとさほど変わりません。高頻度でデータ更新・セットを行いましたが、BGSAVEが発行されたタイミングのデータがきちんと保存され、リカバリ可能でした。ConsoleではからBackupを選択してに名前を入れれば完了です。Windowを指定することで自動実行が可能です。こちらは、最低でも1時間は設定しないといけません。"ping"こんな感じで、ただbgsaveが打たれているだけでした。SnapShotの時間は、cache.m1.mediumで1GB程のデータのSnapShotが完了するまで、約10-15分ほどかかりました。このへんは自前運用しているRedisだと1−2分で完了するので、時間がかかっている印象です。cache.m1.mediumこれでOKです。Groupは引き継がれません。Groupの適用を行います。このへんも、SnapShotのメタデータに含められていると速やかに復旧が出来ると思っています。スクリプトを書いて自動化ですね。URLが新しいものになるので、アプリケーションの設定などを変える必要があることです。この辺りも、既存のEndpointにSwapしてくれる機能があると更に便利だと思っています。これの回避方法としては、Route53などDNSにCNAMEで別名を付けておき、Endpointを設定するとDNSレコードの変更で一応は対応出来ますが、スマートではないです。RedisはBGSAVEなどで子プロセスをforkする場合にメモリを確保するのですが、これはRedisのmaxmemoryには含まれないため、場合によってはswapなどが発生し、パフォーマンスの大幅な劣化が発生します。Redisはここで指定されたメモリは使用しません。ここはユースケースに応じて適切に設定しておくといいかと思います。デフォルトでは制限無しです。Redisの新機能について簡単にまとめてみました。このサービスはフルマネージドなサービスですが、AWSの他のサービスに比べると、殆ど生のRedisを使っている印象で、今のところ、自動SnapShotやホストの管理などを軽減するには良いサービスだと思っています。Windowがあります。最大30分nodeが停止する可能性があるので、そこをうまく扱う必要があります。機能が拡充して、移行メリットが大きくなれば全面的に移行したいと考えています。コスト最適化についてご紹...2019-06-17レシピ検索を支えるレガシーでクリティカルな大規模バッチを刷新した話こんにちは、会員事業部の新井です。ビルドログの読込モバイル基盤グループのヴァンサン(@vincentisambart)です。使ったセキュリティログ検索基盤の構築サービス特性にあった検索システムの設計戦略クックパッド採用説明会「クックパッドはサービスの作り手を採用したいんです。/*}*/スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。