実名型グルメサービスのインフラ事情を語る Retty Tech Cafe #1 参加レポート
rettyのインフラ周りのお話が聞けると聞いて、Retty Tech Cafe #1に参加してきました。
最近のインフラ事情・AWSのお話、Rettyのインフラ構成のお話、Rettyの今後の展開についてのお話の3本立てでございました。
スタートアップにおけるインフラエンジニアの役割
Retty技術アドバイザー 堀内康弘様
- 今は、AWSの登場により、ハードウェアの調達、セットアップ、OSのインストールの手間が省くようになってきた
- さらにChef, puppet, vagrant, dockerなどのツールの成熟により、ユーザ環境の設定、ミドルウェアのインストールや設定なども自動でできるようになってきた
- しかし簡単・自動化されるようになっただけで、その仕組などを最初に作るインフラエンジニアは必要
- スタートアップのインフラの特徴は、人数が少なく、急激に成長していき、変化が激しい
- スタートアップインフラあるある
- アプリエンジニアがインフラ整備
- ぐぐって適当に設定
- ユーザ増加してサーバー応答停止
- ぐぐって解決検索
- 以上繰り返し
- 3つの強力な技術トレンド
- インターネットによって情報が無料に
- 携帯端末などが世界中に広がり常時接続が普及
- クラウドコンピューティングによって無限のコンピューティング能力やストレージ、高度なツールやアプリケーションがだれでも安価に、利用時払いに使える仕組みができた
- インフラのコモディティ化により、扱うデータの規模は飛躍的に増加していく
最近の注目AWSサービス
Amazon RDS
- バックアップやフェイルオーバーに対応したDBを数クリックで利用可能なRDBMS
- スケールアップ時にフェイルオーバのダウン時間があります
- 書き込みがスケールしない
Amazon Aurora
- MySQL互換
- MySQLの5倍の書き込み性能
- 可用性、耐久性が高い
- 自動的に3つのAZにデータを保存
- スケールする
- 無停止でCPUやメモリなどをスケールアップできる
- ストレージは自動拡張 最大64TBまで
- ReadReplicaも数クリックで増設
- RDSから利用できる
その他サービス
- CodeDeploy
- CodePipeline
- CodeCommit
- codeのリポジトリみたいなもの
- EC2 Container Service
AWS Lambda
- まだlimited preview
- イベントに対応するコードを用意するだけ
- サーバなどを意識する必要がない
- 設定したイベントに対応してミリ秒単位でコードを実行
- インフラの管理は必要なし
- 料金はメモリの使用量とCPU実行時間による
- 実行時間は100ミリ秒単位で計算
- 効率的なプログラムを書けば安くなる！
まとめ
- インフラを用意するためにコードを書くエンジニアが今後求められます
FAQ
- インフラで困った経験は？
- 人数が少ないのでとりあえずやってみる
- 知らないがゆえにぶち当たる壁
- apacheのmax clientの数の調整をしないといけないなど
- しかしググれば大体なんとかなる
- Auroraに乗り換えの基準はどれくらいか？
- 同じ性能だったらAuroraのほうが安い
- db.r3.largeよりも大きいものにするなら、auroraのほうがいい
- [余談] amazonに入りたかったら、新サービスを使いまくると入りやすくなります
- スタートアップを考えた構成は何かあるか？
- AWSでやれば柔軟にできるので、最初はえいやでやる
- あとから見なおして小さくなどできるので、変えられる構成が大事
- 変えられる構成なら一番小さいのでもいいのでは
RettyにJoinしてDevOpsを目指して1年経った話
前半はこのスライドと同じ感じです。
今の構成
- Elastic beansを使ってるのが特徴的
- 100万人まで
- VPSでLAMPでやってましたが、AWSに移行した
- 200万人〜400万人
- RDSに書き込んでいたロギングが限界
- スケールアウト対応が追いつかない
- RDSのSlave上限に引っかかる(MySQL5.5)
- Master1台に対して、5台までのスレーブ
- 繰り返される緊急デプロイ
- 鳴り止まないアラート
- そこで、ElasticBeanstalkでインフラの透明化をした
- 500万人〜
- Treasure dataや、circle ciを入れはじめた
- インフラ改善に欠かせなかったマネージドサービス
- ElasticBeanstalk
- RDS
- S3
ElasticBeanstalk
- node, php ruby, doker, tomcatなどがセットになったもの
- デプロイは”eb deploy”コマンドでgitから勝手にデプロイされる
- 大事なこと
- オートスケールを自在に使いこなす
- インスタンスは使い捨てになるのでfluentdでログなどはどんどん外部に飛ばす
- fluentdでMongo&中継サーバでS3とTreasure dataに送っている
- .ebextensionでインスタンスを自在に操る
- デプロイ時のタスクをymlで記述
- 学習コストがすごく低い（ただのシェルスクリプト）
RDS
- 高いが、自動フェイルオーバなど、上回るメリットが有る
S3
- EBSででかいインスタンスを用意するのは面倒
- SPOFになりがち
- Mongoのdiskが溢れてメンテナンス不可能になった
- S3の運用にのったほうが楽
最近やったこと
- chat opsをいれてみた
- HubotからSQSをたたいて、EB Workerを動かす
- スポットインスタンスを使ってお得にスケールする
- 費用対効果を考えると微妙
- コストに対して理解してもらう必要がある
- VPC移行と社内ネットワーク整備
- EC2 classicの負債から脱却
- 社内ネットワーク整備、物理ルータと格闘
まとめ
- AWSたのしい
- マネージドサービスを作ってくれる人を求めてます
Rettyインフラの今後について
RettyCTO 樽石将人様
Retty インフラの要件
- キーワード：スケール
- 規模のスケールと運用のスケール
- 1年〜2年で月間ユーザを2000万〜4000万のユーザーを獲得目標
- 国内と海外とでスケールしていく
- ユーザ数スケールにおけるAWSの効果
- 電力不足、熱対策、パケットロスなどの問題は解決してくれる
- ユーザ数スケールの課題
- シングルマスタDB
- ログ爆発 ユーザ数がふえて、ログが増えていく中でどうやってエラーを見つけるか
- 激甚対策 ディザスターリカバリーとして、リージョンがとんだらどうするか
- 地域数スケールにおけるAWSの効果
- MultiRegion対応
- End User受付最適化 海外のユーザが使う場合は近場のregionで対応するようにするなど
- 地域数スケールの課題
- 遅延対策
- 時差対策
- 障害がおきやすいのは、ユーザがたくさん多い時だが、それは人が起きている時間におきる。海外になると、ゴールデンタイムが寝ている人になっていたりする
- 法律対策
- データの持つregionをかえると、個人情報をもっていてはいけないなどの問題が起こったりする
- ヨーロッパが特に多い
- 中国の検閲対策など
運用のスケール
- Rettyは 地球規模のインフラ as codeをやろうとしている
- 日本から世界へ
所感など
- Amazon Auroraいいんじゃないか！？RDSはフェイルオーバ時のダウンタイムとかいけてなかったけどなんか良さげな気がする！
- hubot連携してしゃべるといろいろ動かすのやってみたい。時間ができればいれてみたい・・・
- Rettyでは、chefは学習コストが高く一部のところでのみ使われてるみたいです。お手製のシェルスクリプトとかも動いてるとか。
