技育CAMPアカデミア_事例を通して学ぶ AWSクラウドアーキテクチャ入門

267 Views

September 14, 24

#AWS #クラウドアーキテクチャ #EC2 #セキュリティ #ベストプラクティス

スライド概要

技育プロジェクトで発表した勉強会のスライドです

Toshiya Matsuzaki

@tm8619

スライド一覧

株式会社Finatext サーバーサイドエンジニア AWS/Go/Terraform

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

ダウンロード

ダウンロード(pdf - 1.7MB)

関連スライド

Aurora3のTempTableの落とし穴とその回避策

Toshiya Matsuzaki 1.8K

猫でも分かるUnreal Engineの学び方 - 超初心者向け編 - 2023 v1.0

ue4 ue5 ue-beginner

エピックゲームズジャパン 1.3M

Unreal Engine5 Lumenの仕組みと肝心なところ

ue5 ue-rendering ue-lumen

エピックゲームズジャパン 1.1M

SQL滅ぶべし

株式会社ホクソエム 857K

猫でも分かる UE5.0, 5.1 におけるアニメーションの新機能について【CEDEC+KYUSHU 2022】

ue5 cedec+kyushu ue-animation ue-optimize ue-bp ue-physics ue-sequencer

エピックゲームズジャパン 822.7K

各ページのテキスト

自己紹介松崎稔矢 Toshiya Matsuzaki 1996-06-19生(28歳) X(Twitter): @tm8619_pro 職種: バックエンドエンジニア趣味: ボウリング/ゲーム/ダーツ/ポーカー/乗馬などその他: ・競技プログラミング経験あり好きなアルゴリズムは乱択・ISUCON2回出場参加記をテックブログに書いてます・ジャンル問わず何でもやりたい好奇心旺盛な性格経歴 2019年1月インターン開始 2021年4月新卒入社入社後、3つのプロダクト新規開発のリードを行う 2024年4月開発チームリーダーになる 2024 Japan AWS Jr.Champions 選出 © 2024 Finatext Holdings Ltd. 2

AWSのベストプラクティスの簡単な紹介 AWS Well-Architected Framework AWSの出している設計指針日本語: https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/welcome.html 英語: https://docs.aws.amazon.com/en_us/wellarchitected/latest/framework/welcome.html 信頼性が高く、安全で、効率的で、費用対効果が高く、持続可能なシステムを設計して運用するための、アーキテクチャに関するベストプラクティスを学ぶことができる。若干AWSの公式ドキュメントは独特な言い回しが多いことがあり初見では難しいので、英語がある程度読める人は、英語のほうが読みやすいかも。一般的な設計原則と、以下6つの柱で構成されている。 - 運用上の優秀性セキュリティ信頼性パフォーマンス効率コスト最適化サステナビリティ © 2024 Finatext Holdings Ltd. 5

AWSのベストプラクティスの簡単な紹介一般的な設計原則 https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/general-designprinciples.html ● キャパシティニーズの推測が不要 ○ 最初に買ったサーバーがでかすぎてもったいなかった・小さすぎてまたすぐ買い足さないといけなかった…などを考えず、柔軟にスケーリングできるシステム ● 本稼働スケールでシステムをテストする ○ 簡単に環境をコピーできるようにする ● アーキテクチャの実験を念頭に置いた自動化 ○ 変更や戻しが簡単にできるようにする ● 発展するアーキテクチャを検討する ○ サービスが成長していっても耐えられる設計にしておく ● データに基づいてアーキテクチャを駆動 ● ゲームデーを利用して改善する © 2024 Finatext Holdings Ltd. 6

https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/general-design-principles.html

AWSのベストプラクティスの簡単な紹介運用上の優秀性 ● ビジネス成果に基づいてチームを編成する ● オブザーバビリティを実装して実用的なインサイトを取得する ● 可能な限り安全に自動化する ● 小規模かつ可逆的な変更を頻繁に行う ● 運用手順を定期的に改善する ● 障害を想定する ● 運用上のあらゆるイベントやメトリクスから学ぶ ● マネージドサービスを使用する ○ サービスによって任せられる範囲はまちまちだが、インフラ面の保守をAWSに任せる ○ 物理的なものの管理は完全に不要 © 2024 Finatext Holdings Ltd. 7

AWSのベストプラクティスの簡単な紹介セキュリティ ● 強力なアイデンティティ基盤を実装する ○ 最小限の人しか通さないようにする、最小権限のみ付与するという最小権限の原則 ○ 弊社の別アカデミア回で、ここについて詳しく解説しています https://speakerdeck.com/kevinrobot34/introduction-aws-iam-3a810adc-5172-4460-97210041456eb2bf ● トレーサビリティの実現 ○ 誰（人やシステム）がどんなアクションをしたかの履歴を残し、後から追えるようにする ● 全レイヤーでセキュリティを適用する ● セキュリティのベストプラクティスを自動化する ● 伝送中および保管中のデータを保護する ● データに人の手を入れない ● セキュリティイベントに備える © 2024 Finatext Holdings Ltd. 8

https://speakerdeck.com/kevinrobot34/introduction-aws-iam-3a810adc-5172-4460-9721-0041456eb2bf

10.

AWSのベストプラクティスの簡単な紹介信頼性 ● 障害から自動的に復旧する ● 復旧手順をテストする ● 水平方向にスケールしてワークロード全体の可用性を高める ○ 一箇所に障害が起きたら全部死ぬような、単一障害点をなくそう、ということ。 ○ 垂直は1つを大きくする、水平は数を増やすこと ● キャパシティーを推測することをやめる ● オートメーションで変更を管理する © 2024 Finatext Holdings Ltd. 9

11.

AWSのベストプラクティスの簡単な紹介パフォーマンス効率 ● 高度なテクノロジーを誰でも使えるようにする ○ AWSのマネージドサービスを使用することで、簡単に使える状態にする ● 数分でグローバルに展開する ● サーバーレスアーキテクチャを使用する ○ サーバーの運用負荷を下げることで、新規開発にリソースを割くことができる ● 実験の頻度を高める ● メカニカルシンパシーを検討する © 2024 Finatext Holdings Ltd. 10

12.

AWSのベストプラクティスの簡単な紹介サステナビリティ ● 作業の影響を理解する ● 持続可能性の目標を設定する ● 使用率を最大化する ● より効率的なハードウェアやソフトウェアの新製品を予測して採用する ● マネージドサービスを使用する ● クラウドワークロードのダウンストリームの影響を軽減する簡単に言うと、AWSが大規模に効率的なオペレーションを考えてくれているので任せてくれると結果効率的な事が多いのと、コストを削減する事（効率的にリソースを使用すること）がそのままサステナビリティに繋がる © 2024 Finatext Holdings Ltd. 11

13.

AWSのベストプラクティスの簡単な紹介ざっくり設計で意識することまとめ ● 最小権限の原則 ● トレーサビリティ（追跡可能性）を高める ● スケーラビリティ（拡張性）を高める ● オブザーバビリティ（可観測性）を高める ● アベイラビリティ（可用性）を高める ● デュラビリティ（耐久性）を高める ● 単一障害点を無くす ● 運用負荷を減らす ● マネージドサービスを使う © 2024 Finatext Holdings Ltd. 12

14.

15.

EC2だけで作った構成を紹介一般的なwebアプリケーションを作りたい要件 ● インターネットに一般公開するアプリフロント・サーバーがある ● メトリクス（メモリ使用量など）を定期的に取得し、監視を行う必要がある ● アプリケーションにはファイルアップロード機能があり、個人情報を登録する可能性がある ● 永続化が必要なデータがある ● 永続化不要だが、高速化のためキャッシュ実装が必要 ● 運用者がDB操作やアプリケーションログ、メトリクスの監視を行う ● ローカルでほぼシステムを構築出来たが、これをAWSにデプロイしたい © 2024 Finatext Holdings Ltd. 14

16.

EC2だけで作った構成を紹介 ● ローカルで作った環境を再現するため、1つの EC2インスタンスに全てを乗せる構成にした。 ● 過去、一瞬だけアクセス過多で落ちた経験から、大きなEC2インスタンスを立てている。 ● セキュリティグループは、全てのポートでインバウンド・アウトバウンドも0.0.0.0/0で許可した。 ● アプリのインメモリキャッシュの実装があり、 1時間を過ぎたデータはcronで起動されるキャッシュクリアジョブ（サーバーのAPIを一つ叩くのみ）で削除される。 ● 運用者は、アプリのログとメトリクス取得ジョブが作成したログを集計し、監視する。 ● DBは、ローカルからMySQLに作成したユーザーPWを使用しログインする。 ● サーバーがファイルをインスタンス内に保存している。 ● サーバーはDockerで起動している。 © 2024 Finatext Holdings Ltd. 15

17.

EC2だけで作った構成を紹介めっちゃコスト高い問題点 ● セキュリティ上のリスクが大きいこれの保守もコスト ● 運用負荷が高いやろうと思えば攻撃し放題 ● インスタンスを大きくしたり小さくしたりすることが難しい ● DBだけ性能上げたい要望に答えられない誰からでもアクセス可ユーザーPWがバレたらDB が自由に書き換えられるインスタンスのアップデートどうする…？ ● インスタンスが仮に壊れた時に全データが失われるリスクがあるやりたいことログ集計大変… ● EC2が単一障害点になるので改善したい ● 最小権限の原則を適用して改善したい ● 運用負荷を減らしたい ● 拡張性・可観測性・追跡可能性を高めたい © 2024 Finatext Holdings Ltd. 16

18.

19.

20.

アーキテクチャを改善していく Amazon Elastic Container Serviceを使用して、APIサーバーの管理を簡潔にできること ● コンテナ管理の自動化 ● オートスケーリング AWS Elastic Container Registry (ECR) ● ECR(Elastic Container Registry)を利用し、イメージのデプロイを簡潔に AWSが用意した Docker Registry ● 柔軟なデプロイ AWS Elastic Container Service(ECS) コンテナ化されたアプリケーションを簡単にデプロイ、管理、スケーリングするためのフルマネージドサービスつまり、いい感じにコンテナを管理してくれるサービス ○ ダウンタイムなしで可能なローリングアップデートなど今回は、拡張性、運用負荷軽減、マネージドサービス使用の観点から、APIサーバーの管理をAWSに寄せるために使用します。 © 2024 Finatext Holdings Ltd. 19

21.

アーキテクチャを改善していく Amazon Elastic Container Serviceの簡単な概念説明 ● タスク定義 ○ コンテナの起動設定を管理する ● タスク ○ コンテナ群のこと ○ タスク定義の設定に基づき、コンテナを立てる ● サービス ○ タスクを管理するもの数の増減や入れ替えなど ● クラスタ ○ サービスやタスクを実行する基盤・集まりクラスタにはEC2が紐づいていて、タスクがEC2の場所を確保する。確保した場所にコンテナを立てる。 © 2024 Finatext Holdings Ltd. 20

22.

アーキテクチャを改善していくやったこと ● APIサーバーをECSタスク経由で起動するようにした ● Docker RegistryとしてECRを使用するようにした嬉しいこと ● APIサーバーのアップデートが楽になった ○ EC2内での作業が不要 ● どのバージョンのAPIなのかが、タスク定義や ECR Image経由で分かるようになった ● 運用負荷軽減・拡張性の向上まだ出来ないこと ● ローリングアップデート ● ≒ APIサーバーを複数台立てること © 2024 Finatext Holdings Ltd. 21

23.

アーキテクチャを改善していく Amazon Elastic Load Balancingを使用して、スケーラブルにできること ● パスやホストでのルーティング ● セキュリティ強化 ● トラフィックを複数のEC2・コンテナに分散する ○ ECSサービスに紐づける事で、動的ポートマッピングを利用可能 Elastic Load Balancing(ELB) ● ヘルスチェックロードバランシングサービスで、サーバーの負荷の分散を行う。3種類ある。今回は、動的ポートマッピングというALBの機能を使いたいことと、アプリへはALBを通した後にEC2にアクセスするようにします。 - Application Load Balancer（ALB） Network Load Balancer（NLB） Classic Load Balancer（CLB）拡張性、単一障害点の回避に繋がります。 © 2024 Finatext Holdings Ltd. 22

24.

アーキテクチャを改善していくやったこと ● フロントが参照するAPIを、ローカルではなく ALB経由にするようにした。 ● APIサーバーの前にALBを置いた嬉しいこと ● APIサーバーのコンテナの数を自由に増やせるようになった ● ローリングアップデートにより、ダウンタイムなしにAPIサーバーを更新できるようになったやりたいこと ● ログ周り、集計も監視もたくさんコマンド打たないといけないし簡単にしたいな… © 2024 Finatext Holdings Ltd. 23

25.

アーキテクチャを改善していく Amazon CloudWatchで監視をAWSに任せよう！できること ● メトリクスの収集とモニタリング ● ログの収集と分析 ● アラームの設定 ● ダッシュボードの作成 ● イベントの監視と自動化 AWS CloudWatch AWSのリソースとアプリケーションの監視および管理を行うためのサービス今回は、可観測性の向上、運用負荷低減の観点で、ログとメトリクス収集を置き換え、更にダッシュボードを作る事にします。 © 2024 Finatext Holdings Ltd. 24

26.

27.

28.

アーキテクチャを改善していくやったこと ● ログをCloudWatchLogsに置き換えた ● メトリクス監視をCloudWatchに置き換えた ● CloudWatch Logsを有効活用できるよう、ログ出力をjson形式にフォーマットを整えた嬉しいこと ● ログの調査が直感的になった ● 監視が集約され、今まで見てなかったものも一緒に見れるようになったやりたいこと ● 仮にEC2インスタンスが壊れたらデータが無くなってサービス終了するので改善したいな… © 2024 Finatext Holdings Ltd. 27

29.

アーキテクチャを改善していく Amazon Simple Storage Serviceを利用して圧倒的な耐久性を得るできること ● 他のAWSサービスとの連携 ○ イベントをトリガーにして後続処理を起動できる ● 自動でのバックアップ ● バージョニング AWS Simple Storage Service(S3) オブジェクトストレージサービス DropBox/GoogleDriveなどのAWS 版とイメージすると分かりやすい ※厳密には仕組みが違うもの ○ 同じファイル名での更新履歴まで取得可能 ● 静的ファイルの配信 ○ フロントのデプロイ先にできる ● セキュリティ設定今回は、障害耐久性や運用負荷低減のため、サーバーのファイル保存先を置き換え、更にフロントのデプロイ先も置き換えることにする © 2024 Finatext Holdings Ltd. 28

30.

アーキテクチャを改善していくやったこと ● フロントをS3に置き、パブリックアクセスを許可することで置き換えた ● サーバー用のS3バケットを作成して使うようにした嬉しいこと ● サーバーのファイルが、EC2に入らずとも確認出来るようになり、耐久性も上がった ● フロントのデプロイが簡単になったやりたいこと ● MySQLのデータも守りたい © 2024 Finatext Holdings Ltd. 29

31.

アーキテクチャを改善していく Amazon Relational Database Serviceを使用して、高可用性を得よう！できること ● 容易なレプリケーション ● 高可用性 ● 自動バックアップ ○ ある時点の状態に戻すことも可能 Amazon Relational Database Service(RDS)/ Amazon Aurora 今回はRDSの中のAurora MySQL（AWSが再設計したもので、MySQL互換で使えつつ独自機能もある）を使用します。ざっくり、高機能になったMySQLと考えて okです。 ● フェイルオーバー ○ 主インスタンスに障害が起きたとき、自動で別のインスタンスがその役割を担う ● ストレージ自動拡張 ● クエリのパフォーマンス分析今回は、データのバックアップ機能の使用や、今後の拡張性を考えEC2インスタンスのDBをAuroraに置き換え © 2024 ます。 Finatext Holdings Ltd. 30

32.

アーキテクチャを改善していくやったこと ● EC2で立っていたMySQLを、Amazon Aurora に置き換えた ● データ移行も行った嬉しいこと ● DBの可用性が上がった ● EC2インスタンスが壊れてもデータが守られる ● スケーラビリティが向上した ○ 簡単にレプリカを追加出来るやりたいこと ● EC2インスタンスにAPIコンテナだけにしたい ● キャッシュ周りもAWSに載せちゃいたい © 2024 Finatext Holdings Ltd. 31

33.

アーキテクチャを改善していく Amazon ElastiCacheを使用して、管理の手間を省き高可用性を得よう！できること ● 可用性やレプリケーション周りはRDSと同じ！ ● Redis/MemcachedをAWSのマネージドで使える ○ サーバー等を立てたり、スケーリングに悩む必要がない Amazon ElastiCache 拡張性と、マネージドサービス使用の観点で使用します Redis/Memcachedを使用可能今回は実際には、言語のキャッシュライブラリ等を使用する事でEC2のインメモリキャッシュを実装も可能ではあるが、AWSのサービスに任せる方針で置き換える。パフォーマンスが高く、サイズを動的に変更可能でスケーラビリティが高い。 © 2024 Finatext Holdings Ltd. 32

34.

アーキテクチャを改善していくやったこと ● キャッシュ管理をElastiCacheに置き換え、 TTL(Time To Live)を1時間に設定した ● キャッシュクリアバッチが不要になったので消した嬉しいこと ● キャッシュクリアバッチを消せた ● EC2インスタンスの内部の構成が非常にシンプルになったやりたいこと ● EC2のメンテナンスも面倒なので管理をやめたい © 2024 Finatext Holdings Ltd. 33

35.

アーキテクチャを改善していく Amazon Fargateを使用して、EC2の管理からも開放されよう！できること ● インフラなしに、コンテナを起動できる ● 必要になった時に必要な分のリソースだけを使用できる Amazon Fargate コンテナ向けサーバーレスコンピューティングサービス ● 今まではEC2の中に収まる量しかコンテナを配置できなかった（増やしたければEC2を追加で立てたり大きくする必要があった）が、それが実質無制限になる運用負荷軽減、拡張性向上、マネージドサービスを利用する観点で使用します。構成の改善により、EC2はAPIサーバーのコンテナしか立っていない状態になったので、コンピューティングのインフラもAWSに任せることにします。 © 2024 Finatext Holdings Ltd. 34

36.

アーキテクチャを改善していくやったこと ● コンテナはFatgate起動にした嬉しいこと ● EC2の管理が不要になった ○ 急にたくさん増やしたいとき、EC2の上限を気にしなくて良い ○ EC2のインスタンスが不調のようなことを気にしなくて良いやりたいこと ● インフラが動かしやすい構成になったので、ネットワーク周りを整備することでセキュリティ強化 © 2024 Finatext Holdings Ltd. 35

37.

アーキテクチャを改善していくやりたいことは、アクセス許可を最小限にする ● APIサーバーはALBから受け取る ● DBはAPIサーバー、運用者からのみアクセス ● ElastiCacheはAPIサーバーからのみ ● サーバーファイル保存用S3はインターネットを通したくないこのあたりは外からアクセス出来ない場所に置くようにする（=プライベートサブネット内に置く）しかし、逆にプライベートサブネット内からもインターネットにアクセス出来なくなる © 2024 Finatext Holdings Ltd. 36

38.

アーキテクチャを改善していく NAT GatewayとVPC Endpoint VPC Endpoint NAT Gateway ネットワークアドレス変換ができるAWSサービス簡単に言うと、プライベートサブネット内のリソースがインターネットにアクセスできるようにしつつ、インターネットからのアクセスは防ぐ事ができるこれを利用することで、プライベートサブネットからインターネットアクセスが可能になるインターネットに出さずにAWS内のサービスにアクセス出来る道を開けてくれるAWSサービス VPC内の通信を振り分けるルートテーブルの設定を行う必要はあるが、用意されたエンドポイントにアクセスした場合、その通信をAmazon S3に向けてくれるようになり、アクセスできるようになるこれを利用することで、インターネットを経由せずS3を使用することができるようになる © 2024 Finatext Holdings Ltd. 37

39.

アーキテクチャを改善していくやったこと ● API・DB・キャッシュをプライベートサブネットに置いた ● ALBのみパブリックに置き、サーバーはALB経由でのみ許可をするようにした ● 運用者がDBを触れなくなってしまったので、必要に応じて都度踏み台EC2サーバーを立てる ● DBはサーバーと、踏み台EC2からのセキュリティグループを許可 ● 踏み台のEC2は、運用者のアカウントからのみ入れる（StartSession）ようにした ● サーバー用S3は、サーバーが置いてあるVPCからのアクセスのみに制御した ● ネットワーク構成の変更のついでに、マルチAZ 構成とした © 2024 Finatext Holdings Ltd. 38

40.

アーキテクチャを改善していく嬉しいこと ● DBに接続できる人がシステムと運用者のみに限られた ● サーバーにインターネットから直接アクセスすることが出来なくなった ○ ALBにファイアウォールを置けば全リクエスト通すことができる ● サーバーファイル用のS3もシステムと運用者しかアクセス出来なくなった ● AZ障害が起きても、システムが落ちなくなったやりたいこと ● さらなるセキュリティ向上のため、ファイアウォールを設置したい ● フロントのコンテンツ配信を早めたい ● 独自ドメインにしたい © 2024 Finatext Holdings Ltd. 39

41.

アーキテクチャを改善していく AWS WAF・Amazon CloudFront・Amazon Route 53 AWS WAF ファイアウォールサービス Amazon CloudFront コンテンツ配信ネットワーク(CDN) Amazon Route 53 ドメインネームサービス（DNS）条件に従ってリクエストをブロックす高可用性、スケーラビリティ、セキュることが出来るリティを兼ね備えているドメインを購入したり、持っているドメインを登録してルーティングブロックのルールはAWSマネージドコンテンツをよりユーザーから物理的のものがあるので、それを使用するだに近いところから配信することで、高けでも十分な効果あり速な配信が可能になる S3/CloudFront/ALB等へのルーティングも容易に可能 © 2024 Finatext Holdings Ltd. 40

42.

アーキテクチャを改善していくやったこと ● フロント配信をCloudFront経由にした ● ドメインを購入し、Route53に登録した ● ALBにWAFを噛ませた嬉しいこと ● コンテンツ配信が全世界に高速になった ● 覚えやすいURLでフロントサービスにアクセス出来るようになった ● SQL Injectionなどのリクエストを機械的にブロックしたり、IPの制限をかけられるようになった一旦基本的な構成としては完成！ © 2024 Finatext Holdings Ltd. 41

43.

今後の展望要件に応じて出来ること ● 高トラフィックを捌きたい ● 監視結果に応じてSlackにログ通知したい ○ APIサーバーの台数を増やす ○ CloudWatchのAlarmからAmazon Lambda(サーバレスコンピューティング)を実行 ○ Auroraリードレプリカ数を上げる ○ 非同期アーキテクチャを考える ● コストを抑えたい ■ Amazon SQS等 ○ AZ障害を許容して、単AZ構成にする ○ DDoSが原因ならAWS Shield ○ リソースを全体的に小さいサイズにする ● 開発者のアクセスを監視したい ○ インスタンスのまとめ買いをする ○ CloudTrailというAPIコールを確認できるサービスを使用して、ログを確認 ○ EC2 StartSessionのログ収集 ○ Aurora MySQLの監視ログ収集当初の構成では到底対応出来なかった要件も、自然にサービス追加で拡張したり、今ある機能だけで実現可能に！ © 2024 Finatext Holdings Ltd. 42

44.

まとめ AWSをフルに利用して、運用面で柔軟で、簡単なシステムを構築しよう！ ● 最小権限の原則 AWS Well-Architectedの観点に従ってAWSのサ ● トレーサビリティ（追跡可能性）を高めるービスに置き換えていったところ… ● スケーラビリティ（拡張性）を高める ● オブザーバビリティ（可観測性）を高める ● アベイラビリティ（可用性）を高める要件への対応で分かる通り、当初の構成でより明らかに柔軟性が増したシステムに！ ● デュラビリティ（耐久性）を高める ● 単一障害点を無くす ● 運用負荷を減らす ● マネージドサービスを使う実際にはまだまだ紹介しきれていないサービスも一口にDBと言ってもAurora以外にたくさんある AWSのサービス間の比較が全く出来ていないが、それを経験できるプログラムが… © 2024 Finatext Holdings Ltd. 43

45.

appendix 実施概要 ↓ Finatext HD のサマーインターン申し込み ↓フォーム毎年サマーインターン(有償)を実施しています！ぜひご参加ください！ 2024年の実施概要は以下のとおりです。実施期間： 2024年8月26日(月)〜2024年8月30日(金) 要項ページ： https://hd.finatext.com/news/20240529/ 【ソフトウェアエンジニア】： - Go言語とAWSを使ってシステムの開発や AWSの技術選定をやっていただきます - AWSの方がゲストで来ます - 今日の話を活かして実践出来ます！【データサイエンティスト】： - Python/SQLで実践的ビッグデータ分析！ - 普段触れない、POSやクレカのデータを利用して実際の分析業務を体験できます © 2024 Finatext Holdings Ltd. 44

https://hd.finatext.com/news/20240529/

46.

47.