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

技育CAMPアカデミア 事例を通して学ぶ AWSクラウドアーキテクチャ入門 2024-07-25 株式会社Finatextホールディングス 松崎稔矢 @tm8619_pro © 2024 Finatext Holdings Ltd.

自己紹介 © 2024 Finatext Holdings Ltd. 1

自己紹介 松崎稔矢 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のベストプラクティスの簡単な紹介 ●EC2だけで作った構成を紹介 ●構成を良くしていきながら、 使用するAWSサービスを紹介する ●要件に応じてどう変えていくのかを考える © 2024 Finatext Holdings Ltd. 3

AWSのベストプラクティスの簡単な紹介 © 2024 Finatext Holdings Ltd. 4

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

• 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のベストプラクティスの簡単な紹介 一般的な設計原則 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

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

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

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

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

EC2だけで作った構成を紹介 © 2024 Finatext Holdings Ltd. 13

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

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

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

構成を良くしていきながら、使用するAWSサービスを紹介する アーキテクチャを改善していく © 2024 Finatext Holdings Ltd. 17

アーキテクチャを改善していく 最終的には左のアーキテクチャを右のアーキテクチャにすることを目指します © 2024 Finatext Holdings Ltd. 18

アーキテクチャを改善していく 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

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

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

アーキテクチャを改善していく 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

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

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

アーキテクチャを改善していく AWS CloudWatch ● アラームを設定したり、ダッシュボー ドを設定したりすることで、監視を集 約できる。 ● リソースの使用状況や、ALBの StatusCodeの件数など、様々なメト リクスを取得可能。 © 2024 Finatext Holdings Ltd. 25

アーキテクチャを改善していく Amazon CloudWatchLogs AWSにログの管理を集約！JSONにすると検索性も上がります。 ALBのアクセスログも設定で集められます。 © 2024 Finatext Holdings Ltd. 26

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

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

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

アーキテクチャを改善していく 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

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

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

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

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

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

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

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

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

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

アーキテクチャを改善していく 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

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

今後の展望 要件に応じて出来ること ● 高トラフィックを捌きたい ● 監視結果に応じて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

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

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/

appendix Finatext HD の各種リンク 公式Xやテックブログもぜひご覧ください！ 公式X→ テックブログ→ © 2024 Finatext Holdings Ltd. 45