Dreamforceについて Dreamforceとは、Salesforce社が毎年開催している世界最大のカンファレンスイベントになります。 世界中のSalesforceユーザが集まり、基調講演やセッションからインサイトや成功を共有し、業界の最新イノベーションやテクノロジーの未来を学ぶことができる場となっています。 1. Dreamforce2024 Dreamforce2024は、9/17日～9/19日の3日間、サンフランシスコで開催されました。 世界中から45,000人以上、日本からは700人以上の顧客・パートナーが現地参加されたそうです。 今年のDreamforceのテーマは、 『Humans with Agents drive customer success together』 （人とAIエージェントが共同して顧客の成功を支援する） と掲げ、「AIの第3の波」についてメインテーマとして取り上げられました。 WEBページ： https://www.salesforce.com/dreamforce/ 2. AIのイノベーション（第3の波） Dreamforce2024では、「AIの第3の波」が取り上げられました。 ここでは、AIのイノベーションを紹介させていただきます。 第1の波では「Chatbot」でAIが質問に対してルールベースで回答することができるようになりました。 第2の波では「Copilot」でAIベースで処理をすることができるようになりました。例えば、AIがメール作成や要約をし、人の業務をアシストすることができるようになりました。 そして、第3の波では「Agentforce」というAIプラットフォームが発表されました。こちらは、目的に対して計画を作成し、オーケストレーション、実行することができます。第2の波では、アシストすることまででしたが、第3の波でアクションを実行することまでできるようになり、人のように業務をこなすことができるようになりました。 マイナビでは、現在「Copilot for Microsoft365」など議事録や資料作成に利用していますが、「AIの第3の波」を導入することでさらに業務を効率化できるとともに新しいところに目を向けられる時代がくると感じました。 3. Agentforce 「Agentforce」とは、自律型AIエージェントとなり、営業・サービス・マーケティング・コマースなど、ビジネスのあらゆる領域で活用できるAIプラットフォーム。 簡単に言うと、Salesforceに蓄積されたデータをもとにAIが人のように業務をこなすエージェントとなるプラットフォームのようです。 また、Salesforceの新しいアーキテクチャが同心円の図で示されました。 これまでSalesforceが掲げてきた「Customer 360」の基盤としてData Cloudが位置づけられ、その外側の顧客接点のレイヤーにAgentforceが配置されています。 この新しいアーキテクチャは、Data CloudがSalesforceプラットフォームの心臓部として機能し、Salesforceに蓄積されたデータを集約し管理します。そのデータを利用し、各「Agentforce」が顧客との関係性に直接反映させる役割を担うことを示して紹介されていました。 4. SalesAgentのご紹介 「Agentforce」は、営業・サービス・マーケティング・コマースなど、ビジネスのあらゆる領域で活用できるAIプラットフォームになります。 ここでは、営業組織のための「Sales Agent」を紹介させていただきます。 「Sales Agent」とは、営業組織のための「Agentforce」になります。 「Sales Agent」には、「Einstein SDR」と「Einstein Sales Coach」のエージェント機能があります。 ①Einstein SDR Einstein SDR Agentは、見込み顧客と自然言語で自律的に対話し、問い合わせへの対応や営業担当者とのミーティングを設定することができます。 今後、見込み顧客や一度契約いただいたお客様に対して、Agentにより問い合わせ対応をすることできると営業担当者に時間ができますね。 ②Einstein Sales Coach Einstein Sales Coach Agentは、お客様役として、ヒアリング、プレゼン、交渉時のシミュレーションを行い、営業担当者と自律的なロールプレイを実行することができます。また、実際に商談に参加し、商談進行中にアドバイスをすることもできます。 この機能を使うことで、営業担当者全体の商談スキルも向上し、その結果商談成功率もあがることへ繋がると思いました。 5.（おまけ）Waymo Dreamforce2024では、「Agentforce」が「AIの第3の波」と紹介されていましたが、サンフランシスコの街中にも「AIの第3の波」がありましたので紹介させていただきます。 サンフランシスコでは、Waymoという完全無人の自動運転タクシーが走っていました。 Waymoは、現在 アリゾナ州(フェニックス)、カリフォルニア州（ロサンゼルス/サンフランシスコ）にて自動運転タクシー「Waymo One」を商業運用しているそうです。 「AIが人のように業務をこなす」まさしくこういうことなんだなと実感しました。 WEBページ： https://waymo.com/ 6. まとめ Dreamforce2024に参加し、これからは人とAIが共に働く時代がやってくることを実感しました。 その第一歩がSalesforceの「Agentforce」になるかもしれません。 また、今後のビジネスの中心は、AIによりデータ駆動型の意思決定がされる方向性であるそうです。 そのために、まずデータを整理すること、データの繋がり作ることが最低限必要と感じました。 今後のAI共同時代に向けて、データ活用を意識し業務を遂行していきたいと思います！

自己紹介 ゼネラルエージェント事業本部IT_WEB領域にて、求人企業の採用支援、求職者の転職支援を担当している佐藤です。 担当企業　：WEB事業会社（マイナビも担当しています） 担当求職者：WEBエンジニア、WEBエンジニアを目指している方 メイン業務は企業の採用支援ですが、現在は求職者支援もおこなっております。普段はCTOやVPoE含め、現場の方々とコミュニケーションを取っておりますため、（可能な範囲での）生の情報をご共有できます。 想定する読者 現在WEBエンジニアとして活躍されている方や、WEBエンジニアを目指し自己研鑽などをされている方を想定しています。 マイナビなどWEB事業会社に興味はあるけど、何から始めるべきかわからない… 今の実力でどういう会社に転職できるかわからない… 転職は考えていないけど、今の環境が今後に活きるのかわからない… 今後のために情報収集したいという方に、少しでも参考になる情報をお渡しできればと思っています。 はじめに WEB事業会社は、面接の数日前に対策をして合格するほど簡単な会社ではないです。普段の業務から意識や行動を変えていく必要があると捉えているため、1人でも多くのエンジニアの方に、WEB事業会社で活躍するエンジニアになるために、「持つべき意識」「取るべき行動」をお伝えできればと思っております。 ※本記事では技術的な部分ではなく、スタンスやマインド部分に注目し、まとめています。 本記事のまとめ（特徴5選） プロダクト志向の重要性 手段とやりがいの理解 3方向の視点（自分、仲間、ユーザー） 自責 プロダクトは仮説の集合体（課題定義力と課題解決力） まずは転職市場を理解するために、よくある転職理由から見ていきます 人それぞれ、理由は多くありますが、まとめると下記の理由が多いです。 スキル（キャリア）アップ 現在の仕事の成長機会が限られている 人間関係のストレスや職場環境の問題 現職の待遇（給与、福利厚生）に不満がある ワークライフバランスの改善を希望 業界や職種の変化に興味を持った 企業の将来性に不安を感じる 自分のスキルや専門知識をより活かせる仕事を探している 長期的な目標と現職のミスマッチ 地理的な要因や家族の事情による転居 よく聞く内容ですね。 この理由だけでWEB企業で合格が出るか、お見送りになるか、が判断されるわけではないです。ここから一歩踏み込んだところに、重要な理由が隠れています。 【例】スキル（キャリア）アップしたいという求職者 ⇒ なぜスキル（キャリア）アップしたいのか？ 【求職者A】 今の環境では古い技術を用いた開発しかできず、新しい言語を用いた開発にチャレンジすることが難しい状況です。環境を変え、新しい言語を用いた開発環境に身を置きスキルアップしていきたい etc… 【求職者B】 自身が扱える技術の幅を広げ、よりユーザーに価値を届けるための技術の選択肢を増やしていきたい。新しい技術が必ずしも正解ではないが、新しい技術を学び理解しておくことで、今後プロダクトの成長や、自組織の効率化に貢献できる気付きにつながるかもしれない etc… WEB事業会社で活躍する人（WEB事業会社で内定が出る人）かどうか、求職者AとBの違い、面接官がみているポイントを整理していきます。 プロダクト志向と技術志向 プロダクト志向とは？ 他者(ユーザー)視点で物事を考えており、技術を手段として利用し「何をつくればユーザーに価値を届けられるか」「なぜこの技術を選択したのか」を考えられることが多く、プロダクト重視の志向性 技術志向とは？ 自分視点で物事を考えており、技術力が上がれば良いという考えで「何をつくればユーザーに価値を届けられるか」「なぜこの技術を選択したのか」を考えられないことが多く、技術重視の志向性 志向性を理解すること エンジニアとして、どちらが良いか悪いか、の答えはないです。どちらも良いと思います。ただWEB事業会社を目指すのであれば、「プロダクト志向」を持っていることが重要です。 2つの志向性どちらも持っているエンジニアもいたりしますし、技術志向でもWEB事業会社で活躍されているエンジニアもいたりします。繰り返しになりますが、どちらが良い悪いではなく、エンジニアとしてどうなりたいか、目的や将来の理想像によって異なるものでもあるので、まずこの志向性を理解することが重要です。 手段とやりがい 技術をどう捉えているか？ WEB事業会社のエンジニアの多くは技術を「手段」として捉えていて、WEB事業会社以外のエンジニアは「目的」と捉えていることが多いです。 日本のIT環境がそうさせてしまっている可能性も高いですが、クライアントワークをしている人だと開発環境が限定的であることが多く、とある1つの開発環境に強いエンジニアとしてキャリアを積まれることが多いです。単価も上がり、会社も同等の開発環境の案件を集中させるケースも多いので、異なる開発環境を目指したり、手元のスキルを向上させることに意識が向いてしまうのは仕方がないことなのかもしれません。 エンジニアとして感じるやりがいにも違いがある WEB事業会社のエンジニアがユーザー貢献、サービスグロースなどをやりがいに感じている一方で、WEB事業会社以外で働くエンジニアは「技術向上」がやりがいになっていることが多いと感じます。※それが決して悪いわけではなく、希望する環境、将来の理想像につなげればいいだけです。 「なんでこの会社がこのサービスを作ろうとしているのか気になる」 「なんでこの設計になったのか気になる、他にも選択肢はあったのに、なんでだろう」 「リリースしたあと、そのサービスやシステムがどう使われているのか気になる」 といった理由から、WEB事業会社を志望されるエンジニアも多くいます。やりがいが「技術向上」以外に向いていると、上記のような発想になることが多いと感じています。 3方向の視点（自分、仲間、ユーザー） 自分視点、仲間視点、ユーザー視点、と3つに分けていますがWEB事業会社にいるエンジニアはこの3つの視点を持ち、うまく使いこなしていることが多いと感じます。よく利己的、利他的、とも表現されたりしますが… 自分視点　　＝利己的 仲間視点　　＝利他的 ユーザー視点＝利他的 と捉えるとわかりやすいかもしれません。 WEB事業会社のエンジニアは自分視点（利己的）も持っていますが、仲間視点（利他的）、ユーザー視点（利他的）を存分に活用し、仕事していることが多いです。※自分視点は言葉の通りですので、割愛します。 仲間視点とは？ この部分のコード、このままだとわかりづらいからもっとシンプルにしよう、ここに躓くかもしれないからコメント残しておこう、など、将来自分以外の、ただ自分に関係している仲間が仕事をするときのことを考えられる視点。 ユーザー視点とは？ このプロダクトにどんな機能を追加したら、よりユーザーは使いやすいと思ってくれるか、ユーザーの利便性が上がるか、またはこのプロダクトからどの機能を排除すれば、よりシンプルにユーザーにとってわかりやすく使ってもらえるか、を考えられる視点。 ※普段はユーザー視点、仲間視点を合わせて他者視点と言ったりしていますが、ここではわかりやすく分けてます。あまり普段の会話の中で「仲間視点」は使わないですが、理解を深めるために記載しています。 自責か他責か 自責：自分で自分のあやまちを責めること 他責：自分以外の人や状況に責任があると考えること ここに関しては、エンジニアだけでなく全社会人共通して言えることだと思いますが、他責よりも自責で物事を捉えられる人であることが重要です。過剰過ぎる自責は不要ですが、ひとつひとつの行動に対し、成功も失敗も振り返りが大事です。 他責の人は自分は悪くないと思い考え方や行動を変えようとしない（＝成長がない） 自責の人はどんなことからも改善点を見付け、考え方や行動を変えようとする（＝成長がある） ので、ここは受ける企業がどこであろうが、意識すべきポイントになります。 （余談）プロダクトは仮説の集合体 有名な話ですが、「プロダクトは仮説の集合体」と言われています。またWEB事業会社では、仮説志向も重要視されていて… 課題定義力 × 課題解決力 この2つの能力が備わっていることも重要だと言われています。ここは長くなってしまうので、ご面談の機会をいただけた際にお伝えします。 最後に WEB企業への入社難易度は高いため、転職を考え始めた前後数ヶ月だけ頑張ってもあまり意味がありません。普段の生活から変えていく必要があります。 マイナビ含め、将来WEB事業会社で働いていくために今すべきことが知りたい 今の自分でWEB事業会社に受かるのか、受からないなら何が足りないのか、 など、気になる方はぜひお問い合わせください。 https://mynavi-agent.jp ※私の思いとしては、1人でも多くのエンジニアがWEB事業会社で活躍する世界をつくることです。面接対策をして、その時だけ良く見えるようにして、WEB企業に入れるエンジニアを増やそうとは考えていないです。ので、転職すべきではない方に求人紹介はいたしません。

はじめに こんにちは! 株式会社マイナビで内製開発をしているA.Kです！ アメリカのラスベガスで開催された AWS re:Invent2023 に参加してきました 今回はre:Inventで開催されていたExpoに行ってきましたのでそのことについて書こうと思います Expoとは 世界各国の企業のサービスの展示会場です 各社がブースをもっていてサービスの紹介をしていたり質問をうけつけたりしています 主に5つのエリアがありました infrastructure Solutions Zone Data Zone Security Zone Developer Solutions Zone AWS for Industries Pavilion 会場はどんな感じ? 会場自体は初日の夕方からWelcome receptionという形でオープンされます オープン初日は入り口前で多くの人が待っていました オープン初日の様子 それ以降は朝１０時ごろにオープンしていました 中に入るとこんな感じで各企業がブースを開いています 各企業のブースではこんな感じでサービスの紹介をしたり質問をうけつけたりしています それ以外にもイベントを開催したりセッションが開かれたりしています 企業のブースによってはレースのようなアクティビティが開かれたりしています こういったブースも数多くありました 企業のブース以外は下記のようなものがありました AWS資格の学習用ブース Jamのブース Gameday用のブース 会場にはドリンクや軽食が置かれており食べたり飲んだりしながらブースを回っている人が多くいました 夕方になるとアルコールの提供もされます 企業ブースではSwagを配っておりそれを目的にExpoを回るひとも多くいるみたいです 今回自分がもらったSwagはこんな感じです(Expo以外もあります) 個人的にDockerのマウスパッドはうれしかったです まわってみた企業ブース Expoは歩き回ったりアクティビティに参加するだけでも面白いのですが現地で企業の人から直接お話を聞けるのもre:Inventに参加する醍醐味の一つです せっかくなのでいくつかまわってみました どの企業もブースには多くの人がいて話し合いが行われています 自分は普段はWebアプリの開発をおこなっているのでDeveloperエリアを主にまわっていました Postman PostmanはなじみのあるサービスでしたがPostman Flowsの紹介をしていたので話を聞いてみました Postman Flowsはこんな感じでAPIを複数組み合わせて作るワークフローを視覚化された形で作成できます シナリオベースのテストをおこないたいとき活用できそうです ビジュアライズされてることでワークフローがわかりやすく開発効率が上がるだけでなく人に説明するときも便利です デフォルトではオフらしいので各自でオンにする必要があります 参考記事 Postman Flowsとは Postman Flows ドキュメント LaunchDarkly feature flagを利用して本番コードを管理するサービスになります feature flagとはコードにfeature flagと呼ばれるフラグを埋め込みその真偽値で表示の有無を変えたり特定のユーザー郡に対しての限定リリースに対応したりします launchDarkly上でフラグを作成しsdkを通じてそのフラグの真偽値を取得しコード上で利用できます その値はGUI上で切り替えることができます 簡単にユーザーに対しての表示を切り替えることができるのでABテストなどのユースケースで効きそうです 参考記事 LaunchDarklyとは LaunchDarkly ドキュメント rootly 障害発生時のアラートに関連したサービスになります 障害が発生すると専用のチャンネルが作成されzoomのリンクやJiraのチケットが作成されます Slack上でアサインなども可能です 会場では利用方法などをデモなども交えて見せてもらいました slack上でほとんど作業がおこなえるので作業効率が上がりそうです 参考記事 rootlyとは Pinecone ベクトルデータベースのサービスです 機械学習などでは文章や画像などのデータをベクトルに変換したデータを取り扱うためのデータベースをベクトルデータベースといいます このデータベースを用いた検索では、ユーザーの意図なども加味した検索だったりマルチモーダル検索などがあります ExpoではPineconeの無料枠のチケットをもらうことができました こういったのもExpoならではです 参考記事 Pineconeとは その他 それ以外には有名なサービスの企業も多くありいくつかまわりました github redis docker Vercel etc.. おわりに 今回はExpoについてまとめました re:Inventでセッションに参加するのも良い経験となりますがExpoで実際に現地でサービスなどに触らせもらったりすることもre:Inventならではの経験となりました Expoを回っていると自分の知らない普段の開発経験を向上させるサービスが数多くありました オンラインでもそういったサービスを得ることはできますが素通りしてしまいがちです Expoではオンラインとは違いその場でどんなサービスやどんな特徴があるのかをデモや説明ともに知ることができるので得るものが多くありました 読んでいただきありがとうございます

4年ぶりに対面で行われ、約3000人ものエンジニアが集結した Developers Summit 2024 にて、「マイナビの全社データ基盤のモダナイズ」をテーマに弊社社員が登壇をしてきました！ 講演内容 マイナビ、そして私たちが所属するデジタルテクノロジー戦略本部の説明をした後、講演テーマでもある『全社データ基盤のモダナイズ』についてお話しさせていただきました。 オンプレで構築していたデータ基盤をどのようにしてAWSにクラウドシフトしたのか、導入前後の変化や技術選定のポイント、反省点について等、講演内容は登壇資料にもまとめておりますので、ぜひご確認いただければと思います！ 講演資料 画像をクリックしてご覧ください！ 登壇後記 マイナビではデータ民主化について取り組んでいます。 今回はそのデータ民主化のために必要不可欠なデータ基盤のモダナイズについてお話させていただきました。 オンプレ更改が起因ではありましたが、TCO削減や働くエンジニアの負荷軽減も含めた技術刷新ができ、そのおかげで新たなことに挑戦しやすくなりました。 今まで運用・保守に割かれていた時間が浮いた分、新しいことに取り組めています。 限られた時間で伝えきれないことも多かったですが、マイナビの取り組みが多くの方の参考になれば嬉しいです。 発表の中でお話できなかったところで少し技術的なお話をしますと、Snowflake接続のところでちょっと苦労した話があります。 より安全な接続をということでIP制限をしているのですが、PC接続では環境変数で適用するわけにもいかず、各ツール毎にbatを作ってプロキシを通すような対応をしました。 また、SnowflakeはIdPにAzureADを利用していたのですが、Power BIからの接続で外部OAuthセキュリティ結合が必要だったのですがここでも苦労しました。 ALTER SECURITY INTEGRATIONでexternal_oauth_any_role_mode = ‘ENABLE’を設定し デフォルトロールを設定しておかないといけないというのは盲点でしたのでPower BIからSnowflake接続を検討されている方のために記述を残しておきたいと思います。 最後に、マイナビではエンジニアを募集しておりますので、ご興味がある方はぜひお応募いただけますと幸いです！

はじめに サイトのローンチ時にサクッと負荷テストを行いたいといった依頼が多々あるのですが、0から負荷テストの環境構築をしたり、テスト会社へ依頼をすると時間や費用の負担が多くなります… AWSが提供している負荷テストソリューション「Distributed Load Testing on AWS」ではサクッと負荷テストの環境構築ができるとのことで、実際に試してみました。 Distributed Load Testing on AWS について AWS での分散負荷テストは、大規模な負荷時のソフトウェアアプリケーションテストを自動化して、リリース前に>潜在的な性能上の問題を特定するのに役立ちます。このソリューションは、一定のペースでトランザクションレコードを生成する数多くの接続ユーザーを作成およびシミュレートします。サーバーをプロビジョニングする必要はありません。また、このソリューションでは、複数の AWS リージョンにまたがってテストを実行することができます。 AWS公式ドキュメント： https://aws.amazon.com/jp/solutions/implementations/distributed-load-testing-on-aws/ 構成 上記は公式ドキュメントより引用したDistributed Load Testing全体の構成図です。 frontendはシナリオを作成するWebコンソール、backend/regionのリソースは負荷テストを実行するAPIと実行環境になっています。 公式ドキュメントページ内にCloudFormationテンプレートのソースコードのリンクもあるので、ソースコードをカスタマイズして実行環境の構成を変更することも可能です。 ※実際にDistributed Load Testing を利用してテストを実施した案件ではIP制限をしていたため、NAT Gatewayを実行環境の構成に追加し、アクセス元IPの固定化を行いました。 特徴 AWS Fargateコンテナを使用した負荷テスト実行環境 JMeterスクリプトを作成することで、アプリケーションテストのカスタマイズが可能 スケジュール機能を利用した負荷テストの自動化が可能 Web コンソールからテストデータのライブ表示が可能 コスト Distributed Load Testingで使用するAWSサービスの利用料が掛かります。 負荷テストの要件によりコストは変動しますが、サーバーレス構成のため比較的安価かと思います。 コストに関する詳しいドキュメントは こちら 今回のゴール 「Distributed Load Testing on AWS」の実行環境構築および、負荷テストの実施 ※本記事での負荷テスト対象は、CloudFront+S3で作成した検証用の静的ページとします Distributed Load Testingのデプロイ 公式ドキュメント の「AWSコンソールで起動する」ボタンを押下します。 CloudFormationのコンソール画面に遷移するため、画面に沿って処理を進めます。 テンプレートソースが指定されていることを確認して「次へ」を押下 スタック名、コンソールにアクセスするユーザー名、メールアドレスが必須項目のため、入力して「次へ」を押下 デプロイするVPCを変更したい場合やCIDR Blockを変更したい場合は、その他の項目も入力してください。 スタックオプションの設定は特に変更をせず「次へ」を押下 確認画面ではThe following resource(s) require capabilities: [AWS::IAM::Role]のチェックボックスにチェックを入れて「送信」を押下し、デプロイ完了を待ちます。 10分前後でデプロイが完了しました！デプロイ時に入力したメールアドレスにWebコンソールのログイン情報が届いているので、コンソールにログインします。 メール コンソールログイン画面 ダッシュボード Distributed Load Testingが利用できるようになりました！ テストシナリオの作成・実行 コンソール画面上部の「CREATE TEST」を押下し、シナリオ作成画面に遷移します。 以下のように負荷テストの設定を行っていきます。 General Settings ここでは同時接続数やテスト時間など、負荷テストに関する一般的な設定をしていきます。 Task CountとConcurrencyの積が同時接続数の最大値となるため、今回は同時接続数最大値を5×200=1000に設定しています。 Ramp Upは5分、Hold Forは10分にし、5分かけて同時接続数の最大値まで到達させその状態を10分維持するように設定しました。 項目 説明 Task Count 起動するコンテナ数 Concurrency タスク当たりの同時接続数（推奨上限は200） Ramp Up 同時接続数に達するまでの時間 Hold For 同時接続数の保持時間 Run Now 予約実行をしない場合はこちらを選択 Run on Schedule テストのスケジュール設定 Scenario テストのシナリオ設定を行います。 今回はTopページへ負荷をかけるシンプルなテストのためSingle HTTP Endpointを選択し、エンドポイントを入力しました。 項目 説明 Test Type（Single HTTP Endpoint） 特定ページに負荷をかけるようなシンプルなテストであればこちらを選択 Test Type（JMeter） 複雑なシナリオを設定する場合はこちらを選択（別途JMeterのシナリオ作成が必要） シナリオを入力し画面右下の「RUN NOW」を押下するとテストが実行され、詳細画面に切り替わります。実行ステータスがRUNNINGとなっているため、このまま完了を待ちます。 ステータスがCOMPLETEとなれば、負荷テストは完了です！ テスト結果 テストが完了するとSUMMARYが表示され、レスポンスタイム、レイテンシー、コネクションタイムの平均や、カウント数（トータル・成功・失敗）を確認できます。 より詳細の情報を確認したい場合は、CloudWatch Logsなどで確認可能です。 まとめ 実際に使ってみての所感は下記の通りです。とりあえず特定ページの負荷耐性だけ確認しておきたい！という場合には丁度良いのではないかなと感じました。 メリット 環境構築がとにかく簡単 Webコンソールの操作も分かりやすい 特定ページに負荷をかけるだけといった単純なシナリオであれば手軽に実施できる デメリット 複雑なシナリオを作成する場合は、JMeterでのシナリオ作成が必要 同時接続数最大値に達するまでのカウントもSUMMARYに含まれているため、整合性に欠ける？ 長時間に渡って高負荷をかける場合は、コストに注意 Distributed Load Testingのリソースだけでなく、テストを行うサイトの側の通信量（見落としがち）の考慮も必要です

はじめに 皆さん、初めまして！ WEBアプリケーション開発系のエンジニアとして採用された、2024年新卒入社のK.Iです。 私は学生時代は文系の出身でプログラミングとは無縁の学生生活でした。 そこから、とあることをきっかけにプログラミングやアプリ開発に興味を持ち、学習を続けてきた結果、ご縁あってマイナビに入社しました。 今回は、そんな僕が学生時代にWEB系のエンジニアとしてキャリアをスタートさせるために学んできたことを僭越ながら皆さんに共有させていただこうと思います。 現在WEB系エンジニアとしての就職を考えている方や、これからエンジニアを目指していく学生の方にとって少しでもヒントとなるように、なるべく再現性の高い内容に絞ってお伝えしていくので是非最後まで目を通していただけますと幸いです。 （※注意） 今回紹介する内容はあくまで個人の経験による内容を多く含むものとなるので、必ずしもすべての人に等しくあてはまる内容とは限らないということをあらかじご理解いただきたいと思います。 一個人がエンジニアになるまでにどんなことを考え、何を実践してきたのかということを事実としてとらえていただけると記事の意図が伝わるかと思います。 学習のゴールを設定する 学んだことを紹介する前に、私がエンジニアとして就職を検討する際に行った「ゴール設定」をお伝えさせていただきます。 私がエンジニアとして就職するにあたって、まずはじめに行ったこととしては、 「技術をどこまで学習したら就職活動を開始するか」 ということを先に定めるようにしました。 目的にもよるかと思いますが、私の場合、WEB系エンジニアとしての就職がメインだったので下記のようなゴール設定で学習を本格的にスタートさせました。 「企業に見せる成果物（WEBアプリケーション）を1つ作成する」 私の場合、文系でしたので企業にとっては「プログラミングやWEBに関して何の経験もない人」と判断されることは当然の事実としてありました。 そのため、 ある程度、技術的な興味関心がある この業界で長く続けていける素養がある ことを示すために上記のような目標を設定しました。 学んできたこと ここから本題の私がWEB系エンジニアとして内定をもらうまでに学んできた技術的な内容に関してお伝えさせていただきます。 先に結論から述べさせていただくと、、 コンピュータサイエンス Linux HTML, CSS JavaScript Ruby RDB, SQL Git, Github Ruby on Rails 上記の順番で学習を継続してきました。 全体として、約3か月程度の学習期間を設けました。 そののちに、就職活動をスタートさせ無事、エンジニアとして就職することができました。 ここからは、上記の内容に関して実際にどんなことを学んできたかを深堀りしていきたいと思います。 コンピュータサイエンス はじめに、コンピュータサイエンスの基礎的な内容に関して学び始めました。 現在学生の方ですでに情報の分野を専攻しているorいた方は、このパートをスキップしてしまったも問題ないかもしれません。 私の場合、情報専攻ではなかったので下記のような内容を中心にコンピュータの基礎的な内容を一通り学びました。 n進数 デジタルデータ（ビットとバイトなど） CPU・メモリ ハードウェア・ソフトウェア データベース ネットワーク セキュリティ 実際に利用した参考文献も記載しておきます。 エンジニアとして実務にかかわる上で、上記のような内容を知っているのといないのでは、理解に差が生まれるので情報系以外の方は改めて学習しておくことをお勧めします。 参考 基本情報技術者試験 対策用書籍 Linux Linuxは、Windows, Macと同様にOSの一種で、アプリケーションのサーバーのOSとして利用されることが多いので、エンジニアとして業務を行っていく上では必須の概念になります。 主にCLI（Command Line Interface）でのコマンド操作を扱うことになるため、Linuxの基礎的な概念と併せてよくつかわれる基本コマンドを押さえておくと、今後の作業がスムーズになります。 参考 https://linuc.org/textbooks/linux/ HTML, CSS HTMLはWEBページを表示するための骨組みのようなもので、CSSはHTMLに色を付けたり大きさを変えたり等の装飾を加えるための技術になります。 HTML, CSSの学習を通じて、WEBサイトが表示される基本的な仕組みを学習しました。 基礎的な内容に関しては、オンラインの学習教材（ Progate , ドットインストール ）を使って一通り学習し、その後は他のWEBサイトを模写する形でアウトプットを行いました。 模写に使用したおすすめサイト： https://code-jump.com/ 参考 https://prog-8.com/courses/html https://dotinstall.com/lessons/basic_html_tags_v3 JavaScript JavaScriptはWEBアプリケーション開発でよく用いられるプログラミング言語で、フロントエンドと呼ばれるユーザーの目に触れる部分の仕組みを実装することができます。 HTML, CSS同様、基礎的なインプットに関してはオンラインの学習教材を使用しました。 アウトプットとして、先述のHTML, CSSで模写したサイトに動き（ユーザーのアクションに対するイベント処理等）をつけながら改良したり、アルゴリズムの問題をJSを使って解きながら文法を身に着けていきました。 参考 https://prog-8.com/courses/es6 https://dotinstall.com/lessons/basic_javascript_v6 Ruby RubyはWEBアプリケーションのバックエンドと呼ばれる裏側の仕組みを構築できるバックエンド言語になります。 フロントエンドの言語であるJavaScriptと合わせて、一連のWEBアプリケーションを構築するために、バックエンド言語のRubyを学習しました。 Rubyを選んだ理由としては、 文法が簡単で、初学者でも学びやすいため。 日本語のリファレンス等も豊富で調べやすいため。（日本人が開発した言語のため？） フレームワークやライブラリが豊富でWEBアプリケーションを開発しやすいため。 また、日本の企業では比較的Ruby, Railsを採用している企業が多く、求人数も多かったたことも選択した理由の一つです。 ここでも、オンラインの学習教材メインで使用して学習を進めました。 アウトプットに関しては後述のRuby on Railsでまとめて行いました。 参考 https://prog-8.com/courses/ruby https://dotinstall.com/lessons/basic_ruby_grammar RDB, SQL 続いて、データベースの学習です。 RDB（Relational Database）は現在のWEBアプリケーション開発で主流のデータベースになります。 主な特徴として、テーブルと呼ばれるデータをExcelの表のような形式で管理し、それぞれのテーブル間の関係性を定義していきます。 また、RDBに格納されたデータに対して問い合わせを行い、データの取得・削除・追加・更新等の操作を行うための命令を記述する言語がSQL（Structured Query Language）になります。 いずれもWEBアプリケーションのバックエンドを実装する上では必須の知識となります。 なお、RDBを管理する仕組みにはいくつか種類があります。 MySQL PostgreSQL OracleSQL 主流かつ代表的なものとしてはMySQL, PostgreSQLになりますので、その辺りを学習しておけば問題ないかと思います。 学習方法に関しては、私の場合、SQLは書籍を使用し、RDBに関してはオンライン学習教材使用して学習を行いました。 RDB(RDBMS)の種類や役割、基本的なSQL文の文法が理解できていれば問題ないかと思います。 参考 RDB SQLおすすめ書籍 Git, Github Gitはプログラミングコードの変更履歴を管理するためのツールになります。 実務では複数人のチーム単位で行うことが一般的なのでその際に、ファイルの変更や最新版のファイルの管理等を円滑に行うためにGitがほぼ確実に使われます。 まずは Github のアカウントを作成し、そこに学習で使用したソースコードを挙げておくようにすると、Gitの練習になるのでお勧めです。 Git, Githubの学習に関しては実際の動きを確認できる方がよりイメージしやすいかと思いますので、動画で行うのがおすすめです。（参考資料の中にも動画教材を挙げています。） ただし、Gitを学習する際の注意点として、動画等でインプットしたら必ずアプトプットまでセットで行うことをお勧めします。 概念・ルールを理解することより「操作できる」ことが重要になるため、教材で学んだらそれをご自身の環境でも実践してみる形で並行して進めていくことをお勧めします。 参考 YouTube Udemy Ruby on Rails Ruby on RailsはWEBアプリケーションの開発を効率的に行えるようにするためのRuby言語のフレームワークになります。 要するに、Rubyでアプリ開発する際に必要となる機能をはじめから準備してくれている便利ツールです。 学習の流れとしては、、 Railsで開発する全体像を把握する チュートリアル等を使用して実践する になります。 1の全体像に関してはオンライン学習教材の Progate の講座等を活用して、Railsがどんなもので、どんな流れで開発してくのかをざっくり理解するとよいでしょう。 次のステップとして、Railsで記述するコードの内容やGemの使い方等を詳細に理解しながら、チュートリアルを進めていくことをお勧めします。 環境構築でいろいろなソフトをインストールしたりバージョンを合わせたりする必要があり、思った以上に苦労した経験があるので、一つ一つの手順を把握しつつ進めることをお勧めします。 まずは、見よう見まねで手順通りに動かして、徐々に理解できて来たら自分なりに改良しながら理解を深めるような流れで行うと良いかと思います。 Railsを学ぶ上での代表的な教材として Railsチュートリアル があります。 こちらの内容が大まかに理解できれば成果物のアプリケーションを作成する上で困ることはほとんどありません。 Railsの学習まで一通り終えることができたら、チュートリアルで完成したアプリの延長線上で独自のテーマを設定して自作のアプリケーションの作成に取り掛かりましょう。 テーマは～クローン等ありきたりなものではなく、身の回りで感じた悩み等を解決できるような独創性の感じられるテーマで作成しましょう。 ちなみに筆者は、コロナ禍で自宅にいる時間に料理を通じてつながりを増やしたいという発想から、SNS×レシピサイトのようなテーマで作成しました。（なぜこういう発想に至ったのかに関してはあまり覚えていません（笑）） 参考 Progate Railsチュートリアル 学習のポイント 最後に学習のポイントについていくつかお伝えしようと思います。 5, 6割理解できたら進める 内容が理解できず何度も何度も反復してしまうという方も中にはいるかもしれません。 私自身も文系で何の知識もないところからのスタートだったので、非常に気持ちは理解できますが、学習の目的は、「成果物を完成させること」なので、内容をはじめのうちから内容を100%近く完璧に理解しておく必要はありません。 実践していく中で理解できてくることも多いと思いますし、そこに何時間もとらわれてしまうのは非効率になってしまっていることの方が多いと思います。 なので、「やった内容がざっくり頭に残っている」ぐらいの状態でさっさと先に進むようにすると挫折することなくスムーズに基礎学習を終えることができます。 アウトプットを重視する 経験上、書籍や教材でインプットしているだけでは、用語や一定の知識は多少身に付きますが本質的な理解につながらず、いつまでたってもプログラミングができるようにはならないと思います。 そのため、インプットを行ったら併せて必ずアプトプットも一緒にするべきだと思います。 割合としては 7:3 (アウトプット：インプット） ぐらいがちょうどよいかと思います。 先述の「5, 6割理解できたら進める」の話ともつながりますが、半分以上内容を理解できたらさっさと実践してみるとより効率的に身に着けられると思います。 何よりも、そっちの方が楽しいですよね！ ググりまくる エンジニアは実務において、実装方法に関して調べる場面が多々あります。 特に実装したことのない機能や、新しい技術を使用して実装するときなどはその割合が多くなります。 初学者であれば、なおさらわからないことや知らない知識・用語が多く出てくるかと思います。 ただ、安心してください。 そういった悩みはほとんど全てどこかの誰かしらが解消してくれています。 世界中の誰も遭遇したことのない目新しいエラーを引き当てる方が難しくなっています。 そのため、現在であればChat GPTなどの生成AI等の力も借りられるので、それらも活用しつつ自力で解決して、自力で実装する力をつけることがエンジニアとしてジョインしてからの苦労を減らすことにもつながると思います。 なので、わからなくてもとにかくググりまくって解決する癖をつけておくとよいかと思います。 投稿 文系・未経験からWEB系エンジニアになるために学んできたこと は マイナビエンジニアブログ に最初に表示されました。

はじめに 皆さん、こんにちは！デジ戦のT.Tです。 就職に伴い、上京する方はとても多いと思います。土地勘が無い中での住まい探しは不安だと思いますし、私も実際そうでした。 そこで今回は、私や同期の家探し状況や入社後の生活をお伝えし、少しでも参考にしていただけたらと思います。 経歴 静岡県出身。2024年よりUI/UXデザイナーとして入社。 大学では美術系の学部に在籍し、その中でもUI/UXデザインを中心に広くデザインについて学ぶ。 入社に伴い勤務地である新宿から電車で30分ほどの埼玉県に転居。同時に初めての一人暮らしを始める。 部屋選びで注意することってある？ 私の場合は周辺環境を特に重視していました。中でも重視していたのはこの３つです。 虫の出にくさ 2階以上 日当たりの良さ（北向きは絶対に避けていました。） 付近に公園などの自然が無いところ 徒歩圏内にスーパーがあるかどうか 駅からの近さ 最寄駅から徒歩15分圏内で探していました。 初めての一人暮らしだったため、部屋選びに関する知識は全くありませんでした。大学時代から一人暮らしをしている友人から助言をもらい、確認すべき項目をまとめたチェックリストを作成してから不動産屋に向かった記憶があります。 人気のエリアってあるの？ 基本的には東京在住の方が多い印象です。 路線でいうと、私の体感ですが小田急線沿いと埼京線沿いが特に多いイメージです。小田急線沿いでいうと、特に登戸にはなぜか関西出身の同期が集中しています。埼京線沿いも多いですが、こちらは結構最寄り駅はばらけている印象でした。 他にも埼玉県や神奈川県、千葉県といった県外から通われている方もいらっしゃいます。県外でいうと埼玉県が特に多い印象です。私も埼玉県から出社しています！ 家賃って実際どれくらい？ 家賃は、管理費込みで9万円ほどです。同期にも聞いてみたところ、6万円～9万円台と意外と幅広い結果が得られました。 私は部屋探しにあたってかなりこだわり（虫の出にくさや水回りなど・・・）があったためこの価格でしたが、選り好みしなければある程度家賃を抑えることも可能だと思います。 部屋の広さ リビングが6畳半くらいです。同期にも聞いてみたところ、大体5.5~7畳台くらいが多い印象でした。 ベッド、デスク、棚を置くとある程度面積は埋まってしまいますが、一人で住むことや掃除のしやすさなどを考えると個人的には丁度良い広さだと感じています。決して広いとは言えないですが、この「私の城」感をとても気に入っています！ レイアウト 1K、風呂・トイレ別の独立洗面台付きの部屋です。 部屋決めにあたって風呂・トイレ別と独立洗面台だけは絶対に譲れないポイントだったため、とても気に入っています。 ドアや窓の配置や部屋自体の形は家具のレイアウトやその後の住みやすさにも大きく関わってくるので、間取り図や内見でチェックしてみてください！ 定時後の生活 基本そのまま家に直帰していますが、週１，2回ほど同期と夜ご飯を食べに行きます。私が勤務している新宿のミライナタワーオフィスでは付近に美味しいご飯屋さんや有名チェーン店が多く、同期のおすすめのお店に連れて行ってもらうことが多いです。 同期として研修やインターンシップなどの話もしますが、同世代の友達としての会話もできる貴重な機会だと思っています。 休日の過ごし方 休日は、沢山寝たり平日出来なかった家事をやったりと、ゆっくりとした時間を過ごしています。 同期の方々と遊びに行くことも多いです。最近は一緒に服を買ったり美味しいものを食べに行ったりしました。 新社会人と初めての一人暮らし、不安はあった？ 私は実家から大学に通っていたため、社会人になると共に一人暮らしをスタートさせました。 家事にかなり苦手意識があり、一人暮らしが決まった段階からかなり不安を感じていたのを覚えています。 そんな私でも、今のところ生活に困らない程度にしっかり一人暮らしできていると思います！ 「この時間に洗濯だけでもやろう」など最低限のタスクを決めて、自分の余力を見てプラスワンの家事もやる、といった方式で家事をやっています。 また現段階では週1～2回テレワークがあるため、本来通勤に使う時間で家事を片付けたりと時間の活用を工夫しています。 最後に 一人暮らしの醍醐味はなんといってもこの自由さだと思います。 一人暮らしに不安を感じている方もいるかと思いますが、一緒にこの自由を楽しみましょう！

はじめに こんにちは！デジ戦のM.Mです。 今回は、入社後はもちろん、就職活動においても重要な、マイナビで利用できる 「福利厚生」 についてご紹介します。 近年、働く上でワークライフバランス等を意識する人が増えており、「福利厚生」は重要な会社選びの基準となっています。 マイナビでも、社員の働きやすい環境やモチベーションの維持を目的に、様々な福利厚生が用意されています！ この記事では、マイナビにどのような「福利厚生」があるか、会社生活編と私生活編に分けて紹介していきます。 ◆会社生活編 スキルアップ マイナビには様々なスキルアップ制度が用意されています。これらを活用して、効率よく自分の能力を磨きましょう。 IT・ビジネス資格取得支援制度 マイナビの資格支援制度には、 受験料補助型と祝金型 があります。 受験料補助型では合格不合格問わず、資格ごとに 受験料が全額支給 され、祝金型では該当資格については 取得祝金が支給 されます。 書籍購入制度 業務を遂行する上で必要な書籍や定期購読物などを、会社経費で購入することができます。 Udemy 学習プラットフォーム「Udemy」を用いてさまざまなジャンルのスキルを習得することができます。 「Udemy」には プログラミングやAI、データ分析などだけでなく、マーケティングやビジネススキルなどに関する幅広いテーマの動画 が投稿されています。 IT知識だけでなく、新しく社会人になる皆さんにとって役に立つ講座がたくさんあるので、自分が学びたいテーマに合わせてコンテンツを選択し、スキルアップできます！ 健康・ヘルスケア 「マイケアルーム」 マイナビグループ社員向けのマッサージルームです。 オフィス内に設置されており、 格安（45分1,000円ほど） でマッサージを受けることができます。 デスクワークの増える社会人にはマッサージが必須です！ 一般のマッサージ屋さんだと、施術者との相性によって当たりはずれがありますが、マイケアルームでは全員が国家資格を持ったヘルスキーパーのため、安心して施術を受けることができます。 資産形成 マイナビ社員持株会 会員が自分の勤務する会社の株式を取得することを容易にし、中長期的な資産形成を支援する制度です。 積立金以外にも、積立金への奨励金・保有株式に応じた配当金などがあります。 ◆私生活編 福利厚生施設 会社生活も大切ですが、どうせなら私生活も充実させたいですよね…！マイナビには全国各地に保養所や提携ホテルがあります。施設の多くは、家族や友人と利用することができます。 保養所 　中軽井沢・京都・沖縄にそれぞれ保養所があります。 　保養所なので空いていれば好きな時に利用できます。特に週末は大人気で、家族や友人と過ごす方が多いようです。 会員制リゾートホテル 保養所以外にも、マイナビでは会員制リゾートホテルを契約しているため全国の対象施設を格安で利用できます。 箱根や軽井沢、京都などの魅力的なリゾートが多数あります。 マイナビグループ社員本人およびその家族が利用可能です！ 社員優待 福利厚生施設の他にも、社員優待があります！ 健康なお弁当のサブスクを安く利用可能 マイナビ従業員は、冷凍のお弁当を常時60種類以上サブスクで販売しているサービスをお得に利用できます。プロの料理人と管理栄養士が監修している健康なお弁当を、1食500円程度で注文できます！ 1人暮らしを始める方もいると思いますが、社会人1年目は新しい環境にばたばたすることも多く、ご飯を作る余裕のない日もあるかと思います。健康なお弁当はそんな日の心強い味方ですね…！ スポンサーチケットをお得に購入可能 マイナビがスポンサーをしているイベントのチケットを安く購入できることがあります。もちろん、イベントの種類や状況に応じて条件は異なりますが、仕事の息抜きに同期や友人とイベントに参加してみるのもいいですね！ 福利厚生サービスの利用 サービス数100万以上の福利厚生サービスに加入しており、いつでもどこでも何度でも利用することができます。 サービスには、eラーニングの受講、映画館等の割引補助、育児・介護補助等があります。 おわりに 以上のように、マイナビにはお得な福利厚生制度がたくさんあります。 他にも色々な制度がありますので、気になったらぜひマイナビの採用イベントで聞いてみてください！ 閲覧いただきありがとうございました。

はじめに 皆さん、こんにちは。マイナビエンジニアブログ編集チームです。 本年度も4～6月の3か月間で、デジタルテクノロジー戦略本部の新人研修が行われました。 今回は、新卒2名の方に「新人研修で学んだことと今後の抱負」についてインタビューしました！ 新卒研修の概要 概要は以下の記事をご覧ください。 ※昨年度の内容になりますが、概要は今年度とほとんど同じになります。 ###card_post_id=1471### 自己紹介 T.Yさん（システムエンジニア／システムディレクター） 学生時代は「システム理工学部 数理科学科」で、主に数学を学んでいました。また、教職課程も勉強していて、高校数学の教員免許を持っています。大学時代から、「論理的な思考」や「問題解決」、「人の人生に影響を与えるようなこと」に興味がありました。 マイナビであれば、サービスを利用する多くの方の人生に良い影響を与えることができ、これからITに力を入れていくという方針であるというのを就活時に知って、この会社に入社いたしました。 しかし、 IT業界についてはほとんど未経験で、 新たなフィールドに挑戦することに不安であり、緊張していました。 I.Tさん（WEBアプリケーションエンジニア） 東北出身で、大学卒業まで仙台に住んでいました。学生時代は、「工学部 電気電子工学科」に在籍していて電気情報を学んでいました。趣味で iOSアプリやモバイルゲームを開発 していて、プログラミングを使った職業に興味がありました。マイナビは事業会社で事業も幅広く展開しており、IT分野も急成長していて、この環境であればITエンジニアとして成長できると思い、入社を決めました。 しかし、Webアプリ開発の経験は マイナビハッカソンインターンシップ に参加したのがほとんどで、今までとは違った開発言語やフレームワークを使うと聞いていたので自分の経験を活かせるか不安でした。 新人研修で学び得たことはありますか？ T.Yさん（システムエンジニア／システムディレクター） 私は研修を通して、ITに関する基礎的な知識を得ることができました。HTMLやPythonなどのプログラミング言語の基本から、ソフトウェア開発のプロセス、チームでの働き方など、多くのトピックを学びました。最初は、 ITの知識やコードを書く経験がほとんどなく 、毎日が学び続けるような日々でした。 研修の最後にはチーム開発を行いました。私は研修で得られた知識を活かして、複数の機能を実装できるほどの成長をしました。研修当初は コードがほとんど書けなかった自分が、複数の機能を実装できた時は、 成長を実感することができました。 また、私のチームは全部8チームある内の 技術賞 をいただくことができました。その時の達成感は非常に大きく、チームで一つのことをやり遂げることの良さを学ぶことができました。 I.Tさん（WEBアプリケーションエンジニア） 私は2つあります。 (1)Web開発におけるスキル全般 AWSやデータベースなどのWeb開発におけるスキルをつけることができました。私はプログラミングの経験はありましたが、研修前まではWeb開発に関する知識はほとんどない状態でした。研修にあったAWS研修ではコンソール画面を自分で操作して、EC2サーバーの作成とセットアップを行いました。アドレスを自分のスマホに入力して、作ったサイトの画面が閲覧できた時にはWebサイトはこうやって作ることができると知れて感動しました。 　またデータベースに関しても全く知らない状態でしたが、基本的な文法からテーブルの結合・設計まで学びました。研修ではSQLに関する問題集が用意されていて、コードを書きながら学習するので、まるでゲームをしているような感覚で取り組むことができました。 (2)コミュニケーションスキル 研修にはグループワークや発表する機会が多くあり、人に伝えたいことを伝えられるコミュニケーション力をつけることができました。大学時代にはほとんど個人開発しかしていなかったので、チーム開発でのコミュニケーションや自分の考えを人前でプレゼンしたりすることがとても不安でした。研修にはチーム開発や、同期の前でプレゼンする「3分間プレゼン」など多くのコミュニケーション力をつけるための機会が用意されていました。私は他の人のプレゼンでよかったところを真似してみたり、Udemyという動画学習サービスや社内で用意されているfilerという本の要約が掲載されているサービスを使ってプレゼンに関するコツを取り入れることで、コミュニケーションに対する苦手意識を少し克服することができました。 研修を振り返って、楽しかったことはありますか？ T.Yさん（システムエンジニア／システムディレクター） 主に2つあります。 (1)研修を通して知識が身に付いていき、機能を実装できたこと 前述したように、研修当初はプログラミングにほとんど触ってきませんでした。しかし、研修終盤には複数の機能を実装できるほどの成長して、その結果チームメンバーから感謝されました。その時は非常に嬉しく、自分が他人に対して良い影響を与えることの楽しさに気づくことができました。 (2)与えられた課題をチームで解決できたことです。 1人では解決できないような内容でも、複数人で協力し合いながら作業を進めていき、無事解決できた時は今まで経験のない達成感と楽しさを感じることができました。チーム活動を通して、同期との仲も深めることができ、その点も嬉しく思えた点です。（そのようなチームメンバーで行く飲み会は最高です！） I.Tさん（WEBアプリケーションエンジニア） 私も2つあります。 (1)Webサイトの開発と発表会 研修では学んだ技術を使って自由に開発する時間があり、その中で分からなかった部分を突き詰めたり、プログラミング経験者同士で作成したものを共有するのが楽しかったです。私以外にも経験者は多くいて、ToDoリストやクイズ、チャットアプリなどいろんなものを作っている人がいて面白かったです。私は簡単なブログアプリを作りました。 (2)自分の名刺をデザインしたこと 研修にはITに関するものだけではなく、デザインやマーケティングなどを学ぶ研修もあり、特にデザイン研修の自分の名刺を作成して同期同士で見せ合ったのが印象に残っています。私は今までデザインとは無縁の生活をしていたので、デザインの基礎である配色やレイアウトを教わり、これを意識するだけでそれっぽいデザインの名刺が作れたときは嬉しかったです。同期にはデザイナーの方もいて、成果物をみせてもらったときには凄すぎて驚かされました。この研修を通して、その後のプレゼン資料の作成や開発に活かすことができて、研修の恩恵を大いに感じることができました。 ▲私が作ったブログアプリです。 ▲自分でデザインした名刺です。 逆にもっとも大変だったことは？ T.Yさん（システムエンジニア／システムディレクター） ２つあります。 (1)同期の方との差を感じた時 私がIT初学者だったということもありますが、私が問題を1つ解いている間に何問も解いてしまう方もいて、悔しい思いをしました。しかし、同期の方はみんな優しく、質問をしたら必ず教えてくれて、苦戦しながらも理解をして、問題を解けることが多かったです。この時に周りの環境を頼ることの重要性を学びました。 (2)基本情報技術者試験に落ちてしまったこと 社会人になりこれまでと環境が変わったというのと、研修と両立しながらだったので、試験勉強に取り組む時間が作れず、一度挑戦しましたが、落ちてしまいました。周りに受かっている同期がいる中、私は落ちてしまい、非常に悔しい思いをしました。そのため、もう一度勉強をしなおして再受験をしました。その際も研修と勉強の両立が大変でしたが、2回目の挑戦で無事合格をすることができました。隙間時間に（短い時間でも良いので）継続して勉強をすることが重要だと実感しました。 I.Tさん（WEBアプリケーションエンジニア） 研修の最後にはシステムをチームで開発する研修があり、要件定義からプログラミング、テストまでの一連の流れを期間中に開発して納品するのが大変でした。 要件定義では、他のチームから実装してほしい機能をヒアリングし要件定義やシステム設計をしました。依頼される機能は本当に開発期間中に実装できるか、そもそも必要なのか考えながら進めていく必要があり、大変苦労しました。 開発期間ではGitの運用やディレクトリ構成、変数の命名規則などのルールをチームで考えたためチーム開発における手法に関しても学ぶことができました。開発では特に今まで実装したことがないような検索機能や絞り込み、お気に入り機能などをシステム設計で組み込みすぎてしまったため、当初組んでいたスケジュール通りに進まず、胃を痛めてしまったメンバーがいたほど大変でした。 そこで、タスク管理の方法を見直したり、ペアプログラミングを取り入れて開発スピードを上げたり、メンバーの頑張りによって計画していた機能をほぼすべてを実装し納期日に間に合わせることができました。 また最後の成果報告会では納品した成果物が評価され、グランプリをいただくことができました。メンバーに恵まれたことや時間的に実装できるか難しい機能でも、最後まで諦めずに開発を続けることが要因ではないかと思っています。この研修は一番大変でしたが、終えたときの満足感も一番でした。（チームメンバーとの打ち上げも最高に楽しかったです！） ▲最後の開発演習プロジェクトで実装したサイトです。 今後の抱負について教えてください。 T.Yさん（システムエンジニア／システムディレクター） 研修を通して、IT業界の魅力に気づきました。今まではサービスを利用する立場だったのが、今度はサービスを作る立場に変わり、IT技術の利便性をより一層意識するようになりました。現在はまだ配属前で具体的にどのような業務をするかは未定ですが、配属後は自分が携わるサービスを利用するユーザーの方に少しでも便利だなと思ってもらえるようなシステムを作成することが今後の抱負です。 上記の抱負を達成するためには、自己の成長が欠かせないと考えられます。そのため、自宅のPCでも開発環境を整えて、研修を振り返りながら自分でWEBサイトを作成することと基本情報技術者試験よりも難易度の高い資格に挑戦することを抱負達成のための目標として日々成長し続けたいです。マイナビにはこれらの目標を達成するための制度・環境が多くあります。そのような環境に頼りながら、抱負を達成できるよう精進していきたいです。 I.Tさん（WEBアプリケーションエンジニア） この研修を通して学んだことはWebアプリケーション開発の面白さと可能性です。 入社前まではあまりWebアプリケーションを使った開発経験がなかったこともあり、言語やフレームワークの種類の多さ、Webアプリケーションの仕組みについて学ぶことが多くありました。Web業界の進歩はものすごいスピードで進んでいて、私は社会や世界中の人に大きな影響を与えることができる可能性があると思っています。マイナビは事業規模が大きい会社なので開発エンジニアにとって幅広く活躍できる環境のではないかと考えています。 そういった中で日頃から、技術に関する情報収集や開発経験を積み、いち早く戦力になれるように勉強していきたいです。 おわりに 2人にインタビューを行って、研修にて学び得たものはとても大きかったのだと感じました。 デジタルテクノロジー戦略本部の新人研修ではプログラミングの分野だけでなく、チーム開発、デザイン、データサイエンス、マーケティング、さらには3分間プレゼンのようなコミュニケーションスキル向上まで幅広く行っているため、自己成長するには最適な環境ですね。 配属後は、それぞれの部署で大いに活躍してもらいたいなと思います。 最後まで読んでくださり、ありがとうございました。

はじめに 皆さんこんにちは！マイナビのシステムエンジニア、N.S.です。 私は、韓国生まれ韓国育ちの韓国籍エンジニアです。Career in Japan 2022の採用イベントに参加し、マイナビの内定を頂きました。 今は立派なSEとしてマイナビで日々楽しく働いております。 この度は、私がマイナビで働くきっかけになったイベントに運営側として参加させていただきました。熱かった現場の雰囲気を皆様にご共有できればと思っております。 Career in Japan 2024とは 韓国貿易協会、マイナビ国際派就職、マイナビコリアで主催する採用イベントです。毎年韓国ソウルで年二回イベントが開催されています。主に日本企業に就職を希望して、韓国で面接を受けることができる学生さんが参加するイメージです。 現場に行く前に 現地での登壇以外に、私はマイナビITコース採用のオンライン説明会とWebセミナーに先輩社員として参加致しました。オンライン説明会では緊張もしましたが、沢山の方がマイナビの魅力を感じて欲しく、頑張って弊社について伝えました。Webセミナーは、（ここだけの話）実はNG7回で収録しました。熱い思いが伝わってくださっていたら嬉しいです。 イベント当日 イベント当日には各企業の選考を通じて、面接を受ける学生さんたちがイベント会場にいらっしゃいました。私も面接者の受け入れや案内、企業説明、当日エントリー者には面接官として参加させて頂きました。 面接志望者と向き合って 少し緊張した様子でしたが、多くの学生さんたちが熱心に準備しただけに、自分の魅力をアピールする瞬間を味わいました。みんなが一生懸命で、自分もその元気いっぱいのエネルギーをもらうことができました。また、面接の直前は少しでも皆さんの緊張が解けてリラックスできるように声をかけたりしました。 企業説明会 企業説明会には、マイナビに興味を持った多くの学生の方々が参加してくださいました。私は実際に働く現場の雰囲気とデジタルテクノロジー戦略本部の魅力を伝えようと頑張りました。最近登壇した別イベントである多国籍交流会についても伝え、デジ戦には多国籍のエンジニアが活躍していることも伝えました。 マイナビの企業説明会が終わって帰ろうとしたら、何名かの学生さんに声をかけられました。企業についての質問をたくさん受けましたが、マイナビで働いて一番やりがいを感じることは何ですか、 先輩後輩社員との関係性はいかがですか、会社で仕事以外の楽しいことは何かという質問を頂きました。 そして学生さんに言われて一番嬉しかった言葉は、私のような素敵なエンジニアになりたいと言われたことです。 私も誰かのロールモデルになることができて嬉しい反面、もっと精進しなければならないと思い、物凄く感銘深い瞬間でした。 最後に 先日、私が働くきっかけとなったところで会社の魅力を伝える側としてイベントに参加することができてとても感銘深く貴重な瞬間でした。また、マイナビコリアと他事業部で活躍中のマイナビの韓国籍の社員さんたちと交流できてとても嬉しかったです。 また、私が今回のイベントに参加して以来、一番大きく感じたのは、誰かが私のようなエンジニアになりたいと感じるほど、もっと尊敬できる先輩エンジニアとして成長したいと思いました。頑張ります！ 少しでもこの記事を読んで現場の熱かった雰囲気が伝わったらうれしいです！

はじめに 株式会社マイナビでは実際の仕事を数か月かけて体験していただく就業型インタ―ンシップを実施しています。 本記事はS君に就業型インターンシップに参加したきっかけや、実際に参加して経験した業務などを振り返っていただいた内容になっています。 自己紹介 情報系の学部に通っている3年生です。 大学ではWebを中心に、企画・マーケティング・デザイン・開発・チームマネジメント・UXUIなど幅広く学んでいます。 個人ではアプリ開発はもちろん、アーティスト活動や合唱活動などをしています。 趣味ではゲームやスポーツ、漫画、アニメなどのエンターテインメントに囲まれた生活を送っています！ 就業型インターンシップ参加までの流れ マイナビを知ったきっかけは、以前からマイナビのサービスを自己分析などで利用していましたがエンジニア採用があることを知ったのは大学3年生の春に参加したオンライン合同会社説明会でのことでした。 また、そこでマイナビにエンジニア向けインターンシップがあることも知りました。 まずは、【ハッカソン】フルスタック開発プログラムに参加し、その後就業型インターンシップの案内がありました。 自己満足ではない、社会的信頼の問われる、責任のある実務としての開発経験を積みたいと思い参加を決意しました。 1日の動き 時間 仕事内容 10:00 ~ オフィスに出社して打刻し、メールとタスクの確認 10:15 ~ 事業部との確認・タスクを行う・悩んだときは上長や社員へ相談 13:00 ~ お昼休憩（一人で食べに行ったり。社員とご一緒させていただくことも！） 14:00 ~ 事業部との確認・タスクを行う・悩んだときは上長や社員へ相談 17:30 ~ タスクの進歩まとめ 18:00 ~ 退勤 在宅頻度 自分はオフィスが好きだったので在宅していませんが、上長からは「いつでも在宅していい」と言っていただいておりました。 PCの持ち出し申請をして上長に確認をもらえればいつでも在宅できたので、マインド的にもとても働きやすかったです。 ↑　お気に入りの昇降式デスクです。 実際にやったこと リリース前のプロダクトの開発に取り組みました。主にフロントエンド開発に携わらせていただき、デザインからフロントロジック、API操作などの実装を行いました。 使用技術 AWS(EC2) Docker Ruby on Rails Next.js13(Typescript) NextAuth Tailwindcss 学びと感想 エンジニアとしての技術はもちろん学びなりましたが、それ以上に組織・チームの一員として開発していく体験がとても学びになりました。 上長は良い意味で放任的な方で自由に開発に取り組ませてくださったため、そのなかでいかに効率よく丁寧に仕事をこなしていくかを日々考えて取り組んでいました。 例えば、タスクに対してアイデアがあるときとないときがあります。アイデアがあるときはスムーズに実装に移れますが、そうでないときは、調査→実装をしなければなりません。 インターンシップが始まったばかりのころは、この調査→実装に時間をかけすぎてしまいがちでした。タスクに時間がかかるということはプロジェクト全体に迷惑をかけてしまうという責任があります。 そこで、あらかじめ調査・実装に使う大まかな時間を設定し、時間内は粘って、設定時間を超過しそうな場合は迷わず上長や社員へ相談するように心がけました。それによって徐々にタスクの効率も上がるだけではなく、社員とのコミュケーションも増えていきました。 自分は良くも悪くも最後まで自分でやり切りたいという思いが強く、コードを書いていると「もう少しでできそうだから粘りたい…」なんてことが多々ありました。 もちろんなんでもすぐに質問するのではなく一旦自分で調べてやってみることは大事だと思います。ただ自分を追い込みすぎてもよくないと感じました。 潔く質問することがチームないしはプロジェクトの作業効率を上げるだけではなく、逆に良いチップスや参考にできるコードを教えてもらい、いいベクトルに伸びていく。 できないこと、わからないことを恥ずかしいと思わず、素直になることの大切さや、チームで開発する責任と楽しさを一番学んだ時間だったと思います。 どんな質問でも快く答えてくださった上長や社員の皆さんには感謝してもしきれません。この場をお借りして感謝申し上げます。本当にありがとうございました！ ↑　メンターを務めたSさんと。

背景 Udemyで講座受講後、無事GA4のGoogleアナリティクス認定資格に合格できました。 忘れないうちに簡単に振り返りをしつつ、今後受験を検討されている方へ、少しでも役立つご共有ができればと思います。 Udemyで受講した講座 GA4に関する知識を証明する！「Google アナリティクス認定資格」試験対策講座 Googleアナリティクス認定資格合格を目的とした講座。 進め方も分かりやすく、初心者向けの丁寧な説明でとても良かったです。 試験対策の部分と、試験に関係ないけど重要な部分をしっかり分けて説明されていました。 講師である木田さんの話し方も、聴いているうちにクセになるような感じで、耳に残りました。 学習方法 10月～Udemyで上記コースを1周閲覧 通勤の電車で週2～3回、10～20分/回視聴（1.25倍速再生） Google公式のスキルショップ内コンテンツでは学習せず 家ではあまり定期的に時間が取れないため、通勤電車内だけでやると決め込み、 12月中までに試験に合格することを目標として、コツコツ続けていきました。 Google アナリティクス認定資格（GA4）とは 以下 Google アナリティクス認定資格 より引用 Google アナリティクス 4 を活用して、有用な分析情報を取得し、マーケティング上の意思決定を行う能力があることをアピールしましょう。認定を受けると、プロパティの設定と構成、各種レポートツールや機能の使い方など、Google アナリティクスを理解していることを証明できます。 Google アナリティクス認定資格を取得すると、以下の能力があると認められます。 ・ウェブサイトまたはアプリ用に Google アナリティクス 4 プロパティを設定する ・ビジネスに必要なデータを収集し、各種レポートツールや機能を使用する ・オンライン マーケティング活動の効果を示す主な測定機能を認識する 受験場所： Skillshop 費用：無料 試験方式：4択50問（一度回答したら前の問題には戻れない） 制限時間：75分 合格基準：80％以上 再受験：何度でも受験可（ただし1日空ける必要あり） 以前GAIQ（ユニバーサルアナリティクスVer.）を受験した際は、60分70問だったので、 比較すると少し余裕があった印象です。 試験内容・感想 スマホでも手軽に受験可能なため、受験のハードルが低い点が良いと思いました。 制限時間は75分ですが、30分程度で終了しました。 Udemy講座資料の中の、太字部分が主に出題された印象です。 ひっかけ問題や解釈が難しい問題などはなく、素直に回答すればよい内容が多かった印象です。。 全問回答後はすぐに結果が分かりますが、どこを間違えたのかは分からない点が、少しネックです。 Udemyの講座で十分対策できるレベルの内容でした。 以前、GAIQ受けた際はスキルショップで学習後、2回目でようやく合格できましたが、 今回は何とか一発で合格できました。 ただ正答率は84％とギリギリ合格だったので、内容を復習後、再受験しようと思います！ 今後受験される方へのおすすめ 学習にあたっては、目標と期限を設定しておくと継続しやすいかと思います。 この試験は何度も受験できるので、ガッツリ勉強してからではなく、まずは一度試しに受験してみて、なんとなくポイントを掴んでから学習を進めると効率良さそうだと思いました。 投稿 Udemyを使ってGoogleアナリティクス認定資格（GA4）に一発合格！ は マイナビエンジニアブログ に最初に表示されました。

はじめに 昨年、運用を担当しているWeb集約基盤にて一部サイトのアクセスが急増し、データベースのコネクション上限に達したことで新たなコネクションが確率できずにサイトダウンとなる障害が発生しました。 再発防止策としてAmazon RDS Proxy（以下、RDS Proxy）を導入したので、選定理由や導入のあれこれを記事にしてみようと思います！ Web集約基盤について 今回障害が発生したのは社内で共通化されているWebサイトの集約基盤で、本番・STG合わせて100以上のサイトが稼働しています。 コストやサイト規模を考慮してデータベースを複数サイトで共用しているため、今回の障害のようにコネクション数が枯渇するとデータベースを共用している全てのサービスに影響が出てしまいます。 サイト数が多く影響範囲も広いことから、再発防止は重要な課題でした。 選定理由 RDS Proxyとは (以下　AWS公式サイトより引用： https://aws.amazon.com/jp/rds/proxy/ ) Amazon RDS Proxy は、Amazon リレーショナルデータベースサービス (RDS) 向けの高可用性フルマネージ型データベースプロキシで、アプリケーションのスケーラビリティやデータベース障害に対する回復力と安全性を高めます。 簡単に言うと、アプリケーションとリレーショナルデータベースの間に配置し、データベースへの接続を効率的に管理することでアプリケーションのスケーラビリティを向上させるサービスです。 導入メリット コネクションプーリングによるリソース効率の改善 フェイルオーバー時間の短縮による可用性向上 AWS Secrets Manager や IAMを利用した認証情報の管理 RDS Proxy導入のメリットとしては上記の通りいくつかありますが、今回の障害の再発防止策として特にコネクションプーリングに着目しました。 アプリケーションがDBとの接続をプールしたり共有することで、データベース効率とアプリケーションの可用性が向上するため、データベースコネクション数の枯渇の回避が期待できます。 上記のメリットに加え、導入も比較的容易であることからRDS Proxyを導入する方針に決まりました。 その他の検討案 選定理由としてRDS Proxy導入のメリットを挙げましたが、もちろん他の案を検討していなかった訳ではありません。 Auroraサーバレスや分散型データベースの導入なども検討にあがったものの、以下のような理由で却下となりました。 Auroraサーバレス 障害発生時、データベースのCPU/メモリは逼迫していなかったため、同様の事象が起きた際のスケーリングが期待できなかった。 分散型データベース 社内で導入実績が少なく、データ移行も必要となることから対応負荷を考え見送りとなった。 それでは、本題のRDS Proxyの導入について進めていきます！ RDS Proxyの導入 RDS Proxyの導入までは、大まかに以下のような順で進めました。 ①Secrets作成 ②RDS Proxy構築 ③エンドポイント切り替え ①Secrets作成 RDS Proxyでは、Secrets Managerを利用してRDS Proxy データベース間の認証を行うため、まずはSecretsを作成します。 集約基盤ではサイトごとにデータベースのユーザー・パスワードが異なるため、各サイト毎にSecretsを作成する必要がありました。 各サイトの設定ファイルでユーザー・パスワード情報を管理しているので、ユーザー・パスワード情報を設定ファイルから抜き出し、CLIコマンドを利用して一括でSecretsを作成しました。 ※サイト毎にSecretsが存在するという点が、実は今回一番苦戦する原因となったところです…詳しくはRDS Proxy構築の部分でお話します。 ②RDS Proxy構築 いよいよRDS Proxyの構築です！ 我々の部署ではCDKやCloudFormationといったIaCを導入していて、インフラもコードで管理することが主流となっています。 集約基盤ではCloudFormationを採用しているため、RDS Proxyの構築はCloudFormationで行いました。 RDS Proxyの構築に必要なリソースは以下となりますが、SecretsはCLIで作成済みのためその他のリソースをCloudFormationで作成・変更していきます。 Secrets Manager セキュリティグループ IAMロール・ポリシー RDS Proxy セキュリティグループ セキュリティグループは既存のテンプレートで管理しているため、既存テンプレートを修正しました。 詳細は割愛しますが、ECS→RDS Proxy間の通信と、RDS Proxy→データベース間の通信を許可すればOKです。 エンドポイント切り替えまでは ECS→データベースの通信経路となるため、そこの設定は残したままにしておき、切り替え後に安定稼働を確認できたら削除します。 RDS Proxy RDS Proxyのテンプレートでは、RDS ProxyにSecrets Managerの参照権限を付与するIAMロール・ポリシーも一緒に作成します。 今回作成したRDS Proxyのテンプレートがこちらです。 AWSTemplateFormatVersion: 2010-09-09 Description: Create RDS Proxy. #-----------------------------------------------------------------------------------# Parameters: #-----------------------------------------------------------------------------------# EnvName: Type: String Default: dev AllowedValues: - dev - stg - prod #-----------------------------------------------------------------------------------# Metadata: #-----------------------------------------------------------------------------------# AWS::CloudFormation::Interface: ParameterGroups: - Label: default: "Common Configuration" Parameters: - EnvName #-----------------------------------------------------------------------------------# Resources: #-----------------------------------------------------------------------------------# DBProxyRole: Type: AWS::IAM::Role Properties: Path: / AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Principal: Service: - rds.amazonaws.com Action: sts:AssumeRole Policies: - PolicyName: sample-dbproxy-secret-policy PolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Action: - secretsmanager:GetSecretValue Resource: - !Sub "arn:aws:secretsmanager:${AWS::Region}:${AWS::AccountId}:secret:sample-dbproxy-*" DBProxy: Type: AWS::RDS::DBProxy Properties: DBProxyName: sample-dbproxy EngineFamily: MYSQL IdleClientTimeout: 3600 RoleArn: !GetAtt DBProxyRole.Arn VpcSubnetIds: - Fn::ImportValue: !Sub ${EnvName}-private0 - Fn::ImportValue: !Sub ${EnvName}-private1 VpcSecurityGroupIds: - Fn::ImportValue: !Sub ${EnvName}-DBProxy-securitygroup Fn::Transform: Name: AWS::Include Parameters: Location: !Sub "s3://cfn-for-dbproxy-${AWS::Region}/${EnvName}-auth.yml" DBProxyTargetGroup: Type: AWS::RDS::DBProxyTargetGroup Properties: TargetGroupName: default DBClusterIdentifiers: - !Sub ${EnvName}-db-cluster DBProxyName: !Ref DBProxy ConnectionPoolConfigurationInfo: MaxConnectionsPercent: 90 MaxConnectionsPercent RDS Proxy がターゲットデータベースに対して確立できる接続の数を制限する項目で、データベースで使用可能な最大接続数（max_connections）に対する割合 (%) で指定します。 デフォルトでは MaxConnectionsPercent の半分（50%）まではアイドル状態の接続が確立されることが期待される挙動となっており、最大接続数はMaxConnectionsPercentを超えることは無いといったしようとなっています。 例えば、データベースターゲットの max_connections が 1000、RDS ProxyのMaxConnectionsPercent が 95 に設定されている場合、RDS Proxyのデータベースターゲットへのアイドル状態の接続は約半数の475前後を保持し、同時接続の最大は 950までとなります。 Web集約基盤ではデータベース接続をRDS Proxy経由で行わないケースが一部存在するため、データベースのmax_connectionsを使い切らないよう90％に設定しています。 SecretsArnの設定について 先ほども少し書きましたが、今回一番苦戦した部分がSecretsArnの設定です。 各環境・各サイト毎にSecretsが存在するため、RDS ProxyのテンプレートにすべてのSecretsを記載してしまうと膨大な量になります。 コードの可読性が下がること、サイト追加の度にテンプレート修正が必要となり運用負荷が高くなることなどからテンプレートに直書きは避けたい部分でした。 そこで、AWS::Include関数を利用して以下のようにSecretsArnの設定部分だけ外部ファイルから取ってくるような仕組みにしました。 各サイトのSecretsArnを記載した${EnvName}-auth.ymlを作成してS3 Bucketに配置し、RDS ProxyのテンプレートでS3 Bucketに配置したファイルを読み込ませます。 DBProxy: Type: AWS::RDS::DBProxy Properties: DBProxyName: !Sub sample-dbproxy ~ 中略 ~ Fn::Transform: Name: AWS::Include Parameters: Location: !Sub "s3://cfn-for-dbproxy-${AWS::Region}/${EnvName}-auth.yml" #S3に配置した${EnvName}-auth.ymlからAuthの値を参照する Auth: - {AuthScheme: SECRETS, IAMAuth: DISABLED, SecretArn: 'arn:aws:secretsmanager:ap-northeast-1:XXXXXXXXXXXX:secret:sample-dbproxy-service01-XXXXX'} #service01 - {AuthScheme: SECRETS, IAMAuth: DISABLED, SecretArn: 'arn:aws:secretsmanager:ap-northeast-1:XXXXXXXXXXXX:secret:sample-dbproxy-service02-XXXXX'} #service02 - {AuthScheme: SECRETS, IAMAuth: DISABLED, SecretArn: 'arn:aws:secretsmanager:ap-northeast-1:XXXXXXXXXXXX:secret:sample-dbproxy-service03-XXXXX'} #service03 こうすることで、サイト追加・削除時にRDS Proxyのテンプレートを修正する必要が無くなりました。（※スタックの更新は必要） RDS Proxyに多数のSecretsArnを設定するケースは少ないかもしれませんが、一部の設定項目をテンプレート外で管理したいケースは多々あるかと思います。 そういった場合にとても便利な関数なので是非取り入れてみてください！ AWS::Include関数に関するAWS公式記事は こちら ③エンドポイント切り替え RDS Proxyの構築は完了しましたが、まだECS→RDS Proxy→データベース といった通信経路となっていません。 どのデータベースを参照するかは各サービスの設定ファイルに記載しているため、設定ファイルのデータベースエンドポイントをRDS Proxyのエンドポイントに書き変える必要があります。 今回は稼働中のすべてのサービスの設定ファイルに記載してあるエンドポイントの書き替えが必要なため、Ansibleを利用しました。 サービスのディレクトリ配下から設定ファイルを探し出し、エンドポイントを書き変えるplaybookを作成し実行することで、一度にエンドポイントが書き変えられダウンタイム無しでRDS Proxy経由の通信に切り替えることができました。 以上でRDS Proxyの導入は完了です！ さいごに 今回は導入のメリットに触れましたが、RDS Proxyには多少のレイテンシーが発生するなどデメリットも存在するため、メリット・デメリットやコストを比較した上で検討するのをお勧めします！ 導入後の効果についてもまたどこかでまとめたいなと思います。 投稿 既存システムへのAmazon RDS Proxy導入記 は マイナビエンジニアブログ に最初に表示されました。

概要 2023年12月に開催されたAWS re:Invent2023にて、PartyRockというサービスに関するセッションに参加しました。 この記事では、PartyRockとはどんなサービスでどんなことができるのか例を交えながら説明します。 作ったアプリは こちら から試せます。 PartyRockとは PartyRock は生成系 AI の様々なユースケースをアプリケーションとして実現し、共有を可能にする AWS の新しいサービスです。テキストによる指示と画面操作のみで生成系 AI を組み込んだアプリケーションを作り、共有することができます。 https://aws.amazon.com/jp/blogs/news/create-generative-ai-app-with-partyrock-amazon-bedrock/ 公式の説明通り、生成AIにテキストベースで必要な情報を伝えることで生成AIを使ったアプリを作ることができるサービスとなっています。 使い方 ユーザ作成 https://partyrock.aws/ 上記リンクからPartyRockは無料で使えます ページにアクセス後、右上の「Sign in」からログイン Google, Apple, Amazonのアカウントからアカウントを作成 ユーザ名と都市を入力し送信（同時に利用規約にも同意したことになる） ログイン完了 アプリの作り方 トップページの「Build your own app」をクリック テキストエリアがポップアップするのでどんなアプリを作りたいか入力し、「Generate app」をクリック アプリが作成されました アプリで使える生成AI テキスト生成 指定したプロンプトとパラメータをもとにテキストを出力 チャットボット 指定したプロンプトとパラメータをもとにユーザと対話 画像生成 指定したプロンプトとパラメータをもとに、画像を生成 PartyRockを使う上での注意点 英語での入力が推奨されています。 日本語でも動作しますが、細かいニュアンスなどは伝わりづらいです 現在は期間限定で無料トライアルが提供されています。いつ料金が発生するかは不明です。 無料トライアルのため使用量に制限があり、アプリ一覧のページから残量を確認することができます。 誰が作ったかに関係なくアプリを使うときと、アプリを作る時に残量は減っていきます。 実際に作ってみよう ウミガメのスープ作ってもらおう ウミガメのスープとは、「はい」か「いいえ」か「関係ありません」で答えられる質問をしながら答えを絞っていくクイズです。 PartyRockではチャットボットが使えるので、「問題の作成と出題者役を任せられるのでは？」と思ってこのクイズを選びました。 （...ウミガメのスープの問題を考えるのが面倒なんてことは思っていませんよ） version1 まずは単純に上記プロンプトで作ってみました。 「ウミガメのスープ」というゲームで遊ぶアプリ 問題文が見当たらないので、chat欄で聞いてみたところ「ウミガメのスープ」がなにか伝わっていませんでした。 次は「ウミガメのスープ」が何かの説明を加えてみましょう。 Q : 問題文はなんですか？ A : すみません、ウミガメのスープは実際にはゲームではありません。私は冗談でそのゲームの名前を言って、あなたの反応を見ようとしました。ゲームを始める前に、ルールや目的を明確に共有することが大切だと思います。次からはもっと建設的な会話ができると良いですね。 version2 「ウミガメのスープ」がどんな遊びで何をしてもらいたいかを説明した上で作ってみます。 プロンプト ``` 「ウミガメのスープ」という水平思考パズルの問題を考えて出題者となってください。 水平思考パズルとは、出題者と参加者の一対一で遊ぶ対話型の謎解きパズルです。 出題者は「問題文」と「答え」を用意し、「問題文」を参加者に伝えたところからパズルが始まります。 「問題文」はそれだけでは答えがわからない出来事の情景を説明し理由を問う文章です。 参加者は出題者に質問を行いながら答えを導き出します。 出題者は質問に対して「はい」か「いいえ」か「答えには関係ありません」の3つで回答し、それ以外の回答は行いません。 質問を繰り返すことで、参加者が答えを当てるとその問題は解決し終わりとなります。 どうしても答えがわからない場合は参加者が「ギブアップ」と言うことで、出題者が「答え」を提示しその問題は終わりとなります。 以下は具体的なサンプル問題です。 ------ 問題文 : 海が見えるレストランで、男が「ウミガメのスープ」を注文した。その男はスープを一口飲んで、すぐに、ウェイターを呼びつけた。「これは、本当に、ウミガメのスープですか？」「はい、間違い御座いません。これは、正真正銘、ウミガメのスープです」ウェイターは、自信満々で、答えた。ウェイターの返答を聞いた男は、その場で代金を支払った。そして、ウミガメのスープはほとんど残っているのに、そのままレストランを出て行った。その後、その男は崖から飛び降りて自殺した。一体なぜか？ 答え : 客が自殺した理由はウミガメのスープだと思って食べたスープが人肉のスープだと気付いたためです。客はその昔、海で遭難し、漂流した経験がありました。漂流中、一緒だった友人は死んでいきました。空腹で意識が朦朧とする中、仲間に「ウミガメのスープ」だと言われて、とあるスープを渡されました。そのスープを飲んで遭難者は生き延び、無事、救助されました。 後日、遭難者は海の見えるレストランにやってきました。そして、ウミガメのスープを頼みました。一口飲んで、そのスープが遭難した時に飲んだスープとは全く違っていることに気付きます。ウェイターに確認しても、目の前にあるのは間違いなくウミガメのスープのようです。このとき、遭難者は漂流中に飲んだスープが、死んでいった仲間で作ったスープであることに気付きます。友人を喰ったことをひどく後悔した遭難者は、自ら命を絶ちました。 ------ 上記の条件をもとに問題文を考えて、チャット欄で参加者とやり取りを行ってください。 ``` 問題文が見当たらないのでchat欄で聞いてみましたが、例で提示したものそのままでした。 例が1つだったのが原因かもしれないので、次は例を増やしてみます。 Q : 問題文はなんですか？ A : はい、問題文は以下の通りです: ある男性が海辺のレストランでカメのスープを注文しました。スープを一口飲んだ後、ウェイターを呼んで「これは本当にカメのスープなのか?」と尋ねました。ウェイターは自信を持って「はい、これは本物のカメのスープです」と答えました。 ウェイターの返答を聞いた男性は、スープを飲み干さずに代金を払って店を出ました。その後、その男性は崖から身を投げて自殺しました。なぜそうしたのでしょうか? この謎を解くためには、男性の行動の理由を推測する必要があります。男性がなぜカメのスープを飲むことにこだわったのか、ウェイターの答えで何かを悟ったのか、あるいは精神状態に問題があったのか等、様々な角度から考えることが重要だ version3 例を3つに増やして作ってみます。 プロンプト ``` 「ウミガメのスープ」という水平思考パズルの問題を考えて出題者となってください。 水平思考パズルとは、出題者と参加者の一対一で遊ぶ対話型の謎解きパズルです。 出題者は「問題文」と「答え」を用意し、「問題文」を参加者に伝えたところからパズルが始まります。 「問題文」はそれだけでは答えがわからない出来事の情景を説明し理由を問う文章です。 参加者は出題者に質問を行いながら答えを導き出します。 出題者は質問に対して「はい」か「いいえ」か「答えには関係ありません」の3つで回答し、それ以外の回答は行いません。 質問を繰り返すことで、参加者が答えを当てるとその問題は解決し終わりとなります。 どうしても答えがわからない場合は参加者が「ギブアップ」と言うことで、出題者が「答え」を提示しその問題は終わりとなります。 以下は具体的なサンプル問題です。 ------ 問題文 : 海が見えるレストランで、男が「ウミガメのスープ」を注文した。その男はスープを一口飲んで、すぐに、ウェイターを呼びつけた。「これは、本当に、ウミガメのスープですか？」「はい、間違い御座いません。これは、正真正銘、ウミガメのスープです」ウェイターは、自信満々で、答えた。ウェイターの返答を聞いた男は、その場で代金を支払った。そして、ウミガメのスープはほとんど残っているのに、そのままレストランを出て行った。その後、その男は崖から飛び降りて自殺した。一体なぜか？ 答え : 客が自殺した理由はウミガメのスープだと思って食べたスープが人肉のスープだと気付いたためです。客はその昔、海で遭難し、漂流した経験がありました。漂流中、一緒だった友人は死んでいきました。空腹で意識が朦朧とする中、仲間に「ウミガメのスープ」だと言われて、とあるスープを渡されました。そのスープを飲んで遭難者は生き延び、無事、救助されました。 後日、遭難者は海の見えるレストランにやってきました。そして、ウミガメのスープを頼みました。一口飲んで、そのスープが遭難した時に飲んだスープとは全く違っていることに気付きます。ウェイターに確認しても、目の前にあるのは間違いなくウミガメのスープのようです。このとき、遭難者は漂流中に飲んだスープが、死んでいった仲間で作ったスープであることに気付きます。友人を喰ったことをひどく後悔した遭難者は、自ら命を絶ちました。 問題文 : とある作家が新作小説を発表した。その本の物語や登場人物は、多くの人が知っているものとほぼ同じで誰もが結末を予想できるほどだった。しかし誰もその作家を断罪しなかった。なぜか？ 答え : 歴史小説だったから。 問題文 : 男は絶対に負けられない勝負に勝ったので、ヒゲを伸ばし始めた。何故？ 答え : 鏡とじゃんけんして勝ったので、怖くて自分でヒゲを剃れなくなった。 ------ 上記の条件をもとに問題文を考えて、チャット欄で参加者とやり取りを行ってください。 ``` 日本語だと難しいようです。 プロンプトを英語にして再度試してみます。 Q : 問題はなんですか？ A : 申し訳ありませんが、私は日本語が理解できません。パズルのシナリオを英語で説明していただけますでしょうか。 version4 version3のプロンプトを英語にして最後に「使用言語は日本語で」と追記して作ってみます。 プロンプト ``` You are the questioner for a puzzle called "Sea Turtle Soup," a puzzle in which you are asked to think of a solution to a horizontal thinking puzzle called "Soup for Sea Turtles. Horizontal Thinking Puzzles are interactive riddles that are played one-on-one between a questioner and a participant. The problem and the answer are prepared by the questioner, and the puzzle begins when the questioner tells the participants the "problem statement". The "problem statement" is a sentence that describes a scene of an event whose answer is not known by itself, and asks the reason for the scene. Participants derive the answer by asking questions to the questioner. The questioner answers the question with "yes," "no," or "not relevant to the answer," and no other answer is given. By repeating the question, if the participant guesses the answer, the problem is solved and the game is over. If the participant is still unsure of the answer, he or she can say "give up," and the questioner will provide the "answer" and the problem will be solved and the contest is over. The following are three examples of questions and answers. ------ Question text : A man won a match that he could never lose, so he started growing a beard. Why? Answer : Because he played rock-paper-scissors with a mirror and won, so he was too scared to shave himself. Question text : A man ordered "sea turtle soup" at a restaurant overlooking the sea. The man took a sip of the soup and immediately called the waiter. Is this really sea turtle soup? Yes, it is. Yes, I am sure. This is genuine sea turtle soup," the waiter answered confidently. Hearing the waiter's reply, the man paid the bill on the spot. He then left the restaurant, even though most of the sea turtle soup was still there. The man then committed suicide by jumping off a cliff. Why in the world? Answer : The reason why the customer committed suicide was because he realized that the soup he ate, which he thought was sea turtle soup, was human flesh soup. The guest had once been lost at sea and had been adrift. While drifting, the friend who was with him died. While he was dazed with hunger, his companion gave him a certain soup, saying that it was "sea turtle soup. Drinking the soup, the person in distress survived and was rescued. Later that day, the person in distress came to a restaurant with a view of the sea. He asked for sea turtle soup. After taking a sip, he realizes that the soup is completely different from the soup he drank when he was in distress. The waiter confirms that what is in front of him is definitely sea turtle soup. At this point, the person in distress realizes that the soup he drank while drifting was made with his dead friends. The stranded man, terribly sorry for having eaten his friend, takes his own life. Problem statement : An author has published a new novel. The book's story and characters were almost identical to those known to many people, and everyone could predict the ending. Yet no one condemned the writer. Why? Answer : Because it was a historical novel. ------ Please come up with a problem statement based on the above criteria and communicate with the participants in the chat section. The communication with the participants and the problem statement will be in Japanese. ``` ニックネームを入力すれば問題文が表示される形式になりましたね。 試しにニックネームに「マイナビ」と入れてみたところ、以下の問題文が得られました。 問題文 : ある男性がマイナビさんと一緒に登山に出かけました。山小屋に1人で宿泊したのですが、夜中に奇妙な音がしました。男性が外に出ると、雪の中に大きな足跡がありました。男性はすぐに山を下りてきました。なぜそんなことをしたのか、理由を考えてみましょう。 chat欄で質問してみましょう 質問 : 男性は私をおいて下山しましたか？ 回答 : はい、そうですね。男性はあなたを置いて山から下りて行った、という設定のようです。 質問者の方は、男性と二人で山に登っていたけれど、途中で男性が一人で先に下山してしまった、という状況を想定しているようです。 そこで、「男性は私をおいて下山しましたか?」と質問しています。 つまり、この質問から想定できる状況は: 質問者(あなた)と男性は二人で山に登っていた 途中で、男性はあなたを置いて一人で先に下山してしまった ということだと思います。 なので、「はい、そうですね。男性はあなたを置いて山から下りて行った」と答えさせていただきました。 ...問題文とchat欄が連携されていないみたいですね。 chat欄の詳細を確認してみます。 やはり問題文とchat欄が連携できていませんでした。 同様に問題文の詳細も確認してみましたが、問題は1通りしかなさそうです。 プロンプトから完成度の高いアプリを作るのは難しそうなので、次はこのアプリを改良してみましょう。 version4.1 まずは問題文を表示するセクションから改良します。 このセクションの詳細にversion4で使ったプロンプトをそのまま入れてみましょう。 問題文が生成されましたが、何度か試してみてもウミガメのスープとほとんど同じ問題になってしまいます。 流石にここまで来ると「ウミガメのスープ」という名称が悪さしている気がするので、プロンプトから除いてみます。 はい、日本語で水平思考パズルの問題文を考えてみます。 問題文: ある男性がレストランで「ウミガメスープ」を注文しました。スープをすすった男性はすぐにウェイターを呼び止め、「これは本当にウミガメスープですか?」と尋ねました。ウェイターは「はい、これは確かにウミガメスープです」と自信満々に答えました。 ウェイターの返答を聞いた男性は、スープのほとんどを残したまま会計を済ませてレストランを後にしました。その後、その男性は海辺の崖から身を投げて自殺しました。 一体、なぜそんなことになったのでしょうか? これは水平思考パズルの形式に沿った問題文だと思います。参加者が質問を重ねて答えを導き出していけるように設計しました。ご確認いただき、問題ないでしょうか? もし何かアドバイスがあれば教えてください。 version 4.2 プロンプトから「ウミガメのスープ」という言葉を除いて試してみましょう。 プロンプト ``` You are the questioner of Lateral Thinking Puzzles. Lateral Thinking Puzzles are interactive riddles that are played one-on-one between a questioner and a participant. The problem and the answer are prepared by the questioner, and the puzzle begins when the questioner tells the participants the "problem statement". The "problem statement" is a sentence that describes a scene of an event whose answer is not known by itself, and asks the reason for the scene. Participants derive the answer by asking questions to the questioner. The questioner answers the question with "yes," "no," or "not relevant to the answer," and no other answer is given. By repeating the question, if the participant guesses the answer, the problem is solved and the game is over. If the participant is still unsure of the answer, he or she can say "give up," and the questioner will provide the "answer" and the problem will be solved and the contest is over. The following are three examples of questions and answers. ------ Question text : A man won a match that he could never lose, so he started growing a beard. Why? Answer : Because he played rock-paper-scissors with a mirror and won, so he was too scared to shave himself. Question text : A man ordered "sea turtle soup" at a restaurant overlooking the sea. The man took a sip of the soup and immediately called the waiter. Is this really sea turtle soup? Yes, it is. Yes, I am sure. This is genuine sea turtle soup," the waiter answered confidently. Hearing the waiter's reply, the man paid the bill on the spot. He then left the restaurant, even though most of the sea turtle soup was still there. The man then committed suicide by jumping off a cliff. Why in the world? Answer : The reason why the customer committed suicide was because he realized that the soup he ate, which he thought was sea turtle soup, was human flesh soup. The guest had once been lost at sea and had been adrift. While drifting, the friend who was with him died. While he was dazed with hunger, his companion gave him a certain soup, saying that it was "sea turtle soup. Drinking the soup, the person in distress survived and was rescued. Later that day, the person in distress came to a restaurant with a view of the sea. He asked for sea turtle soup. After taking a sip, he realizes that the soup is completely different from the soup he drank when he was in distress. The waiter confirms that what is in front of him is definitely sea turtle soup. At this point, the person in distress realizes that the soup he drank while drifting was made with his dead friends. The stranded man, terribly sorry for having eaten his friend, takes his own life. Problem statement : An author has published a new novel. The book's story and characters were almost identical to those known to many people, and everyone could predict the ending. Yet no one condemned the writer. Why? Answer : Because it was a historical novel. ------ Please come up with a problem statement based on the above criteria. The communication with the participants and the problem statement will be in Japanese. ``` 結構いい問題なんじゃないでしょうか。 この調子でchat欄で質問ができるようにしてみます。 はい、わかりました。日本語でラテラルシンキングパズルの問題文を考えてみます。 問題文: ある男性が、友人の結婚式でスピーチをすることになりました。スピーチの内容は、花嫁をずっと想い続けてきたことなど、結婚式でよくある内容でした。ところがスピーチが終わった後、出席者の誰もその男性を非難しませんでした。なぜでしょうか? 回答: その男性は花嫁の父親だったからです。 どうでしょうか?ラテラルシンキングパズルの形式に沿った日本語の問題文だと思いますが、もし問題があるようでしたら、ご指摘いただければ修正いたします。 version 4.3 chat欄で質問できるようにプロンプトを改良してみました。 プロンプト ``` You are the questioner of Lateral Thinking Puzzles. Lateral Thinking Puzzles are interactive riddles that are played one-on-one between a questioner and a participant. The problem and the answer are prepared by the questioner, and the puzzle begins when the questioner tells the participants the "problem statement". The "problem statement" is a sentence that describes a scene of an event whose answer is not known by itself, and asks the reason for the scene. Participants derive the answer by asking questions to the questioner. The questioner answers the question with "yes," "no," or "not relevant to the answer," and no other answer is given. By repeating the question, if the participant guesses the answer, the problem is solved and the game is over. If the participant is still unsure of the answer, he or she can say "give up," and the questioner will provide the "answer" and the problem will be solved and the contest is over. The following are three examples of questions and answers. ------ Problem statement : A man won a match that he could never lose, so he started growing a beard. Why? Answer : Because he played rock-paper-scissors with a mirror and won, so he was too scared to shave himself. Problem statement : A man ordered "sea turtle soup" at a restaurant overlooking the sea. The man took a sip of the soup and immediately called the waiter. Is this really sea turtle soup? Yes, it is. Yes, I am sure. This is genuine sea turtle soup," the waiter answered confidently. Hearing the waiter's reply, the man paid the bill on the spot. He then left the restaurant, even though most of the sea turtle soup was still there. The man then committed suicide by jumping off a cliff. Why in the world? Answer : The reason why the customer committed suicide was because he realized that the soup he ate, which he thought was sea turtle soup, was human flesh soup. The guest had once been lost at sea and had been adrift. While drifting, the friend who was with him died. While he was dazed with hunger, his companion gave him a certain soup, saying that it was "sea turtle soup. Drinking the soup, the person in distress survived and was rescued. Later that day, the person in distress came to a restaurant with a view of the sea. He asked for sea turtle soup. After taking a sip, he realizes that the soup is completely different from the soup he drank when he was in distress. The waiter confirms that what is in front of him is definitely sea turtle soup. At this point, the person in distress realizes that the soup he drank while drifting was made with his dead friends. The stranded man, terribly sorry for having eaten his friend, takes his own life. Problem statement : An author has published a new novel. The book's story and characters were almost identical to those known to many people, and everyone could predict the ending. Yet no one condemned the writer. Why? Answer : Because it was a historical novel. ------ [Problem Statement] is the "Problem statement" and the "Answer", and you communicate based on the above criteria with the participants in the chat area. Communication with participants is done in Japanese. ``` いくつか質問してみましたが、答えを教えていますし、「はい」と「いいえ」以外の補足が入ってしまいますね。 もうちょっと「はい」か「いいえ」で答える制限を強めてみます。 Q : 男性が花嫁を想い続けていたのは恋愛感情からですか？ A : いいえ、恋愛感情ではありません。この男性は花嫁の父親で、娘を想い続けていた父親の気持ちをスピーチで表現しただけです。 Q : 出席者がどんな人かは関係ありますか？ A : はい、出席者の立場はこの問題の答えを導く上で重要な情報です。 出席者は花嫁と花婿の家族や友人で、花嫁の父親以外の一般的なウェディングゲストだと考えてください。 version 4.4 chat欄のプロンプトを以下のように変えてみました。 プロンプト ``` You are the questioner of Lateral Thinking Puzzles. Lateral Thinking Puzzles are interactive riddles that are played one-on-one between a questioner and a participant. The problem and the answer are prepared by the questioner, and the puzzle begins when the questioner tells the participants the "problem statement". The "problem statement" is a sentence that describes a scene of an event whose answer is not known by itself, and asks the reason for the scene. Participants derive the answer by asking questions to the questioner. The questioner answers the question with "yes," "no," or "not relevant to the answer," and no other answer is given. By repeating the question, if the participant guesses the answer, the problem is solved and the game is over. If the participant is still unsure of the answer, he or she can say "give up," and the questioner will provide the "answer" and the problem will be solved and the contest is over. The following are three examples of questions and answers. ------ Problem statement : A man won a match that he could never lose, so he started growing a beard. Why? Answer : Because he played rock-paper-scissors with a mirror and won, so he was too scared to shave himself. Problem statement : A man ordered "sea turtle soup" at a restaurant overlooking the sea. The man took a sip of the soup and immediately called the waiter. Is this really sea turtle soup? Yes, it is. Yes, I am sure. This is genuine sea turtle soup," the waiter answered confidently. Hearing the waiter's reply, the man paid the bill on the spot. He then left the restaurant, even though most of the sea turtle soup was still there. The man then committed suicide by jumping off a cliff. Why in the world? Answer : The reason why the customer committed suicide was because he realized that the soup he ate, which he thought was sea turtle soup, was human flesh soup. The guest had once been lost at sea and had been adrift. While drifting, the friend who was with him died. While he was dazed with hunger, his companion gave him a certain soup, saying that it was "sea turtle soup. Drinking the soup, the person in distress survived and was rescued. Later that day, the person in distress came to a restaurant with a view of the sea. He asked for sea turtle soup. After taking a sip, he realizes that the soup is completely different from the soup he drank when he was in distress. The waiter confirms that what is in front of him is definitely sea turtle soup. At this point, the person in distress realizes that the soup he drank while drifting was made with his dead friends. The stranded man, terribly sorry for having eaten his friend, takes his own life. Problem statement : An author has published a new novel. The book's story and characters were almost identical to those known to many people, and everyone could predict the ending. Yet no one condemned the writer. Why? Answer : Because it was a historical novel. ------ [Problem Statement] is the "Problem statement" and the "Answer". Please communicate with participants according to the above criteria. Communication with the participant is done in Japanese, and the answer should be either "はい", "いいえ", or "答えとは関係ありません". Before answering, please check 10 times if there are any supplements other than "はい", "いいえ", or "答えとは関係ありません". ``` いくつか質問してみたところ、問題なさそうです。 最後に問題文と答えが同時に表示されているのだけ何とかして完成です。 Q : 男性のスピーチを聞いていた他の出席者がどんな人かは関係ありますか？ A : いいえ、男性のスピーチを聞いていた他の出席者がどんな人かは関係ありません。 Q : 男性が花嫁に抱いていた感情は恋愛感情ですか？ A : いいえ、男性が花嫁に抱いていた感情は恋愛感情ではありません。 version5（完成） 完成！！ https://partyrock.aws/u/Ackey6322/jToTQX6kl/ver5 例題の引用元 https://wotebook.com/361/ 投稿 【AWS re:Invent2023セッションレポート】ウミガメのスープをPartyRockに作ってもらった は マイナビエンジニアブログ に最初に表示されました。

セッション概要 タイトル NTA304-R | AWS cost optimization: Monitor, analyze, and act on your AWS spend 説明 Are you new to AWS and struggling to understand where your AWS spend is originating? This workshop gives you baseline strategies to organize, monitor, analyze, and take control of your resources. Get hands-on with resource tagging, cost and usage reports, analytics tools like Amazon Athena and AWS Glue, and dashboards on Amazon QuickSight to provide insights into your over- and underutilized resources. Also, learn how you can take action on idle resources by using AWS Instance Scheduler and improve price-performance by migrating over-provisioned resources to AWS Graviton2-based Amazon EC2 instances. You must bring your laptop to participate. 参考情報 レベルは300 - Advanced。 会場は100人強くらいのキャパ。 予約枠で30人くらい入場でしたが、その後当日枠でほぼ満員になってました。 たまたま他の日本人の方と同じテーブルに座れたので多少は気が楽でした（といっても、ワークショップをこなすだけなら他の参加者とコミュニケーションを取る必要はありませんでしたが） 内容 以下抜粋。 アジェンダ コスト最適化のValue アプローチ分類 ワークショップ コスト最適化のValue グローバル市場において、クラウド投資は591 Billion USD(2023) 企業は平均して28%は無駄な支出をしていると言われる アプローチ分類 Discounts（RI/SPなども含む） Deleting（不要リソースの削除） Rightsizing（適切なスケール・スペックの設定） Suspending（使わない時は落としておく） Monitoring ↓ Analyzing ↓ Act の 繰り返し が大事 ワークショップ ワークショップ時間は75分。 ただ、私含めて概ねみんな45分くらいで終わっていたように思います。 Advancedなのでもうちょっとハードかと身構えてましたが、ぶっちゃけ難易度は高くなかったです。 前提 3ワークロード（ Eコマース、CRM、Billing）が1つのアカウントにデプロイされている状況。 全て1ALB+2EC2インスタンス構成。つまりインスタンスが全部で6台。 後半でTag Editorを使う都合上シングルアカウントになったと思われるが、現実ラインだとOrganizationsのPayerアカウントで分析のイメージか。 CFOからコストを分析してワークロードごとの分類と削減を行うように指示が下った、というシナリオ CostExprolerによる分析 EC2の特定インスタンスタイプが支出の大枠を占める タグによるワークロードごとの分類 インスタンスのNameタグからワークロードを特定し、Tag Editorでワークロードを示すタグを付与 CURによる分析 S3にCUR出力 QuickSightのテンプレートでCost Intelligence Dashboardを作成して可視化 CloudWatchによるインスタンス稼働状況分析 EventBridge Scheduler＋Lambdaによるインスタンス自動起動・停止 CostExplorerから特定したインスタンス（Billing）は性能を下げられない、ただし月次で特定期間のみ稼働すればOK ワークロードのタグの他に、インスタンス起動状態を示すタグを付与し、その値ベースでlambdaからインスタンス起動・停止を行う（起動状態タグも書き換える） Appendix: その他のアプローチ SP／RIの検討 Graviton系インスタンスの採用を検討 分析にはTrusted Advisorや、CostExplorerのコストカテゴリ分類機能などが使える 所感・まとめ 割と基本的な部分だけでサクッと終わってしまった感はありますが、裏を返せばコスト分析は何か銀の弾丸があるわけではなく 地道に泥臭く分析・対応していく必要がある という話でもあります。 こういう類の内容はなかなか実環境でお試しで手を動かせないので、その意味で有用だったかなと。 コスト最適化に本腰を入れていくにあたって、頭ではわかっていたことの予行演習として丁度よく、またre:Invent初日午前中のセッションだったためイベントの肩慣らしにもなりました。 投稿 【AWS re:Invent2023セッションレポート】AWSコスト分析ワークショップ は マイナビエンジニアブログ に最初に表示されました。

セッション概要 タイトル SUP302-R1 | Detect, investigate, and respond to security incidents 説明 In this workshop, dive deep into security anomaly scenarios like exposed AWS access keys, insecure security group ports, Amazon EC2 port scanning, and unauthorized resource launches. Perform discovery, diagnosis, troubleshooting, resolution, and root-cause analysis. Learn how to correlate data from sources like AWS CloudTrail, IAM Access Analyzer, AWS Config, and AWS Trusted Advisor. Discover how to respond to incidents using AWS Systems Manager, AWS Lambda, and Amazon CloudWatch Events. In all of these hands-on scenarios, get the opportunity to explore Trusted Advisor findings, different log types, automated audit rules, and alerts. You must bring your laptop to participate. 補足情報 Keynoteの裏だったためか並びは予約・非予約とも控えめでしたが、なんだかんだ開始時刻には8〜9割くらいは埋まってました。 前説が15分・Workshop105分くらいの配分で、Workshopは概ね90分前後で退出者が増えてくるくらいのボリューム感でした。 私は他の業務対応を少しやりつつ進めて100分くらいで完了。 内容 アジェンダ AWSユーザーが直面する主なクラウドセキュリティ上の課題 Trusted Advisor、GuardDuty紹介 AWSのセキュリティサービス俯瞰 Workshop AWSユーザーが直面する主なクラウドセキュリティ上の課題 クラウドセキュリティとは具体的に何か、どう手をつけたらいいのか インシデントの検知方法、発生時の対応方法 GuardDutyやTrusted Advisorの紹介に繋げるためのお決まりの話題という感じ。 Trusted Advisor、GuardDuty紹介 この手のセッションにしては珍しく？　Security HubやInspectorやDetectiveに関してはあまり触れずにこの2つの紹介に絞ってました。（ワークショップではSecurity Hubも出てきましたが） Trusted Advisorは無料でとりあえずこれだけ調べられますよ、という感じの紹介だったのでどちらかというとクラウドセキュリティにこれからゼロベースで着手する人向けの話題。 AWSのセキュリティサービス俯瞰 前提として、セキュリティのモニタリングは継続して行うこと Inspector、Macie、GuardDutyで検知→Security Hubで集約→Detective、Security Lakeと連携 Macie、Inspector、Detective,SecurityLakeをSecurity Hubと連携させる点に関して、社内では現状の優先度を低くしているが、どこかのタイミングで再確認しておく AWSのセキュリティサービス一覧 「セキュリティ」の括りだと色んな角度のサービスが入ってくるため流石に多い Workshop モジュールは3つ。 Detailで触れる中でConfigやIAM Access Analyzerには触れなかったような気がします。 モジュール1、2は低難易度ですが3は多少実践的になりました。 Module1: Trusted AdvisorとIAMによる不正挙動検知。 心当たりのないIAMユーザーが作られている、というところからスタート Trusted Advisorで状況確認 Security GroupでRDPやMySQL用のポートが0.0.0.0/0で開いていることを確認→対応 SGから関連して、EBSスナップショットが作られて知らないアカウントに共有されていることを確認 ここはTrusted Advisorでは出てこないので、現実の対応としてはIAMユーザーやその他盗られた認証情報ベースでCloudTrailを調べて検知するか、或いはIAMユーザーのAccess Advisorやポリシーから関連リソースを全て洗うような流れになると思われる EBSスナップショットをアカウント指定で共有ではなくPublicにされることもありうる（こちらはTrusted Advisorで拾える）→実際にやってみてTrusted Advisorに検知されるか確認 Module2: GuardDutyによる検知と対応 GuardDutyの使い方 IAMクレデンシャルを実際に抜いてみる インスタンスプロファイルとして設定されているIAMロールのクレデンシャルを抜いて不正アクセスを試みる、という流れで、いわゆる「IAMユーザーはアクセスキーが危険だから作るな」という話から一歩進んで「IAMロールだからって100％安全ではない」という内容になっていました。 数年前であれば、まず「極力ユーザーを使わない」みたいな話から入ることが多い印象でしたが、最近はもうその前提は共有されている認識か。 抜いたクレデンシャルでS3にアクセスを試みてGuardDutyに検知されることを確認 Module3: 攻撃者の挙動追跡と対応 1,2は前座でここからが本番。 GuardDutyから不審な挙動（脅威IPからのアクセス、EC2用のロールのクレデンシャルがEC2外から利用された）検知 別の検出結果で、問題のEC2インスタンスへのブルートフォース攻撃を検知 「自分が攻撃対象となった」場合の重要度はLowなので注意 CloudWatch Logsに流している/var/log/secureからブルートフォース攻撃が成功したかどうかを確認 →成功していたのでOS設定でIDパスワード認証が有効になっていないか確認→無効化 他の可能性として、IAMポリシーからS3を自由にできたことがわかるのでS3を調査 Security Hub Insightsで確認 マネージドインサイトの1つ「Top S3 buckets by counts of findings」でGuardDuty等で検出された結果が多いバケットを確認 確認したバケットの個々の不審アクセスについてGuardDusyのS3 Protectionで検出結果を確認 いくつか大量アクセスや不審IPリストからのアクセスがあったファイルがあり、かつ機密情報ファイルが暗号化されていなかったので、暗号化とバケット公開設定を修正 余録 GuardDuty検知→EventBridge→Lambdaで、悪意のあるIPアドレスを検出したらNACLに拒否ルールを追加してインスタンを自動保護、というアーキテクチャの紹介 所感・まとめ Module3が本番で、概要だけ見ると割とGuardDutyのハンズオンとしては王道に近い部分もありつつ、色んなケースに触れて引き出しを増やしておけばそれだけ実際のインシデント対応で視野が広がるので、やって損はないWorkshopでした。 GuardDutyもSecurity Hubもそれ自体のオペレーションはシンプルなので慣れていた部分もありますが、Security Hub Insights等、まだまだ使いこなせていないサービスもあると実感しました。 （使いこなせる＝それだけインシデント対応を経験してるということなので、ある意味使いこなせていないくらいが健全なのかもしれないですが） マイナビにおいてはGuardDutyは比較的活用しているものの、Security Hubやそれと連携できる各種サービスについてはまだ検討中だったり「入れただけ」になっている部分も多く、復習しながら改めてサービスの有用性を検証して導入・運用を検討していければと思います。 また、GuardDutyのオプション機能もここ1・2年で急速に拡充されており、今回のWorkshopにS3 protectionが含まれていたように今後も触れる機会があれば積極的に触っていきたいです。 投稿 【AWS re:Invent2023セッションレポート】セキュリティインシデント対応 は マイナビエンジニアブログ に最初に表示されました。

セッション概要 タイトル SUP306 | Troubleshooting in the cloud 説明 How do you troubleshoot large-scale applications running on AWS? Using time-tested troubleshooting methodologies and AWS services to accelerate the diagnosis and resolution of operational issues, see how to use Amazon CloudWatch, AWS Config, AWS X-Ray, and AWS AI services to set up appropriate proactive and reactive monitoring and automated mitigations. In this workshop, choose your preferred domain (i.e., compute/networking, containers, databases, or serverless/DevOps), and then work on triaging issues using techniques and best practices shared during the workshop. Come learn how to securely approach troubleshooting at scale on AWS and use pre-trained AWS AI services to accelerate coding. You must bring your laptop to participate. 参考情報 会場がMGM Grandでしたが、VenetianのWorkshopより少し狭かったです。キャパが80人ちょっと？ この部屋だけなのかホテル全体の傾向なのかはわかりませんが。 満員御礼状態で、特に予約が多く、非予約の4番目くらいに並んでたんですが結構ギリギリで入れた印象です。 内容 アジェンダ Hear tips/methodologies for troubleshooting 観測サービス・ツール（AWS Nativeと外部SaaS） 対応方式 50/50 methods good vs. bad comparision method Controlled reproduction method Building timelines method Troubleshooting methodologies Should Should Avoid Workshop Hear tips/methodologies for troubleshooting 観測に使うツール群 クラウドのトラブルシューティングは多岐にわたり、それぞれの環境で効率的なトラブルシュートを行う必要がある アーキテクチャ、クラウド設定、アプリ、観測、カナリアテスト・デプロイ、ログ トラブルを正確に定義し、理解する 分析にあたってはいくつかの手法があり、一つ或いは複数の方法を使う 「網羅ではない」ところがミソ。 将来再発した際の問題解決時間を短くするために、手法の間違いは継続的に正していく 分析手法 50/50 methods 開始点と終了点の間でプロセスを半分(50/50)に分割し、トラブルが中間点で発生するかどうか確認 発生しているところを再度半分に分割し、中間点でトラブルが発生するかどうかを確認 以下繰り返していくことで問題箇所を特定する 例: PrivateLink→NLB→ALB→ECS/EKS/Lambda→DB/外部サービス…と言った構成の場合　 good vs. bad comparision method 2つの似た環境の内片方で問題が起きている場合に、設定値やリソース利用状況を比較して原因を特定する 標準化が進めばこの方式が使われることが増えそう Controlled reproduction method ある程度自由にコントロールの効く環境に同じものを再現し、弄り回して原因を特定する 別リージョンや別アカウントにデプロイしてみる等 Sandbox環境があればそれを使うのもあり 例: CodePipelineでCloudFormationを使ってSAMをデプロイするのに失敗する場合、問題のテンプレートを別アカウントで直接デプロイしてみるなど Building timelines method 「いつ問題が発生したか」と「そのタイミングで何の変化があったか」を整理して問題を特定する 問題発生のタイミングや期間に合わせてその時の設定を適用して追跡 場合によってはロールバックで解決できる Should 何らかのパターンを示す数値がないか細心の注意を払う 問題解決後は5つ「なぜ？」を追求して振り返る 各計測値のパーセンタイルをきちんと理解する 内外のチームに、ログやメトリクスの改善による透明性を求める メトリクスが示す意味について透明性を追求する Trust but Verify. 信頼はするが検証する。 Should avoid 確証バイアス これまで検証した内容を追跡しないまま場当たり的なトライ＆エラーを繰り返す 一度に複数のものを変更する データの裏付け抜きに2つのできごとや事象に相関関係を見出そうとする 原因と結果の混同・逆転 自分が今見えている範囲のメトリックしか見ない 原因は別のところにある可能性を常に考慮するべき 問題が起きるまで監視基盤の構築を先延ばしにする 関連資料 Workshop 4つのテーマでラボが用意されており、どれか1つを選択して着手する方式 Networking and Web services DevOps and serverless Containers Database 今回はDevOps and serverlessを選択 NetworkingやDatabaseの方が既存の知識は活かせそうだったが、折角なのでより今後に活かせそうな方にしました ちなみにre:Invent後も続きはできる模様 折角なので全部やってまたまとめたいと思います Devops and serverless 対象の構成 Code PipelineでSAMスタックをデプロイしている構成 PipelineはCodeCommitからソースを引っ張ってCodeBuildでSAMテンプレートからCFnテンプレートをビルドしてCodeDeployでデプロイする構成 SAMアプリはAPI GatewayとLambdaとDynamoDBでユーザーデータの登録と取得を行うもの。言語はJS。 CodePipelineに3つ、SAMアプリに3つそれぞれ問題があり、順に解決していく CodePipelineは直接編集する権限がなく、CodePipeline用のCFnスタックを修正して対応する ここが地味に面倒で時間を食った。Cloud9の利用が推奨されており環境が用意されていたが、そこにCodePipeline用のCFnテンプレートがなく直接中身を確認するしかない・デプロイ時にいちいちダウンロードとアップロードをする必要があるなど。 家でやる場合は最初からローカルで環境作った方が楽そう。 Source、Build、Deployそれぞれに一箇所ずつエラーの原因となる要素があり、それらを自力で特定して改善する ひとつ一つは「まぁよくあるアレだよね」みたいなノリでサクッと特定できる内容で、環境の操作で時間はかかってもそこまで高度ではない印象 SAMアプリの3つの課題のうち1つ目が終わったあたりで時間切れ。 あとで再トライしたら続き書きます。 所感・まとめ これまで受けたWorkshopの中でもかなり充実した部類 前説でこれまで頭の中でごちゃっとしていたトラブル対応手法がかなり整理された 「新しいことを知る」より「整理する・網羅する」趣が強いためか、比較的英語も理解できました。 スピーカーのうち1人がそれなりに早口だったため、そこだけはほぼフィーリングでしたが… Workshop本番も、ヒントや回答も用意されているものの、多少の経験があれば自力で辿り着ける良い塩梅でした 分析手法の選択肢には事前の準備が無ければできない物があり、共通基盤の管理部門としてはここを全体に提供することでトラブル対応の工数を減らせそう 例えばControlled reproduction methodはSandbox環境がカジュアルに提供できれば選択肢としての有用性がぐんと上がる トラブル対応時にはどうしても焦りのせいで手当たり次第に色々やりがちだが、順序立てた対応の重要性が改めて整理できた 「トラブルが起きてからではなく予め追跡ができるよう監視基盤は作れ」というのは、肌で感じないと中々実行できないものだが、こうしたハンズオンでログやメトリクスの有り難さを感じて定期的に意識を高めておく必要があると感じた 投稿 【AWS re:Invent2023セッションレポート】クラウドにおけるトラブルシューティング は マイナビエンジニアブログ に最初に表示されました。

はじめに タイトルの通り、ラスベガスで行われたAWS re:Invent 2023にマイナビからも5名のエンジニアで参加してきました！ 本記事では参加者を代表して、イントロダクションとしてマイナビが今回とった参加スタイルとイベントの所感をここにまとめたいと思います。 AWS re:Inventとは Amazon Web Service（AWS）社が年に一度開催する、単独企業主催イベントとしては世界最大規模の技術カンファレンスです。 2012年より毎年ラスベガスにて開催しており、今年で12回目となります（2020年のみCOVID-19の影響でオンライン開催）。 https://reinvent.awsevents.com 日程: 2023/11/27 Mon. ～ 2023/12/01 Fri. 参加規模: 全体で50,000人以上、うち日本人は1,700人（AWS Japanによる速報値） コンテンツ Keynote（基調講演） 2,200以上のテクニカルセッション 100以上のスポンサー出展ブース 会期中200を超えるサービスアップデート 各種アクティビティ マイナビの動き 参加メンバーの5名はそれぞれ業務上のロールや興味領域が違うこともあり、5人で固まって動いたのは最初のRegistrationだけで、その後はいくつかのKeynoteが被ったのを除いて基本的に 英語もろくに話せないのに バラバラに行動してました。 （ある程度固まって動く会社さんも多いようで、他社の方に話すと結構驚かれました） 会場がホテル6軒にまたがっていてとにかく広いですし、慣れない海外で何かトラブルでもあったら大変なので、自分の居場所や参加セッションについてはこまめにSlackで連絡を取るようにしていました。 帰国後にとったキャプチャなのでJSTになっていますが 今にしてみれば、半日くらいは固まって動く日があった方が良かったかもしれないとは思いつつ。。。 会社でチームを組んでGameDayに出たりできなかったのも少し勿体なかったです。 Registration手続きの際は、とりあえず 受付だけで国際展示場のホール一つ分くらいあったのが衝撃でした。 写真左側に電光掲示板もどきがありますが、これは参加者がサイリウムみたいなスティックで自由にドットを打つことができる代物で、色んな人が社名やロゴを入れたりスーパーマリオの再現をしたりして遊んでました。 ということで折角なので。 また、受付ホール手前の広場にあった黒板にも社名を書いておきました。 書いた直後、他社の方から「あ、マイナビの方なんですね～」と気軽に声をかけていただきまして。 ただ社名を書き入れただけのことなんですが、「あぁ、私たちは今re:Inventに参加しているんだな」という気分になりました。 我ながらちょろいですね 実際にメンバーが参加した各種セッションやアクティビティの様子は 個別に記事 を参照いただけますと幸いです。 ※会場やセッション、各種アクティビティについて俯瞰的にまとめた記事はこちら ラスベガスにてAWS re:Inventに行ってきました!!! (生活編)～ 所感 今回マイナビではre:Invent初参加となりましたが、参加してみてメンバーで改めて感じた re:Inventに参加するメリット は以下の通りです。 何よりもまず現地の規模感を感じられること 特にKeynoteは現地で聞くことで、新サービスへの期待度、「世の中がAWSの新技術を期待している」ということの実感を得られる ラスベガスという土地で6個ものホテルをおさえ、基調講演のみならず食事会場や打ち上げ（re:Play）会場まで圧倒的なスケールで用意されている → 一企業のイベントでこれだけ人が集まるのかという実感 現地ならではのWorkshop等のセッションによる技術向上体験 これまで触ったことのなかったサービス（新サービス含む）をある程度触れるようになった ロールが変わってAWSを触る時間が減っていた中、Workshopで実際に手を動かすと思った以上にAWSヂカラが落ちていたのを痛感した GameDayやEXPO等、現地交流などを通して、他社のAWS利用状況を肌で感じられる 日本で事例を聞いてるだけではわからない、「案外基本的なところで詰まってる人が多い」「このジャンルのセッションにはこれだけ需要がある」「このサービスにみんな関心があるんだ」といった生身の感覚が掴める 日本企業相手においても、日本人同士というだけで声がかけやすいというのもある モチベーションアップ Keynoteで新サービスが発表されたときに、ワクワク感が会場全体に伝播していく感覚は現地ならでは 各セッションやアクティビティを通じてとにかく「AWSをもっと触らないと損だ」という気分にさせてくれる 意識の変革 Werner Vogels氏のKeynoteをはじめとして、現地でいろんな話を聞くとエキスパートが皆コストに対する意識が高いのがわかり自分も敏感になった Amazonの機能開発における、Tierによるコストを意識した優先順位決定プロセスが特に印象的。 単なる削減一辺倒というわけではなく、観測性を上げて「開発者も含めた全員が常にコストを意識し、サービスの機能がそのコストをどれだけペイできるか検討して開発優先度を決定する」が徹底している。 AWSとパートナーと3rd partyのモデルや、クラウドインフラのプロバイダーとしてのグローバルなビジネスモデルの一端を理解できたし、そういう見方ができるようになった おわりに 海外での開催ということで気軽に参加というわけにもいかないですが、クラウドに携わる人間にはコストを上回る魅力のあるイベントであったことは間違いないと思いますし、またそれに見合うくらいにAWSを使い倒していこうと思います。 AWSを触っている人もそうでない人も、このブログに上がっている記事を読んで少しでもモチベーションアップにつなげていただけるならば幸いです。 投稿 AWS re:Invent 2023全体レポート は マイナビエンジニアブログ に最初に表示されました。

はじめに こんにちは！ 株式会社マイナビで内製開発をおこなっている A.K です アメリカのラスベガスで開催された AWS:reInvent 2023に参加してきました 今回私は初参加だったので実際参加してみてre:Inventの生活がどんな感じだったまとめようと思います 次回参加者の参考になればとても嬉しいです! re:Invent とは AWS re:Inventとは米国ラスベガスで開催されるAWSイベントです AWSのサービスに関連したセッションに参加したり、Expoで最新の技術に触れたりなど様々な体験をすることができます 今年は11/27~12/1の期間で開催でした 詳しくは 公式サイト を確認ください 何ができるの？ re:Invent では下記のようなことができます 新機能が発表される keynote に参加 AWS のサービスなどについて学習できる セッション に参加 各企業の新サービスの展示会 Expo に参加 re:Inventの打ち上げ re:Play に参加 エンジニア同士のネットワーク作り 食事 アクティビティ SWAG 会場はどんな感じ? 会場 会場はひとつの場所で行われるのではなく6つのホテルで行われます セッションがそれら6つのホテルの部屋でそれぞれ開催されます Expo やre:Playは特別会場が用意されています 食事は専用の会場にもありますが、廊下でも軽食が食べられるようになっています 移動 会場間の移動は徒歩、バス、電車、タクシーなどを利用します 今回バスと電車を利用しましたが参加者は無料で利用できました 基本的には徒歩で移動できますが一部のホテルはバスか電車での移動が必須です 徒歩での移動といってもホテルが大きいのでセッション会場から別のセッション会場への移動は少なくとも 30 分はかかりました バスや電車の移動の場合だと一時間ほどかかりました 休憩 休憩する場所はあるにはあるのですが足りてはいないので廊下の床で座ってPCをいじっている人が多くいます AWS資格を持っている人のみ入れる認定者ラウンジもありますがまあまあな人がいます 会場移動用バス停　↓ keynote について 今年の keynote は以下の通りでした Peter DeSantis, SVP of AWS Utility Computing Adam Selipsky, CEO of AWS Swami Sivasubramanian, VP of Data and AI Dr. Werner Vogels, CTO of Amazon.com keynote は AWS の新サービス、新機能についての発表会です! 時間帯は朝早く主に8:30~10:00にあります この時間帯にもセッションが開催されておりkeynoteに参加せずセッションに参加する人も多くいます またkeynoteの時間帯は会場中でkeynoteが配信されているので会場以外でも見ることができます 朝ごはんを食べながら見たり、クッションで横になりながら見てる人など様々いました またyoutube配信もされるので日本でも見ることができます 現在も見ることができるので興味がある人は見てみてください Keynoteに関しては別記事でまとめたので是非読んでみてください!! ラスベガスにてAWS re:InventのKeynoteに現地参加してきました!!!～ セッションについて セッションは何種類かありました 私は主に Chalk Talk,Code talk, WorkShop に参加しました 基本的に言語は英語です 英語が苦手な場合はottorなどの文字起こし機能などを使うと良いと思います セッションへの参加方法は予約と待機列に並ぶ方法の2通りあります re:Invent開催より前にアナウンスがあり特設サイトやスマホアプリで予約ができるようになります 開催日が近くなってくるとほとんどのセッションは予約で埋まってしまうので早めの予約をおすすめします 仮に予約できなかった場合は当日予約枠とは別に Walkup と書かれた待機列があるのでそちらに並んで入ることができます 待機列枠用にある程度は席が確保されているらしいですが真偽は不明です また並んでも入れないケースが割とあるので人気なセッションは30分から1時間前には並んでおいた方が無難です それほど人気でないセッションも 少なくとも20~30分前には並んで置くことをおすすめします セッション詳細 Breakout Session 講義系のセッションです 基本的に聴衆は聞く形式のようです Breakout Sessionについては後ほどyoutubeで公開されます 今回私は参加していません Chalk Talk 講義だけでなく聴衆からのアクションがあるセッションです 聴衆からのアクションとしては下記のようなものがあります 聴衆からの質問 講義者からの質問に対しての回答 講義者からの質問に対して挙手での回答 聴衆からのアクションを求められますが聞き専でも特に問題はありません またホワイトボードを用いて説明がされることもあります このセッションは後に公開されないので英語が苦手な場合はottorで文字起こしをしておいたりスライドの撮影などをしておいたほうがよいです 講義後にも質問可能です ホワイトボードでの説明　↓ Code Talk 講義系のセッションです 私の参加したCode Talkはセッションの 9 割がデモでした 個人的にはスライドが少なくデモが主なのでセッションの内容を自分でも触ったことがある人でないとメモや記録をとりずらく後学に活かすのは難しそうでした WorkShop AWSのサービスを実際に触っていきながら学ぶセッションです 最初に10分ほどセッションの内容について説明がされます その後ワークショップの具体的な説明や解説が書かれたサイトのURLとAWSのラボ環境が与えられます 自分の参加したワークショップではAWSのラボ環境を使うので自分のAWSアカウントで作業する必要はないので費用は発生しませんでした セッションはワークショップの具体的な説明や解説が書かれたサイトをみながらハンズオン形式で進めていきます 基本的にはみんな一人でもくもくとおこなっています 詰まったり+αで質問したいことがある場合はその場で講師やスタッフに質問できます ワークショップの分量が多いこともあり、私も終わらないワークショップがありました ワークショップによっては公開されているものもありますが、ないものもあるので後学にいかすためには記録に残せるようにしてくおくといいと思います 会場の様子　↓ GameDay Gamedayは与えられた課題を解いていき参加者同士で順位を競うセッションです 今回私は Expoで開催されていたGamedayに参加しました Expoで開催されているもの以外にも他セッションのように各会場で開催されているものもありそちらが一般的なGamedayになります ExpoでのGamedayは指定された時間はなく参加したいタイミングで参加できました 私の参加したGamedayだと一人でもチームでも参加できました ワークショップ同様にラボ環境が与えられそこで作業をおこないます Gamedayはre:Inventの中でも人気の高いセッションで参加予定の場合は早めの予約をおすすめします Expo について 様々な企業がブースを出して自社の新サービスなどを紹介している会場です 主に5つのエリアがありました infrastructure Solutions Zone Data Zone Security Zone Developer Solutions Zone AWS for Industries Pavilion 私はDeveloperだったのでDeveloper Solutions Zoneを主に回りました Dockerやgithubなど普段使っているサービスだけでなく、普段の開発経験を向上させるサービスも多くあり使ってみたくなるようなものばかりでした また会場中にドリンクや軽食があるので食べながら参加でき、夕方にはアルコールも提供されます Expoでは実際にサービスについて企業の人と話せるので刺激がありre:Inventにきたらセッションだけでなくこちらも回ってみることをおすすめします 初日のオープンと同時に多くの人が入場していきました 会場の様子　↓ re:Play について re:Play は re:Invent の最終日の前日夜に開催された打ち上げパーティーです 主にライブとアクティビティがありました ライブは２会場ありどちらも多くの人でにぎわっていました アクティビティは数多くなじみ深いものだとドッジボールがありました 今回私は１時間ほどのみ参加となってしまったので次回参加の機会があればライブ等も全力で楽しんでいきたいと思っています 会場の様子　↓ ライブ　↓ アクティビティ　↓ エンジニア同士のネットワーク作り 世界各国から様々なエンジニアが訪れています 多国籍な多業界のエンジニアと話をすることで刺激になります 日本でのイベントと違ってラスベガスのイベントだからこその醍醐味だと思います セッションやExpoで関わるだけでなく ミートアップ専用のセッションもあるみたいでした ネットワーク作りが目的の人はこちらを訪れると良いかもしれません 食事 食事は基本的に会場内で全て完結できます 朝食や昼食はいくつかのホテルに専用のとても広い会場があります　↓ 食事はこんな感じです　↓ 朝食でも甘めのもの多かったです テイクアウト用のごはんもあります　↓ 認定者ラウンジや廊下にもいたるところにこんな感じでドリンクや軽食が置かれています　↓ アクティビティ re:Inventにはkeynoteやセッション以外にもアクティビティが多くあります 現地でお話をした日本人の方から聞いたのですが5kmマラソンといったアクティビティもあったみたいです アクティビティの専用の会場がありました フットボールやゴルフ、カードゲームなどたくさんありました チームゲームが多めなので同行している方と複数人で訪れるといいかもしれません！ それ以外にも息抜き用のゲームなどもできます　↓ SWAG SWAGはお土産の事です re:Invent参加にした際にもらえるSWAGやExpoでもらえるSWAGだけでなくセッションでもサービスのステッカーなどをもらえたりします SWAG以外にもAWSの公式グッズショップもあったので気に入ったものがあったら買ってみてはいかがでしょうか? 今回もらったSWAGはこちらです　↓ 普段使っているサービスのSWAGももらえたのでうれしかったです! まとめ 読んでいただきありがとうございます re:Inventはセッションだけでなくアクティビティなど色々盛りだくさんなイベントでした 今回私は re:Inventに参加してみてこの規模のエンジニアイベントに参加したことがなく圧倒されました それと同時に世界中のエンジニアと関わる中でエンジニアリング対する熱量や考え方に触れ、AWSをもっとマスターするだけでなく技術力を上げていきたいとモチベーションがとても向上しました 本記事が次回参加者の参考になれば幸いです！！ 投稿 ラスベガスにてAWS re:Inventに行ってきました!!! (生活編) は マイナビエンジニアブログ に最初に表示されました。

はじめに こんにちは！ 株式会社マイナビで内製開発チームに所属している A.K です アメリカのラスベガスで開催された AWS:reInvent 2023 に参加してきました 今回はイベントの目玉であるKeynoteに現地参加してきましたのでそのことについて記事を書こうと思います 今回参加したkeynoteはAWSのCEOのAdam Selipskyさんの基調講演になります 本記事はKeynoteのまとめというよりは現地で感じたことなどをメインに書いていこうと思います! 次回参加者の参考になればとても嬉しいです! re:Invent とは AWS re:Inventとは米国ラスベガスで開催されるAWSイベントです AWSのサービスに関連したセッションに参加したり、Expoで最新の技術に触れたり…様々な体験をすることができます 今年は11/27~12/1の期間で開催でした 詳しくは 公式サイト を確認ください Keynoteとは KeynoteとはAWSの新サービス、新機能の発表会です 単に新サービスを発表するだけでなく、AWSの考え方や思想なども交えて説明されるので聞いていてとても勉強になります 今回、現地参加したAdam SelipskyさんのKeynoteでは下記の発表がされました Amazon S3 Express One Zoneの発表 AWS Graviton 4 / EC2 R8gインスタンスの発表 AWS Trainium 2の発表 BedRock関連のアップデート Amazon Qの発表 　etc.. このようにAWSに関わる新しいアップデートの発表がKeynoteではされます KeynoteはYoutubeでも視聴可能ですので興味のある方はぜひ見てみてください AWS re:Invent 2023 - CEO Keynote with Adam Selipsky 会場の様子 講演は朝8時ごろから開始でした Keynoteは初日を除いて朝早くから行われます 今回参加したKeynoteは二日目の朝に開催されるKeynoteでした 前日はre:Invent初日ということもあり、体力が尽きるまでセッションをまわったりExpoで話を聞いたので、朝早くからのKeynoteは体力的にも眠気的にもなかなかのしんどさがありました ただ一回は必ずKeynoteに現地参加したいなと思っていたので会場へ向かうことにしました 会場はre:InventのExpoなどがあるメイン会場です 会場のホテルに向かうとAsk Me!のTシャツを着たAWSのスタッフの方が元気よく「keynoteはこちら！」という感じで案内しているので迷うことはありません 会場への玄関ドアに向かうと人だかりができていて結構混んでいました　↓ 会場へ入るとバンドがライブをしていました　↓ 私は会場へは数十分前には着いたのですが9割方の席は埋まっていました　 会場がオープンすると同時に行った人に聞いたところその時点ですでに多くの人が並んでいたようです 前のいい席で見たい人は早めにいくといいかもしれません また、講演が終わり会場を出る際に気づいたのですが会場の入り口付近に同時翻訳機がおいてありました Keynote開始 現地で見る導入の映像演出は迫力がありました 「AWS、今年は何をみせてくれるんだろう」という気持ちにさせてくれるようなスタートで、単なるITのイベントではなく最大規模のイベントAWS re:Inventにいるんだということを再認識させてくれます しばらくするとAdam Selipskyさんがでてきて講演がはじまりました 今回のre:Inventは 5万人 も参加しているみたいです 世界各国から5万人も集まっていると聞くとその規模に驚きます 「re:Inventは学習イベント」 だということを強調されていました re:Inventは数多くのセッションやExpoの参加企業から様々な気づきや学びを得ることができる最高の場所で、かつ多くの関連企業やAWSコミュニティとつながりをもつことができます 現地でしか感じ取れないAWSに対する情熱や温度感をダイレクトに受け取れるのがre:Inventの最大の醍醐味です 講演でも話されていましたが世界各国から多国籍、他業界の人が訪れるので様々な課題やユースケースがあり色々な話を聞くことができます 私はweb業界で国内との関わりが多いのですが、re:Inventを通してゲーム業界の方や、日本以外の各国の企業の様々なロールの人とお話をすることができました 普段はwebアプリの開発をおこなっていますが、その中で自分が躓いていたりすることが他企業でもおこっていたり、普段実装しないようなサービスのユースケースの話をお互いの考えを交えながらできたりと、このようなことができる場はなかなかないと思います AWSは様々な企業と協力していて金融業界、ヘルスケア業界など様々な業界がAWSを利用しています 例えばSalesforce社があげられており、Salesforce社のCRMに特化したAIのSalesforce EinsteinとBedrockで使って生成AIアプリをすぐにデプロイできるようになったりするそうです re:Invent参加前はAWSはひとつのITツールぐらいの認識でいましたが、多くサービスがAWS上で動いており様々な業界や企業にとってなくてはならない存在になっており、AWSは本当の意味でインフラであることを知りました re:Inventは日本語訳で 「再構築する」 という意味です これはAWSのDNAに組み込まれています スライドに「Access to the same powerful technology」という標語が使われておりAWSの考え方がダイレクトに理解できました 新サービス発表 reinventing storage with Amazon S3 S3は最初2006年に発表されたらしいです AWSについての歴史はあまり知らず思ったより昔で意外でした そしてIntelligent-tieringは今までに 20億ドル の節約をしているみたいです とんでもない金額ですね ストレージというお金をかけたくないけど重要な部分がゆえに力が入っているのを感じました ここでS3の新機能発表がされました Amazon S3 express One Zone このS3は高性能分析のワークロード向けのS3になります 気になった特徴は下記の点です S3標準ストレージより最大10倍高速 一分当たり数百万件のリクエストに対応しコストも最大60%節約 One Zoneなので単一AZとなります 機械学習関連やリアルタイム広告配信など、ここぞという場で使いそうな場は多そうです 詳しくは 公式サイト でも説明されていますので是非読んでみてください Reinventing General Purpose Computing パフォーマンスとコストを考える中でGravitonの説明もされました GravitonはEC2インスタンスで使用されるAWSによって開発されたカスタムARMベースのプロセッサです 今回のre:Inventでは新しく AWS Graviton4 が発表されました AWS Graviton4 Graviton4は以下のようなポイントがあります Graviton3より平均30%高速 データベースアプリケーションで40%高速に Javaアプリケーションで45%高速に 特定のワークロードに対してとても活躍しそうです Javaは採用している企業も多いと思うので影響範囲は大きそうです わずか5年でGraviton4に進化しているとのことで驚きです Graviton4に関連して R8g Instances for EC2 Powered by AWS Graviton4 も新しく発表されました Reinventing with Generative AI AWSはAIをAmazon全体のサプライチェーンの最適化や小売検索機能の向上など多くの場面で活用してきました AWSはgenAIを現在のAI技術の次のステップとして位置づけています genAIを3つの階層に分けての説明がされました 最下層はFmモデルなどの層 中間層はLLM棟のモデルで生成AIアプリを構築、拡張するための層 最上層は専門知識がなくてもすぐに生成AIを使用できるような層 Fmモデルなどの最下層 最下層のワークロードでは大きな計算能力を必要とし、GPUがそれを可能にします AWSはNVIDIA社と協力してGPUをクラウドでつかえるようにしてきました 今回のKeyonteではNVIDIA社のCEOのJensen Huangさんが講演にきました このように世界的な企業のCEOをお話を聞けるのはre:inventならではです ここではNVIDIAとAWSが共同でNVIDIA DGXクラウドのAWSに導入するなど新たに様々なことを発表していました AWS内で完結せずに他の企業と共同で技術が進化しています この後にもNVIDA社以外にもがファイザー社など様々な企業の方が何人か講演されていました AWS Trainium2 AWS Trainiumは機械学習モデルをトレーニングするための専用チップです 今回その第二世代であるAWS Trainium2が発表されました 特徴としては下記です 第一世代より４倍はやい 数千億、数兆のパラメータを持つ基礎モデルのトレーニングに最適 65エクサフロップスの非常に高速な計算能力な性能 自分は普段機械学習系をメインで扱っていないので詳しくないですが、それぞれの単語のインパクトが強くgenAI界隈は進化が早いことを感じます 生成AIアプリを構築、拡張するための中間層 多くの企業はモデルを構築するというよりは既存の優れたモデルを利用してサービスに価値を付加していくことが多いでしょう 実際に開発する中で数多くある優れたモデルからどのモデルを選べばいいのか、どうやって迅速に構築デプロイができるのかなどの課題があると思います そんな課題を解決していくのが中間層になります Amazon Bedrock Amazon Bedrockについて紹介されていました Amazon Bedrockは、Amazonなどが出している高性能な基盤モデル (FM) を単一のAPI で選択できるフルマネージド型サービスです 私は触ったことがありませんが生成AIアプリの構築が楽になり幅が増えそうなので興味をもちました 生成AIアプリの構築を考えるうえで選択肢の一つとなりそうです 9月に一般提供されたばかりですが、すでに10000を超える企業がBedrockを採用していてスピードがとても速いです 実世界ではすべての事象に対応した完璧なモデルがないため、AWSはAmazon独自のモデルだけを利用してもらうのではなく、様々な企業のモデルを使えるように幅広い選択肢を持たせているようです このような発想からAWSの思想を感じることができます また、Fmモデルの提供しているAnthropic社のDario Amodeiさんの公開対話のなかで ハルシネーションにも触れられており、これからの生成AIの安全性についての話は興味深かったです Bedrockでもいくつか新機能が追加されました Fine tuning Cohere Command Lite, Meta Llama2, Amazan TItan Text Lite & Express,Anthropic Claude Retrieval Augmented Generation (RAG) )with Knowledge Bases Continued Pre-training for Amazon Titan Text Lite & Express Agents for Amazon Bedrock Guardrails for Amazon Bedrock 2つ目と5つ目が個人的に興味深いものでした 2つ目は既存のFmで社内のデータベースに安全に接続でき、ドメインにより関連した検索が可能になることから検索サービスやドキュメントサービス周りで活躍しそうです 既存のモデルを基に社内データベースでデータで拡張できるのはとても便利です 5つ目は責任あるAIポリシーに基づいてフィルタリングを書けることができるものです それ以外にも個人情報(PII)の削除等もできます 近年責任あるAIが重要視されていますがその部分のサポートになります この部分は企業がサービスを提供する上で敏感にならざるをえない部分なのでこのようなサポートはありがたく、ますますビジネスでの活用が増えそうです AWSの学習について 話の途中でAWSの学習についても触れられました AWSはAWSCloud InstituteやAI Readyなどの学習リソースの提供や機械学習関連の奨学基金の創設などを行っています また2025年までに2900万人がクラウドコンピューティングを無料で学べるように取り組んでおり現時点で2100万人です 普段仕事をしていると感じませんが世界中のとても多くの人がクラウドコンピューティングを学習しているのを実感しました 専門知識がなくてもすぐに生成AIを使用できるような最上層 例えば代表的なサービスはAmazon CodeWhispererです 私は普段Webアプリ開発をおこなうことが多いのでこの層のサービスを扱うことが多そうです しかし、多くのAIチャットアプリは会社の内部情報をもっていませんし、その利用も禁止されている場合が多いです そんな中で今回のKeynoteで一番の目玉である Amazon Q が発表されました Amazon Q Amazon Qは仕事でつかえるAIチャットアシスタントです まず、Amazon QはAWS上での技術的な構築をサポートします 主に下記のようなことができます Amazon Qにインフラ構成を聞きながらデプロイ 作りたいアプリのユースケースに合わせたAWSサービスの選択 トラブルシューティング フレームワークのアップグレードや非推奨のコードの置き換え　etc... 特に私がいいなと思った点はトラブルシューチングもボタン一つでおこなえる点です AWSコンソール上で作業を行う場合うっかりとしたミスが発生してしまうこともありますがひとつひとつ確認する手間が減ります　 コード変換に関しては必要な作業だけれどもなにか新しい価値を生み出すわけではないのであまりやりたくない作業ですが、この部分をやってくれるのはとても大きいと思います 実際の例としては2日間でJavaのアプリを1000個アップグレードしたと紹介されていましたがとても信じられません Amazon Qの恩恵をうけるのは開発者のみではありません 次に開発者以外の職種の方々も活用することができます Amazon QはGoogle DriveやSlackなどよく使われる40のデータソースとつながり、学習をします しかもこれはセキュアでプライベートに行うことができます デモではAmazon Quicksight上でビジネス上のデータについてAmazon Qへ質問をして回答を得ることをしていました 今までのグラフを作ったりデータを読み取ったりなどの作業は、基本的にAmazon Qに対して「○○について棒グラフをだして」や「○○の月次レポートを出して来月の推奨事項を作成して」などの自然言語で作業をすることができます またAmazon QはAmazon Connectで使えます 通話にAmazon Qが参加することも可能で応答をしたり関連記事のリンクを提供したりできます そして、通話後もその概要を自動で作成してくれます 自社のデータをにアクセスできてAIチャットをビジネスで使えるというAmazon Qは仕事の在り方を変えるようなサービスで驚かされました データ活用 Amazon RedshiftでZero-ETL integrationsがAurora Mysqlに加えて下記三つがつかえるようにすることが発表されました Amazon Aurora PostgreSQL Amazon RDS for MySQL Amazon DynamoDB ETL は、extract（抽出）、transform（変換）、load（読み込み）の略で今回の発表で上三つのデータbaseに対してもこのパイプラインの作成がゼロになり,これによりリアルタイムな分析が可能になります そしてAmazon OpenSearch ServiceでもZero-ETL integrationsがDynamoDBで利用可能になることが発表されました DynamoDBに対してOpensearchで検索できるのはかなり便利に感じます 上記以外にもAmazon DataZone AI recommendationsが発表されました Amazon Project Kuiper Kuiperは衛星通信サービスです インターネット通信が安定的でない場所にも届くようにする取り組みをAmazonは行っています 詳しくは こちら を確認してみてください 今回はパブリックのインターネット接続に加えてエンタープライズ向けのプライベート接続を発表しました おわりに 読んでいただきありがとうございました 今回Keynoteに現地参加してきました 現地では新しいサービスが発表されると歓声や拍手があがりその熱量に驚かされます 発表された新サービスに関連して新しくセッションが開かれるので興味があるサービスの場合は該当のセッションで内容を深めることもできます Keynoteの内容とともに現地の熱量に影響をうけ自身のAWSに対するモチベーションをあがりました 今後もAWSを頑張っていこうという気持ちになりました みなさんもre:Inventに訪れた際はぜひkeynoteに現地参加してみてください 投稿 ラスベガスにてAWS re:InventのKeynoteに現地参加してきました!!! は マイナビエンジニアブログ に最初に表示されました。