Recommended
More Related Content
Similar to KLabのチャットシステム インフラ変遷
Similar to KLabのチャットシステム インフラ変遷 (20)
More from KLab Inc. / Tech
More from KLab Inc. / Tech (20)
KLabのチャットシステム インフラ変遷
- 2. 2 好きなAWSサービス ● CloudFormation ● Secrets Manager 福間 雅弘 クラウドエキスパート エンジニアリング本部技術統括部インフラG KLab株式会社 KLabのクラウド関連インフラ全般 画像 AWS Summit Online 2022 登壇します
- 3. 3 想定視聴者 ● オンプレミスからクラウドへ移行を考えている人 ● 特にデータベースの移行に興味がある人 ● クラウドでサーバを利用しているが、コンテナ利用を考 えている人
- 4. 4 アジェンダ ● KLabのチャットシステムとは？ ● クラウドネイティブ化 4ステップ ● KMSのクラウド移行 ● データベース移行の詳細 ● 今後のKMS ● まとめ
- 6. 6 KLabのチャットシステムとは？ ● 正式名称は KLab Messaging Service(KMS) ● SDK形式でクライアントライブラリを提供
- 8. 8 KMSシステム構成要素 ● IRCサーバ ○ メッセージ配信用基盤(メッセージハブ) ○ インターネット・リレー・チャット(irc)デーモンが動いて いる ● APIサーバ ○ KMSを利用する上で必要な操作を受け付ける ○ ユーザ認証情報登録や、NGキーワード登録など ● UAサーバ ○ クライアントアプリケーションが接続するサーバ ○ ユーザ発言をリアルタイムで中継する
- 10. 10 共有環境のメリット・デメリット ● メリット ○ 一つの物理環境でシステムを提供 ■ 管理コストが低い ● デメリット ○ 問題発生時は全てのタイトルに影響が出る ■ システムメンテナンスは全タイトルと 調整が必要
- 12. 12 天災によるDC停止の危機 ● DCの電源が喪失 ○ 1週間程度で止まってしまう！ ● 対象はKMSが動いていたDC ○ 停止するとKLabの全タイトルに影響が出る
- 13. 13 エクソダス … 出DC！ ● 急いで別環境へ移行する ● 別DCはサーバリソースに余裕がない ○ AWSを利用する ● 受け入れのためサービスセットアップ ○ サーバ準備、DB移行手順確認、DNSの管理変更… ● 緊急時のための準備を加速
- 17. 17 クラウドネイティブ化 4ステップ オンプレのシステムをクラウド最適化する 1. クラウド上のサーバを利用し環境移行を行う 2. システム構成そのままで、コンテナ化を行う 3. 一部機能をクラウドサービスに置き換える 4. ビジネスロジックもクラウドサービスに特化させる
- 18. 18 当時のKLabのAWS利用 ● 主として利用していたのはCDN ○ Amazon CloudFrontが主体 ● 一部タイトルで、Amazon Elastic Compute Cloud (Amazon EC2) ベースでAPIを実装
- 20. 20 KLAWSフレームワークの問題点 ● 元となるAmazon Machine Image(AMI)が古い ○ ベースOSが debian wheezy ○ 当時はEOLが直近 ● AWS Nitro Systemベースの新しいインスタンスタイプが選べない
- 21. 21 AWS移行
- 22. 22 クラウドネイティブ化 4ステップ オンプレのシステムをクラウド最適化する。 1. クラウド上のサーバを利用し環境移行を行う 2. システム構成そのままで、コンテナ化を行う 3. 一部機能をクラウドサービスに置き換える 4. ビジネスロジックもクラウドサービスに特化させる
- 24. 24 AWS移行に関する問題 1. AWSアカウントの管理問題 ○ 1つのアカウントに複数のKMSシステムを配置するのは、 共有システムと同じ課題が発生するのでは？ 2. 構築作業の問題 ○ 複数のKMSシステムを作成するのは、手間なのでは？ 3. ベースとなるAMIの問題 ○ 既存のKLAWS用のAMIを利用すると、新しいEC2インスタ ンスタイプを使えないのでは？
- 25. 25 AWSアカウントの分割 ● AWSのベストプラクティスに則った管理方法 ○ タイトルだけでなく、開発/本番環境でも分離 ● スイッチロールの利用 ○ 一度の認証で、複数アカウントを利用可能にする
- 26. 26 AWS CloudFormationを利用した構築 ● サービス部分だけでなく、通知設定などもまとめて構築 ● 複数のAWSアカウントで同一の環境を準備
- 27. 27 AMIのベースOS更新 ● KLAWS環境作成用のAnsible playbookを準備 ○ Amazon Linux 1/2、debian wheezy/stretch に対応 ● 最終的に、debian stretchを採用 ○ Nitro SystemベースのEC2インスタンスが利用可能に！
- 28. 28 Amazon RDSデータベースエンジンの選択 ● RDS for MySQLではなくAmazon Auroraを採用 ○ AWSが提供するRDBMS ■ MySQL互換とPostgreSQL互換それぞれ提供 ● 東京リージョンで利用可能になった際に検証実施 ○ 致命的な問題が発生し採用を見送った ● 期間が経過し、上記問題も解決したので採用 ○ 追加された機能が魅力的(DB移行で説明) ○ 可用性設計がマルチAZのMySQLより向上
- 34. 34 コンテナの利用
- 35. 35 クラウドネイティブ化 4ステップ オンプレのシステムをクラウド最適化する。 1. クラウド上のサーバを利用し環境移行を行う 2. システム構成そのままで、コンテナ化を行う 3. 一部機能をクラウドサービスに置き換える 4. ビジネスロジックもクラウドサービスに特化させる
- 36. 36 コンテナサービスとは？ ● VMとは異なる仮想化技術 ○ 仮想的なユーザ空間(コンテナ)でプロセスを動かす ● コンテナイメージを指定して起動する ○ アプリが動く最小限のファイルでイメージを作成
- 37. 37 コンテナのメリット（個人的な見解） ● 継続的インテグレーション(CI)を行いやすい ○ VMイメージのパイプライン管理は面倒 ○ コンテナイメージはパイプライン化しやすい ● 継続的デリバリー(CD)も容易 ○ Kubernetes(k8s)などオーケストレーションを利用 ○ さらにCDツールを組み合わせる
- 38. 38 コンテナで実現したいイメージ ● Amazon Elastic Kubernetes Service (EKS)の利用
- 39. 39 コンテナベースのシステム開発に向けて① ● 移行検討時のKLabの状況 ○ プロダクション環境でコンテナ利用は0 ● コンテナの理解程度が低かった ○ k8s/ECS/EKSはおろか、Dockerとは何か？メリットは？
- 40. 40 コンテナベースのシステム開発に向けて② ● 素養はあった ○ インフラのメンバー中心に情報を収集 ○ AWSからの情報提供があった
- 41. 41 コンテナ化のために実施したこと - 役割編 ● 開発-インフラの役割を緩め、一緒に業務を行う ○ これまでは開発者がAWSリソース定義をしなかった ● AWSアカウントの管理方法を改めた ○ 開発環境は開発者が自由にサービスが使えるようにした ■ 費用に対するガードレールを設置 ○ 本番環境も、デプロイ期間を定め開発者がAWSリソース定 義を可能にした
- 43. 43 コンテナ化のために実施したこと - 技術編 ● 共通の技術/言語で開発する ○ python ○ AWS Cloud Development Kit (AWS CDK) ■ https://aws.amazon.com/jp/cdk/ ○ k8sのマニフェスト
- 44. 44 AWS CDKとは？ ● 今までのAWSのリソース作成は定義ベース ○ CloudFormationの json/yaml のテンプレート ● CDKでは、AWSリソース作成をコードとして記載する ○ サブネット定義をforループで定義したり… ● ソフトウェア開発手法を取り込みやすくなった
- 50. 50 アジェンダ(再掲) ● KLabのチャットシステムとは？ ● クラウドネイティブ化 4ステップ ● KMSシステムのクラウド移行 ● データベース移行の詳細 ←イマココ ● 今後のKMS ● まとめ
- 51. 51 データベース移行の詳細
- 52. 52 データベースの移行パターン 1. オンプレミス環境からAWS環境への移行作業 ○ MySQLの移行方法を利用する 2. AWS環境内の移行作業 ○ EC2版KMSからEKS版KMSへ移行 ○ Aurora固有機能を利用する
- 53. 53 オンプレミスからAWSへのDB移行 ● 2パターンの移行方法 ● mysqldumpを利用してexportし、importする ○ データ量が多くない ○ メンテナンス時間で移行が完了する場合 ●MySQLのレプリケーションを利用する ○ データ量が多い ○ メンテナンス時間で移行が完了しない場合
- 55. 55 Auroraのレプリケーションに関する資料 ● Auroraユーザガイドに必要な情報が記載されています ○ レプリカ元は外部MySQL ○ レプリカ先はAurora ● RDSはレプリケーション関連のコマンドに制限がある ○ RDS for MySQL、Auroraともに制限 ○ 代わりに、レプリケーション用プロシージャが存在 ■ mysql.rds_set_external_master ■ mysql.rds_start_replication ■ mysql.rds_stop_replication
- 56. 56 AWS環境内での移行 ● 別VPCにAuroraクローンをおこなう ○ クローン実行時データが瞬時に利用できる ○ クローン先のRDSインスタンスが起動するまで待つだけ
- 57. 57 AWS移行後の対応
- 60. 60 AWSサポートの活用 ● システム移行に関して、AWSサポートと会話 ○ EC2版への移行やEKS版開発で技術支援をもらっていた ● データ統合に関しても相談した ○ 同一CIDRのVPCの通信について相談したところ… ■ Network Load Balancer(NLB)を組み合わせれば通信できる とヒントをもらった
- 62. 62 VPC-A から中間VPCの通信 ● VPC-Aから中間VPCはVPCピアリングで接続 ○ EC2インスタンスから、NLB-Aに通信を行う インスタンス A DB B
- 63. 63 中間VPC内の通信 ● NLB-A のターゲットは NLB-B のIPアドレスを指定 ○ 同一VPCなので直接通信する NLB-Bへ通信 インスタンス A DB B
- 64. 64 中間VPCからVPC-Bへの通信 ● NLB-BのターゲットはVPB-BのRDSエンドポイント ○ NLB-Bのあるサブネットのルートテーブルを設定 ■ 10.0.0/16 はVPC-BのVPCピアリングに向く 10.0.0.0/16 はVPC-B にルーティング インスタンス A DB B
- 65. 65 中間VPCからVPC-Aへの通信(戻りパケット) ● NLB-Aのあるサブネットのルートテーブルを設定 ○ 10.0.0/16 はVPC-AのVPCピアリングに向く 10.0.0.0/16 はVPC-A にルーティング インスタンス A DB B
- 66. 66 データ統合の工夫 ● 同一テーブル定義を利用していた ○ Primary Keyが重複する ● AWS Database Migration Service (DMS)の利用 ○ データ変換をかけながらロードを実施
- 68. 68 今後のKMS
- 69. 69 クラウドネイティブ化 4ステップ オンプレのシステムをクラウド最適化する。 1. クラウド上のサーバを利用し環境移行を行う 2. システム構成そのままで、コンテナ化を行う 3. 一部機能をクラウドサービスに置き換える 4. ビジネスロジックもクラウドサービスに特化させる
- 72. 72 まとめ
- 73. 73 まとめ ● クラウドマイグレーションを行う際は「クラウドネイテ ィブ化 4ステップ」を頭に置く ● クラウド化によってシステムをより柔軟に扱うことがで きるようになった ● マネージドサービスを活用することでシステムの統合・ 移行作業を簡素化できる
- 74. 以上