FANCOMI Ad-Tech Blog

株式会社ファンコミュニケーションズ nend・新規事業のエンジニア・技術ブログ

RedisサーバをDockerで置き換えるインフラインターン

8月5日〜9日の5日間、ファンコミュニケーションズでインフラコースのインターンシップに参加させていただきました。

タイトル通り、稼働しているRedisサーバの内一台をDockerコンテナ内で動かすことに取り組みました。
その後、logやDBサーバの冗長化構成の調査と落とした時の動作確認、復旧手順の作成と実行を行いました。
詳しい日程と取り組んだ内容、得られた知見と感想について以下にまとめます。

日程

テーマ 課題
1 オリエンテーション・環境準備 社用PCをカスタマイズする
踏み台サーバにsshできるようにする
個人用インスタンスにsshできるようにする
個人用インスタンスでdockerを利用できるようにする
個人用インスタンスを、カスタマイズする
開発 CentOS 7ベースのDockerコンテナを起動する
ゴールを定める プロダクトは今、どう動いているかを理解する
2 リリース後に、どうなっているべきかを考える
考えた内容をメンターに説明する
考えた内容をGitHubのIssueに投稿する
DockerコンテナでRedisを起動する
Redisのセットアップ
PR作成
テスト項目を考える
テストコードを書く
3 リリース リリース時に、想定されるリスクを考える
リスクへの対応方法を考える
リリース後の確認項目を考える
考えた内容をメンターに説明する
考えた内容を作業PRにまとめ、レビュー依頼を出す
リリースする
まとめ ブログ記事の執筆など
4 リリース結果の報告会

​ 本番サーバの構築が終了したので、その後、本番サーバを停止する課題に取り組みました。 以下、課題の詳細になります。 ​

テーマ 課題
4 調査 sslサーバ3台以上にログインし、実際にどんな構成になっているか確認する
サーバにどんなリクエストがきているか調べる
リクエストはどう処理されているか調べる
処理中に登場するrsyslogへの出力箇所を見つける
rsyslogdのconfファイルを確認する
rsyslogdの転送先のサーバを調べる
各サーバが、何のログを最終的にどこに出力しているのかを調べる
各サーバが、どう冗長化されているか調べる
構成図を描き、メンターにレビューしてもらう
構成図を描き、インフラ/開発エンジニアにレビューしてもらう
障害試験 どのサーバ・どのプロセスを停止するか決める
停止したときに、何が起こるか想像する
想像したとおりになったか、確認方法を考える
想像したとおりにならなかった場合の対処方法を考える
障害試験の作業PRを出す
停止してみる
想像したとおりになったか、確認する
5 まとめ ブログ記事の執筆など
障害試験結果の報告会
スキップしたOptionalの課題をすすめる

※考える系の課題でも、はじめは必ずメンターとの対話形式ですすめる時間を確保する

対話しながら進めることができたので、とっかかりが掴みやすくスムーズに進めることができました。

やった事

既存構成の把握

nendのクリック処理を行っている部分をとっかかりに、オンプレミスにあるサーバの構成を把握し、構成図に起こしました。

f:id:t_murata:20190809120404j:plain
nend - クリック処理の既存構成図

MySQL部分のMasterとSlaveの関係はもっと複雑ですが、ソースから読み取れた分だけ記載しています。一部の詳しい構成は4日目にメンターさんから説明を受けました。

Redisコンテナの作成

稼働中のRedisバージョンに合わせてインストール。
設定ファイルもビルド時にコピーする。

FROM centos:centos7

RUN <Redisのビルドとインストール>

COPY conf.d  /path/to/redis/etc/
RUN mkdir /path/to/redis/data
EXPOSE<Redisのポート>

CMD ["/path/to/redis.conf"]
ENTRYPOINT  ["/path/to/redis-server"]

Docker(Redis)デプロイ

上記のDockerfileを元にデプロイ。

Rsyslogサーバ(AWS)を落としてみる

AWS上のlogサーバの内、一台を落とす。
影響の確認と落とした際の他サーバの動作を予想し、復旧時の動作確認方法をまとめる。
レビューを貰ったのち、実行する。

MySQLサーバ(Slave)を落としてみる&復旧する

AWS上のMySQLスレーブの内、一台を落とす。
落とすまでの手順とDBが壊れた際の復旧処理をまとめる。
レビューを貰ったのち、実行する。

日別のタスクとメモ

1日目

 - 開発環境にDockerを導入

 - 構成の大枠をメンターから教えてもらう
 - それを元に踏み台サーバからWebサーバにアクセス
 - httpd.conf等を見ながら構成を想像する
 - ps auxでどんなプロセスが動いているか確認
 - Rsyslogとzabbixのプロセスを発見したので、各設定ファイルを見てサーバのIPを特定
 - Rsyslogのロギング方法を確認

 - WebのLVSサーバを見に行く
 - keepalivedの設定が想像通りになっていることを確認

 - PHPのclick処理部分を読み始める
 - Define多すぎてよくわからなくなる
 - redis_manager.phpなどredisに関わる部分の処理を読む
 - どのサーバがどの設定ファイルを読んでいるかを把握する
 - clickがどのDBサーバを使っているかを大体把握する

2日目

 - 1日目に把握した構成を雑にまとめる
 - レビューをもらう

 - Redisスレーブのconfを確認してコピー
 - 開発環境のDockerにRedisコンテナを作る
 - Dockerfile記入
 - WARNINGが出る為、docker runのオプションとOS設定を変更
 - そのままのconfを適用すると動かなくなったので、ログを見ながらconf内容を修正

 - redis-cliを使ったテストをシェルスクリプトにまとめる

 - Dockerfileのissueを作成

3日目

 - Redis Dockerfileのレビューを受けて修正する
 - リリースの為の手順とPRを発行する
 - リリース手順のレビューを受ける
 - リリース手順を修正する

 - リリース!
 - 元に戻す

 - インターン中のまとめ

4日目

 - conversionのRsyslogと冗長化の調査
 - どのサーバ、どのプロセスを停止するか決める
 - 停止したときに、何が起こるかを考える
 - 障害試験の作業PRを出す

 - 実行!

 - インフラチームに成果発表

 - DB(Slave)を落としてみる
 - AWS CLIの書き方を調べる
 - DB落とす→復旧までの手順をまとめてPRを出す

5日目

 - DB落としてみて復旧作業。
 - インターンの振り返り

分かった事

一つのシステムの一部分のインフラだけでも、想像以上にサーバが多い。
影響を受けるサーバや本番への適用手順などを整理して、まとめる→レビューすることで抜け漏れやミスを防げ、新たな問題も見つけ出せる。
Warningは読み飛ばさない。結構重要な設定ミスだったりする。
Dockerやインフラを触る上で、Linuxや主要なミドルウェアの知識は必須。
知識があったら設定項目や構成をもっと素早く洗い出せたと思う。
ミーティングに参加していても、分からない用語が多数出てきたので出来る範囲で触ってみたいと思う。
シェルスクリプトとviが出来ると捗りそう。

この仕事楽しい!

長期間働けるならやってみたいこと

Docker上で動くRedisを増やして、最終的にはすべてのRedisサーバをDocker上で動かす。 デプロイからテストまでを自動化し、テストに失敗したらロールバックする構成を組みたい。Ansibleに組み込んでみたい。

既存のインフラを監視して問題点を把握できるようにしたい。
問題点を分析した上で、適切な対策ができるようになりたい。
システムの要件に応じた適切な技術の選定とインフラの0からの構築をしてみたい。
Kubernetesをオンプレミス環境で使ってみたい。

インターンの感想

本番環境にリリースするまでの流れを短い間に経験出来て、とても面白かったです。
システム構成を読み解くこと、その一部を変更することでどのような影響を及ぼすかを考えること、テストやリリースの流れと問題点を洗い出すことなど、それぞれのフェーズで考え、試行錯誤することが多く、楽しく過ごせました。
メンターや社員さんとの距離感もよく、悩んでも分からない部分に関しては質問がしやすかったので、スムーズに進めることが出来ました。

5日間、ありがとうございました!