Keep up with Tech!: [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