0埋めしないようにするには、「-」マイナスつける。
> Time.now.strftime('%Y/%-m/%-d %-H:%-M:%-S') => "2015/6/6 13:9:54"
通常
> Time.now.strftime('%Y/%m/%d %H:%M:%S')=> "2015/06/06 13:10:05"
2015年6月6日土曜日
[Ruby]一桁の日時の値を0埋めしない
2015年6月3日水曜日
[AWS] AWS Summit 2015 Day2
2日は雨の始まり。
それでも人は前日より多い気がしました。
【ランチセッション】1000 万 DL 突破！BrainWars を支える AWS サービスた
・ 資料
- http://www.slideshare.net/matsukaz/brainwarsaws
・ スピーカー
- 松下 雅和 氏（株式会社トランスリミット CTO）
・ サマリ
- Brain Warsのゲームの裏側のアーキテクチャの説明を機能ごとに分割しながら説明
- いろいろなAWSサービスを利用していた
- 自分自身もやったことあるので想像がつきやすく、セッションが切れた場合や
タイムアウト時の振る舞いもユーザからすればエラーでなく見える対応等もしていた
- 機能だけでなく、コストと運用についても意識すること
・ BrainWarsの概要
- Brain Warsをやったことある人（挙手）
→ まぁまぁいる（自分もやってる）
- 11ヶ月で1200万DL突破
- ユーザは、海外が多く、日本は4.6%のみで、海外が95.4%。アメリカが1/4ほどしめている。
- 男女比率はほぼ同じ。20代が約半数。
・ アーキテクチャの基本方針
- スピード優先
- 積極的にアーキテクチャを見直す
- AWSは東京リージョンが多いが、Oregon や Virginia 中心。
（AWSにこだわらないらしいが…）
・ コストはシビアに
- 費用対効果が合わないプロダクトやサービスは使わない。
- 必要でも高いものは自作も検討
- AWSの中の人もびっくりするくらいの低コストで運用している
・ 運用を楽に楽しく
- 深谷生涯に強いアーキテクチャを意識
- hubotによるChatOpsベースの運用
・ 全体アーキテクチャ
・ OpsWorksの活用で工夫している点
- Chefのレシピを追加し、file descriptorなどのチューニングからプロセスの再起動、CloudWatch連携
- タイムアウトしたり、ソケットサーバが落ちた場合、
対戦相手をランダムで選んで操作ログを返却したりする （つまりゴーストと対戦）
・ SNSの活用
- ChatOpsで通知
- SNSは安く、全ユーザに毎月数回送信しても$10ほど。
- トピック数やメッセージサイズだけでなくAPIの呼び出し頻度にも制限があるので注意！
・まとめ
- どのサービスも使いこなせれば強力！
- 大事なのはそれぞれのサービスの特徴を見極めること
- 機能面だけでなく、利用後のコストと運用もイメージすること
・ ランチセッションのお弁当
アコーディア・ゴルフが取り組むクラウド・ファースト！
・ スピーカー
- 田中 理（株式会社アコーディア・ゴルフ 経営企画本部 情報システム部 Web企画推進部 統括部長）
・ サマリ
- 2010年頃からITインフラの移行。
- メールサービスをGoogle Appsへ移行したり、ゴルフ場情報サービスを
GoogleAppEngineへ移行したりと進めてきた。
- 昨年2014年に数々あるサービスの中、Web予約システムのクラウド化を実施。
- 確証を得たので、今後は、基幹系であるERPシステム、連結会計システム等、
他のサービスも順次移行予定。
・ アコーディアはゴルフ総合サービスを提供
- 運営ゴルフ上、運営ゴルフ練習場、提携ゴルフ練習場、ポイントカードサービス
・ アコーディアのポイントカード
- ゴルフ場のメンバ数18万人
- びじたのお客様360万人
- ポイントカード発行枚数380万枚
- 3人に1人がカードあり。
- ビッグデータはリピート率の向上に活用
・ アコーディアにはさまざまなシステムがある
- ゴルフ場システム、宿泊施設の管理システム、ポイントカード管理、
Web予約、会計、人事・給与、等々
・ クラウドへの取り組みと移行理由
- 2010年にメールサーバをGoogleAppsへ移行
→ システム担当者運用負荷の改善(システム障害、スパム・ウィルス対応）
→ ヘルプデスク運用不可の改善(初期設定、容量制限の対応)
→ Webメールの汎用性向上
→ 現行メールシステムにかかる保守費用の削減
- 2011年にGoogleAppEngineを利用したゴルフ場情報サイトを作成
→ ゴルフ場情報を全体で共有しお客様に時速に回答できるようにする
→ 社内サイト構築
- 2014年にアコーディアWeb予約システムをAWSに移行
→ Webシステムが時間帯によってアクセスが集中する。
ピーク時の安定性を確保できる。
→ 柔軟なリソースを確保できる
→ 充実したサービスのラインナップ
EC2, S3、RDS、VPC、Route53
→ データセンタのリージョン選択が可能
→ データの所在が不透明になりがちだが、DCのリージョンが選択可能
・ 今後の取り組み
- 基幹系であるERPシステム、連結会計システム等をAWSに移行
- 理由としては、Webシステムの運用実績から基幹系などのシステムを移行しても
問題ないことが実証されたため
・ なぜクラウド？
- メリット
→ 先行投資を弱小化
→ 迅速な導入が可能
→ コストの最適化が図れる
- デメリット
→ 幅広いサービスの知識が必要
→ 設定黒目や設定内容が煩雑
→ 仮想技術特有のクセ
・ 2010年に仮想環境へ移行した際に比べ、2015年のCloud環境への移行は
HW構築、調達が5ヶ月だったのが、1.5ヶ月になり、本番稼働が4ヶ月短縮。
・ なぜAWS?
- 日本で展開しているCloudエンダーとして、一番優れたベンダーエコシステムが構築されている
- Cloudpack Classmethod, Serverworks, NRI
・ クラウドの方程式
- y = f(x)
→ y: AWS最適解
→ f: ベンダのエコシステム
→ x: エンドユーザの要望
【デベロッパー向け】なぜクックパッドは開発しやすいのか
・ 資料
- https://speakerdeck.com/mirakui/developer-productivity-in-cookpad
・ スピーカー
- 成田 一生 氏（クックパッド株式会社 インフラストラクチャー部 部長）
・ サマリ
- 開発、テスト、デプロイについてのお話
- 開発のしやすさを求めるのは、現場を楽にしたいのではなく、素早く価値を提供したいから
- 開発は、本番データを使い、ユーザと同じ体験をしながら開発を進める
- テストは、割れ窓理論にならないように。
- デプロイは属人的ではなく、正確で、速いことが重要
・ Cookpadのシステム
- フルAWS
→ 1000 EC2インスタンス at peak
→ 15000 req/sec at peak
- Cookpadは世界一巨大なmonothilic Rails アプリケーション
- Railsの最初のトラブルはクックパッドで起こるらしい
・ 開発しやすいとは何か？
- まず、開発しにくいのは何か？
→ 技術的な問題にとって、イノベーションが阻害されている状態
→ 大量のレガシーコード、技術的負債
→ テストはあるけど常にFailで放置状態
→ デプロイが属人的で時間かかる
・ 今日の話は、開発、テスト、デプロイの視点について
・ 開発
サービス開発とは提供しているのはサービスなので、機能よりサービスやユーザ体験が重要。
- 本番と同期したDBデータを使う
→ ユーザと同じ体験ができる
→ 予期せぬデータによるバグに気づきやすい
→ 重いクエリに気づきやすい
- 本番から開発DBへのデータ渡し
→ 開発者の誰かがが半年に1回くらい気が向いたときに、本番データを
もってきて開発DBに入れていたが、この手動更新には問題があった。
→ 新サービスが新データで試せない
- master（本番）、slave（開発）構成にしよう
→ スレーブだと、開発時のインサートと本番のデータ追加で、I
DがAUTO＿INCREMENTで、ぶつかるんでは？という問題に対して、
AUTO INCREMENTに巨大オフセットを設定することで、
かぶらないようにしている。
→ ステートメントレプリケーションでは壊れやすいので、
行ベースレプリケーションにする。
slave_skip_error _ONにすることで、slaveが上手くいったかどうかを監視
- 本番環境を使って開発する
→ "Eat your own dog food" 自分達のサービスは自分達が使うべき。
→ スタッフユーザとしてログインすると、開発中のサービスが利用できる。
→ サービスというのは、使ってみないと価値が分からない。
→ 早めにリリースして、使ってもらってエラーを出す。
- Chanko
→ スタッフユーザ権限をフラグで分岐するとコードが汚くなる。
ここでChankoを利用する。
→ ChankoはUnitというファイルにベータ機能のロジックを記述する。
→ 価値が認められたら、unitファイルを削除(un-chanko）
・ テスト
- ステージング用サーバもあるが、利用頻度は低く、開発環境から本番へそのままリリースする文化ができている
- RSpec
→ 1800ファイル, 21000以上のexamplesで、7分の実行
- テストスメル
→ 実行時間が長い
→ 壊れやすい
→ Failしやすい
→ 実行環境への依存
- RRRspec
→ 速くて、安くて、安定したCI
→ 複数のSpotInstanceを使ってRSpecの並列実行
→ CI Workierは業務時間外は減らしてコスト削減
- EC2 Spot Instance フォールトトレランス
→ まれに失敗するテストは、１度でも通れば良し。３回に１回通れば良いと。
- 割れ窓理論
割れている窓をそのまましているとだんだん治安が悪くなる
直すだけで阻止できる
→ つまり、Failしたら、作者にチャットで通知
→ まれに失敗するexampleは、業務時間外に回し続ける
→ パーセンテージが高いと怪しい
・ デプロイ
- CIが通ったもののみ
- 作成したひとが、デプロイし 責任もってロールバック
- デプロイに重要なこと：
→ 属人的ではないこと
→ 正確であること
→ ロールバックできること
→ 十分に速い
- Capistrano
→ 2014年まで使っていたい
→ Mamiya
ハイスケーラブルで、並列実行ができ、実行時間が８分から１３秒になった
・ 開発のしやすさを保つため
→ 割れ窓にしないためには、責任者と指標が必要
・ 開発のしやすさの価値
- 開発からデプロイまでの速さが速ければ、本番環境を使った開発が実現できる
→ ユーザと同じ体験の中で開発
- 開発しやすさに投資する価値は十分にある
- 開発組織もサービスも健全な状態を保てる
【デベロッパー向け】サーバにログインしない・させないサービス運用
・ 資料
- https://speakerdeck.com/koid/aws-summit-2015-devcon
・ スピーカー
- 小出 幸典 氏（株式会社Gunosy 開発本部）
・ サマリ
- できるだけサーバにログインさせないこと。
- ログインして手を入れられると、chefのレシピと乖離ができてしまう
- アプリケーションのデプロイは、信頼できるものである必要がある。
すべてを統合した一連のワークフローを作ることが重要。
- 調査系に関しても、ログ収集し、ブラウザから分析できる仕組みを導入する
・ Gunosyについて
- ニュースキュレーションアプリ
- 現在900万DL突破
・ 仕組み
- ユーザが記事をタップすると、Gunosyに通知が行き、
興味/関心のある記事が送られたり、広告が配信される
・ 開発言語
- API：Golang
- パートナー様、広告主向け管理画面：Rails
- バッチ・内部向け管理：Django or Python
・ その他
- バージョン管理：GitHub
- デプロイ：chef
・ 開発の特徴
- 小さい単位絵作ってすぐ捨てる
- マイクロサービス的
- 機能が増えたら分割
- メンテするよりリプレース
・ サーバにログインされて困ること
- 信頼できないビルド・デプロイ
→ 開発者の手元でビルドしてアップロード
→ サーバに入ってデプロイスクリプト実行
- 勝手に加えられる変更
→ 勝手に追加されるパッケージ（サーバ追加、リプレースしようとしたら動かない）
→ 勝手に変更されるcrontab （コメントアウトしたのは誰？なぜ？）
・ 以前からchefを使っていた
- サーバとレシピの間に乖離がある
- レシピを追随させろ
- ・ログインして直接いじるのはやめましょう・
・ アプリケーションのデプロイは、信頼できるものである必要がある。
- 信頼できないデプロイは、事故のリスク、手戻りの発生、エンジニアの時間的、
精神的負担が発生する
・ 継続的デリバリ
- バージョンツール、CIツール、デプロイツールを使えば良いというわけではない。
- すべてを統合した一連のワークフローを作ることが重要
・ 現在…
- GitHubを中心とした開発・デプロイフロー
- Service Hookを利用し、各サービスを連携
→ GitHub、Circle CI、AWS OpsWorks
→ Mergeボタンに集中
→ マージするたびに、自動でビルド・テスト・デプロイを実行
→ デプロイしたければPullRequestを作る
・ 結果として
- 見える化、ビルド、デプロイの高速化、事故の削減
- すべての情報がGitHubに集約
- Pull Request Driven Deploy
- ワークフローがわかりやすい
・ より、サーバにログインしないために・・・
- どうしてもつきものなのが調査
→ ミドルウェアログ収集、アプリケーションログ収集
- ブラウザからすべてのログをみられるように
→ OS/ミドルウェアログ
→ papertrail
→ アプリケーションログ収集
→ airbrake(errrbit)
→ kibana
・サーバへの不要なログインはやめましょう
【デベロッパー向け】東急ハンズを支える技術 - iOS と AWS で POS を作ってみた -
・ スピーカー
- 今井 智明 氏（ハンズラボ株式会社 ITエンジニア）
・ 現在のAWS利用範囲
・ POSレジスタの機能って？
- 売上登録、決済、情報提供
・ なぜ自社開発？
- レジを顧客とのコミュニケーションの場とする
- シンプルで使いやすいPOS
- 新規出店や繁忙期に簡単に対応する
・ なぜiOS?
- 見栄え。単純にかっこいい。Apple製品が好き（代表の長谷川さんが）
- 操作性。考えられたUI。
- 保守性。 一般的なPOSよりは安価で故障しない。壊れたら新しいのかって交換。
・ なぜAWS?
- 柔軟性。多様なサービスあり。
- 可用性、堅牢性。落ちない、亡くならない仕組みが組み込まれている。
- 低コスト。使った分だけ支払い。勝手に値下げ。工夫次第で大規模システムを安価に運用。
- SDK。iOS用SDKがあり簡単。継続して機能追加と改善がされている。
・ シンガポール店のPOS
- 年間8億の売上高、2店舗、レジ6台、商品件数3万点。
・ シンガポール店のPOS(iOS)
- レジはiPadAir、顧客ディスプレイはiPad mini2
- データ連携は、AWS Mobile SDK v1。マスタや取引データの連携でS3。
ローカルDBはCoreData マスタデータや取引データのCRUDで利用
EC2ｘ1台、S3
- マスタダウンロードや取引データ連携で利用。
・ 東急ハンズの新POS (iOS)
- 年間800億円の売上。60店舗以上。800台のレジ。商品100万件。
ハンズメッセピーク時取引発生数450件／分
- レジもカスタマディスプレイもiPad Air2
- iOS8.3、 Swift、MobileSDK v2、ローカルDBはRealm
・ 機能は、ハンズクラブカード連携。決算処理連携（カード、電子マネー）等々
- データ連携は、S3, SNS, DynamoDB, Lambda
おまけ
・ 2日間でのべ1万人超えの参加者
・ 無料イベントなのに豪華
・ おやつ
・アンケートに回答して再び扇子
それでも人は前日より多い気がしました。
【ランチセッション】1000 万 DL 突破！BrainWars を支える AWS サービスた
・ 資料
- http://www.slideshare.net/matsukaz/brainwarsaws
・ スピーカー
- 松下 雅和 氏（株式会社トランスリミット CTO）
・ サマリ
- Brain Warsのゲームの裏側のアーキテクチャの説明を機能ごとに分割しながら説明
- いろいろなAWSサービスを利用していた
- 自分自身もやったことあるので想像がつきやすく、セッションが切れた場合や
タイムアウト時の振る舞いもユーザからすればエラーでなく見える対応等もしていた
- 機能だけでなく、コストと運用についても意識すること
・ BrainWarsの概要
- Brain Warsをやったことある人（挙手）
→ まぁまぁいる（自分もやってる）
- 11ヶ月で1200万DL突破
- ユーザは、海外が多く、日本は4.6%のみで、海外が95.4%。アメリカが1/4ほどしめている。
- 男女比率はほぼ同じ。20代が約半数。
・ アーキテクチャの基本方針
- スピード優先
- 積極的にアーキテクチャを見直す
- AWSは東京リージョンが多いが、Oregon や Virginia 中心。
（AWSにこだわらないらしいが…）
・ コストはシビアに
- 費用対効果が合わないプロダクトやサービスは使わない。
- 必要でも高いものは自作も検討
- AWSの中の人もびっくりするくらいの低コストで運用している
・ 運用を楽に楽しく
- 深谷生涯に強いアーキテクチャを意識
- hubotによるChatOpsベースの運用
・ 全体アーキテクチャ
・ OpsWorksの活用で工夫している点
- Chefのレシピを追加し、file descriptorなどのチューニングからプロセスの再起動、CloudWatch連携
- タイムアウトしたり、ソケットサーバが落ちた場合、
対戦相手をランダムで選んで操作ログを返却したりする （つまりゴーストと対戦）
・ SNSの活用
- ChatOpsで通知
- SNSは安く、全ユーザに毎月数回送信しても$10ほど。
- トピック数やメッセージサイズだけでなくAPIの呼び出し頻度にも制限があるので注意！
・まとめ
- どのサービスも使いこなせれば強力！
- 大事なのはそれぞれのサービスの特徴を見極めること
- 機能面だけでなく、利用後のコストと運用もイメージすること
・ ランチセッションのお弁当
アコーディア・ゴルフが取り組むクラウド・ファースト！
・ スピーカー
- 田中 理（株式会社アコーディア・ゴルフ 経営企画本部 情報システム部 Web企画推進部 統括部長）
・ サマリ
- 2010年頃からITインフラの移行。
- メールサービスをGoogle Appsへ移行したり、ゴルフ場情報サービスを
GoogleAppEngineへ移行したりと進めてきた。
- 昨年2014年に数々あるサービスの中、Web予約システムのクラウド化を実施。
- 確証を得たので、今後は、基幹系であるERPシステム、連結会計システム等、
他のサービスも順次移行予定。
・ アコーディアはゴルフ総合サービスを提供
- 運営ゴルフ上、運営ゴルフ練習場、提携ゴルフ練習場、ポイントカードサービス
・ アコーディアのポイントカード
- ゴルフ場のメンバ数18万人
- びじたのお客様360万人
- ポイントカード発行枚数380万枚
- 3人に1人がカードあり。
- ビッグデータはリピート率の向上に活用
・ アコーディアにはさまざまなシステムがある
- ゴルフ場システム、宿泊施設の管理システム、ポイントカード管理、
Web予約、会計、人事・給与、等々
・ クラウドへの取り組みと移行理由
- 2010年にメールサーバをGoogleAppsへ移行
→ システム担当者運用負荷の改善(システム障害、スパム・ウィルス対応）
→ ヘルプデスク運用不可の改善(初期設定、容量制限の対応)
→ Webメールの汎用性向上
→ 現行メールシステムにかかる保守費用の削減
- 2011年にGoogleAppEngineを利用したゴルフ場情報サイトを作成
→ ゴルフ場情報を全体で共有しお客様に時速に回答できるようにする
→ 社内サイト構築
- 2014年にアコーディアWeb予約システムをAWSに移行
→ Webシステムが時間帯によってアクセスが集中する。
ピーク時の安定性を確保できる。
→ 柔軟なリソースを確保できる
→ 充実したサービスのラインナップ
EC2, S3、RDS、VPC、Route53
→ データセンタのリージョン選択が可能
→ データの所在が不透明になりがちだが、DCのリージョンが選択可能
・ 今後の取り組み
- 基幹系であるERPシステム、連結会計システム等をAWSに移行
- 理由としては、Webシステムの運用実績から基幹系などのシステムを移行しても
問題ないことが実証されたため
・ なぜクラウド？
- メリット
→ 先行投資を弱小化
→ 迅速な導入が可能
→ コストの最適化が図れる
- デメリット
→ 幅広いサービスの知識が必要
→ 設定黒目や設定内容が煩雑
→ 仮想技術特有のクセ
・ 2010年に仮想環境へ移行した際に比べ、2015年のCloud環境への移行は
HW構築、調達が5ヶ月だったのが、1.5ヶ月になり、本番稼働が4ヶ月短縮。
・ なぜAWS?
- 日本で展開しているCloudエンダーとして、一番優れたベンダーエコシステムが構築されている
- Cloudpack Classmethod, Serverworks, NRI
・ クラウドの方程式
- y = f(x)
→ y: AWS最適解
→ f: ベンダのエコシステム
→ x: エンドユーザの要望
【デベロッパー向け】なぜクックパッドは開発しやすいのか
・ 資料
- https://speakerdeck.com/mirakui/developer-productivity-in-cookpad
・ スピーカー
- 成田 一生 氏（クックパッド株式会社 インフラストラクチャー部 部長）
・ サマリ
- 開発、テスト、デプロイについてのお話
- 開発のしやすさを求めるのは、現場を楽にしたいのではなく、素早く価値を提供したいから
- 開発は、本番データを使い、ユーザと同じ体験をしながら開発を進める
- テストは、割れ窓理論にならないように。
- デプロイは属人的ではなく、正確で、速いことが重要
・ Cookpadのシステム
- フルAWS
→ 1000 EC2インスタンス at peak
→ 15000 req/sec at peak
- Cookpadは世界一巨大なmonothilic Rails アプリケーション
- Railsの最初のトラブルはクックパッドで起こるらしい
・ 開発しやすいとは何か？
- まず、開発しにくいのは何か？
→ 技術的な問題にとって、イノベーションが阻害されている状態
→ 大量のレガシーコード、技術的負債
→ テストはあるけど常にFailで放置状態
→ デプロイが属人的で時間かかる
・ 今日の話は、開発、テスト、デプロイの視点について
・ 開発
サービス開発とは提供しているのはサービスなので、機能よりサービスやユーザ体験が重要。
- 本番と同期したDBデータを使う
→ ユーザと同じ体験ができる
→ 予期せぬデータによるバグに気づきやすい
→ 重いクエリに気づきやすい
- 本番から開発DBへのデータ渡し
→ 開発者の誰かがが半年に1回くらい気が向いたときに、本番データを
もってきて開発DBに入れていたが、この手動更新には問題があった。
→ 新サービスが新データで試せない
- master（本番）、slave（開発）構成にしよう
→ スレーブだと、開発時のインサートと本番のデータ追加で、I
DがAUTO＿INCREMENTで、ぶつかるんでは？という問題に対して、
AUTO INCREMENTに巨大オフセットを設定することで、
かぶらないようにしている。
→ ステートメントレプリケーションでは壊れやすいので、
行ベースレプリケーションにする。
slave_skip_error _ONにすることで、slaveが上手くいったかどうかを監視
- 本番環境を使って開発する
→ "Eat your own dog food" 自分達のサービスは自分達が使うべき。
→ スタッフユーザとしてログインすると、開発中のサービスが利用できる。
→ サービスというのは、使ってみないと価値が分からない。
→ 早めにリリースして、使ってもらってエラーを出す。
- Chanko
→ スタッフユーザ権限をフラグで分岐するとコードが汚くなる。
ここでChankoを利用する。
→ ChankoはUnitというファイルにベータ機能のロジックを記述する。
→ 価値が認められたら、unitファイルを削除(un-chanko）
・ テスト
- ステージング用サーバもあるが、利用頻度は低く、開発環境から本番へそのままリリースする文化ができている
- RSpec
→ 1800ファイル, 21000以上のexamplesで、7分の実行
- テストスメル
→ 実行時間が長い
→ 壊れやすい
→ Failしやすい
→ 実行環境への依存
- RRRspec
→ 速くて、安くて、安定したCI
→ 複数のSpotInstanceを使ってRSpecの並列実行
→ CI Workierは業務時間外は減らしてコスト削減
- EC2 Spot Instance フォールトトレランス
→ まれに失敗するテストは、１度でも通れば良し。３回に１回通れば良いと。
- 割れ窓理論
割れている窓をそのまましているとだんだん治安が悪くなる
直すだけで阻止できる
→ つまり、Failしたら、作者にチャットで通知
→ まれに失敗するexampleは、業務時間外に回し続ける
→ パーセンテージが高いと怪しい
・ デプロイ
- CIが通ったもののみ
- 作成したひとが、デプロイし 責任もってロールバック
- デプロイに重要なこと：
→ 属人的ではないこと
→ 正確であること
→ ロールバックできること
→ 十分に速い
- Capistrano
→ 2014年まで使っていたい
→ Mamiya
ハイスケーラブルで、並列実行ができ、実行時間が８分から１３秒になった
・ 開発のしやすさを保つため
→ 割れ窓にしないためには、責任者と指標が必要
・ 開発のしやすさの価値
- 開発からデプロイまでの速さが速ければ、本番環境を使った開発が実現できる
→ ユーザと同じ体験の中で開発
- 開発しやすさに投資する価値は十分にある
- 開発組織もサービスも健全な状態を保てる
【デベロッパー向け】サーバにログインしない・させないサービス運用
・ 資料
- https://speakerdeck.com/koid/aws-summit-2015-devcon
・ スピーカー
- 小出 幸典 氏（株式会社Gunosy 開発本部）
・ サマリ
- できるだけサーバにログインさせないこと。
- ログインして手を入れられると、chefのレシピと乖離ができてしまう
- アプリケーションのデプロイは、信頼できるものである必要がある。
すべてを統合した一連のワークフローを作ることが重要。
- 調査系に関しても、ログ収集し、ブラウザから分析できる仕組みを導入する
・ Gunosyについて
- ニュースキュレーションアプリ
- 現在900万DL突破
・ 仕組み
- ユーザが記事をタップすると、Gunosyに通知が行き、
興味/関心のある記事が送られたり、広告が配信される
・ 開発言語
- API：Golang
- パートナー様、広告主向け管理画面：Rails
- バッチ・内部向け管理：Django or Python
・ その他
- バージョン管理：GitHub
- デプロイ：chef
・ 開発の特徴
- 小さい単位絵作ってすぐ捨てる
- マイクロサービス的
- 機能が増えたら分割
- メンテするよりリプレース
・ サーバにログインされて困ること
- 信頼できないビルド・デプロイ
→ 開発者の手元でビルドしてアップロード
→ サーバに入ってデプロイスクリプト実行
- 勝手に加えられる変更
→ 勝手に追加されるパッケージ（サーバ追加、リプレースしようとしたら動かない）
→ 勝手に変更されるcrontab （コメントアウトしたのは誰？なぜ？）
・ 以前からchefを使っていた
- サーバとレシピの間に乖離がある
- レシピを追随させろ
- ・ログインして直接いじるのはやめましょう・
・ アプリケーションのデプロイは、信頼できるものである必要がある。
- 信頼できないデプロイは、事故のリスク、手戻りの発生、エンジニアの時間的、
精神的負担が発生する
・ 継続的デリバリ
- バージョンツール、CIツール、デプロイツールを使えば良いというわけではない。
- すべてを統合した一連のワークフローを作ることが重要
・ 現在…
- GitHubを中心とした開発・デプロイフロー
- Service Hookを利用し、各サービスを連携
→ GitHub、Circle CI、AWS OpsWorks
→ Mergeボタンに集中
→ マージするたびに、自動でビルド・テスト・デプロイを実行
→ デプロイしたければPullRequestを作る
・ 結果として
- 見える化、ビルド、デプロイの高速化、事故の削減
- すべての情報がGitHubに集約
- Pull Request Driven Deploy
- ワークフローがわかりやすい
・ より、サーバにログインしないために・・・
- どうしてもつきものなのが調査
→ ミドルウェアログ収集、アプリケーションログ収集
- ブラウザからすべてのログをみられるように
→ OS/ミドルウェアログ
→ papertrail
→ アプリケーションログ収集
→ airbrake(errrbit)
→ kibana
・サーバへの不要なログインはやめましょう
【デベロッパー向け】東急ハンズを支える技術 - iOS と AWS で POS を作ってみた -
・ スピーカー
- 今井 智明 氏（ハンズラボ株式会社 ITエンジニア）
・ 現在のAWS利用範囲
・ POSレジスタの機能って？
- 売上登録、決済、情報提供
・ なぜ自社開発？
- レジを顧客とのコミュニケーションの場とする
- シンプルで使いやすいPOS
- 新規出店や繁忙期に簡単に対応する
・ なぜiOS?
- 見栄え。単純にかっこいい。Apple製品が好き（代表の長谷川さんが）
- 操作性。考えられたUI。
- 保守性。 一般的なPOSよりは安価で故障しない。壊れたら新しいのかって交換。
・ なぜAWS?
- 柔軟性。多様なサービスあり。
- 可用性、堅牢性。落ちない、亡くならない仕組みが組み込まれている。
- 低コスト。使った分だけ支払い。勝手に値下げ。工夫次第で大規模システムを安価に運用。
- SDK。iOS用SDKがあり簡単。継続して機能追加と改善がされている。
・ シンガポール店のPOS
- 年間8億の売上高、2店舗、レジ6台、商品件数3万点。
・ シンガポール店のPOS(iOS)
- レジはiPadAir、顧客ディスプレイはiPad mini2
- データ連携は、AWS Mobile SDK v1。マスタや取引データの連携でS3。
ローカルDBはCoreData マスタデータや取引データのCRUDで利用
EC2ｘ1台、S3
- マスタダウンロードや取引データ連携で利用。
・ 東急ハンズの新POS (iOS)
- 年間800億円の売上。60店舗以上。800台のレジ。商品100万件。
ハンズメッセピーク時取引発生数450件／分
- レジもカスタマディスプレイもiPad Air2
- iOS8.3、 Swift、MobileSDK v2、ローカルDBはRealm
・ 機能は、ハンズクラブカード連携。決算処理連携（カード、電子マネー）等々
- データ連携は、S3, SNS, DynamoDB, Lambda
おまけ
・ 2日間でのべ1万人超えの参加者
・ 無料イベントなのに豪華
・ おやつ
2015年6月2日火曜日
[AWS]AWS Summit 2015 Day1
資料はだいぶ公開されているけど、自分用にレポートに残しておきます。
開催日・場所
・2015年6月2日(火)～3日（水）
・グランドプリンスホテル新高輪 （国際館パミール、飛天）
SmartNews のデータサイエンティストの高速イテレーションを支える広告システム
・資料
http://www.slideshare.net/smartnews/aws-summit-tokyo2015newsads
・スピーカー
小宮 篤史 氏（スマートニュース株式会社 エンジニア）
蘭 雨陽 氏（スマートニュース株式会社 エンジニア）
・AWSを利用する理由
- インフラ専任のエンジニアがいない
- 本当に大事な所（事業）に注力したい
- データサイエンスの高速なイテレーションを実現するためにAWSの各種サービスの良いところを利用。
・データサイエンス
- 広告システムにおいても、機械学習や最適化タスクが存在する
- A/B Testing
→ 長時間のログデータをいろいろな軸で集計し分析するために、S3 + EMR (+Presto)
→ 配信ロジックの実装では、EMR (+Hivemall)＋ DynamoDB
→テスト結果のレポーティングをするために、Redshift（＋Chartio）
急成長しつづける freee、AWS との付き合い方
・資料
https://speakerdeck.com/futoase/aws-summit-tokyo-2015-freee
・スピーカー
- 松崎 啓治 氏（freee株式会社 ソフトウェアエンジニア）
・サマリ
- サービス運用は予測できないことばかり。
→3年先を予測して設計してもうまくいかないので、
柔軟に設計変更しなくてはならない
- AWSでインフラコストを任せることができたので、
少人数でサービスをリリースして急成長することができた
・freeeの会社概要
- 2012年7月創業
- クラウド会計ソフトの会社
・クラウド会計ソフト
- 創業から2年で30万事業所が登録
- 2015年2月に2万事業所突破し、その1か月後には3万事業所！
・さまざまな失敗談
- 失敗談① 〜 DB Drop事件（初期）
開発環境のDBを消すスクリプト
Chefで実行したら対象がproductionになってしまった…
即座にメンテモードに入る
RDSのRestore to Point in Timeにより復元しサービス復帰
Drop、Deleteが行えるユーザを絞りましょう。それ用のユーザを作成しましょう。
- 失敗談② 〜 Security Groupの問題…
Security Group が上限である100に達してしまった
ホワイトリストで切り分けをしていた
1つのVPC内でProductionとStagingを運用していたので、
ACL、VPC、ネットワークセグメントの再設計中
- 失敗談③ 〜 index貼り忘れによるサービスダウン寸前
innotopで詰まってるクエリを特定して貼った
・発表では主に創業から現在に至るAWSの適用について語る
- 最初は、Herokを利用していたが、徐々にAWSにシフトしていく話。
- サーバ台数増えすぎ、サービス増加に伴いVPCの再設計が
必要になってきていることなど課題が出てきているので
改善を図っていきたいとのこと。
・以下は詳細
- 2012年10月～
β版リリース。メンバ5名。インフラエンジニア0名。
さくらVPS、PostgreSQL、Herokを利用
- 2012年12月～
AWS導入
EC2とRDS、Herok
- 2013年1月～
AWS中心になり、Herokなくす
Jenkins導入、Amazon SQS利用
- 2013年3月～
サービスの正式リリース。メンバ10名。インフラエンジニア0名。
CloudPackを利用し、VPCにサービス移行
その後はアプリ開発に注力
- 2013年10月
メンバ28名。インフラエンジニア入社。
VPN接続が可能になった
NagiosからZabbixへ
Kibana導入
- 2014年2月～
モバイル版(iOS)リリース
- 2014年4月～
Andoroid版リリース
- 2014年5月～
クラウド給与計算ソフトfreeeリリース
クライド会計ソフトfreeeと同一VPC内で別サービスとしてリリース
2サービスあるので、同一認証機構が必要になったため、共通認証基盤サービスを提供
- 2015年4月～
これからの話
メンバ100名
サーバ台数増えすぎ、VPCの再設計、master DBしかないので、スケールをどうするか等の課題があり
【パネルディスカッション】 デベロッパーが切り拓く、次の時代
Twitterから抜粋
・モデレーター
松尾 康博 氏（アマゾン データ サービス ジャパン 株式会社 ソリューションアーキテクト）
・パネリスト
伊藤 直也 氏（Kaizen Platform, Inc 技術顧問）
大場 光一郎 氏（株式会社クラウドワークス 執行役員 CTO）
・外部環境の変化の中で活躍するフィールドを切り開いてトップデベロッパーとして変わらなかったこと、変わっていったことはありますか？
- トレンドはいつか終わる、その繰り返し、安住しないことが重要
- 昔と違う部分というと、技術はエンタープライズからコンシューマー
だったんだけど、もういまはコンシューマーからという流れに
なっているというのが大きな変化。
・外部環境の変化に対してデベロッパーとして、技術を取捨選択した際の
大原則・ 考え方はありましたか？
- シンプルなほうが常に勝つ
- 課題があるから解決するために新しい技術を触り始める。
- 技術者が自分の持っている技術で出発すると失敗するケースが多い。
この技術はここまでしかできないという限界がきたときに先に進めなくなる。
- 技術のブレイクスルーのタイミングはこういう物を作って欲しいと言われて、
試行錯誤してエンジニアが作り上げた時に生まれるもの。
- Apple MacBook はデザイナーができるできない関係なくデザインして
それをエンジニアがブレークスルーをして実現しているらしい
・これからの外部環境の変化をどう迎え撃てばよいでしょうか？
（スキルセット、ロール等いちデベロッパーの立場としてチームを編成する立場として）
- 曖昧な状況で自立してやれる人でチームを組むのがやりやすい
- 外部環境は変化するものだということを受け入れること。
- 割とモヤモヤとした状況の中で、PJを進めていける人は強い。
曖昧耐性がある人。
- 技術は手段
- 大きな課題があって、そこに技術が組み合わさって達成した感じがある。
- エンジニアと企画を部門で分けてしまうと、温度差がでてきたので縦割りに変えた話。
ビジネスゴールに対して開発者も責任を持たないといけない
- 年齢にもよるけど、特定の技術だけでやっていくのはリスクが高い。
新しいテクノロジーが入ってきた時にガンガン動くのはやはり若い人。
ローソンがAWSを使うまでの軌跡 ～打ち破れ、現行踏襲～
・スピーカー
進藤 広輔氏（株式会社ローソン 業務統括本部 システム基盤部 マネジャー）
・サマリ
- 現行踏襲の壁を打ち破るためにはチェンジが必要
- チェンジするためには、マインドを変え、AWSを理解し、現行（オンプレ）との
違いを理解し、そして周囲の環境を変える
・ローソンがAWSの利用を開始するまで
- 2013年：情報収集
- 2014年：構築/試用開始
- 2015年：利用開始（全体最適）
・ローソンのアプローチ
- AWS本格利用に向けて、一定の品質をと持つために各社のベンダーと共有が必要である
- 以下が3つのアクションと特徴
1. 共通基盤の実装
・個別最適を避ける
・全システム横断で必要な基本的機能の提供
2. ポリシー、ガイドラインの確立
・ローソンAWS利用に関するルールブック
・AWSを使ったシステム構築のノウハウ集
3. 標準化の推進
・AMIやスタックのカタログ化
・AWSの各種サービスのパラメータを標準化
・プロジェクトの各フェーズを通じて基準・標準を設定
- 要件定義： サービス選定基準
- 設計： OSパラメータシート AWSサービスパラメータシート、パラメータ
- 構築： AWS構築標準WBS、チェックシート、カタログAMI(24種）
- テスト： インフラ標準結合テストケース
・ 現行踏襲の壁を打ち破るため 現行踏襲 vs チェンジ
- AWS利用を阻む最大の敵が *現行踏襲*
→思考停止、イノベーション減退、機会喪失、モチベーション低下等
- 現行踏襲による守られる(?)ものもあるが良くはない。
→基盤と開発部門の暗黙の壁、情シスの丸投げ体質
→リスク回避として、オンプレの安全神話やできない、分からないことの露呈…
- 現行踏襲を打ち破るためには チェンジ ！
→考える、違いを知る、自らトライ、柔軟に、守備範囲を広げる
・必要なチェンジ
- マインド
→システムは作るのではなく使うもの
→24/365止まらない仕組みではなく、業務影響がない範囲で止まることを前提とする
→サイジング偏重ではなく、まず起動する。サイジングは性能試験後で良い。
→システムを使い続けるのではなく、不要になったら捨てることで、いろいろ試せる
- 設計
→今までのが当たり前というのではんく、AWS的当たり前という考え方
→ IPアドレスでアクセスではなくFQDNでアクセス
→データはローカル/共有ディスクではなく、腹持ちしない
（S3を使いこなすのが鍵）
→ピーク特性でサイジングではなく、負荷に応じてスケールアップ/アウト
→セッションステートフルではなく、セッションステートレス
負荷に応じて並列分散処理
- 関係性
→基盤と開発部門の壁は情シスが主役
→インフラ vs アプリ ではなく、インフラ・アプリ連合とするAWSは
PaaSが豊富であり、境界がない。
・チェンジの道筋
- マインドを変える
- AWSを理解する
- 現行（オンプレ）との違いを理解する
- 周囲の環境を変える
・AWS活用に向けて
- システム構築時の課題要因は、OSS共通基盤、コミュニケーションミスが
6-7割ほど占めている。
AWS固有の問題は、1割くらいしかない。
Developers Night
おまけ
アンケートに回答してもらったもの
おやつのクッキーとチロルチョコ
開催日・場所
・2015年6月2日(火)～3日（水）
・グランドプリンスホテル新高輪 （国際館パミール、飛天）
SmartNews のデータサイエンティストの高速イテレーションを支える広告システム
・資料
http://www.slideshare.net/smartnews/aws-summit-tokyo2015newsads
・スピーカー
小宮 篤史 氏（スマートニュース株式会社 エンジニア）
蘭 雨陽 氏（スマートニュース株式会社 エンジニア）
・AWSを利用する理由
- インフラ専任のエンジニアがいない
- 本当に大事な所（事業）に注力したい
- データサイエンスの高速なイテレーションを実現するためにAWSの各種サービスの良いところを利用。
・データサイエンス
- 広告システムにおいても、機械学習や最適化タスクが存在する
- A/B Testing
→ 長時間のログデータをいろいろな軸で集計し分析するために、S3 + EMR (+Presto)
→ 配信ロジックの実装では、EMR (+Hivemall)＋ DynamoDB
→テスト結果のレポーティングをするために、Redshift（＋Chartio）
急成長しつづける freee、AWS との付き合い方
・資料
https://speakerdeck.com/futoase/aws-summit-tokyo-2015-freee
・スピーカー
- 松崎 啓治 氏（freee株式会社 ソフトウェアエンジニア）
・サマリ
- サービス運用は予測できないことばかり。
→3年先を予測して設計してもうまくいかないので、
柔軟に設計変更しなくてはならない
- AWSでインフラコストを任せることができたので、
少人数でサービスをリリースして急成長することができた
・freeeの会社概要
- 2012年7月創業
- クラウド会計ソフトの会社
・クラウド会計ソフト
- 創業から2年で30万事業所が登録
- 2015年2月に2万事業所突破し、その1か月後には3万事業所！
・さまざまな失敗談
- 失敗談① 〜 DB Drop事件（初期）
開発環境のDBを消すスクリプト
Chefで実行したら対象がproductionになってしまった…
即座にメンテモードに入る
RDSのRestore to Point in Timeにより復元しサービス復帰
Drop、Deleteが行えるユーザを絞りましょう。それ用のユーザを作成しましょう。
- 失敗談② 〜 Security Groupの問題…
Security Group が上限である100に達してしまった
ホワイトリストで切り分けをしていた
1つのVPC内でProductionとStagingを運用していたので、
ACL、VPC、ネットワークセグメントの再設計中
- 失敗談③ 〜 index貼り忘れによるサービスダウン寸前
innotopで詰まってるクエリを特定して貼った
・発表では主に創業から現在に至るAWSの適用について語る
- 最初は、Herokを利用していたが、徐々にAWSにシフトしていく話。
- サーバ台数増えすぎ、サービス増加に伴いVPCの再設計が
必要になってきていることなど課題が出てきているので
改善を図っていきたいとのこと。
- 2012年10月～
β版リリース。メンバ5名。インフラエンジニア0名。
さくらVPS、PostgreSQL、Herokを利用
- 2012年12月～
AWS導入
EC2とRDS、Herok
- 2013年1月～
AWS中心になり、Herokなくす
Jenkins導入、Amazon SQS利用
- 2013年3月～
サービスの正式リリース。メンバ10名。インフラエンジニア0名。
CloudPackを利用し、VPCにサービス移行
その後はアプリ開発に注力
- 2013年10月
メンバ28名。インフラエンジニア入社。
VPN接続が可能になった
NagiosからZabbixへ
Kibana導入
- 2014年2月～
モバイル版(iOS)リリース
- 2014年4月～
Andoroid版リリース
- 2014年5月～
クラウド給与計算ソフトfreeeリリース
クライド会計ソフトfreeeと同一VPC内で別サービスとしてリリース
2サービスあるので、同一認証機構が必要になったため、共通認証基盤サービスを提供
- 2015年4月～
これからの話
メンバ100名
サーバ台数増えすぎ、VPCの再設計、master DBしかないので、スケールをどうするか等の課題があり
【パネルディスカッション】 デベロッパーが切り拓く、次の時代
Twitterから抜粋
・モデレーター
松尾 康博 氏（アマゾン データ サービス ジャパン 株式会社 ソリューションアーキテクト）
・パネリスト
伊藤 直也 氏（Kaizen Platform, Inc 技術顧問）
大場 光一郎 氏（株式会社クラウドワークス 執行役員 CTO）
・外部環境の変化の中で活躍するフィールドを切り開いてトップデベロッパーとして変わらなかったこと、変わっていったことはありますか？
- トレンドはいつか終わる、その繰り返し、安住しないことが重要
- 昔と違う部分というと、技術はエンタープライズからコンシューマー
だったんだけど、もういまはコンシューマーからという流れに
なっているというのが大きな変化。
・外部環境の変化に対してデベロッパーとして、技術を取捨選択した際の
大原則・ 考え方はありましたか？
- シンプルなほうが常に勝つ
- 課題があるから解決するために新しい技術を触り始める。
- 技術者が自分の持っている技術で出発すると失敗するケースが多い。
この技術はここまでしかできないという限界がきたときに先に進めなくなる。
- 技術のブレイクスルーのタイミングはこういう物を作って欲しいと言われて、
試行錯誤してエンジニアが作り上げた時に生まれるもの。
- Apple MacBook はデザイナーができるできない関係なくデザインして
それをエンジニアがブレークスルーをして実現しているらしい
・これからの外部環境の変化をどう迎え撃てばよいでしょうか？
（スキルセット、ロール等いちデベロッパーの立場としてチームを編成する立場として）
- 曖昧な状況で自立してやれる人でチームを組むのがやりやすい
- 外部環境は変化するものだということを受け入れること。
- 割とモヤモヤとした状況の中で、PJを進めていける人は強い。
曖昧耐性がある人。
- 技術は手段
- 大きな課題があって、そこに技術が組み合わさって達成した感じがある。
- エンジニアと企画を部門で分けてしまうと、温度差がでてきたので縦割りに変えた話。
ビジネスゴールに対して開発者も責任を持たないといけない
- 年齢にもよるけど、特定の技術だけでやっていくのはリスクが高い。
新しいテクノロジーが入ってきた時にガンガン動くのはやはり若い人。
ローソンがAWSを使うまでの軌跡 ～打ち破れ、現行踏襲～
・スピーカー
進藤 広輔氏（株式会社ローソン 業務統括本部 システム基盤部 マネジャー）
・サマリ
- 現行踏襲の壁を打ち破るためにはチェンジが必要
- チェンジするためには、マインドを変え、AWSを理解し、現行（オンプレ）との
違いを理解し、そして周囲の環境を変える
・ローソンがAWSの利用を開始するまで
- 2013年：情報収集
- 2014年：構築/試用開始
- 2015年：利用開始（全体最適）
・ローソンのアプローチ
- AWS本格利用に向けて、一定の品質をと持つために各社のベンダーと共有が必要である
- 以下が3つのアクションと特徴
1. 共通基盤の実装
・個別最適を避ける
・全システム横断で必要な基本的機能の提供
2. ポリシー、ガイドラインの確立
・ローソンAWS利用に関するルールブック
・AWSを使ったシステム構築のノウハウ集
3. 標準化の推進
・AMIやスタックのカタログ化
・AWSの各種サービスのパラメータを標準化
・プロジェクトの各フェーズを通じて基準・標準を設定
- 要件定義： サービス選定基準
- 設計： OSパラメータシート AWSサービスパラメータシート、パラメータ
- 構築： AWS構築標準WBS、チェックシート、カタログAMI(24種）
- テスト： インフラ標準結合テストケース
・ 現行踏襲の壁を打ち破るため 現行踏襲 vs チェンジ
- AWS利用を阻む最大の敵が *現行踏襲*
→思考停止、イノベーション減退、機会喪失、モチベーション低下等
- 現行踏襲による守られる(?)ものもあるが良くはない。
→基盤と開発部門の暗黙の壁、情シスの丸投げ体質
→リスク回避として、オンプレの安全神話やできない、分からないことの露呈…
- 現行踏襲を打ち破るためには チェンジ ！
→考える、違いを知る、自らトライ、柔軟に、守備範囲を広げる
・必要なチェンジ
- マインド
→システムは作るのではなく使うもの
→24/365止まらない仕組みではなく、業務影響がない範囲で止まることを前提とする
→サイジング偏重ではなく、まず起動する。サイジングは性能試験後で良い。
→システムを使い続けるのではなく、不要になったら捨てることで、いろいろ試せる
- 設計
→今までのが当たり前というのではんく、AWS的当たり前という考え方
→ IPアドレスでアクセスではなくFQDNでアクセス
→データはローカル/共有ディスクではなく、腹持ちしない
（S3を使いこなすのが鍵）
→ピーク特性でサイジングではなく、負荷に応じてスケールアップ/アウト
→セッションステートフルではなく、セッションステートレス
負荷に応じて並列分散処理
- 関係性
→基盤と開発部門の壁は情シスが主役
→インフラ vs アプリ ではなく、インフラ・アプリ連合とするAWSは
PaaSが豊富であり、境界がない。
・チェンジの道筋
- マインドを変える
- AWSを理解する
- 現行（オンプレ）との違いを理解する
- 周囲の環境を変える
・AWS活用に向けて
- システム構築時の課題要因は、OSS共通基盤、コミュニケーションミスが
6-7割ほど占めている。
AWS固有の問題は、1割くらいしかない。
Developers Night
おまけ
アンケートに回答してもらったもの
登録:
投稿 (Atom)