なぜクラウドを使わないのか（あるいは、なぜクラウドを使うのか）
こんにちは、はるかさんです。 今日からはじまるピクシブ株式会社Advent Calendar 2015、1日目を担当することになりました。 先日娘に本物のアドベントカレンダーを買ってあげた訳ですが、意外と高いので来年は使い回せるように丁寧に使わせようと思っています。
さて、ピクシブ株式会社では現在10を越えるサービスが運用されており、それらを支える様々な社内ツールが存在します。 アドベントカレンダー初日の今日はこれらのシステムがどういったところで動いているか、簡単に紹介しようと思います。
クラウドサービスの利用
面接の際によく聞かれる質問の1つが「ピクシブはなぜクラウドを使ってないんですか？」という質問です。 今年だけでも10回くらいは回答しましたが、結論から言えばピクシブでは所謂クラウドサービスをいくつも利用しています。 いくつかの例を見てみましょう。
Google AnalyticsとGoogle BigQueryによるデータ解析
ピクシブではWebサイトのユーザ傾向分析のためはやくからGoogle Analyticsを活用してきました。 たくさんのデータがGoogle Analytics上に保存されています。 Google Analytics Premiumでは、Google BigQueryにデータをエクスポートすることが可能です。 ピクシブでは、Google AnalyticsからエクスポートしたデータとFluentdを利用してBigQueryに出力したデータをマージし、 様々なデータ分析を行っています。
GitHubとCircle CI、Coverallsを利用した開発
ピクシブではGitHubを利用した開発も積極的に行われていますし、CIにはCircle CI、Travisといったクラウドサービスが利用されています。 一方、pixivのソースコードが入っているpixiv.gitは自社サーバ上のGitLabにoriginがあります。 これは、GitHubや他の依存サービスがダウンしている状況においても、支障を来すことがないようにするためです。
なぜクラウドを使わないのか（あるいはなぜクラウドを使うのか）
紹介した以外にもピクシブではたくさんのクラウドサービスを使用しています。 とはいえ、pixivのアプリケーションはAWSのEC2（あるいはGCPのGCE）上のVMでは動作していませんし、 画像配信は白河の配信クラスタから行われています。 その理由は「pixivのシステム設計がクラウドサービスに最適化されていない」からです。
クラウドサービスに最適化するとは
クラウドサービスに最適化するということはどういうことでしょうか。 ここでいう「最適化する」ということは「そのインフラストラクチャが提供できる資源の稼働率を100%に近づける」ことを指します。 つまり、インフラストラクチャにかかるコスト（支払う料金）を最低限に抑えつつ、最大のパフォーマンスを発揮させると言うことです。
クラウドサービスの課金体系
クラウドサービスの課金体系は例外はありますが、基本的に「使った分だけ課金」です。 EC2の場合はさらにオンデマンドインスタンス、リザーブドインスタンス、スポットインスタンスの3種類に分かれます。 インフラエンジニアとしてはこれらの課金タイプとインスタンスタイプの違いを十分に理解して、最小のコストで最大のパフォーマンスを引き出すのがミッションになります。
課金タイプによる違い
オンデマンドインスタンスはいつでも起動できて、しかも「使った分だけ課金」というかんじで便利な課金タイプですが、その分料金は割高に設定されています。 割引プランとして用意されているのがリザーブドインスタンスとスポットインスタンスです。
リザーブドインスタンスは一定期間同じタイプのインスタンスを予約することで割り引く仕組みです。 クラウドサービスでも、サーバが沸いて出てくる泉があるわけではなく、実際には使用される量を見積もりながら地道にサーバを買い足しています。 あらかじめこれだけ使う、というのがわかればそれに応じた設備投資が可能になるため、その分割引設定を行うのがリザーブドインスタンスの仕組みです。
スポットインスタンスも安くなる理由自体は同じです。 クラウドサービスは使用されるかもしれない最大のリソースを見積もってサーバを用意する必要があるため、余っているサーバが存在します。 余っているサーバをその時間だけであれば安く提供することができるのがスポットインスタンスです。
インスタンスタイプによる違い
仮想マシン自体のタイプもワークロードにあわせてたくさんの種類が用意されています。一般的なワークロードを想定して、メモリあたりの単価が安めのm4タイプ、 逆にメモリあたりの単価は高いが、CPUコアあたりの単価は比較的安価なc3、c4タイプ、それ以外にもたくさんのインスタンスタイプが用意されています。 パフォーマンスを最大限使用するにはこれらのインスタンスタイプについて十分なベンチマークを取り、ワークロードに対し適切なインスタンスタイプを選択する必要があります。
オートスケーリングの利用
課金タイプによる違いを有効に利用し、「使った分だけ課金」を実現するには、サーバも「使った分だけ起動」を実現しなければなりません。 これを実現するのがオートスケールです。 ピクシブには残念ながらクラウドサービスに最適化するノウハウがないためオートスケールの知見がそれほどありませんが、参考になる資料が公開されているため紹介しておきます。
専用サービスの利用
AWSにはEC2以外にミドルウェアの管理も行ってくれるマネージドサービスがあります。
- Route53: DNSサーバ
- ELB: ロードバランサ
- S3: オブジェクトストレージ
- RDS: マネージドRDBMS
- ElastiCache: マネージドKVS
これらのサービスはコンピューティング資源としては割高ですが、その分運用コストを大きく削減してくれます。 DNSサーバは遅延を考えれば世界中に配置する必要がありますし、ストレージは冗長性と可用性の維持が非常に大変です。 これらを安価に提供するRoute53やS3といったサービスはピクシブでも活用しています。 クラウドサービスを選択する際は単純なコンピューティング資源の安さだけではなく、マネージドサービスとの使用も考慮し、全体として最適化されたシステムを構築する必要があります。
クラウドサービスにおけるセキュリティ
クラウドサービスだからといって鍵をかけなくていいわけではありません。 データセンターであれば鍵の管理や入館管理をデータセンターが行ってくれますが、クラウドサービスの初期状態ではルートのパスワードかアクセスキーが漏れればなんでもし放題の状態です。 善良な管理者は各ユーザの鍵ごとに権限を設定し、各ユーザの行動履歴を把握し、サービスごとの使用コストを管理する必要があります。
AWSにはIAM、AWS Config、CloudTrail、CloudWatchといったこれらを満たす十分な機能が用意されていますが、様々なサービスを適切に設定し、適切に運用しなければなりません。 クラウドだからといって決して放置しておいて良いわけではなく、十分なセキュリティを確保するためにはオンプレミスと同様にきちんと権限管理やセキュリティ上の運用が必要になります。
ピクシブにおける最適化
さて、ここまで述べた通り、クラウドサービスにおいてその性能を十分に発揮するためには、必要なノウハウが数多く存在します。 ではデータセンターにサーバを置く所謂オンプレミス環境ではこのような最適化は存在しないのでしょうか。 もちろん、そんなことはなく、オンプレミス環境においても多くの最適化のための手法が存在します。
3つの拠点
ピクシブでは現状3つの拠点を運用しています。
旧社屋にはピクシブの黎明期を支えていた自作サーバが開発用途や小規模なサービスに利用されています。 旧社屋は法令停電のために停止しなければならない、UPSが非力など、サービスの主運用に使用するためには少々問題があるため、メインのサービスはデータセンターでの運用に移行しています。
新宿データセンターはピクシブが最初に運用を開始したデータセンターです。自転車で通えるほどの距離にあるため、ちょっとしたパーツ交換も簡単にできるのが特徴です。
白河データセンターは最も新しい拠点です。ラックの高さが高く、電源容量、ネットワーク容量が充実しているのが特徴です。主に画像配信の拠点として利用されています。
安定したワークロード
オンプレミスとクラウドサービスの大きな違いはその課金体系です。先ほど説明したようにクラウドサービスは「使った分だけ課金」が一般的ですが、 オンプレミスではあらかじめ負荷を用意し初期投資を行い、ラックや電源の使用料も月に決まった分だけ支払う必要があります。 ネットワークに関しても使用する帯域を予め提示するコミットメントに応じて課金するのが一般的です。
pixivは長期間サービスが継続しており、季節ごとの負荷の増減がはっきりしていること、 TVCMのような突発的影響が少ないこと、突発的トラフィックが吸収できるほど十分なトラフィックが日頃からあること から負荷が非常に予測しやすいシステムといえます。 そのため、負荷の増加に応じた初期投資が可能で、余剰リソースの無駄も少なく、継続的な投資が可能になっています。 これがオンプレミスを利用している大きな理由です。
ハードウェアレベルでの最適化
好きなハードウェアを利用できるというのはオンプレミスの大きな特徴でしょう。 クラウドサービスは用意されているインスタンスタイプから最適なものを選択するだけですが、オンプレミスでは調達するハードウェアにかなりの自由があります。 ioDriveをはじめとするPCI-Express SSDは話題になりましたが、NVMe、M.2といったインターフェースの製品も増えつつありますし、搭載できるサーバ製品も出てきました。 ピクシブでは、このような最新のハードウェアを常に検証していますし、チューニングが必要な部分はハードウェアレベルでの最適化を行っています。
クラウドサービスとの連携
オンプレミスだけを使わなければならない、クラウドサービスだけを使わなければならない、ということはありません。 ピクシブではパブリッククラウドであるIDCFクラウドと既存のデータセンター間のL3接続を行い、同一ネットワークとして一部サービスで利用しています。 これにより、ストレージなどの重要な部分はオンプレミスで稼働させつつ、クラウドのCPUリソースを活用することができます。
他にもクラウドサービスが得意とする点は多いですし、クラウドサービスの利点、オンプレミスの利点双方をうまく活用していくことが求められる技術になります。
まとめ
さて、長くなりましたが、「ピクシブはなぜクラウドを使わないのか」という質問には十分に回答できたのではないでしょうか。 まとめると、ピクシブはクラウドサービスだからといって使わないわけではなく、目的に合わせて最適な構成を考え、結果としてクラウドサービスの比率が現状低くなっている、ということになります。 このエントリをもって「ピクシブはなぜクラウドを使わないのか」に対してのアンサーエントリにできればと思います。
ピクシブではエンジニアを募集しています！
そんなピクシブではクラウドにもオンプレにも強いエンジニアを募集しています。 自分だったらクラウドをもっと使えるぞ！！自分だったらもっとハードウェアチューニングできる！！というエンジニアの方はエントリーお待ちしております！
