昨日 2月20日　西新宿のgumi本社で行われた「gumi study#18」勉強会に参加してきました。

（都庁前駅A5出口から新宿中央公園を通って勉強会会場でありましたgumi本社に到着。10～15分はみておくのがいい。初台からでも距離はあまり変わりませんが、都庁前駅がオススメ）

まずは会場風景

「AutoScalingを約1年運用してきました」　株式会社gumi 西村　遊様

AutoScalingを運用してみた経験の話でした。git(bootstrap用)、chef（サーバー設定)を組み合わせて、サーバーインスタンスの構築を一から構築することを避けている。

AutoScalingのパターンとして以下をあげていました。

Scaduled Scale out

トラフィック同時接続数が増加したら、インスタンスを起動し、減少したら、インスタンスを削除することをスケジュールで制御。gumiではゲームアプリなので、ユーザ層が利用する時間が異なる＝時間によって負荷も違う

Auto Healing

インスタンス数を調整するパターン。

最初は、gumiではスポットインスタンスで行っていたとのこと。

スポットインスタンスがくせ者で、スポットプライスの変動が激しくなっている。( ap-northest-1cだけが激しい。ap-norhest-1bも激しくなってきた。）オンデマンド価格の三倍に設定してみても、追いつかない。

入札価格が超えてしまい、スポットインスタンスが強制的にterminateしてしまう。最近ではスポットインスタンスでの運用をやめたとこと。

「クラメソ的 CloudFormationのススメ」 クラスメソッド　植木　和樹様

CloudForamtionの話。

利用するメリット

• クリックで構築可能
• 再利用可能。同じような構成だと別の案件で使っていたものをコソコソ直して、数日で提供した案件もあつたとのこと
• 何度でも使い回せる
• ELB、EC2の構成のシステムには最適
• git、subverisionで変更管理

デメリット

• jsonのクセ
• CFnで対応できないプロパティがある
• 対応していないAWSサービスがある。最近RedShiftがCFnに対応したなど
• COMPLETE直前でロールバックしてしまつた

CFnを利用することで、AWSサービスの構成がよくわかるなど、学習効果がある。AWSを理解してみたい方にはオススメ。

「Chef導入後のインフラ業務あれこれ」　株式会社gumi 本間　和教

「このサーバーがだれが準備したかわからない」

「どのように準備したかわからない」

など運用に問題山積み。

運用を改善する目的で、Chefを導入。

Chef-serverを導入して、すべて解決したわけではない。

社内のChatTool、機能別ではなく、サーバー別で。

インストール手順もレシピ化。