【勉強会メモ】re:Union 2018 Osaka
- 日時：2018-08-05（日）10:00 - 19:00
- 場所：エムオーテックス新大阪ビル
大阪北部地震で中止になったAWS Summit 2018 Osakaで予定されていたセッションを再構成した、JAWS-UG主催の仕切り直しイベントです。残念ながら全てのセッションに参加することはできませんでしたが参加したセッションだけメモを残しておきます。
個人的にはLift-and-Shiftの事例から始まり未来のエンジニアにまで言及されていた部分が刺さりました。あとはNintendo SwitchもガッツリAWSを使っているんだなぁというのも改めて時代を感じました。
SUMMIT TOKYO re:cap〜基幹システムの移行とクラウドネイティブ構築、それぞれの事例のお客様をお迎えして〜
亀田 治伸様(アマゾン ウェブ サービス ジャパン株式会社)
Summit Tokyoで発表された東京リージョン対応サービス
- AWS EFS
- 分散型ファイルシステム
- SageMaker
- AWS Fargate
- コンテナ環境の管理
- サーバサイドの細かい設定をする場合はECS
- QuickSight
- BIサービス
- ダッシュボード機能
- 現時点ではTabrouのような高度なBIツールを置き換えるようなものではない
大阪リージョン
Day1 Keynoteサマリー
- リージョン間の通信はインターネットに出ることがあったがinternalな通信ができるようになった
- Cloud Journey
- 12年間の知見蓄積とフレームワーク化
- Lift-and-Shift
- システムのクラウド移行
- いきなりコスト削減を目指さない
- 将来の最適化＆進化
Cloud + Community ⇒ 情シス2.0
友岡 賢二様 (フジテック株式会社)
The End of Corporate Computing
- 電気の発電機を持つ人は今やほとんどいない
- データセンターを持っているのは発電機をもっているようなもの
伝統的手法での企業データセンター
- 自社でつくるとめちゃくちゃ大変でコストかかる
固定リソースの限界
- 好きな時に好きなだけ立ち上げてあとで消せる
- Pay per use
- 拡張性・伸縮性
調達コスト
- 構築に最低6ヶ月ぐらいかかる
フジテックの情シス（88 servers）事例
- 初期費用
-95%
- 運用費用
-42%
- サーバレス
- 19,600円／年
- Lambdaにしたら100円／年
クラウドジャーニー
- Lift & Shift
- Re-Sizing & COst Optimization
- Serverless
Enterprise IT's Challenges
E-JAWS-UG
- 120企業
- コミュニティにエンジニアを放流しよう
Lift-and-Shift
- システムの維持コスト最適化
- 生産性の向上
AWS Well-Architected
- クラウドの正しい設計概念
TCO計算ツール
- Cloud Economics（投資効果算定支援）
AWS Support
- お客様をサポートするチーム
- Trusted Advisor
クラウドネイティブ
- クラウドで新規構築
高橋 真知様(株式会社 Stroly)
位置情報サービス - ターゲットやテーマを決めたマップ - 看板や紙で配布→もらっても位置がわからない→Webサービス化 - アナログ地図は世界中にバラバラ→位置情報と地図を連動させる
誰でも地図を一括登録
- アプリではないのですぐに利用できる
京都市の事例
- 260箇所の地図看板にQRコード設置
- 誰がどの看板を見たかもわかる
参考
www.slideshare.net
クラウドネイティブなアプリケーション開発
- 仮説立案⇒開発⇒検証⇒くりかえし
AWS loft tokyo（目黒）
- 2018年10月
- コワーキングスペースのような場所
- AWSアカウントがあれば無償で入れる
- S3でデータを捨てる必要がなくなる
- 蓄積されたデータは分析されビジネス強化に使われる
- データ分析⇒ビジネス設計⇒製品・サービス設計⇒提供開始⇒くりかえし
- 機械学習がサイクルを加速させる
BUILD ON
参考： AWS BUILD ON
参考
AWS Summit Tokyo 2018 資料・動画一覧 - ｜AWS
Lift-and-Shift による失敗しない AWS 移行のやり方
大石 良様(株式会社サーバーワークス)
AWSパートナー
- Premier
- 上位0.3%
どうやってクラウドに移行するか
Lift-and-Shift
- 既存のサーバーやシステムをで移行
- クラウドらしいサービスを活用してビジネスのデジタル化を推進
いきなりキラキラに移行しようとするとやけどする
- 運用手順変更
- 合意形成、手順作成、組織変更などが必要
- AWSのアップデートの速さ
- やっている途中で新しいサービスが出たりするとやる気を失う
AWSの隠れたメリット
- ネットワーク移行しやすい
- 仮想マシンが移行しやすい
- アプリケーションが移行しやすい
関西（西日本）の移行事例
- ネットワーク移行事例
- 仮想マシンの移行
- アプリケーションの移行
災害はいつくるかわからない
川村 暢様(株式会社NTTスマイルエナジー)
Lift-and-Shit戦略を実行した実例
AWSを使おうと思ったきっかけ
- 最初はプライベートクラウド
- NTTグループのサービスでスモールスタート
- ビジネスのスピード感にインフラが追いつかなくなった
- センサーIoT→センサー数が数万に急増
- ライセンス料がかかる
- ⇒AWSを使おう
AWSを使ってみた感想
- コスト面
- 環境を簡単につくれる
- あとで増減できる
- いったん作ってみて出せる
- エンジニアのモチベーションが上がった
Lift-and-Shiftをやってみてどのように評価されているか
- 少なくとも数年単位のスケジュールでやっていたものが5ヶ月でできた
- ほとんどインフラを知らないメンバーが2,3週間で仮想サーバの移行ができた
今後の展望
キラキラ系を目指す
金融機関の事例
- Lift
- 分散系サーバ、Webサイトの移行
- Shit
- セキュリティ対策としてログを分析
- FAQのAlexa対応
Cloud Automator
- AWS運用を自動化
新しいアーキテクチャへの移行支援
人材価値の変化
- エンジニアの価値が相対的に増大
- 若者層の価値が相対的に増大
不足する人材
- 優秀なエンジニア
- 若手人材
企業の変化
何を自社で行い何を外部に委託するか→AWSをIT基盤にする
※参考
Nintendo Switch (TM) 向けプッシュ通知システム「NPNS」
渡邉 大洋様 (任天堂株式会社)
※資料
Nintendo Switch （TM） 向けプッシュ通知システム「NPNS」
NPNS
- プッシュ通知システム
- Nintendo Push Notfication Service
- 常時接続を使用
NPNS利用例
- フレンドのオンライン通知
- Nintendo みまもりSwitchでの設定変更
- ゲームDL後に完了メッセージ
性能要件など
- スケーラビリティ：1億台に備える
- 可用率：AWSリージョン規模の障害未満は可動
- 遅延：数秒（正常時）、数分（異常時）
- インフラ費用：適切な範囲に抑える
構成要素
※下2つはREST API
XMPP Cluster採用技術
- ejabberd
- Erlangで書かれたOSS
- クラス構成のXMPPサーバ
- 大規模な利用実績が多い
- RDS for MySQL
- 高負荷時のレプリ遅延が少ない
- ElastiCache for Redis
Consumer/Provider採用技術
- RoR
- 社内での開発・運用実績から
- Amazon Aurora
- RDS for MySQLから乗り換え
- 柔軟なスケール
その他
インフラ設計
クラウド選定
- AwsをIaaSとして利用
- 社内実績
- メンバーの経験・スキル
- マネージド・サービス
- 配置
- シングルリージョン
- ネットワーク安定性、リソースの利用効率向上
- Multi-AZ
XMPPのロードバランス
- ELBは不採用
- Classic Load Balancer
- 常時接続に使えない
- Application Load Balancer
- プロトコルが合わない
- Network Load Balancer
- 検証次期とリリース次期があわない
- Classic Load Balancer
- 直結＋DNSラウンドロビン
- Route53に全ノードのAレコードを登録
- ConsulがRoute53のレコードを更新
- ディスカバリは用意しない
- 外部向けI/Fは増やさない
技術詳細
クラスタ維持
ejabberdを2方向から死活監視
- Consul
- すぐ反応
- Auto Scaling
- 慎重に様子見
デプロイ
ドリップ処理
- スムーズな切り替え
- 接続を少しずつBlue→Greenに移動
- 常時接続では接続処理が最も高負荷
- 再接続タイミングを分散させたい
- 切断期間は短くしたい
- やっかいな点
- デプロイが長時間化→今は約2時間
- インスタンス費用がその間2倍に
ドリップ処理の自動化
- Auto Scaling→Lifecycle Hook→CloudWatch Events→Run Command→EC2 Instance
省メモリ化
- インフラ費用を抑えたい
- ejabberdを省メモリ化
- OpenSSLのメモリ削減＆開放
- hibernate前にリソースを開放
- r3.largeで1台あたり72万接続
- ejabberdを省メモリ化
- ところが
- CPUもメモリも秋があるために接続数が増えない
- Security Groupの制限を回避
- セッションの上限にあたっていた
- Security Groupを無効に
- 限界まで設定可能に
- セキュリティ 外部アクセスはNetwork ACLsで制限
TCP切断対策
- 途中経路でのいy増切断を防ぐ
- 無通信期間にKeepAlive（L4,L7）
- 最適感覚を本番環境で実験
- TCP KeepAlive(L4)
- アプリケーション KeepAlive (L7)
- データを入れたパケットを定期的に送信
- 送信間隔：クラスタ間で対照実験
- 送信無し→65秒間隔
- 切断を50%削減
ふりかえり
12月の同時接続数増大→通知送信数は削減できている 規模
- 約700万同時接続
- 約2万通・秒
- 約l200億通／月
AWSの異常 - 発生した異常 - 局所的なネットワーク異常 - RDS I/O遅延 - EBS遅延 - EC2インスタンス異常停止 - NPNSサービスへの影響 - AZ冗長等によりサービスは正常稼働を維持
Erlangでの運用
良かった点 - 安定性 - VM,クラスタ、プロセス監視ツリー - メモリ効率 - 並列性 - hot code loading
ejabberd改造内容
- 並列性、安定性、対象外制
- 省メモリ化
- 独自機能
まとめ
- 必要要件を達成
- AWS起因のサービス停止は無かった
- サービス規模は順調い成長
