ITエンジニア特化型Q&Aサイトteratailを言語、DB、クラウドなどフルリプレイスした話

by レバレジーズTechアカウント

Slide 1

Slide 1 text

ITエンジニア特化型Q&Aサイト teratailを言語、DB、クラウドなどフルリプレイスした話レバレジーズ株式会社　リードエンジニア　竹下義晃

Slide 2

Slide 2 text

自己紹介レバレジーズ株式会社テラテイルグループ　リーダー竹下義晃経歴 2009/3 東京大学大学院農学生命科学研究科修了 2009/4 芸者東京株式会社入社 2020/6 レバレジーズ株式会社入社一般社団法人 Japan Scala Association 理事兼任現在Webフロント、バックエンド、インフラ、データ分析などフルスタックエンジニアとして teratail開発に関わっています前職では、アプリマーケターとして Traﬃc Run!など全米1位を獲得したハイパーカジュアルゲームのUA/MOを担当したことも

Slide 3

Slide 3 text

目次 ● teratailとは ● リプレイス概要 ○ リプレイスの目的 ○ 技術スタックの比較 ● AWS Fargateによるサーバーレス化 ● AWS CDKによるIaC化 ● AWS Cloud9を活用したデータ移行 ● まとめ

Slide 4

Slide 4 text

teratailとは

Slide 5

Slide 5 text

ITエンジニア特化型Q&Aサイト「teratail（テラテイル）」は、2014年7月にオープンしたエンジニアの問題解決プラットフォームです。学生やプログラミング初心者から第一線で活躍する方々まで、幅広いエンジニアの問題解決をサポートしています。 https://teratail.com/

Slide 6

Slide 6 text

リプレイス概要

Slide 7

Slide 7 text

リプレイスの目的

Slide 8

Slide 8 text

問題点モノリシックで、長期に渡って改修を続けて来たことで、システム肥大化小さな修正でも全体に波及する機能追加やバグ修正のコストが高くなり、開発効率が低下使用しているフレームワーク、PHPのVersionのサポート期限も近づいていた

Slide 9

Slide 9 text

リプレイスで達成したいこと ● 技術スタックを刷新し、開発効率を向上 ● 長期的にも開発効率を高い状態で維持 ● teratailをベースに、新サービスを展開する際にも既存の機能を活用可能に今回のリプレイスのスコープ ● 技術的な部分がメイン ● UIはそのまま ● 機能も基本そのままで使用されてない機能は削ってスリムアップ

Slide 10

Slide 10 text

技術スタックの比較

Slide 11

Slide 11 text

使用技術の比較

Slide 12

Slide 12 text

構成の比較

Slide 13

Slide 13 text

全体構成

Slide 14

Slide 14 text

今回のメイン 25分ではすべて説明しきれないので、今回は主にAWSのサービスを活用することで特に効果的だった部分に焦点を当てて話して行きたいと思います。

Slide 15

Slide 15 text

説明する部分 ● AWS Fargateによるサーバーレス化 ○ コスト効率UP ○ 運用効率UP ● AWS CDKによるIaC ○ インフラ構築の効率 UP ○ インフラ構築のブラックボックス化を防ぐ ● AWS Cloud9による旧DBから新DBへのデータ移行 ○ 複雑かつ困難な作業を効率よく

Slide 16

Slide 16 text

AWS Fargateによるサーバーレス化

Slide 17

Slide 17 text

AWS Fargateとはサーバーレスかつ従量課金のコンテナ向けコンピューティングエンジン特徴 ● 管理不要 ● オートスケールなどの設定容易 ● ログ、メトリクス監視も容易 ● 従量課金なのでコストを最適化可能

Slide 18

Slide 18 text

構成

Slide 19

Slide 19 text

以前は kubernetesクラスターを利用していたが、オートスケールが無いため非ピーク時はリソースがあまり、ピーク時には足りなくなりかけていたバッチ処理を動かすと、アプリサーバーにも影響が出ることもあったサーバーでバグが発生した場合は、ソースコードを巻き戻して再デプロイ

Slide 20

Slide 20 text

リソースの効率化オートスケールかつ従量課金なので、ピーク時に合わせたハードウェアを用意する必要なしなので、トータルコストダウンマイクロサービスごとの負荷に合わせてタスク数を調整質問マイクロサービスタスク数4 お問い合わせマイクロサービスタスク数2 バッチ処理は新しいTaskで起動するので、アプリサーバーに影響はしない、かつ、実行した分しか料金がかからない

Slide 21

Slide 21 text

運用の効率化フルマネージドなので、タスクが落ちても自動で復帰オートスケールで自動で負荷に対応デプロイも安全に行える巻き戻しはタスク定義で一つ前のバージョンを指定して再デプロイするだけ

Slide 22

Slide 22 text

AWS CDKによるIaC化

Slide 23

Slide 23 text

AWS CDKとは AWS Cloud Development Kit AWSのIaCを行える強力なサービス ● プログラミング言語でインフラを定義できる ○ 型による実行前の整合性チェック ○ ライブラリ化によるノウハウの共有 ● デフォルト設定が優秀なので記述量が減る ● プログラミングの開発ノウハウを転用可能 ○ 抽象化、一般化、インターフェイス化による整理 ○ 自社ユースケースに合わせて宣言的なライブラリへの拡張同様なツール ● AWS CloudFormation(CDKはCloudFormationのJsonを出力します) ● Terraform

Slide 24

Slide 24 text

以前は itamaeによる構築、または、UIコンソールでの手動作成前任者がやめ、手順書も揃ってなかったり、実態と乖離があったりして、構築方法が半ブラックボックス化

Slide 25

Slide 25 text

構成管理＝ソースコード構成がソースコードで管理され、そのままインフラが構築されるため、ソースコードが構成資料かつ構築手順書となる staging,productionなど様々な環境で、かんたんに同じ構成を再現可能変更時も差分を事前に確認して、安全に変更可能

Slide 26

Slide 26 text

マイクロサービスとの相性マイクロサービスが複数あるが、構成は大体似ている CDKなら、汎用化したStackを作っておくと、いくらでも同様の構成を構築可能 Staging,Productionを判定してスペック変更や、Amazon Simple Storage Service(S3)を使うサービスにはS3へのアクセスポリシーを追加などの小さな差異を、ロジックで実現できる

Slide 27

Slide 27 text

AWS Cloud9を活用したデータ移行

Slide 28

Slide 28 text

AWS Cloud9とはブラウザ上で使用できる統合開発環境 ● VSCodeのGUIで操作が可能 ● 接続を切ると自動で停止状態になる ● 基本的なライブラリなどが導入済み

Slide 29

Slide 29 text

データ移行の課題クラウド跨ぎ =>　新DBはVPCのPrivate Subnetに用意しているので、外部からはアクセスが容易ではない PostgreSQLからMySQLへ => バックアップからそのまま復元はできない正規化や設計見直しによるテーブル構造の変化 => 単純にデータ移動するだけでは移行できない

Slide 30

Slide 30 text

データ移行の課題

Slide 31

Slide 31 text

解決策 AWS Cloud9の利用 VPC内に Amazon Elastic Compute Cloud(EC2)インスタンスが作られるので、DBへのアクセスが可能基本的なプログラム実行のためのライブラリがインストール済み変換ルールベースのデータ移行ツールの開発テーブル構造の変更、MySQL化を同時に行うことのできる移行ツールを開発

Slide 32

Slide 32 text

AWS Cloud9を使う利点実態はAmazon EC2だが、初期環境構築が非常に楽ブラウザ上からGUIで操作が可能 => 対話的に実行が容易 => サーバープログラムを転用したメンテナンスプログラムを楽に実行可能 DBと同じVPC内で実行できるので、アクセス設定不要時間が経つと勝手に休止状態になるので、スペックが良いマシンを立てて落とし忘れていて請求が！ということが無い

Slide 33

Slide 33 text

普通に移行プログラムを作成したときの問題点問題点 * すべてのカラムが移行されたかを検証するにはコードを読む必要がある * コードが煩雑になりがち

Slide 34

Slide 34 text

変換ルールベースのデータ移行ツールカラム単位で「変換操作」のルールを定義し、ルールを列挙したファイルを読み込むことでデータ変換される削除されたデータは、カラムの削除のルールを確認するだけでチェック可能 => テーブル構造が変わっても漏れなくデータ移行されていることが保証できる

Slide 35

Slide 35 text

変換ルールベースのデータ移行ツール実際は、ルール生成と変換の 2段階に分けている単純な変換は自動でルール生成し、複雑なルールのみマニュアルで作成するだけで良いようにして労力を減らしている

Slide 36

Slide 36 text

まとめ

Slide 37

Slide 37 text

AWSのサービス活用による運用の効率化今回は主に ● AWS Fargate ● AWS CDK ● AWS Cloud9 に焦点を当てましたが、それ以外にも ● Amazon RDS - Amazon Aurora ● Amazon ElastiCache for Redis Cluster ● Amazon Opensearch Service Cluster ● Amazon CloudFront など、数多くのフルマネージドのサービスを組み合わせて活用することで構築、運用、保守すべてが効率化しています。

Slide 38

Slide 38 text

AWSのサービス活用による運用の効率化 ● 専属のインフラエンジニアがいなくても、十分に大規模サービスのインフラを運用していける ● アプリエンジニアがインフラまで面倒を見れるようになることで、 SREとしての働き方が容易に

Slide 39

Slide 39 text

最後に

Slide 40

Slide 40 text

レバレジーズで働きませんか？ teratailやレバテック、看護のお仕事、WeXpatsなど、30を超える様々なサービス開発を通じて社会貢献に努めています。「顧客の創造を通じて関係者全員の幸福を追求し、各個人の成長を促す」を一緒に実現していきませんか？