gumiStudy 18に参加してきた #gumistudy

gumiStudy 18に参加してきた #gumistudy

Clock Icon2014.02.21

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

2014/2/20(木)に開催された株式会社 Gumi 様主催の勉強会、gumiStudy #18に参加してきました!

今回で18回目となるgumiStudyですが、私個人としては初参加になります。今回は弊社クラスメソッドより植木が登壇するとのことで、普段一緒に仕事する立場にいながらも楽しみにしていました。

当日のTweetまとめはこちらです。

GumiStudy 18 まとめ #Gumistudy - Togetterまとめ

会場は株式会社gumi様の東京本社の会議室。とても広くて奇麗な会議室でした。またジュースやお菓子なども頂いてしまいました。ハリボーのグミ美味しかったです。 写真はセッション前のアイスブレークでリラックスする講師の皆さん。

IMGP0761

Session01. AutoScalingを約1年運用してみました

発表:西村 遊さん(株式会社gumi)

入社2年目で現在SysOpsを担当されているという西村さん。gumiさんのシステムでのAutoScallingの使い方やその中で発生した問題点などについてお話頂けました。

西村さんが経験されてきたAutoScallingの使い方としては、EC2をAMIからLaunchし、アプリケーションはgitを使ってChef Nodeとしてbootstrapした後Chef Serverからセットアップ、rsyncでアプリケーションの最新ソースコードを取得し、正常性を確認後にELB配下に組み込んでいるとのこと(最後の質疑応答で出たのですが、AutoScallingでEC2が立ち上がった時点ではELBに組み込まれているため、一旦スクリプトでELBから外して、正常性確認が取れた後に改めてELBに組み込んでいるとのことでした)

一部のEC2はスポットインスタンスを使われているそうですが、実際にやってみるとスポットインスタンスの価格変動が激しく、また昨年末辺りからスポットインスタンス価格が高騰しており、リソースが必要な時間帯に価格が変動してEC2が切り離される自体が続いたことから、現在はスポットインスタンスの導入は止めて、ピーク時間帯にリソースが増える設定に変更したとのこと。 スポットインスタンスをAutoScallingのLaunchインスタンスとして使うのは教科書的な設計だと思うのですが、こういった落とし穴があるというのは勉強になりました。

Session02. クラメソ的CloudFormationのススメ

発表:植木 和樹さん (クラスメソッド株式会社)

CloudFormationについて、クラスメソッドではどのような使われ方をしているのかや、これからCloudFormationを始める方へのCFnでの考え方などのお話でした。

クラスメソッドでは昨年末アドベントカレンダーとしてCloudFormationで色々な環境を一発構築する「アドベントカレンダー2013:AWS CloudFormationビッグバンテンプレートまとめ | Developers.IO 」という企画を行いましたが、この裏話として、企画当時10人いたエンジニア+営業担当のメンバーのうち、CloudFormationを使っていたのが3人程度だったとのこと。しかしアドベントカレンダーを実施するにあたって皆で勉強し、25日間を乗り切ったとのことでした(私も当時社員では無かったのですが1本書かせて頂きました!)

そんな植木さんも初めてJSONで書かれたCFnテンプレートを見たときは「心が折れそうになった」とのことで、テンプレートの読み解き方、書き方、勉強の仕方についてお話して頂きました。私自身最初は心が折れそうになった一人なので良く分かります...しかし最後にお話されたように(弊社都元が言っているように)「各プロダクトの構成要素とそのプロパティ、相互関係が見えてくるので、各プロダクトをモデルとして理解できるようになる」という意味で、CloudFormationを勉強することはAWSをより深く知ることに繋がると思います。

個人的にはCloudFormationがもっと多くのリソースに対応してくれることを期待しています!

Session03. Chef導入後のインフラ業務あれこれ

発表:本間 知教さん (株式会社gumi)

本間さんからは、gumiさんで導入しているChef Serverについて話をして頂きました。gumiさんでは以前はサーバ環境構築に業務の大半を取られており、新しい技術や手法の調査になかなか時間が取れない状態だったとのこと。一部Puppetやpsshを使った運用改善を行っていたものの、セットアップされたAMIがどのように作られたか分からない(ブラックボックス化)状態になっていたり、ドキュメントの管理が煩雑だったり、他のメンバーが対象サーバに対してどんな作業を行ったのかが分からないなどの、色々な問題が発生していたそうです。

しかしチームメンバーや管理するサーバ台数が増えたこともあり、「攻めの運用体制」としてChef Serverを導入したそうです。導入時には用語の多さやRecipeの作成単位など色々と悩みどころはあったそうですが、運用した結果環境準備は圧倒的に早く出来るようになったとのこと。

バッドノウハウについてもお話頂きました。例えばレシピにアプリ情報を直書きしてしまい他のアプリへ適用しようとしたときに修正コストが大幅に発生したり、roleにレシピを詰め込みすぎて最終的な構成が見えづらくなったりなど。また「孤独なChef使いが生まれてしまった」というお話をされていたのですが、これは「ChefConf 2013: Beginner Chef Antipatterns 」の中で語られたものですね(和訳は「[和訳] 初心者Chefアンチパターン By Julian Dunn #Opschef_ja « CREATIONLINE, INC. 」にあります)

弊社でも「AWSリソースはCloudFormationで、システムリソースはChef(solo)で」という構築手順を一部適用しているのですが、汎用的なChefのRecipeを蓄積していくところはまだまだ試行錯誤を繰り返しているところです。このため本間さんのお話は大変参考になりました。

最後は「運用チームは日々改善、失敗から立ち上がるサイクルが大事」というお言葉で締め。

Session04. 2014年版 クラウドを使うユーザーが考えるべきこと

発表:吉田 パクえさん (株式会社co-meeting)

 トリは吉田さんから、AWSに限らずクラウド全般についての現状と展望、そして意識についてのお話でした。

色々な場所でセミナー講師などをされている吉田さんですが、2013年から2014年にかけてエンジニアを中心にクラウド利用が広がったものの、経営者や営業担当などエンジニア以外向けのセミナーの回数が増えており、そういったエンジニア以外の方へはクラウドについての理解がまだまだ広がっていないのではないかと懸念されているとのこと。またエンジニアの中でもクラウドを分かる・分からないという格差が広がっているのではとのことでした。特に地方ではクラウドが分かるエンジニアが少ないとのことで、これは北海道民の私にも身につまされる話でした。

早いスピードでクラウドに対応していくのも大事だが、エンジニア以外とちゃんと価値観を共有しないとビジネスとして落とし穴になりうるので、エンジニア主導でクラウドが分からない人に対するクラウド知識の伝達が必要とお話されていました。担当者レベルではなく会社自体の意思としてクラウド利用が促進されているのかを意識するのは大事なんでしょうね。

まとめ

どのお話も大変参考になりました。弊社もAWSを中心にビジネスを行っていますが、やはり他社様のやり方や事例などをお聞きするのはとても参考になります。これからもこういった勉強会にたくさん参加して皆さんのお話を伺いたいですし、同様に弊社のやり方や事例を多くの方にお伝えしたいですね。

最後に、講師の皆さん、株式会社gumiさん、ありがとうございました!

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.