AWSマイグレーション事例祭りのレポート
はじめに
4/9(火)にAWSマイグレーション事例祭りに参加したので、そのレポートです(雑メモです
セッション
オープニング
- この4月に四本のセミナーを企画
- 新機能の紹介
- ドコモ・ヘルスケアの事例
- AWSの特徴：テクノロジーリソースがUtility化した
- トライ・アンド・エラーを多く繰り返せることから、イノベーションの加速できたなどフィードバックをもらっている
グリー株式会社
→オンプレミス環境がその多くをしめている。
- AWSをどうやっていこうした、ではなく背景・メリット・デメリット・失敗談等の話
- 背景
この四点からAWSが優位だったため、この度導入を決めた。
- 反対意見
- オンプレを見越してコードを書いていたのに、AWSを導入したら書き直しが発生する
- 社内ツール等の移行もある
- AWS移行後の恩恵
- 10以上のプロダクトを移行し、約40%のサーバー費用を削減(3000万/月の削減)
- メリット
- デメリット
トレードオフの関係があるのが、今回はメリットのほうが良かった
- 運用面での変化
- 良かった点
反省点
まとめ
- 移行は成功だった
- マニュアルやサポートもあってAWSがBESTだった
- 経営と組織マネージメントとエンジニアの相互理解と協力が必須だった
- 事前に考慮しておく
CyberZ
- 分析環境をAWSのAthenaにした振り返り
- プロダクト概要
- ビックデータ環境の利用形態
- データ収集→処理→分析/可視化のフローが一般的だと
データの収集(計測サーバーの通信をログに出力) →Hadoopでデータ集計→ウェブアプリケーション(自社開発)で可視化
固定の集計軸システムはできる(ユーザ単位でどれだけ違うのかなど)が、軸を決めていないこと(任意軸システム)もしている(Prestoというオンプレ上に立っているものを使っている)。
発表では任意軸システムの話におけるものを話す
- 分析エンジニアがクエリを書いて結果をとって、顧客側にレポートを提供
- クエリはtableau, redash(BI)を経由して、裏でprestoをが動いて返している。
- prestoはビックデータを解析するクエリエンジン(Mysqlとは違うような形式)
- 定期的に送付するシステムもある
- この環境を動かす選択肢
この3つを満たしているAthena
- Athenaの説明
- 移行後の課題と解決
- 良かった点
- 金額安い：AthenaのほうがEMRと比べると体感10倍安い
- クエリがはやい：
- Amazon AthenaのほうがEMRと比べると、SELECTクエリが約2~3倍早い
- インサートする側はEMR + Hiveと比べると、CTASクエリが10倍早い
- 運用が楽：EMRはチューニングやエコシステム化などを考えないといけないがAthenaは全く気にする必要がない
- 悪かったところ
マッチングエージェント
- 運用開始から5年
- 稼動システムの刷新の難易度
- リスクを最小化して、それを示すのが大変
- 複雑な変更は大変
- 計画を作るのが大変：工数が増えれば不確実性も増える
- 影響確認するのも大変：単純に確認する項目が増える、
- 切り戻すのが大変：どっかしらでどかっと変更したときに中途半端なところでエラーが出ると出戻りも発生
- どうするべきか
- 一つの目的に絞っていること(PRも同様)
- 4つくらいにシステムの変更はある
- add (機能追加
- upadate (機能の動作変更
- delete (機能の削除
- refactor (機能の振る舞いを変更せずに更新
その4つの変化に対して対応する
漸進的というのは「順を追って小さな変化を起こしていくこと」という意味 どういう影響が起きるか正しく理解できればリスク軽減にもなるし、経営者に説明しやすくもなる
- システムの課題点
- 構成の管理コストが高い(インフラの方にお願いしたり)
- デプロイに一時間かかる
- パフォーマンスが不安定
どういう優先度で解消するべきかを見直すのが大事 コンテナ化はやろう、DBに関しては最適なインスタンスタイプでクラスタ構成にしようなどある
→AWSにおDirect Connectがそれを解決した。
Direct Connect
EC2への移設
ECSの構成
EC2からECSへ移行
- Trafic flowを利用 : LB同士の振り分けにも対応できる
- ECCSのメリットとして、イミュータブルなので、開発言語などのバージョンアップが以前より気軽になった。
- オートスケーリングが簡単、EC２と比べてアプリの最新版のデプロイをどうするかとか気にしなくてよかった
- タスク定義されているので、ロールバックも簡単
ニフティ
- レガシーなシステム脱却しよう！
- 2017年の夏からベンダー選定契約を行い、現在は移行中
- 社内セキュリティルールをどう適用するか
- そのAWS版をつくったり、社内の認証系をどうするか、支払いコスト配布に関してどうするかなど
- ニフティはサービスごとにAWSアカウントを作成、そのアカウントと損益計算の単位とのヒモ付アカウントと作成時でやる
- 比較が大変で、Gartnerの比較表をつくたがあまり良くなかった(カタログスペック比較になってしまうから)
- 選定基準を先に決め、どのくらい満たせるか図るのが良い
- ニフティの場合はインシデント時のログ配置などがある。
- AWSにどうやって移行するか
- 計画段階で検証している。
- 内製に決め打ちしていた：移行後に開発運用できる人材がいなければ目的の一つである生産性向上につながらない。属人化しちゃうから。
- CloudEndureをつかって動かした(PtoV)
- 準備フェイズ
- ニフティニュースの移行プロジェクト
- 移行パターン調査：システム動作言語や環境、AWSのノウハウ蓄積状況を考えてrehost(リフトアンドシフト)を実行した
- システムズマネージャーをつかってnon-sshでメンテしたり、クラウドフロントでキャッシュを扱ったり、athenaを使ってランキングデータを生成したり、Lambdaをつかってslackに障害アラートを送るようにしたり設計した。
- CloudEndure：ライフマイグレーションツール
- エージェントをインストールしてぽちるだけなので、専門知識が不要
- 複数サーバーの同期の状況管理ができる。
- 移行でハマったポイント
- CLoudEndureではNFSサーバーが起動不能
- 技術マニュアルに乗ってない仕様があった：初回のデータ同期完了しないとサーバーが起動すらできない。1日あたり50Gもあり、いつまで立っても起動してくれなかった。 →S3をつかってNFSのデータを移行した。tarとか適切な形式で前処理は必要
- パフォーマンスが出ない
- 当初は可用性を高めるためにマルチAZ化する設計だった。
- それをすると、パフォーマンスが出なくて困った。
- 推定すると、細やかなレイテンシ差 * ワークロードあたりのタスク数 * タスクあたりのIO数がかけあわさって遅くなってしまった→マルチAZをあきらめ、シングルエイジにした。(アプリケーション側がレガシー過ぎていじれないのが原因の一つでもある
- HTTPS周り
- バッチやルーツでHTTPS通信する際に2つのエラーに遭遇
- 原因はレガシーである(TLSバージョン問題やSNI問題)があった
- 解決方法としては、使用言語のアップデートをおこなったり、泣く泣くELBセキュリティポリシーの緩和を行った
- CLoudEndureではNFSサーバーが起動不能
- AWS移行後
- 運用のしやすさが向上した。
- 技術負債をAWSサービスの力を借りて解消中
最後にレガシーなシステムほど慎重に。
