2017.05.16

『1日2100万枚』auが提供するデータお預かりサービスにコンテナを導入しました

DSC00535

KDDI サービスアプリケーション開発1部の増田です。

この度、私が開発を担当している「データお預かりサービス」(旧auCloud)にコンテナ(Docker)を導入しました。本サービスはKDDIクラウドプラットフォームサービス(以下、KCPS)上で構築しています(参考)。今回は、KCPSへのDocker導入を検討している、KCPS開発担当 KDDI プラットフォーム技術部 杉田氏とクラウド基盤上でのコンテナ導入における課題や今後の計画について議論した内容を掲載します。

1日700万枚のアップロードと2100万枚のサムネイル作成

DSC00543

 

杉田さん
はじめに、データお預かりサービスとはどのようなサービスですか。
増田さん
auをご利用のお客様の写真、動画、アドレス帳などをお預かりしているサービスです。お客様の大事な思い出でしたり個人情報をお預かりしているため、データの流出、滅失等が許されないサービスとなっております。また、お客様の機種変更時のデータ移行に必要なサービスとなるため、サービスの停止もお客様に多大な影響を与えてしまうキャリアグレードのサービスとなります。
杉田さん
お預かりしているデータの容量や数はどのくらいあるのでしょうか。
増田さん
お預かりデータの総容量は現在13ペタバイトとなります。1日あたり平均で700万枚の写真や動画がアップロードされています。また、アップロードされたコンテンツに対して、大中小3種類、1日平均2100万枚のサムネイルを作成しています。
杉田さん
1日2100万枚とは凄い数ですね!かなりの数のサーバがあると思うのですが、具体的にはどのような構成で処理しているのでしょうか?
増田さん
アップロードのされ方やコンテンツの種類(写真と動画)によって、4種類の仮想サーバで構成されています。アップロードされたデータを定期的に取得しバッチ処理でサムネイルを作成しているのですが、一定時間以内にサムネイルの作成を完了させるようにするため、数百台の仮想サーバが稼働しており、運用面でもコスト面でも課題となっています。
杉田さん
なるほど。その大量のサーバの集約と処理の効率化を目指してコンテナの導入に踏み切った、ということでしょうか?
増田さん
はい。コンテナの特徴として、

・軽い、早い (…高密度化できる)
・可搬性、再現性 (…開発や運用プロセスの改善)

といったことが挙げられますが、今回はリソースの効率化を一つの目的として事前に検証を行いました。検証の結果、アプリケーションをコンテナ化しサーバの構成をチューニングすることで処理効率が向上することがわかったため、商用システムへの導入を進めることになりました。ちょうど同じようなタイミングでKCPSにDocker対応しているCentOS7.2がリリースされましたよね。

杉田さん
そうです。私の方でもKCPS上でのDockerコンテナ利用について検証していたため、グッドタイミングでしたね(笑)。

クラウドブログサーバ構成

お客様影響ゼロでの商用導入に向けて

杉田さん
まだまだ世の中では開発環境でのコンテナ利用が多いと思いますが、商用システムにコンテナを導入するにあたり何か苦労や工夫したことはありましたか?
増田さん
今回はシステム全体の一部のサーバ(機能)だけをコンテナ化したため、運用が大きく変わらないようにしました。具体的には以下のような点です。

▼ログの保存

キャリアグレードのサービスを掲げている以上、アプリケーションログを一定期間保存しお客様から調査依頼をいただいた際等にログ調査を行う必要があります。コンテナの性質上、そのままではコンテナが落ちるとログも一緒に消えてしまうため、DockerのData Volumeを利用し仮想サーバのストレージ領域にログを保存するようにしました。

▼コンテナログとホスト名の紐付け

既存のシステムでは各サーバのログをログ集約サーバに集めています。その際、ホスト単位でログを管理しているのですが、コンテナから出力されるログはコンテナIDしかキーとなる情報がありません。そのままだとコンテナが再起動したり仮想サーバの障害により切替った場合などにコンテナIDも変わってしまい、正しくログ調査ができない恐れがあります。そのため、出力されたログと稼働している仮想サーバのホスト名を紐づけるような仕組みを加えています。

クラウドブログ-ログ集約ppt

杉田さん
既存の運用方法に影響が出ないように、ログの処理に一工夫したということですね。仮想サーバ側に保存しておけば、コンテナが落ちても再度同じ領域を指定すればそのまま利用できますからね。
商用環境へのリリースについてはどのような手順で行ったのでしょうか?
増田さん
コンテナ化した新しいサーバを追加し、リソースを確認しながら旧サーバを停止する、というフローを繰り返すことで、サービス影響なく全てのサーバのコンテナ化を行うことができました。並行運用できたのも、既存の運用を変えないような工夫を事前に行っておいたからです。合わせて、運用への引継もスムーズに行えました。

クラウドブログppt

杉田さん
実際に商用へリリースしてからはどうでしょうか?性能面や運用面で何か問題は発生しましたか?
増田さん
結果として物理サーバの台数を半数にすることができました。また、導入から3か月経ちましたが、お客様影響や処理遅延は発生しておりません。お預かりサービスのピークトラフィックはイベントの際なのですが、先日の5月連休も普段の約倍(1300万枚/日)の写真がアップロードされ4000万枚近くのサムネイル作成を行いましたが、エラーや処理遅延等は発生せず、安心して過ごすことができました。
杉田さん
素晴らしい!新しいシステムをコンテナで構築したのではなく、運用中の既存の商用システムにコンテナを導入したというのは、非常に価値があることだと思います。

クラウドとコンテナ  今後の展望

DSC00546

杉田さん
クラウドを利用するメリットはいくつかありますが、その一つに「いつでもすぐに、スケーラブルに利用できる」ということがあると思います。コンテナはまさにそのメリットを加速化させる技術ではないかと。KCPSとしても、コンテナで構成されるアプリケーションやシステムがクラウドのメリットを享受できるような仕組みを提供していく必要があると考えています。
KCPSを利用するお預かりサービス担当として、今後このシステムに対してどのように考えていますか?またKCPSに期待することはありますか?
増田さん
今回は既存の運用にできるだけ影響が出ないようにコンテナの導入を実施したこともあり、比較的低い障壁でコンテナ化を実現できました。ただお預かりサービスにはまだまだ多くの役割をもったサーバがあります。コンテナ化することでリソースの効率化を図るだけでなく、バージョンアップや増設といったメンテナンス作業に対する運用面での改善も進めていきたいです。イベントの際の一時的な高負荷に対して、自動的にサーバやコンテナがスケールアウトするような構成が組めるとよいですね。
杉田さん
そうですね。コンテナ化することが目的ではなく、運用の負荷を減らし、アプリケーションの開発に集中してよりよいサービスを継続的に提供することが結果的にお客様にとって重要だと思います。加えて、KCPSは高い稼働率を誇るサービスでもありますので、コンテナを導入しても既存の可用性や信頼性を損なわず運用できるようなインフラにすべく、私の方でも検証を進めていくつもりです。実ユーザとして、ぜひ増田さんの意見も聞きたいので、今後もよろしくお願いします!

         ※参考)KCPS稼働率2017年1Q

―対談を終えて

Dockerの商用導入は社内的にも事例がなかったのですが、ハードルは想定より低く、導入により受けられた恩恵も大きいものとなりました。今後も杉田さんをはじめKCPS担当の方と協力してコンテナやその他新技術も積極的に採用していけたらなと思っております。皆様もぜひ一度コンテナに触れてみてはいかがでしょうか。

カテゴリ
タグ

KDDI株式会社 プラットフォーム開発本部
サービスアプリケーション開発1部

増田 光洋

新着記事
タグ
アーカイブ
カテゴリー
Contact
TOP