はじめに
先の 2022/11/28~2022/12/2、ラスベガスにて AWS の最大級のイベント「AWS re:Invent 2022」が開催され、 弊社からも数名のエンジニアが参加しました。 そこで今回は参加メンバーによるイベントの体験記や、それぞれが興味を持ったセッションなどについて紹介したいと思います。
プラットフォーム事業本部：pospome
プラットフォーム事業本部の pospome です。
プラットフォーム事業本部では共通インフラ基盤として EKS を利用しています。
そういった背景もあり、今回の AWS re:Invent 2022 では AWS の EKS サービスチームとディスカッションする機会をいただきました。
具体的な内容を記載することはできませんが、 EKS についての技術的な相談や EKS とは直接関係ない AWS/Amazon の開発体制についての質問など、 ソフトウェア開発に関連するあれこれについてディスカッションすることができました。 自分の役割がアーキテクトということもあり、 ディスカッションした内容は実際にプラットフォーム事業本部内で活用していく予定です。
AWS re:Invent 2022 のセッションの多くは YouTube 上で公開されているので、 「わざわざ現地に行く必要はあるのか?」と思われる方がいるかもしれませんが、 このように現地で色々なエンジニアと交流できるのは re:Invent ならではの醍醐味だと思います。
IT インフラ本部 SRE 部：小野輝也
SRE 部の小野輝也です。私は以下の 2 つのワークショップに参加してきたので、その様子をレポートします。
- AWS Migration and Modernization GameDay
- Data analysis with Amazon EKS and AWS Batch
AWS Migration and Modernization GameDay
こちらは GameDay と呼ばれるタイプのセッションです。他の参加者と 3 人のチームを組んで課題に取り組み、他のチームとスコアを競います。 競技テーマが Migration と Modernization で、オンプレ上にあるアプリケーションサーバと DB を AWS へマイグレーションし、コンテナワークロードに載せ替えるなどのモダナイゼーションをするのが目標となります。
マイグレーションにはAWS Server Migration ServiceとAWS Database Migration Serviceというサービスを利用しました。私は業務でオンプレからの移行をしたことがなかったので、今回の GameDay で初めて概要を知ることができました。これらのサービスを使うことで、最小限のダウンタイムでワークロードの移行ができるようです（ダウンタイムを最小化することも、競技のスコアに影響する要素でした）。
チームメイトがこのサービスを使ったことがあったそうなので、マイグレーションの作業はお任せしました。結構時間との戦いになるので、こういった役割分担は重要になります。私はマイグレーションと並行して AWS 移行後の ECS Fargate 移行といったモダナイゼーションに向けた実装を担当しました。残念ながら時間切れで ECS へのマイグレーションは達成できませんでしたが、素早くマイグレーションとモダン化を実装するという点で力試しになりました。
チームは同じテーブルに座った人と適当に組むことになるので、初対面で出身国も違うエンジニアと協働作業をするという貴重な経験をすることができました。ややハードルを感じながらも勢いで参加登録した GameDay でしたが、「意外とやればできる」、「いややっぱり全く英語わからん」という両面を感じることができたので参加する価値はあったかなと思います。
Data analysis with Amazon EKS and AWS Batch
こちらはワークショップと呼ばれるタイプのセッションで、実際に手を動かしながら AWS のサービスをハンズオン形式で学ぶことができます。今年の 10 月にAWS Batch が EKS のサポートを開始しましたが、それを実際に触ってみようという内容でした。
AWS Batch は、バッチジョブを実行できるマネージドサービスです。依存関係やジョブスケジューリングのポリシーが定義できるため、Step Functions や ECS ScheduledTask などと比較して、より大規模で複雑なバッチジョブ実行に向いているサービスという印象があります。今回のアップデートは、これまで ECS しか利用できなかったバッチ処理のコンピューティング環境に EKS on EC2 が加わる、といったものでした。
ワークショップは AWS が用意したハンズオン環境を使って進めていきます。Batch on EKS を実際に触った感じだと、EKS 側に namespace を作成して RBAC の紐付けを行うだけで、あとは従来の Batch のように実行できました。EKS クラスタを既にワークロードで利用している場合は、マネージドサービスの特長を生かして便利に使えるものだと思います。
セッション中は随時 AWS のエキスパートに質問することができます。そこで、「Batch のコンピューティング環境として EKS Fargate のサポートは今後ありえますか？」という質問をしてみました。返答としては「ほぼない」とのことでした。理由としては、「Batch は EKS の Kubernetes API を叩くことで、バッチジョブの処理に利用するノードや Pod の管理を実質的に EKS に代わって担うため、そのような構成と Fargate は相性が悪い」といった旨のことを仰っていました（が、筆者のリスニング力が不十分なのでこれは一部誤っている可能性があります...）。
全体的な感想
この他にも基調講演や Expo（企業ブース）など魅力的なイベントが盛りだくさんで、とても濃密な時間を過ごすことができました。私自身の成長という点だと、英語で他のエンジニアに話しかける、質問するといった積極性と度胸は少しレベルアップした気がします。そのようにして関わった人の多くが re:Invent をとても楽しんでいる様子で、世界中で AWS を使う人、作る人たちの熱量を肌で体感できました。
プラットフォーム事業本部：Anri
プラットフォーム事業本部の Anri です。 私は、今回初めて re:Invent に現地参加し、いくつかのセッションを聴講しました。本稿では、その中でも特に印象に残った "DOP402: Implementing DevSecOps pipelines with compliance in mind" というセッションについて紹介します。
DevSecOps とは、サービスの開発・運用サイクルにセキュリティの観点を取り入れ、アジャイルかつ持続的なセキュリティ対策をサービスに導入する考え方のことを言います。このセッションでは、企業の中で DevSecOps を根付かせるための方法論について、概念・理念的な部分から、監査体制の構築に向けた実践的な方法まで、網羅的に紹介されていました。
ところで、re:Invent のセッションはいくつかの種類 (Keynote, Breakout Session, Chalk Talk, Workshop, etc) に分類されており、このセッションは Chalk Talk という類のものでした。Keynote や Breakout Session などに比べて特徴的なのは、発表者と参加者のインタラクティブ性が重視されている点です。100 人以上の参加者が集まる Breakout Session とは異なり、Chal Talk は比較的小規模 (5-60 人程度) に行われ、発表中に参加者がいつでも自由に手を挙げて発言したり、質問したりすることが許されています。今回のセッションでも多くの参加者が思い思いの意見や疑問を投げ合い、かなり活発に議論が交わされており、そのおかげで発表が全く進まず、終盤でプレゼンの進行スピードが急激に加速していったのが印象的でした。
しかし、そのおかげでわかったことがありました。私は普段 DevOps エンジニアとして働いており、セキュリティに関しては基本的な部分のみ知っている程度で、発展的な知識を有しているわけではありません。このセッションに参加したのも単なる興味本位な理由でした。セッションが始まる前、他の参加者はセキュリティに関してある程度責任をもつ役職についている人がメインなのかなと想像していたのですが、Chalk Talk の中で他の参加者の話を聞いていると、どうやら私と同じ DevOps エンジニアが参加者の大半を占めていることがわかり、親近感を覚えました。
また、参加者から寄せられる質問も、現場で働くエンジニアならではといったものが多く、「社内のセキュリティ部門が各開発チームの CI パイプラインに自動セキュリティテストを組み込むとしたら、どのような業務フローになるのか？」とか「各開発チームのプロダクトから脆弱性が検知された場合、解消の責務を追うのは開発チームなのか、それともセキュリティ部門なのか？」など、かなり実践的な疑問が寄せられていました。そして、発表者 (AWS の Solution Architect の方) はこれらの質問に対し「Amazon の開発組織では、基本的にパイプライン自体の保守運用やサービスからの脆弱性除去については開発チームが責務をもつ ("You build it, you run it" の原則) 一方で、セキュリティ部門はパイプライン構築に必要なテンプレートやライブラリ等を提供し、また各種セキュリティテスト結果の集約と監査を行うなどといったように責務をわけている」というような内容の回答をしていました。このようなプラクティカルな知識が得られるのも、参加者による自由な質問が許される Chalk Talk ならでは、といった印象を受けました。
Breakout Session などは後日アーカイブ配信があり、インターネット経由での視聴が可能ですが、Chalk Talk などは特に配信されないので、現地でなければ参加ができません。それに、世界中のエンジニアからの生の声を聞く体験は、ただプレゼンを聞くだけでは得られない感動や気づきがありました。もしこの記事を読んでいるあなたが、来年以降 re:Invent に参加するチャンスを得られた時は、Chalk Talk や Workshop などといった、よりインタラクティブなプログラムに参加されることをオススメします。
ITインフラ本部 インフラ部：星野卓哉
インフラ部コーディネートグループの星野です。
AWS Organizationsを使ったマルチアカウントの運用・管理をしています。
AWS Organizationsに関連したセッションに参加してきましたので、紹介したいと思います。
Best practices for automating AWS account migration
このセッションはChalk TalkでAWS Organizations間のアカウント移行に関するベストプラクティスについてディスカッションするような内容でした。
Chalk Talkとは、AWSに関するサービスに対する、少人数を対象にした
スピーカーと聴講者との間で交わされるディスカッション形式のセッションです。
現在Organizationsは様々なサービスと連携されており、
今後は更にAWS Organizations間のアカウント移行で考慮すべき点が多くなってくると思います。
今回新たに登場したAccount Assessment for AWS Organizationsというソリューションを使えば、
信頼されたアクセスが有効なAWSサービス、委任されたアカウント、IDやリソースベースのポリシーを検出することで、
依存関係を特定できるので、安全にアカウント移行できるようになるみたいです。
Account Assessment for AWS Organizationsは以下のような構成となっており、CloudFormationのスタックを使用してデプロイできるようです。
実際のデモの様子がこちらです。
業務の中で、外部のOrganizationsへアカウントを譲渡することもあれば、内部のOrganizationsに招待することもありましたが、
今までどのサービスで信頼されたアクセスが有効になっているか、アカウント委任しているサービスは何かを意識することがなかったなと思いました。
今後、業務で活かせる部分があるかもしれないので、触ってみようと思います。
Delegating access in a multi-account environment with IAM Identity Center
こちらもChalk Talk形式で行われたセッションでした。
このセッションはAWS IAM Identity Centerを使用して、AWS OrganizationsやAWS Control Towerでのアクセス管理の委任についてディスカッションするような内容でした。
Organizationsの管理アカウントは、メンバーアカウントの作成や削除から請求情報まで管理しているアカウントのため、
別アカウントに管理を委任することで、権限が強すぎる親アカウントにログインする必要がなくなり、今までより安全に運用できるようになります。
また、Organizationsやマルチアカウント運用関連のセッションを聞いていて、必ず耳にするのがAWS Control Towerでした。
AWS Control Towerは各アカウントの統制を制御できるサービスですが、Account FactoryでAWSアカウントのプロビジョニングも可能なサービスです。
アカウントごとの初期設定も可能とのことなので、
今後、我々が運用しているAWSアカウント発行システムに組み込めるかな・・みたいなことを考えたりしました。
感想
初のre:invent参加でしたが、今回は主に後日資料公開されないというChalk Talkに参加してきました。
議論が交わされる中で、これ聞きたいなと思ってもなかなか英語で発言するのが難しかったです。
もしまた行く機会があったら、しっかりと英語も勉強して臨みたいと思います。
あとは、聞きたいセッションがあっても予約で埋まっているというのが多々あったので、もっと早めに登録すればよかったと後悔しています。
マーケティング本部 マーケティング・テクノロジー部：濱田翔馬
マーケティング・テクノロジー部の濱田翔馬です。普段は、広告配信システムや通知配信サービスの開発、運用を行なっています。
今回は、配信に関わるセッションを中心に参加したので、その中から興味深かったものをご紹介します。
How Yahoo cost optimizes their in-memory workloads with AWS
このセッションでは、Yahooが広告配信のインフラコストをどのようにして削減したかについて語られていました。
Yahooの広告配信サーバーでは、毎日3200億以上もの広告イベントが発火されています。その広告イベントから発生する費用や収益は、広告イベント（広告リクエストや広告オークション）とユーザーイベント（クリックやインプレッション）をJOINしていくことで集計されていきます。
各イベントログはそれぞれ非同期に蓄積されるため、JOINオペレーションを適切に行っていく必要があります。例えば、5分間に発生したインプレッションから発生した広告費用など算出する場合、直近４時間に蓄積された広告オークションをスキャンしていく必要があります。これはクリックなども同様です。そして、そのJOINオペレーションは５分間隔で定期的に実施する必要がありました。
イベントログは、Apache Sparkによって４時間前まで遡ってスキャンしていきます。これは30TB以上のデータを処理することを意味します。この設計は、運用コスト面、パフォーマンス面であまり良いものではありませんでした。
彼らはこの課題を解決するために、Key-Valueデータストアを活用した新しい方法の模索を始めました。
Key-Valueデータストアを選定した理由には、以下の要件がありました。
- 同じデータセットを毎回読み込まないようにしたい
- 必要なデータのみアクセスするようにしたい
- バッチ処理やストリーミング処理に最適化させたい → in-memoryデータベースの活用
従来の方法では、大量のイベントログをS3に蓄積し、直近４時間分のデータをApache Sparkで5分間隔にJOINしていました。これを、広告イベント発火時にKey-Valueデータストアに登録する仕組みへ切り替えることで、無駄の多いワークロードの脱却を図りました。
Key-Valueデータストアとして、チームでは３つの技術を審議に上げました。
- Amazon DynamoDB
- サーバレス、マネージド
- 耐久性、持続性が保証されている。今回のユースケースではそこまで重要ではない
- 高い運用コストがかかる
- HBase
- HDFSやS3上で動作し、Amazon EMRで使用する
- すでにバッチやストリーミング用のオンプレ環境にて運用経験がある
- OSアップデートやチューニングにかかるメンテナンスコストが発生。メンテナンスはできる限り避けたい
- Amazon ElastiCache
- AWSのフルマネージド・サービス
- in-memoryのKVデータストア。Redisが活用されている
- すでにストリーミング・ワークロードでRedisを活用した運用経験がある
- 全体的に高いパフォーマンス。レスポンスが１ミリ秒未満という速さ
上記３つを比較した上で、Amazon ElastiCacheを活用する選択肢を見出しました。
Amazon ElastiCacheによる広告システムのプロトタイプでは、以下のような構成を試したようです。
- Redis 6.2.6
- R6g.2xlarge nodes
- 52.82 GiB RAM
そして、１時間分のオークションデータをElastiCacheクラスターのキャッシュにのせ、テストを行いました。結果としては、150ノードが必要になり、そのデータの加工にはおよそ5分〜10分という時間を有すことが分かりました。また、クラスターサイズという観点では、実際のプロダクションにのっているデータを使用した場合、ElastiCacheにておよそ650ノードが必要という結果になりました。
ここから、4時間分の広告イベントデータをElastiCacheにのせる方法は、運用コストが高く現実的ではないことが分かります。そこで、根本原因を掘り下げるため、JOIN時にスキャンされているデータの偏りについて分析を行いました。
分析した結果、次のことが分かりました。
- JOINオペレーションでアクセスした95%のデータは、直近１時間分のデータに集中していた
- 残りの5%のデータは、３時間分の古いデータによるものでした
ここから考えられる解決策は、3時間分のデータをディスクにオフロードしておき、オンデマンドで再度メモリに読み込む方法でした。
パフォーマンスを犠牲せずにこれを達成する方法はあるでしょうか？
彼らは、この方法を解決するためにいくつかの手法を試しました。
一つ目は、全体の広告イベントデータ25％（１時間分のデータ）をAmazon ElastiCacheに読み込み、同時に全データをHBaseにサイド・キャッシングする手法です。
しかし、これは初期にHBaseを技術選定から外した理由にもある通り、複雑な処理ロジックと運用コストがかかることから採用を見送ることにしました。
その間、Amazon ElastiCacheでは新しいオプションがリリースされました。それは、Amazon ElastiCache with data-tieringです。
二つ目の方法は、data-tieringを活用することでした。これはまさに彼らが求めていたものだったようです。data-tieringでは、RAMとSSDの両方を活用することで効率的に大量のデータ蓄積&処理を実現することができます。つまり、直近１時間分の広告イベントをRAMにキャッシュし、その他のデータをSSDに保管する構成をAWSのフルマネージドな環境にスケールする状態で実現できる、ということになります。
Amazon ElastiCache with data-tieringでは、以下の構成を試しました。
- R6gd.2xlarge
- 52.82 GiB RAM
- 199.07GiB SSD
この構成は、従来よりも大幅なコスト削減に繋げることができました。クラスターノードの数が 650ノード → 150ノード に削減でき、コストを50%カットすることができたのです。また、JOINに関わるワークロードは以前と同じく、５分〜１０分以内に完了しており、定めているSLAへの影響もなかったようです。
今日運用されているアーキテクチャは画像のようになっています。
広告サーバーから発行された広告イベントがAmazon Kinesisを通じてS3データレイクに保存されます。そして、Amazon EMRがそこから抽出したデータを活用して、JOINオペレーションを実行し、ElastiCacheに保存します。最終的に、JOINしたデータをS3に戻し、Amazon Athenaを使って効果計測を行っています。
最後に、この設計から学んだ事例を紹介していました。
このアーキテクチャをプロダクションへデプロイしたあと、EMR clusterにて問題が発生しました。原因は、Amazon EMRクラスターがElastiCacheクラスターへの接続時に新規のコネクションを立て続けていたことが原因でした。これによって、ElastiCacheクラスターへの接続が混線してしまったことで、後続のJOINオペレーションに影響を与えていたということです。
解決策は至って標準的で、コネクションを維持したり、スレッド間で共有することで接続数を減らすなどの対策を行いました。
ここは、マーケティング・テクノロジー部でも、以前同様の事象でエラーを発生させてしまった経験があり、他社の事例でも同じ現象を聞けてニヤリとしてしまいました。
以上がセッションの概要になります。前半ではYahooにおけるコスト削減の話がメインで進行し、後半では、Amazon ElastiCache with data-tiering に関する内部的な処理やワークフローについて詳細が解説されていました。私自身、ふんわりとした理解で今まで業務を行っていたこともあり、改めて適切な技術選定の重要性に気がつかされる印象的なセッションとなりました。
今回は紹介しきれませんでしたが、ぜひセッションの後半にも目を通してほしいなと思います。AWSサービスの内部がどういう設計になっているのか、その一旦を伺うことができ、これもかなり面白かったです。
全体的な感想
AWS re:Inventは、現地に参加したからこそ出会えるセッションがたしかに存在する、と感じました。今回ご紹介できなかったセッションの他にも、興味深いセッションはたくさんありました！Amazon PrimeでNFL配信するために何をしたか？など、普通では聴講できないようなセッションがたくさんありました。
AWS re:Inventのセッションは、現地にいったからこそ出会えるものがたくさんあると感じる良い機会になりました。ぜひ皆様も機会があればぜひ挑戦してみてほしいです！様々な発見があり、とても有意義な時間をすごすことができました。今後とも、AWS re:Inventのセッションには注目していきたいと思います。
動画配信事業部：堀越俊行
22新卒で配信基盤グループの堀越です。
私は22新卒エンジニアとして入社しました。 現在は業務でAWSを扱ってはいませんが、クラウドやサーバーサイドに興味があり、プライベート等で触ってみていたので手を上げたところ、幸運なことに今回のイベントに参加させていただけることになりました。(ありがとうございます！)
私は今回、オンラインでは体験できない、オフラインならではと言えるものに参加しようと思い、会場を回ってきました。 そんなこんなでほぼ全ての開催日の私のスケジュールは(朝ごはん→KeyNote→Expo→昼ごはん→セッションやワークショップ) でした。
ここでは私が参加したワークショップの話を書きたいと思います。 私は以下の4つのワークショップに参加しました。
- Configuring Amazon S3 security settings and access controls
- Data Analysis with Amazon EKS and Amazon Batch
- Proactive Auto Scaling for Optimal cost and Availability
- Build better ML models for business decisions using Amazon SageMaker Canvas
選択したワークショップに一貫性がみられませんね。 先ほど書いた通り、現在AWSサービスをあまり扱っていないので、触ったことのないサービス等を選んでみました。 このうち、上二つのものについて詳細に書きたいと思います。
Configuring Amazon S3 security settings and access controls
これはAWS S3の機能について説明を受けたのち、それらの設定を用いてセキュアなバケットを構築できるように実践するワークショップでした。 (セッションとしてはこちらの内容が近いです。)
やはりS3はAWSのデータレイクとして最も普遍的なもので、多くのデータを扱う上でセキュリティを意識して扱わなければならない場面が多々あります。 そんなS3ですが、AWSとしてはベストプラクティスとして以下のことを推奨しています。
- S3バケット
- SSE-KMSをデフォルトの暗号化キーとして使用する
- SRRまたはCRRを用いてオブジェクトをレプリケートする
- オブジェクトロック・バージョニング・MFA認証での削除
- 共有バケットの制御簡素化のためのS3アクセスポイント
- バケットポリシーによるアクセス制限をかけたVPCエンドポイント
- ACLsの代わりにIAMとバケットポリシーを使用する
- AWSアカウント
- 複数のバケットのパブリックアクセスをブロックする
- AWS Configでセキュリティ設定をモニタリングする
- IAM Access Analyzer を使用してセキュリティアクスを監査する
- AWS Organizations/マルチアカウント
- バケットポリシーを適用するためにSCPを使用する
- パブリックバケット識別のためAWS Control Centerによるガードレールを用いる
これらのベストプラクティスを補完するために
- S3 Storage Lens
- S3 Batch Replication
- AWS Backup for S3
- S3 Object Ownership
などが最近のセキュリティ系アップデートとして提供されています。
これらのベストプラクティスを達成すれば完璧、というわけではないでしょうが、 さまざまなシステムでS3を選定する場面は多くあると思うので、その際にはセキュリティの観点から必要な対応が取れる必要があるなと考えさせられました。
Data Analysis with Amazon EKS and Amazon Batch
このワークショップでは、Amazon EKSを使用して大規模なデータ分析を管理およびスケジューリングするためAWS Batchを利用する方法について学びました。 AWS Batchの基本的なコンセプトと、AWS BatchがAmazon EKS内で実行されている他のAWSサービスとどのように連携しているかを理解した後に実際に簡単な機械学習モデルをトレーニングしてみることでAmazon EKSクラスターをデプロイし、AWS Batchを活用してポッドを管理しするといった全体の流れをより深く理解することができました。
ここで挙げられているEKSとAWS Batchですが、この二つを用いてバッチワークロードを実行できるようになったのは先々月です。 それまではECSを通じてFargateやEC2を制御していました。
AWS Batchとは、ジョブスケジューラとリソースオートスケーラの側面を持つサービスです。 バッチ処理を行う際にフルマネージドに大規模なリソースを扱うジョブを高効率に実行してくれます。
EKSは、(というよりKubernetesは)マイクロサービスの管理に優れています。 マイクロサービスとバッチワークロードの得意な面が以下の4点で異なります。
- マイクロサービス
- 実行時間：開始後一定時間は停止しない
- 応答時間：ミリ秒単位
- 高可用性：ゾーン間でのレプリケーション
- 実行周期：周期的な実行
- バッチワークロード
- 実行時間：有限な実行時間
- 応答時間：数分から数日
- 高可用性：対象外、ゾーンレベルの高速アクセス
- 実行周期：一時的な実行
さらに、バッチワークロードには以下の用件が求められています。
- エクストリームスケーリング
- ジョブ再実行ロジック
- ジョブの依存関係の定義
これらのことから、Kubernetesをそのままバッチ処理の実行環境として扱おうとすると色々な不都合が起こります。 しかし、バッチワークロードとしてもフルマネージドでオートスケーリング可能なコンテナ実行環境は扱いたいわけで、さまざまなソリューションが生まれてきました。(Apatch YuniKorn, Volcano, Kueue, etc...) ただ、これらのサービスはAWSの求めるベストプラクティス足りえませんでした。
ワークショップでは、実際にCloud9を用いてEKSやAWS Batchを管理し、イメージ処理を行うバッチ処理やクラスタの負荷検証を行うワークロードを実行しました。 構築、実行した環境は以下のようなものになっています。
バッチ処理に関して、特に配信基盤では負荷検証などさまざまな場面で用いることがあり、その際のソリューションの一つとしてとても勉強になりました。
感想
新卒ながらこのような体験をさせていただけて、とてもありがたいです。 今回記事として書いたものはワークショップが中心となりましたが、その他のセッションも実際に現地に行ったからこそ出会えたものなどが多くありました。 実際に業務として扱っている海外のエンジニアと交流をすることもでき、自分の学びを見つめ直す機会にもなり、とても有意義な時間を過ごすことができました。
また行く機会などあったら、今回の体験からどれだけ感じ方が変わったのかを確かめ、より深く学びを得れる場にできればいいと思いました。
おわりに
参加したメンバーのイベントの体験記や興味を持ったセッションについてのレポート、いかがでしたか？ 今回はさまざまな事業部からのメンバーで参加したので、各々参加したセッションや感想が異なっておりとてもおもしろいですね。
さらに今回参加したのは比較的若いメンバーでした。 このように手を上げれば誰にでもチャンスがある会社というのをしっかりと実感できましたし、新卒の身としてはとてもありがたい環境だなと常々感じています。
今後も弊社ではAWSの活用を進めていきながら、 今回得た知見を活かしてよりAgilityの高いテックカンパニーを目指します。
