SmartNewsを支える「さくらのクラウド」

公開日
更新日

スマートニュースの大平と申します。ご縁が有りまして、当記事も含めて２回ほど「さくらのナレッジ」に記事を寄稿させていただくことになりました。よろしくお願いいたします。

弊社は創業１年ちょっとの、いわゆる「スタートアップ」企業ですが、そういった会社におけるさくらインターネットのサービスの使い方や、スタートアップ企業にとってのメリットなどについて語ることができればと思っています。

 

SmartNewsについて

まず、弊社の提供しているサービスについて多少理解していただいた方が記事も読みやすいと思いますので、簡単に紹介させていただきます。

SmartNews（スマートニュース）| ニュースが快適に読めるスマホアプリ

smartnews

SmartNewsは、Twitterでつぶやかれる大量のWebページの解析に基づき、いま話題になっているニュース記事を快適なインターフェースで閲覧できるスマートフォン向けアプリケーションです。現在（2014年2月13日現在）iOS版とAndroid版を提供しています。
弊社内で「違い棚」と呼んでいる独自のUIや、自然言語処理や機械学習の検知を最大限取り入れて最適なニュース記事の分類と配信を自動的に行っている事が、サービスの大きな特徴です。

サービスが直面していた課題

SmartNewsは2012年12月のリリース当初から順調にユーザー数を伸ばしてきましたが、ユーザー数の増加に伴うトラフィック増に、常に頭を悩ませていました。
SmartNewsでは朝・昼・夕の１日に３回、ユーザーの携帯端末に最新ニュースが届いたことを伝えるpush notificationをお送りする仕様になっています。そのため、ユーザーからのトラフィックもpushのタイミングに合わせて集中し、非常にギザギザなトラフィックスパイクが発生します。

network traffic graph

ピーク時の負荷を捌くために多数のサーバーが必要となりますし、また発生する通信データの量も軽視できないものとなっていました。
特にネットワーク転送量の増大が頭を悩ませる課題で、多くのクラウドサービスにおいて転送料金は従量課金、もしくは転送量の上限が定められている事業者が多く、トラフィックの増大は運用コストの増大に直結する状況でした。
ユーザーに安定した快適な環境を届けつつ、コストも抑えたい、というのが直面していた課題です。

 

「さくらのクラウド」を用いたエッジサーバー

その一つの対策として、コンテンツのエッジサーバーを「さくらのクラウド」上に構築しました。
他の拠点に置いてあるコンテンツをそのまま配信するのではなく、クラウド上に置いたサーバーを介して配信することで以下の効果を狙いました。

  1. サーバー負荷の低減
  2. 転送料金の節約
  3. 安定したコンテンツの配信

一点目については、クラウド上のエッジサーバーで一定期間キャッシュを行ったり適切なレスポンスヘッダを付与することで、過剰なリクエストを抑制することにより実現しました。
二点目、三点目については、さくらクラウドが転送料金が原則無料で、かつ通信品質についても速度・レイテンシともに非常に安定しているという事が大きく寄与しています。

構成

以下では実際の構成の一部について簡単にご紹介します。

server architecture

フロントにはnginxを置き、バックエンドのコンテンツサーバーのreverse proxyとして動作させる、という構成です。
「さくらのクラウド」ではサーバー１台ごとにグローバルIPが付与されますが、１サーバーあたりに割り当てられるネットワーク・インターフェースは100Mbpsなので、それらのサーバー群を1Gbpsのスイッチの下にぶら下げる形でネットワーク集約を行っています。ロードバランサーはHA Proxyを用いても良かったのですが、クラウドの機能としてアプライアンスのロードバランサーが提供されているのでこちらを使用しています。

運用

弊社では「さくらのクラウド」含めて複数のクラウドサービスを使用しており、かつサーバー台数もそれなりに存在するため、インフラ管理の効率化も重要な課題です。たとえば適応先のクラウドサービスによって提供されるOSのディストリビューションやCPUなどのスペックも異なるケースもあるため、環境に応じて最適な環境構築を行うような仕組みが必要です。

弊社では自動化・効率化を行うために、chefを用いたprovisioningの半自動化を行い、解決しています。
得られる利点について例を一つあげると、chefでは接続先のサーバーのOSによって処理を振り分けたり、接続先サーバーのCPUコア数に応じてパラメータを変更する、という事ができます。
そういう形でchefのrecipeを汎用的に適用可能なものにし、環境構築の負荷を低減しています。

#OSごとに振る舞いを変える例
case node['platform']
when "ubuntu"
    puts "I am ubuntu." 
when "centos"
    puts "I am centos."
when "amazon"
    puts "I am amazon."
end
#CPUのコア数ごとにworker processの数を変える例
default['worker_processes'] = node['cpu'] && node['cpu']['total'] ? node['cpu']['total'] : 1
default['worker_connections'] = 1024
default['worker_rlimit_nofile'] = default['worker_connections'] * default['worker_processes']

なお、chefに関しては、当「さくらのナレッジ」の中でも多数記事が投稿されておりますので、ご興味のある方はあわせてご参照ください。
Chef - さくらのナレッジ

また、弊社の技術ブログでもchefを用いた運用について簡単にご紹介していますので、こちらもご興味のある方はご参照ください。
chef + fabricを用いたクラウドサービス管理 | SmartNews開発者ブログ

 

実際に構築・運用してみて

以下、実際に「さくらのクラウド」上でサービスの構築・運用をしてみて経験したこと、ならびに感じたことを記載します。

ネットワーク回線

ネットワーク回線は非常に安定しています。サービスイン後、ほとんど問題になった事はありません。これでネットワーク転送費用がかからない、というのは非常に頼もしく感じます。

ロードバランサーで発生したボトルネック

一点、発生したトラブルとしては、ロードバランサーのキャパシティを見誤り、ロードバランサーをボトルネックとしたネットワークの滞留を発生させてしまう、という事が一時期ありました。もちろん、私どもが「さくらのクラウド」の提供機能の仕様に慣れてなかったということが主要因です。

以下のサイトにロードバランサーの性能目安が記載されています。
新機能「ロードバランサ」について | さくらのクラウドニュース

性能目安 100Mbps、4000セッション、100cps程度

実際には、こちらは目安なので、性能の上振れ下振れはあると思いますが、クラウドの提供するロードバランサー機能を使用して構築する場合は、こちらの数値を参考にキャパシティプランを検討する必要があります。

サービス無停止でのサーバー移行

エッジサーバーのトラフィック自体も順調にかつ急速に増加したため適宜サーバー数の調整を行っていたのですが、当初構築したスイッチの構成ではIPアドレスが枯渇してしまいました。そのため当時置かれていた石狩第一ゾーンのサーバー群を止めずに、並行して石狩第二ゾーンにスイッチを最適化した構成を構築し、サーバー群をそちらに全て移し替える、という作業を行いました。

migration

サーバー台数的にもトラフィック的にも決して小さいものではなかったわけですが、ユーザーに影響を一切与える事なくスムーズに移行を行う事ができました。こういった構成変更が柔軟に行えるのもクラウドサービスの利点と思います。

ディスク障害

現在は解消した模様ですが、一時期、ディスクの障害が断続的に発生していた時期がありました。その影響で、特定のサーバーにてディスクへの書き込みが不可になったり、サーバー自体がダウンする、といったことが起こりました。
もちろんサービスを使用する側としては障害が少ないに越した事は無いですが、クラウドサービスであるかに関わらずサービスを運用していると予期せぬ障害が予期せぬタイミングで発生する可能性は現実的にゼロにはできません。なので、たとえシステムの一部に障害が発生してもサービスに影響が出ないような、冗長性をもった構成にすることが必要があります。
弊社の上述の例でも、スイッチのレイヤーから多重構成にしており、最低限の冗長性は確保するようにしています。そのためディスク障害の際もサービスには影響を与えることがありませんでした。

チューニング・キャパシティプランニング

こちらはメリット・デメリット双方あるかもしれませんが、「さくらのクラウド」では各レイヤーがブラックボックスになっている比率が少なく、その分サービスインまでにしなければいけない作業も多くなりますが、キャパシティがある程度イメージしやすいです。
たとえばスイッチやロードバランサー、サーバーの論理ネットワーク構成やネットワーク帯域など。

具体的に言うと、スイッチの帯域を何G~Mbpsにするか、そのスイッチに何台のロードバランサー・サーバーをぶら下げるか、等で、これらの作業を自分の手でひとつづつ行っていく必要があります。
構成を自分で明示的に決めなければいけない事でかえって、ボトルネックが発生した際の問題の絞り込みも比較的容易に行えますし、最適なチューニングも行いやすいと、個人的には感じています。

監視・モニタリング

「さくらのクラウド」にはWebUI上に簡易的なアクティビティ表示機能が標準で付属していますが、こちらは正直機能として不足しているため、独自に監視・モニタリングの仕組みを用意する必要があります。もちろん、世間的に知名度が高くよく使われているnagios、ganglia、GrowthForecastなどのツールはクラウド上のサーバーにも適用できますので、別途環境を用意するのが良いと思います。

スイッチやロードバランサーなどアプライアンス系の機能については標準のアクティビティ表示機能のみが頼りになります。こちらは、たとえばAPI経由でメトリクス情報を取得できるようになればトラフィックの監視が行え便利になるので、ぜひ今後のご対応を期待したいところです。

 

まとめ

以上、スマートニュースにおける「さくらのクラウド」の使用事例について、一例ですが簡単にご紹介させていただきました。

なお、弊社が「さくらのクラウド」を使用する事になったのは、さくらインターネット社から「スタートアップ支援プログラム」の提供をいただいた事がひとつのきっかけでした。
次回は、こちらの話も含め、スタートアップ企業にとって「さくらのクラウド」ならびに「さくらインターネット」の各種サービスを使用する事でどんなメリットがあるか、書いてみたいと思います。

 

おしらせ

banner_cloud

banner_startup