読者です 読者をやめる 読者になる 読者になる

astamuse Lab

astamuse Labとは、アスタミューゼのエンジニアとデザイナーのブログです。アスタミューゼの事業・サービスを支えている知識と舞台裏の今を発信しています。

クラウドにあるステージング環境のシステムコスト大幅削減を進めている話

こんにちは。並河(@namikawa)です。

このブログは持ち回り制にしているのですが、前回分でメンバーが一通り書き終えましたので、今日から2巡目になります。早いなぁ。

幸いにしてエキサイティングな毎日なので、ブログに書くようなネタはたくさんある(真顔)のですが、一緒に開発・デザインしてくれるメンバーが早くたくさん来てほしいと思う今日この頃です。

さて、今回の私のエントリは、タイトルの通り、弊社で持っているサービス群のステージング環境のシステムコストの削減を進めている話をします。

・・・本当は、弊社オフィスのある銀座近郊の美味しいラーメン屋を紹介するエントリとか書きたいんですけど、技術ブログという名目でありながら前回のエントリも技術っぽくない内容だったのと、おまえ会社のブログで何書いてるんだと上から怒られそうなので、ちゃんと真面目に(技術の話を)書こうかな、とw (冗談です。怒られません。)

その前に前提の話

少し話はそれますが、弊社のサービスの多くは所謂オンプレな環境で本番稼働しています。そして、私が入社した時点では、試験的な意味合いでステージング環境が AWS (Amazon Web Servoces) 上で動いていました。

その後、社内で検討を重ねた結果、サービス基盤の方向性として、 Google Cloud Platform (以下GCP) を利用する方針としました。なぜそうしたか、については話すと長くなりそうなので、またの機会に別途書こうかと思いますが、現状として、サービスのステージング環境を GCP (主にGCE) へと移行している段階です。

コスト削減をどのように行ったか

f:id:astamuse:20160810113214j:plain

で、ここから本題。セキュリティの都合上、書きにくいこともあるので、手法の一部は割愛しますが、

  • GCE (Google Compute Engine) を使うことにした
  • ステージング環境の稼働時間を平日日中だけにした
  • インスタンスのスペックを見直した

あたりをメインに見直しました。それぞれについて、簡単に説明します。

GCE (Google Compute Engine) を使うことにした

元々、ステージング環境は AWS で運用していましたが、前述の通り、本番環境をオンプレで運用している関係上、ステージング環境については Amazon EC2 をメインとして使っています。

気持ち的には、クラウドサービスを活用したサーバレスアーキテクチャだとかデータ解析基盤とか、こんな風に変えていきたいなーと色々考えましたが、大人の事情もあって、本番・ステージングともに、まずは現状の使い方の延長線上で考える方針としました。

それではと、単純に機能・コストを比較してみたときに、 AWS (EC2) よりは GCP (GCE) の方がコストメリットが出そうだという事がわかりました。

これは弊社サービスの特性上、それなりのデータ量を抱えたデータストアが多く、インスタンスのストレージコストでの差が大きく出た、という点が大きかったことに尽きます。 また、データがたくさんある以上、バックアップを保管する際にも、GCS の Nearline Storage のように安くてそこそこスペックの大容量ストレージがあることもポイントです。

機能的な面においても、比較的低スペックのインスタンスについても、他クラウドサービスと比べて、ネットワークスループットが良く、大量データをインサートするときなんかにもボトルネックになりづらい点も助かります。

クラウドサービスを活用する以上、将来的には、マネジメントサービスをもっと活用していきたいとは思いますが、現状、 GCP は AWS ほどのバリエーションはないので、そこに関してはクラウドサービスの今後の動きを注視しつつ、見極めていきたいなと考えています。

ステージング環境の稼働時間を平日日中だけにした

コスト削減効果としては、これが一番大きいのですが、ステージング環境の稼働時間を、平日日中だけ、つまり関係者が働いている時間帯だけに限定しました。

皆さん、帰宅の際にオフィスに誰もいなかったら、オフィスの電気を消して帰ったりしますよね?あれと同じで誰も使っていない時間はサーバを落としましょう、という話です。

とは言え、最後の人が全インスタンスを落とすのは大変だし、オペミスの温床になる可能性もあるため、 Jenkins で自動化していて、具体的には、以下のような感じで運用しています。

  • 平日の9時45分頃からインスタンスを自動起動、同じく平日の22時頃にインスタンスを自動停止しています
  • インスタンスの自動起動/停止は、 Jenkins のジョブで行っています
  • 22時以降も利用するために延長したい場合は、開発メンバーが Jenkins ジョブのスケジュール設定を変更します



その他、注意点や工夫した点は、以下の通りです。

  • 月〜金の中には、祝日が含まれるタイミングがあるので、祝日はインスタンスを起動しないようにしました
    • こちらの祝日判定ライブラリを活用させていただきました
    • 年末年始休暇とか、会社特有の休日は、上記ライブラリだけだと不十分なので、別途自前で対応が必要です
  • インスタンス自動停止ジョブについては、急遽休日にインスタンスを起動した場合などでも落とし忘れがない様、平日に限らず毎日実行しています
  • 延長などで、 Jenkins ジョブのスケジュールを変更した場合、設定の戻し忘れを考慮して、毎朝ジョブの設定を元に戻す"ジョブ"を実行しています
  • ジョブの単位は、サービスごとであったり、データクラスタなど、依存関係や起動順序を意識すべきインスタンス類をまとめて作るようにしました

この結果、ステージング環境の稼働時間は、元々の3分の1程度になりました。クラウドサービスを使うとサーバインスタンスなどは時間単位の従量課金になるので、その分のコストが浮く事になります。

インスタンスのスペックを見直した

これは、リプレースや移行をするタイミングなどで、必ず検討する内容だとは思いますが、実際に使われているリソース量などをベースに、インスタンスのスペックを決めます。

ステージング環境の位置付けにもよりますが、アプリケーションの機能テストを行う場、だとすると、リソースに大きな余裕を持たせる必要もないかと思います。 また、モノにもよりますが、不必要に冗長になっている構成も一部削減したりなど、見直しを実施しています。

基本的には前述の通りですが、弊社のステージング環境は、毎日シャットダウンする前提ですので、その前提だとインスタンスのスケールアップ/ダウンも容易です。

このように、まずはスモールスペックでスタートし、実際に使いながら適宜必要なものを使っていくという考えがクラウドサービスを活用する上では必要かと思います。

結果

その結果、コストはどうなったか、という話ですが、残念ながらまだ移行の途中ではあるので、正確な before/after な数値は出ていません。ごめんなさい。

ですが、現状の手応えとシミュレーションの結果をあわせて考えると、システムの稼働時間を大きくカットしたことと、元々の使い方に少々無駄があったこともあり、必要コストは約 75% 〜 80% 程度カットできる見込みであることを報告しておきます。(あくまでステージング環境の、ですけどね。でも結構大きいのよ。)

・・・という見込みと大人な事情から、さっさと移行してしまって、もっと新しいことを進めていきたいので、色々とお手伝いしていただける方を大募集中です。是非、下部のバナーから(ry

それでは!=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́

Copyright © astamuse company, ltd. all rights reserved.