AWS re:Invent2014～AWS本社見学編～

こんにちは。花嫁修業中セールスチームの中嶋(mnakajima18)です。
昨日の永淵のポストに続き、re:Invent2014ツアー内で企画されましたAWS本社見学についてレポートします。

受付

受付はアメリカンな雰囲気を漂わせ、一人ひとりパスポートをチェックされ入館手続きしました。
受付まで登るエレベーターはダンボール柄を期待していたのですが、いたって普通のエレベーターだったので日本のオフィスはおちゃめだなと感じました。

見学ツアーでは4つのセッションを企画してくださいました。
それぞれの概要についてお伝えします。

Support team session
(Escalation Manager 東 祥平さん)

Support Team Sessionではシアトルサポートチームのエスカレーションマネージャーである東さんからお話いただきました。

• サポートチームのミッション
  • 地球上で最もお客様を大切にするサポートを目指す
• サポートプラン
  • 法人向けにエンタープライズ、ビジネス、個人開発者向けにデベロッパー、無料サポートとしてベーシックの4種類を用意している
• サポートの特徴
  • クラウドのようにフレキシブルなのでいつでも加入できいつでも変更可能
  • シアトルに拠点があるため、夜間帯であっても外注はせずAmazon社員がすべて対応(24時間サポートでないプランは日本拠点ですべて対応する)
• シアトルに拠点があるメリット
  • シフトの効率化
    • 日本で夜勤対応をさせるエンジニアを雇うほうが難しい
    • ワークライフバランスを向上させるために徹夜で調査をさせる必要がなくなった
  • 2拠点での相互バックアップ体制
    • 3.11の際に日本の受付が停止してしまったとき、問合せ先をシアトルに変更することで問題なく対応できた実績がある
  • USチームとの交流
    • 開発者がUSにいるため日本よりも早くサービス開発者と情報交換ができる
  • 他のエンジニアとの交流
    • GoogleやFacebookが拠点をシアトルに移したことで、それぞれのエンジニアと情報交換ができる
  • 過ごしやすい環境
    • 日本よりも夏場が涼しい
    • ゴルフ場が安い

Leadership Principles
(AWS Kinesis Debelopment Manager 堀 剛さん)

AWS Kinesisの開発マネージャーである堀さんからKinesisの概要、AmazonのLeadership Principlesについてお話いただきました。

• Kinesisの概要
  • ストリーミングデータをリアルタイムで収集し処理するマネージドサービス
• Kinesisの生い立ち
  • AWSの従量課金モデルを成り立たせるための測定する仕組みを持っていた。
    その中で出てくる課題(速度向上、リアルタイム分析、大量データを蓄積したい、運用コストを抑えたい)を解決するために作られた
• 堀さんの信念
  • Good intentions are not good enough(やる気だけではだめ)
  • Need a Closed Loop System(やる気をいかにシステム化するか)
• Leadership Principlesについて
  • 詳細はこちら　http://www.amazon.co.jp/Values-version2/b?node=52268051
  • その中でも印象的なものをいくつか
    • Customer Obsession
      • すべてお客様からを第一に考える
      • サービスを企画する際にはPRFAQを作る
      • プレスリリースを書き、お客さんから挙がってくる質問の仮説を立て回答を用意する
      • プレスリリースを書くことでチームでサービスの価値を共有し、方向性を見失ったら立ち戻れるようにする
    • Dive Deep
      • 5Whys
      • 障害が起こった後になぜを繰り返す
      • なぜを繰り返すことで次にすべきことを明確にする
    • Hire and Develop the Best
      • いかにチームを作っていくかを考える
      • 5Whysのフィードバックを繰り返すことで、若手のスキルアップにつながる
    • Have Backbone; Disagree and Commit
      • チーム内の全員が同じ意見であることは非常に危険
      • データを元に討論し敬意をもって意義する必要性がある
      • 討論を経て決定したことに同意はしなくても全面的にコミットする
• 日本人であることのメリット・デメリット
  • 完璧主義な職人肌の人が多いのでものづくりに対する誇りがある
  • 間違っていたら恥ずかしいという気持ちから意義を発言する力が弱い

RDS debeloping story
(RDS Product Manager Pavan Pothukuchiさん)

RDSのProduct MangerであるPavan PothukuchiさんからRDSの概要、RDSの現状についてお話いただきました。

• RDSの生い立ち
  • RDSができるまではEC2上でRDBSを構築するしかなかった
  • データベースに関するフィードバックを集めたところパフォーマンスのチューニングにもっと時間を割きたいという意見が多かった
  • それなのに冗長化するための構築や運用に時間とお金がかかっている現状があった
  • お客様には別の部分に注力してもらうためにRDSが生まれた
• Customer Obsession
  • 堀さんの話の中でもでてきたLeadership Principlesの1つであるお客様を第一に考えている
  • オペレーターであってもエンジニアであっても、どの職種であってもこの信念は念頭に置くようにしている
• Multi-AZの利用状況について
  • 2012年から開始し、現在ではRDS利用者の47%が使っている
• 最近のアップデート
  • M3、R3、T2インスタンスに対応
  • フランクフルトリージョンに対応
  • Cross Region Replicationの実装
  • MySQL5.5から5.6へのアップデート方法のリリース
• 今後
  • 99.95%の可用性を引き上げたい
  • 3TB制限のストレージの容量をアップしたい
• エンジンについて
  • MySQLが一番使われているが、Oracleの売上は高い
  • MariaDBの対応は現状ではないが、今後ニーズが増えてきたら対応する

DynamoDB debeloping story
(DynamoDB Team Developer Alexander Patrikalakisさん)

DynamoDBチームの開発者であるAlexanderさんからDynamoDBの概要についてお話いただきました。
元々はマネージャーの方がお話される予定だったのですが、急遽ご都合がつかなくなってしまいピンチヒッターとして登場。
同時通訳の方が訳し始めた瞬間、Alexanderさんが流暢な日本語で話されたので会場はどっと笑いに包まれました。

• DynamoDBの特徴
  • 管理が不要で可用性が高いマネージドサービス
  • 必要なIOPSの加減ができる
  • テーブルに対し、パーティションを分裂させ3箇所のデータベースにデータを保存することができる
• TableのKey、Indexの操作について
  • Hash KeyのみかHash Key+Rage Keyの利用が可能
  • Local Secondary IndexとGlobal Secondary Indexのどちらかを選択することが可能
    • まだアップデートされていないが作成後にIndexの追加が可能
  • Storongly Consistentは読み込み後の更新まで時間がかかる
    • 3つのテーブルが反映されてから返ってくる
  • Eventually Consistentは読み込み後すぐに更新される
    • 3つのテーブルの一貫性は担保できないがスピードが早い
• 最新のアップデートについて
  • 部分的なアイテムの変更が可能となった
  • スループットを増加する際に任意の値が指定可能

感想

講演されたすべての方が常にAWSのLeadership Principlesを念頭に考えていることを感じました。
職種は関係なくサービスの価値やチームの目標を共有し、今この時点でやるべきことを考えているという言葉が印象的でした。
今回のお話を参考にさせていただき、このような方々がつくるサービスをどう提案していくかもっと掘り下げて考えていきたいですね。

最後にオフィス内のカフェが素敵だったのでパチリ