株式会社メドレー の技術ブログ
全1359件
こんにちは。 ジョブメドレー の開発チームでエンジニアをしている新居です。 はじめに 2020 年 4 月に、新卒エンジニア 3 名が入社しました。 入社後は新卒エンジニア研修を実施し、先日 8 月 25 日の最終報告会をもって終了しました。 コロナウイルスの影響で入社間もなくフルリモート勤務となり、不慣れなところもありましたが、本年度の研修の取り組みを紹介します。 2020 年度新卒エンジニア 研修の概要 メドレーでは昨年度から新卒エンジニアを迎えており、合わせて研修も開始しました。 初めての研修をどのような視点で計画・実施したかについては、昨年平木がこちらにまとめています。 2019 年度エンジニア新卒の研修について - Medley Developer Blog 今年は人事部のご協力もいただきながら、昨年の内容を少しアップデートして行いました。 研修の目的は、 新卒メンバーが同じ空間で互いに刺激し合いながら、社会人への思考転換をはかり、業務遂行に必要となる基礎知識とスキルを習得すること です。 研修は以下の 4 つのフェーズに区切って行いました。 研修のフェーズ 研修の内容 ここから 4 つのフェーズ毎に内容を紹介します。 フェーズ 1：社会人&メドレー基礎研修 1. オリエンテーション メドレーの事業や組織、大切にしている行動規範などの概要説明 セキュリティ研修とコンプライアンス研修 2. ビジネス研修 ビジネスマナー研修 ビジネススキル研修 ビジネススタンス研修（外部研修） フェーズ 1 では「医療ヘルスケアの未来をつくる」メンバーの一員として大切にして欲しいことを学ぶフェーズでした。 社会人としての最低限のマナーやスタンスは勿論ですが、メドレーで働く上で土台となるマインドをここで学び、 医療ヘルスケア分野の課題を解決する一員 として共にプロダクトを作るためのベースを築けたと思います。 フェーズ 2：エンジニア基礎研修 1. 開発基礎 1 講義「メドレーが求めるエンジニアとは」 ジョブメドレー と CLINICS の事業・プロダクトについての概要説明 Ruby on Rails（以下 Rails）の基礎トレーニング 2. 開発実践 チーム開発体験 3. 開発基礎 2 書籍 『Web を支える技術 -HTTP、URI、HTML、そして REST』 の輪読会 ドキュメンテーション研修とプレゼンテーション研修 中間報告会の準備と実施 フェーズ 2 から開発の研修がスタートしました。 開発基礎 1 開発の研修に入る前に、エンジニアの執行役員 田中から「メドレーが求めるエンジニアとは」というテーマで講義を行いました。メドレーがどういうエンジニアを求めているのか、目指すところの視点合わせを行い、これから行う研修に対する意識や取り組みの質を上げることを目指しました。 メドレーが求めるエンジニア像については CTO 平山の記事にも詳しく書いています。 メドレー平山の中央突破: THE エンジニア その後ジョブメドレーと CLINICS の事業・プロダクトについての概要説明、Rails の基礎トレーニングを行いました。メドレーのプロダクトは Rails 製です。Rails やウェブアプリケーション開発に慣れていない新卒メンバーは、Rails の基礎トレーニングで Ruby on Rails チュートリアル を使って基礎からみっちり学びます。 Ruby on Rails チュートリアルの進め方 ここで大切なことは、漠然とひたすら写経してチュートリアルを進めるのではなく、毎日のフィードバック会でしっかりその日の進捗や学びを共有し、不明点はメンターに質問してもらうようにすることです。 メンターは、新卒メンバーが理解が浅いまま進めてたり、理解していて欲しいところがいい加減になってたり、進め方や学びの方向性がズレてる場合などはアドバイスを入れて軌道修正することを心掛けました。 また「実際の開発ではこうだよ」といった実務を踏まえたアドバイスや、意識していることも伝えていきました。 20 新卒 S さんの感想 「毎日のフィードバック会の中で、その日学んだ技術がジョブメドレーではどのように利用されているのか、どういったことに留意して利用しているのかなどを確認できたので、現場の人の感覚を少しずつ知ることができた。」 新卒メンバーは毎日リズム良く進捗を出し、メンターは新卒メンバーのフォローと引き上げを意識し、成果を最大化できるよう努めました。 開発実践 続いて開発実践ではチーム開発を行いました。前回までは各自個別に進めていましたが、ここではジョブメドレーに関する課題解決を目的としたプロジェクトに対して、チームで向き合う研修でした。 開発実践の目的と達成すべきこと 実務ではチーム開発が基本となり、チームメンバーとの協働は必須です。学生時代に業務レベルのチーム開発を経験しているのは稀ですし、実務に入る前にチームでプロジェクト推進するとはどういうことかを知るのは、とても価値があると思います。 加えて、チームで課題をどう解決していくのかも、新卒メンバー同士で話し合って決める必要があるので、課題解決力も養われたと思います。 今回はプロトタイプを作って成果発表するところまででしたが、プロジェクト推進においてはスケジューリング、要件定義、各種設計、開発フローやコミュニケーションフローの整備、実装、テスト、などなど、やることは尽きません。 また、このプロセスの中で密なコミュニケーションが必要不可欠となるので、新卒メンバー間のチームワークも向上し、お互いのことを更に知ることができたと思います。 この段階で、チームでプロジェクトを推進することの全体感を知り、プロジェクト推進の苦悩苦闘を実体験できたのは大きな経験値になったと思います。 20 新卒 O さんの感想 「各機能の影響を互いに受けないためにブランチを細分化するブランチ戦略や GitHub を用いたコード管理について理解できた。一方で、UI を考える際にチームの各メンバーの認識のズレが生じたことや、序盤は各メンバーの進捗の詳細を把握できていなかったことから報・連・相の重要性を再認識した。」 20 新卒 T さんの感想 「初めてのチーム開発であったことから、実装の序盤は、どのファイルなら編集しても他のメンバーの作業に影響がないのか、動作確認のための画面を作るファイルは自由に作成して良いのか、どのテーブルから関係する他のテーブルの情報を含めた情報を取得をするかなどに悩んでいた。今になって振り返るとチーム内で話せば解決することに対して、技術的にも心理的にも難しさを感じた。」 ###開発基礎 2 フェーズ 2 最後の開発基礎 2 では、書籍 『Web を支える技術 -HTTP、URI、HTML、そして REST』 の輪読会を行いました。もっと前のフェーズでの実施も検討しましたが、開発基礎 1 と開発実践を経た後の方が書籍の内容の納得感が高くなるだろうという判断で、この段階での実施となりました。 その後、中間報告会に向けたドキュメンテーション研修とプレゼンテーション研修を行いました。仕事を進めていく上では、背景や目的を正しくステークホルダーへ共有しながら進めていくことが必要で、伝えたいことを適切に文章として整理し、他者へ分かりやすく伝えていくことが求められます。中間報告会では、そういったことを意識しながらこれまでの研修でやってきたことや成果、学びをレポートにまとめ、プロダクト開発室の室長と副室長、メンター陣の前でプレゼンテーションして報告しました。 フェーズ 3：事業部 OJT 1.代表取締役医師 豊田の講義 日本における医療制度の課題とそれに対するメドレーの位置付けについての講義 2.ジョブメドレー開発 OJT ジョブメドレーの実際の開発 Issue に対応し、ジョブメドレーの開発プロセスを体験 フェーズ 3 の最初は豊田代表の講義を受けました。基礎的な研修を終え、ジョブメドレー開発 OJT に入る前にメドレー社の社会的意義などを改めて代表から伝えていただきました。 続いて、ジョブメドレー開発 OJT は以下の狙いを持って進めました。 ジョブメドレー開発 OJT の狙い 実際に行ったことは、手始めに小さい不具合系 Issue の対応に取り組んだ後、サーバーレスポンス改善の Issue に取り組むというものでした。 サーバーレスポンスの改善は、1 人 1 画面を担当し、「プロファイルツールで分析 → 改善できそうな箇所を調査 → 改善方針の検討 → 提案 → 実装 → レビュー → リリース」というサイクルを回しました。 1 つ目の Issue 対応でも心掛けたことですが、言われたものを実装するのではなく、 ある課題を解決するためにどうしたら良いかを自分で主体的に考えることを重視しました。実装力と同じくらい課題解決力も大切にしているためです。 とはいえ成果が何も出せないというのは、精神衛生上良くないので、日々の朝会と夕会にて進捗や状況をしっかり確認しながら適宜フォローやインプットを行い、ヒントになりそうな過去 Issue のリンクを渡して参考にしてもらったり、メンターの適切なバックアップも必要です。 今回の OJT を通じて実務を知ることで、実際にエンジニアとして仕事をするイメージが沸き、同時に仕事をする上で足りないことも明確になります。自分の課題と向き合うことで、直近の自身の学習プランの軌道修正もできます。 課題は簡単なものではありませんでしたが、最終的に 1 人 1 つ以上のサーバーレスポンス改善 PR をリリースすることができました。 S さんの感想 「速度パフォーマンスの悪いコードに対する嗅覚、オブジェクトを生成しすぎていないか、無駄に通信を走らせていないかなどを学べた。」 O さんの感想 「Issue を本質的に解決するメドレーの開発姿勢について学んだ。Issue を表面的に解決するのではなく、背景や目的、関連するコードなどの不明点を調査し、十分に理解・納得した上で修正することの意識付けができた。また、Issue に関連する一部分のコードを修正すれば良いという狭い視野を持たず、修正による影響範囲を考慮した上で全体の最適化を考えることが重要であると学んだ。」 フェーズ 4：最終報告 1. 最終報告会 最終報告会の準備と実施 最後のフェーズ 4 では、これまでの研修でやってきたことや成果、学びをレポートにまとめ、役員陣の前でプレゼンテーションして報告しました。 役員陣の前なので緊張は最高潮になりますが、自分達が研修を通じて何を得てどう成長したか、今後どういうエンジニアを目指していくのか、などを役員陣の前でアピールする貴重な機会となりました。 1 人 10 分の枠内で役員陣にどういう情報をどういう表現でプレゼンテーションするかを考える機会にもなったので、情報整理力や表現力が培われる場にもなりました。 さいごに 2020 年度の新卒エンジニア研修も無事終了することができました。改めて、新卒メンバーのみなさん、関係者のみなさん本当にお疲れ様でした。 振り返ると、メドレー社員としてのマインドや開発の基本的なことをしっかりインプットしつつ、新卒メンバーが主体的に課題解決に取り組む研修ができたように思います。 必要な技術スタックを 1 から 10 まで懇切丁寧に資料に落とし込み、講義形式で行う研修も身になることは多いですが、 メドレーの研修のような課題解決を実体験する研修はより実務に繋がる実践的な研修だと思います。 少しハードな面もあるかもしれませんが、このような研修を乗り越え、医療ヘルスケア分野の課題解決に取り組みたい学生エンジニアのみなさん、少しでも興味を持っていただけると幸いです。 もちろん中途エンジニアの方もぜひお気軽にお話をしましょう。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp
こんにちは。 ジョブメドレー の開発チームでエンジニアをしている新居です。 はじめに 2020 年 4 月に、新卒エンジニア 3 名が入社しました。 入社後は新卒エンジニア研修を実施し、先日 8 月 25 日の最終報告会をもって終了しました。 コロナウイルスの影響で入社間もなくフルリモート勤務となり、不慣れなところもありましたが、本年度の研修の取り組みを紹介します。 2020 年度新卒エンジニア 研修の概要 メドレーでは昨年度から新卒エンジニアを迎えており、合わせて研修も開始しました。 初めての研修をどのような視点で計画・実施したかについては、昨年平木がこちらにまとめています。 2019 年度エンジニア新卒の研修について - Medley Developer Blog 今年は人事部のご協力もいただきながら、昨年の内容を少しアップデートして行いました。 研修の目的は、 新卒メンバーが同じ空間で互いに刺激し合いながら、社会人への思考転換をはかり、業務遂行に必要となる基礎知識とスキルを習得すること です。 研修は以下の 4 つのフェーズに区切って行いました。 研修のフェーズ 研修の内容 ここから 4 つのフェーズ毎に内容を紹介します。 フェーズ 1：社会人&メドレー基礎研修 1. オリエンテーション メドレーの事業や組織、大切にしている行動規範などの概要説明 セキュリティ研修とコンプライアンス研修 2. ビジネス研修 ビジネスマナー研修 ビジネススキル研修 ビジネススタンス研修（外部研修） フェーズ 1 では「医療ヘルスケアの未来をつくる」メンバーの一員として大切にして欲しいことを学ぶフェーズでした。 社会人としての最低限のマナーやスタンスは勿論ですが、メドレーで働く上で土台となるマインドをここで学び、 医療ヘルスケア分野の課題を解決する一員 として共にプロダクトを作るためのベースを築けたと思います。 フェーズ 2：エンジニア基礎研修 1. 開発基礎 1 講義「メドレーが求めるエンジニアとは」 ジョブメドレー と CLINICS の事業・プロダクトについての概要説明 Ruby on Rails（以下 Rails）の基礎トレーニング 2. 開発実践 チーム開発体験 3. 開発基礎 2 書籍 『Web を支える技術 -HTTP、URI、HTML、そして REST』 の輪読会 ドキュメンテーション研修とプレゼンテーション研修 中間報告会の準備と実施 フェーズ 2 から開発の研修がスタートしました。 開発基礎 1 開発の研修に入る前に、エンジニアの執行役員 田中から「メドレーが求めるエンジニアとは」というテーマで講義を行いました。メドレーがどういうエンジニアを求めているのか、目指すところの視点合わせを行い、これから行う研修に対する意識や取り組みの質を上げることを目指しました。 メドレーが求めるエンジニア像については CTO 平山の記事にも詳しく書いています。 メドレー平山の中央突破: THE エンジニア その後ジョブメドレーと CLINICS の事業・プロダクトについての概要説明、Rails の基礎トレーニングを行いました。メドレーのプロダクトは Rails 製です。Rails やウェブアプリケーション開発に慣れていない新卒メンバーは、Rails の基礎トレーニングで Ruby on Rails チュートリアル を使って基礎からみっちり学びます。 Ruby on Rails チュートリアルの進め方 ここで大切なことは、漠然とひたすら写経してチュートリアルを進めるのではなく、毎日のフィードバック会でしっかりその日の進捗や学びを共有し、不明点はメンターに質問してもらうようにすることです。 メンターは、新卒メンバーが理解が浅いまま進めてたり、理解していて欲しいところがいい加減になってたり、進め方や学びの方向性がズレてる場合などはアドバイスを入れて軌道修正することを心掛けました。 また「実際の開発ではこうだよ」といった実務を踏まえたアドバイスや、意識していることも伝えていきました。 20 新卒 S さんの感想 「毎日のフィードバック会の中で、その日学んだ技術がジョブメドレーではどのように利用されているのか、どういったことに留意して利用しているのかなどを確認できたので、現場の人の感覚を少しずつ知ることができた。」 新卒メンバーは毎日リズム良く進捗を出し、メンターは新卒メンバーのフォローと引き上げを意識し、成果を最大化できるよう努めました。 開発実践 続いて開発実践ではチーム開発を行いました。前回までは各自個別に進めていましたが、ここではジョブメドレーに関する課題解決を目的としたプロジェクトに対して、チームで向き合う研修でした。 開発実践の目的と達成すべきこと 実務ではチーム開発が基本となり、チームメンバーとの協働は必須です。学生時代に業務レベルのチーム開発を経験しているのは稀ですし、実務に入る前にチームでプロジェクト推進するとはどういうことかを知るのは、とても価値があると思います。 加えて、チームで課題をどう解決していくのかも、新卒メンバー同士で話し合って決める必要があるので、課題解決力も養われたと思います。 今回はプロトタイプを作って成果発表するところまででしたが、プロジェクト推進においてはスケジューリング、要件定義、各種設計、開発フローやコミュニケーションフローの整備、実装、テスト、などなど、やることは尽きません。 また、このプロセスの中で密なコミュニケーションが必要不可欠となるので、新卒メンバー間のチームワークも向上し、お互いのことを更に知ることができたと思います。 この段階で、チームでプロジェクトを推進することの全体感を知り、プロジェクト推進の苦悩苦闘を実体験できたのは大きな経験値になったと思います。 20 新卒 O さんの感想 「各機能の影響を互いに受けないためにブランチを細分化するブランチ戦略や GitHub を用いたコード管理について理解できた。一方で、UI を考える際にチームの各メンバーの認識のズレが生じたことや、序盤は各メンバーの進捗の詳細を把握できていなかったことから報・連・相の重要性を再認識した。」 20 新卒 T さんの感想 「初めてのチーム開発であったことから、実装の序盤は、どのファイルなら編集しても他のメンバーの作業に影響がないのか、動作確認のための画面を作るファイルは自由に作成して良いのか、どのテーブルから関係する他のテーブルの情報を含めた情報を取得をするかなどに悩んでいた。今になって振り返るとチーム内で話せば解決することに対して、技術的にも心理的にも難しさを感じた。」 ###開発基礎 2 フェーズ 2 最後の開発基礎 2 では、書籍 『Web を支える技術 -HTTP、URI、HTML、そして REST』 の輪読会を行いました。もっと前のフェーズでの実施も検討しましたが、開発基礎 1 と開発実践を経た後の方が書籍の内容の納得感が高くなるだろうという判断で、この段階での実施となりました。 その後、中間報告会に向けたドキュメンテーション研修とプレゼンテーション研修を行いました。仕事を進めていく上では、背景や目的を正しくステークホルダーへ共有しながら進めていくことが必要で、伝えたいことを適切に文章として整理し、他者へ分かりやすく伝えていくことが求められます。中間報告会では、そういったことを意識しながらこれまでの研修でやってきたことや成果、学びをレポートにまとめ、プロダクト開発室の室長と副室長、メンター陣の前でプレゼンテーションして報告しました。 フェーズ 3：事業部 OJT 1.代表取締役医師 豊田の講義 日本における医療制度の課題とそれに対するメドレーの位置付けについての講義 2.ジョブメドレー開発 OJT ジョブメドレーの実際の開発 Issue に対応し、ジョブメドレーの開発プロセスを体験 フェーズ 3 の最初は豊田代表の講義を受けました。基礎的な研修を終え、ジョブメドレー開発 OJT に入る前にメドレー社の社会的意義などを改めて代表から伝えていただきました。 続いて、ジョブメドレー開発 OJT は以下の狙いを持って進めました。 ジョブメドレー開発 OJT の狙い 実際に行ったことは、手始めに小さい不具合系 Issue の対応に取り組んだ後、サーバーレスポンス改善の Issue に取り組むというものでした。 サーバーレスポンスの改善は、1 人 1 画面を担当し、「プロファイルツールで分析 → 改善できそうな箇所を調査 → 改善方針の検討 → 提案 → 実装 → レビュー → リリース」というサイクルを回しました。 1 つ目の Issue 対応でも心掛けたことですが、言われたものを実装するのではなく、 ある課題を解決するためにどうしたら良いかを自分で主体的に考えることを重視しました。実装力と同じくらい課題解決力も大切にしているためです。 とはいえ成果が何も出せないというのは、精神衛生上良くないので、日々の朝会と夕会にて進捗や状況をしっかり確認しながら適宜フォローやインプットを行い、ヒントになりそうな過去 Issue のリンクを渡して参考にしてもらったり、メンターの適切なバックアップも必要です。 今回の OJT を通じて実務を知ることで、実際にエンジニアとして仕事をするイメージが沸き、同時に仕事をする上で足りないことも明確になります。自分の課題と向き合うことで、直近の自身の学習プランの軌道修正もできます。 課題は簡単なものではありませんでしたが、最終的に 1 人 1 つ以上のサーバーレスポンス改善 PR をリリースすることができました。 S さんの感想 「速度パフォーマンスの悪いコードに対する嗅覚、オブジェクトを生成しすぎていないか、無駄に通信を走らせていないかなどを学べた。」 O さんの感想 「Issue を本質的に解決するメドレーの開発姿勢について学んだ。Issue を表面的に解決するのではなく、背景や目的、関連するコードなどの不明点を調査し、十分に理解・納得した上で修正することの意識付けができた。また、Issue に関連する一部分のコードを修正すれば良いという狭い視野を持たず、修正による影響範囲を考慮した上で全体の最適化を考えることが重要であると学んだ。」 フェーズ 4：最終報告 1. 最終報告会 最終報告会の準備と実施 最後のフェーズ 4 では、これまでの研修でやってきたことや成果、学びをレポートにまとめ、役員陣の前でプレゼンテーションして報告しました。 役員陣の前なので緊張は最高潮になりますが、自分達が研修を通じて何を得てどう成長したか、今後どういうエンジニアを目指していくのか、などを役員陣の前でアピールする貴重な機会となりました。 1 人 10 分の枠内で役員陣にどういう情報をどういう表現でプレゼンテーションするかを考える機会にもなったので、情報整理力や表現力が培われる場にもなりました。 さいごに 2020 年度の新卒エンジニア研修も無事終了することができました。改めて、新卒メンバーのみなさん、関係者のみなさん本当にお疲れ様でした。 振り返ると、メドレー社員としてのマインドや開発の基本的なことをしっかりインプットしつつ、新卒メンバーが主体的に課題解決に取り組む研修ができたように思います。 必要な技術スタックを 1 から 10 まで懇切丁寧に資料に落とし込み、講義形式で行う研修も身になることは多いですが、 メドレーの研修のような課題解決を実体験する研修はより実務に繋がる実践的な研修だと思います。 少しハードな面もあるかもしれませんが、このような研修を乗り越え、医療ヘルスケア分野の課題解決に取り組みたい学生エンジニアのみなさん、少しでも興味を持っていただけると幸いです。 もちろん中途エンジニアの方もぜひお気軽にお話をしましょう。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp
こんにちは。 ジョブメドレー の開発チームでエンジニアをしている新居です。 はじめに 2020 年 4 月に、新卒エンジニア 3 名が入社しました。 入社後は新卒エンジニア研修を実施し、先日 8 月 25 日の最終報告会をもって終了しました。 コロナウイルスの影響で入社間もなくフルリモート勤務となり、不慣れなところもありましたが、本年度の研修の取り組みを紹介します。 2020 年度新卒エンジニア 研修の概要 メドレーでは昨年度から新卒エンジニアを迎えており、合わせて研修も開始しました。 初めての研修をどのような視点で計画・実施したかについては、昨年平木がこちらにまとめています。 2019 年度エンジニア新卒の研修について - Medley Developer Blog 今年は人事部のご協力もいただきながら、昨年の内容を少しアップデートして行いました。 研修の目的は、 新卒メンバーが同じ空間で互いに刺激し合いながら、社会人への思考転換をはかり、業務遂行に必要となる基礎知識とスキルを習得すること です。 研修は以下の 4 つのフェーズに区切って行いました。 研修のフェーズ 研修の内容 ここから 4 つのフェーズ毎に内容を紹介します。 フェーズ 1：社会人&メドレー基礎研修 1. オリエンテーション メドレーの事業や組織、大切にしている行動規範などの概要説明 セキュリティ研修とコンプライアンス研修 2. ビジネス研修 ビジネスマナー研修 ビジネススキル研修 ビジネススタンス研修（外部研修） フェーズ 1 では「医療ヘルスケアの未来をつくる」メンバーの一員として大切にして欲しいことを学ぶフェーズでした。 社会人としての最低限のマナーやスタンスは勿論ですが、メドレーで働く上で土台となるマインドをここで学び、 医療ヘルスケア分野の課題を解決する一員 として共にプロダクトを作るためのベースを築けたと思います。 フェーズ 2：エンジニア基礎研修 1. 開発基礎 1 講義「メドレーが求めるエンジニアとは」 ジョブメドレー と CLINICS の事業・プロダクトについての概要説明 Ruby on Rails（以下 Rails）の基礎トレーニング 2. 開発実践 チーム開発体験 3. 開発基礎 2 書籍 『Web を支える技術 -HTTP、URI、HTML、そして REST』 の輪読会 ドキュメンテーション研修とプレゼンテーション研修 中間報告会の準備と実施 フェーズ 2 から開発の研修がスタートしました。 開発基礎 1 開発の研修に入る前に、エンジニアの執行役員 田中から「メドレーが求めるエンジニアとは」というテーマで講義を行いました。メドレーがどういうエンジニアを求めているのか、目指すところの視点合わせを行い、これから行う研修に対する意識や取り組みの質を上げることを目指しました。 メドレーが求めるエンジニア像については CTO 平山の記事にも詳しく書いています。 メドレー平山の中央突破: THE エンジニア その後ジョブメドレーと CLINICS の事業・プロダクトについての概要説明、Rails の基礎トレーニングを行いました。メドレーのプロダクトは Rails 製です。Rails やウェブアプリケーション開発に慣れていない新卒メンバーは、Rails の基礎トレーニングで Ruby on Rails チュートリアル を使って基礎からみっちり学びます。 Ruby on Rails チュートリアルの進め方 ここで大切なことは、漠然とひたすら写経してチュートリアルを進めるのではなく、毎日のフィードバック会でしっかりその日の進捗や学びを共有し、不明点はメンターに質問してもらうようにすることです。 メンターは、新卒メンバーが理解が浅いまま進めてたり、理解していて欲しいところがいい加減になってたり、進め方や学びの方向性がズレてる場合などはアドバイスを入れて軌道修正することを心掛けました。 また「実際の開発ではこうだよ」といった実務を踏まえたアドバイスや、意識していることも伝えていきました。 20 新卒 S さんの感想 「毎日のフィードバック会の中で、その日学んだ技術がジョブメドレーではどのように利用されているのか、どういったことに留意して利用しているのかなどを確認できたので、現場の人の感覚を少しずつ知ることができた。」 新卒メンバーは毎日リズム良く進捗を出し、メンターは新卒メンバーのフォローと引き上げを意識し、成果を最大化できるよう努めました。 開発実践 続いて開発実践ではチーム開発を行いました。前回までは各自個別に進めていましたが、ここではジョブメドレーに関する課題解決を目的としたプロジェクトに対して、チームで向き合う研修でした。 開発実践の目的と達成すべきこと 実務ではチーム開発が基本となり、チームメンバーとの協働は必須です。学生時代に業務レベルのチーム開発を経験しているのは稀ですし、実務に入る前にチームでプロジェクト推進するとはどういうことかを知るのは、とても価値があると思います。 加えて、チームで課題をどう解決していくのかも、新卒メンバー同士で話し合って決める必要があるので、課題解決力も養われたと思います。 今回はプロトタイプを作って成果発表するところまででしたが、プロジェクト推進においてはスケジューリング、要件定義、各種設計、開発フローやコミュニケーションフローの整備、実装、テスト、などなど、やることは尽きません。 また、このプロセスの中で密なコミュニケーションが必要不可欠となるので、新卒メンバー間のチームワークも向上し、お互いのことを更に知ることができたと思います。 この段階で、チームでプロジェクトを推進することの全体感を知り、プロジェクト推進の苦悩苦闘を実体験できたのは大きな経験値になったと思います。 20 新卒 O さんの感想 「各機能の影響を互いに受けないためにブランチを細分化するブランチ戦略や GitHub を用いたコード管理について理解できた。一方で、UI を考える際にチームの各メンバーの認識のズレが生じたことや、序盤は各メンバーの進捗の詳細を把握できていなかったことから報・連・相の重要性を再認識した。」 20 新卒 T さんの感想 「初めてのチーム開発であったことから、実装の序盤は、どのファイルなら編集しても他のメンバーの作業に影響がないのか、動作確認のための画面を作るファイルは自由に作成して良いのか、どのテーブルから関係する他のテーブルの情報を含めた情報を取得をするかなどに悩んでいた。今になって振り返るとチーム内で話せば解決することに対して、技術的にも心理的にも難しさを感じた。」 ###開発基礎 2 フェーズ 2 最後の開発基礎 2 では、書籍 『Web を支える技術 -HTTP、URI、HTML、そして REST』 の輪読会を行いました。もっと前のフェーズでの実施も検討しましたが、開発基礎 1 と開発実践を経た後の方が書籍の内容の納得感が高くなるだろうという判断で、この段階での実施となりました。 その後、中間報告会に向けたドキュメンテーション研修とプレゼンテーション研修を行いました。仕事を進めていく上では、背景や目的を正しくステークホルダーへ共有しながら進めていくことが必要で、伝えたいことを適切に文章として整理し、他者へ分かりやすく伝えていくことが求められます。中間報告会では、そういったことを意識しながらこれまでの研修でやってきたことや成果、学びをレポートにまとめ、プロダクト開発室の室長と副室長、メンター陣の前でプレゼンテーションして報告しました。 フェーズ 3：事業部 OJT 1.代表取締役医師 豊田の講義 日本における医療制度の課題とそれに対するメドレーの位置付けについての講義 2.ジョブメドレー開発 OJT ジョブメドレーの実際の開発 Issue に対応し、ジョブメドレーの開発プロセスを体験 フェーズ 3 の最初は豊田代表の講義を受けました。基礎的な研修を終え、ジョブメドレー開発 OJT に入る前にメドレー社の社会的意義などを改めて代表から伝えていただきました。 続いて、ジョブメドレー開発 OJT は以下の狙いを持って進めました。 ジョブメドレー開発 OJT の狙い 実際に行ったことは、手始めに小さい不具合系 Issue の対応に取り組んだ後、サーバーレスポンス改善の Issue に取り組むというものでした。 サーバーレスポンスの改善は、1 人 1 画面を担当し、「プロファイルツールで分析 → 改善できそうな箇所を調査 → 改善方針の検討 → 提案 → 実装 → レビュー → リリース」というサイクルを回しました。 1 つ目の Issue 対応でも心掛けたことですが、言われたものを実装するのではなく、 ある課題を解決するためにどうしたら良いかを自分で主体的に考えることを重視しました。実装力と同じくらい課題解決力も大切にしているためです。 とはいえ成果が何も出せないというのは、精神衛生上良くないので、日々の朝会と夕会にて進捗や状況をしっかり確認しながら適宜フォローやインプットを行い、ヒントになりそうな過去 Issue のリンクを渡して参考にしてもらったり、メンターの適切なバックアップも必要です。 今回の OJT を通じて実務を知ることで、実際にエンジニアとして仕事をするイメージが沸き、同時に仕事をする上で足りないことも明確になります。自分の課題と向き合うことで、直近の自身の学習プランの軌道修正もできます。 課題は簡単なものではありませんでしたが、最終的に 1 人 1 つ以上のサーバーレスポンス改善 PR をリリースすることができました。 S さんの感想 「速度パフォーマンスの悪いコードに対する嗅覚、オブジェクトを生成しすぎていないか、無駄に通信を走らせていないかなどを学べた。」 O さんの感想 「Issue を本質的に解決するメドレーの開発姿勢について学んだ。Issue を表面的に解決するのではなく、背景や目的、関連するコードなどの不明点を調査し、十分に理解・納得した上で修正することの意識付けができた。また、Issue に関連する一部分のコードを修正すれば良いという狭い視野を持たず、修正による影響範囲を考慮した上で全体の最適化を考えることが重要であると学んだ。」 フェーズ 4：最終報告 1. 最終報告会 最終報告会の準備と実施 最後のフェーズ 4 では、これまでの研修でやってきたことや成果、学びをレポートにまとめ、役員陣の前でプレゼンテーションして報告しました。 役員陣の前なので緊張は最高潮になりますが、自分達が研修を通じて何を得てどう成長したか、今後どういうエンジニアを目指していくのか、などを役員陣の前でアピールする貴重な機会となりました。 1 人 10 分の枠内で役員陣にどういう情報をどういう表現でプレゼンテーションするかを考える機会にもなったので、情報整理力や表現力が培われる場にもなりました。 さいごに 2020 年度の新卒エンジニア研修も無事終了することができました。改めて、新卒メンバーのみなさん、関係者のみなさん本当にお疲れ様でした。 振り返ると、メドレー社員としてのマインドや開発の基本的なことをしっかりインプットしつつ、新卒メンバーが主体的に課題解決に取り組む研修ができたように思います。 必要な技術スタックを 1 から 10 まで懇切丁寧に資料に落とし込み、講義形式で行う研修も身になることは多いですが、 メドレーの研修のような課題解決を実体験する研修はより実務に繋がる実践的な研修だと思います。 少しハードな面もあるかもしれませんが、このような研修を乗り越え、医療ヘルスケア分野の課題解決に取り組みたい学生エンジニアのみなさん、少しでも興味を持っていただけると幸いです。 もちろん中途エンジニアの方もぜひお気軽にお話をしましょう。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp
こんにちは。 ジョブメドレー の開発チームでエンジニアをしている新居です。 はじめに 2020 年 4 月に、新卒エンジニア 3 名が入社しました。 入社後は新卒エンジニア研修を実施し、先日 8 月 25 日の最終報告会をもって終了しました。 コロナウイルスの影響で入社間もなくフルリモート勤務となり、不慣れなところもありましたが、本年度の研修の取り組みを紹介します。 2020 年度新卒エンジニア 研修の概要 メドレーでは昨年度から新卒エンジニアを迎えており、合わせて研修も開始しました。 初めての研修をどのような視点で計画・実施したかについては、昨年平木がこちらにまとめています。 2019 年度エンジニア新卒の研修について - Medley Developer Blog 今年は人事部のご協力もいただきながら、昨年の内容を少しアップデートして行いました。 研修の目的は、 新卒メンバーが同じ空間で互いに刺激し合いながら、社会人への思考転換をはかり、業務遂行に必要となる基礎知識とスキルを習得すること です。 研修は以下の 4 つのフェーズに区切って行いました。 研修のフェーズ 研修の内容 ここから 4 つのフェーズ毎に内容を紹介します。 フェーズ 1：社会人&メドレー基礎研修 1. オリエンテーション メドレーの事業や組織、大切にしている行動規範などの概要説明 セキュリティ研修とコンプライアンス研修 2. ビジネス研修 ビジネスマナー研修 ビジネススキル研修 ビジネススタンス研修（外部研修） フェーズ 1 では「医療ヘルスケアの未来をつくる」メンバーの一員として大切にして欲しいことを学ぶフェーズでした。 社会人としての最低限のマナーやスタンスは勿論ですが、メドレーで働く上で土台となるマインドをここで学び、 医療ヘルスケア分野の課題を解決する一員 として共にプロダクトを作るためのベースを築けたと思います。 フェーズ 2：エンジニア基礎研修 1. 開発基礎 1 講義「メドレーが求めるエンジニアとは」 ジョブメドレー と CLINICS の事業・プロダクトについての概要説明 Ruby on Rails（以下 Rails）の基礎トレーニング 2. 開発実践 チーム開発体験 3. 開発基礎 2 書籍 『Web を支える技術 -HTTP、URI、HTML、そして REST』 の輪読会 ドキュメンテーション研修とプレゼンテーション研修 中間報告会の準備と実施 フェーズ 2 から開発の研修がスタートしました。 開発基礎 1 開発の研修に入る前に、エンジニアの執行役員 田中から「メドレーが求めるエンジニアとは」というテーマで講義を行いました。メドレーがどういうエンジニアを求めているのか、目指すところの視点合わせを行い、これから行う研修に対する意識や取り組みの質を上げることを目指しました。 メドレーが求めるエンジニア像については CTO 平山の記事にも詳しく書いています。 メドレー平山の中央突破: THE エンジニア その後ジョブメドレーと CLINICS の事業・プロダクトについての概要説明、Rails の基礎トレーニングを行いました。メドレーのプロダクトは Rails 製です。Rails やウェブアプリケーション開発に慣れていない新卒メンバーは、Rails の基礎トレーニングで Ruby on Rails チュートリアル を使って基礎からみっちり学びます。 Ruby on Rails チュートリアルの進め方 ここで大切なことは、漠然とひたすら写経してチュートリアルを進めるのではなく、毎日のフィードバック会でしっかりその日の進捗や学びを共有し、不明点はメンターに質問してもらうようにすることです。 メンターは、新卒メンバーが理解が浅いまま進めてたり、理解していて欲しいところがいい加減になってたり、進め方や学びの方向性がズレてる場合などはアドバイスを入れて軌道修正することを心掛けました。 また「実際の開発ではこうだよ」といった実務を踏まえたアドバイスや、意識していることも伝えていきました。 20 新卒 S さんの感想 「毎日のフィードバック会の中で、その日学んだ技術がジョブメドレーではどのように利用されているのか、どういったことに留意して利用しているのかなどを確認できたので、現場の人の感覚を少しずつ知ることができた。」 新卒メンバーは毎日リズム良く進捗を出し、メンターは新卒メンバーのフォローと引き上げを意識し、成果を最大化できるよう努めました。 開発実践 続いて開発実践ではチーム開発を行いました。前回までは各自個別に進めていましたが、ここではジョブメドレーに関する課題解決を目的としたプロジェクトに対して、チームで向き合う研修でした。 開発実践の目的と達成すべきこと 実務ではチーム開発が基本となり、チームメンバーとの協働は必須です。学生時代に業務レベルのチーム開発を経験しているのは稀ですし、実務に入る前にチームでプロジェクト推進するとはどういうことかを知るのは、とても価値があると思います。 加えて、チームで課題をどう解決していくのかも、新卒メンバー同士で話し合って決める必要があるので、課題解決力も養われたと思います。 今回はプロトタイプを作って成果発表するところまででしたが、プロジェクト推進においてはスケジューリング、要件定義、各種設計、開発フローやコミュニケーションフローの整備、実装、テスト、などなど、やることは尽きません。 また、このプロセスの中で密なコミュニケーションが必要不可欠となるので、新卒メンバー間のチームワークも向上し、お互いのことを更に知ることができたと思います。 この段階で、チームでプロジェクトを推進することの全体感を知り、プロジェクト推進の苦悩苦闘を実体験できたのは大きな経験値になったと思います。 20 新卒 O さんの感想 「各機能の影響を互いに受けないためにブランチを細分化するブランチ戦略や GitHub を用いたコード管理について理解できた。一方で、UI を考える際にチームの各メンバーの認識のズレが生じたことや、序盤は各メンバーの進捗の詳細を把握できていなかったことから報・連・相の重要性を再認識した。」 20 新卒 T さんの感想 「初めてのチーム開発であったことから、実装の序盤は、どのファイルなら編集しても他のメンバーの作業に影響がないのか、動作確認のための画面を作るファイルは自由に作成して良いのか、どのテーブルから関係する他のテーブルの情報を含めた情報を取得をするかなどに悩んでいた。今になって振り返るとチーム内で話せば解決することに対して、技術的にも心理的にも難しさを感じた。」 ###開発基礎 2 フェーズ 2 最後の開発基礎 2 では、書籍 『Web を支える技術 -HTTP、URI、HTML、そして REST』 の輪読会を行いました。もっと前のフェーズでの実施も検討しましたが、開発基礎 1 と開発実践を経た後の方が書籍の内容の納得感が高くなるだろうという判断で、この段階での実施となりました。 その後、中間報告会に向けたドキュメンテーション研修とプレゼンテーション研修を行いました。仕事を進めていく上では、背景や目的を正しくステークホルダーへ共有しながら進めていくことが必要で、伝えたいことを適切に文章として整理し、他者へ分かりやすく伝えていくことが求められます。中間報告会では、そういったことを意識しながらこれまでの研修でやってきたことや成果、学びをレポートにまとめ、プロダクト開発室の室長と副室長、メンター陣の前でプレゼンテーションして報告しました。 フェーズ 3：事業部 OJT 1.代表取締役医師 豊田の講義 日本における医療制度の課題とそれに対するメドレーの位置付けについての講義 2.ジョブメドレー開発 OJT ジョブメドレーの実際の開発 Issue に対応し、ジョブメドレーの開発プロセスを体験 フェーズ 3 の最初は豊田代表の講義を受けました。基礎的な研修を終え、ジョブメドレー開発 OJT に入る前にメドレー社の社会的意義などを改めて代表から伝えていただきました。 続いて、ジョブメドレー開発 OJT は以下の狙いを持って進めました。 ジョブメドレー開発 OJT の狙い 実際に行ったことは、手始めに小さい不具合系 Issue の対応に取り組んだ後、サーバーレスポンス改善の Issue に取り組むというものでした。 サーバーレスポンスの改善は、1 人 1 画面を担当し、「プロファイルツールで分析 → 改善できそうな箇所を調査 → 改善方針の検討 → 提案 → 実装 → レビュー → リリース」というサイクルを回しました。 1 つ目の Issue 対応でも心掛けたことですが、言われたものを実装するのではなく、 ある課題を解決するためにどうしたら良いかを自分で主体的に考えることを重視しました。実装力と同じくらい課題解決力も大切にしているためです。 とはいえ成果が何も出せないというのは、精神衛生上良くないので、日々の朝会と夕会にて進捗や状況をしっかり確認しながら適宜フォローやインプットを行い、ヒントになりそうな過去 Issue のリンクを渡して参考にしてもらったり、メンターの適切なバックアップも必要です。 今回の OJT を通じて実務を知ることで、実際にエンジニアとして仕事をするイメージが沸き、同時に仕事をする上で足りないことも明確になります。自分の課題と向き合うことで、直近の自身の学習プランの軌道修正もできます。 課題は簡単なものではありませんでしたが、最終的に 1 人 1 つ以上のサーバーレスポンス改善 PR をリリースすることができました。 S さんの感想 「速度パフォーマンスの悪いコードに対する嗅覚、オブジェクトを生成しすぎていないか、無駄に通信を走らせていないかなどを学べた。」 O さんの感想 「Issue を本質的に解決するメドレーの開発姿勢について学んだ。Issue を表面的に解決するのではなく、背景や目的、関連するコードなどの不明点を調査し、十分に理解・納得した上で修正することの意識付けができた。また、Issue に関連する一部分のコードを修正すれば良いという狭い視野を持たず、修正による影響範囲を考慮した上で全体の最適化を考えることが重要であると学んだ。」 フェーズ 4：最終報告 1. 最終報告会 最終報告会の準備と実施 最後のフェーズ 4 では、これまでの研修でやってきたことや成果、学びをレポートにまとめ、役員陣の前でプレゼンテーションして報告しました。 役員陣の前なので緊張は最高潮になりますが、自分達が研修を通じて何を得てどう成長したか、今後どういうエンジニアを目指していくのか、などを役員陣の前でアピールする貴重な機会となりました。 1 人 10 分の枠内で役員陣にどういう情報をどういう表現でプレゼンテーションするかを考える機会にもなったので、情報整理力や表現力が培われる場にもなりました。 さいごに 2020 年度の新卒エンジニア研修も無事終了することができました。改めて、新卒メンバーのみなさん、関係者のみなさん本当にお疲れ様でした。 振り返ると、メドレー社員としてのマインドや開発の基本的なことをしっかりインプットしつつ、新卒メンバーが主体的に課題解決に取り組む研修ができたように思います。 必要な技術スタックを 1 から 10 まで懇切丁寧に資料に落とし込み、講義形式で行う研修も身になることは多いですが、 メドレーの研修のような課題解決を実体験する研修はより実務に繋がる実践的な研修だと思います。 少しハードな面もあるかもしれませんが、このような研修を乗り越え、医療ヘルスケア分野の課題解決に取り組みたい学生エンジニアのみなさん、少しでも興味を持っていただけると幸いです。 もちろん中途エンジニアの方もぜひお気軽にお話をしましょう。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp
こんにちは。 ジョブメドレー の開発チームでエンジニアをしている新居です。 はじめに 2020 年 4 月に、新卒エンジニア 3 名が入社しました。 入社後は新卒エンジニア研修を実施し、先日 8 月 25 日の最終報告会をもって終了しました。 コロナウイルスの影響で入社間もなくフルリモート勤務となり、不慣れなところもありましたが、本年度の研修の取り組みを紹介します。 2020 年度新卒エンジニア 研修の概要 メドレーでは昨年度から新卒エンジニアを迎えており、合わせて研修も開始しました。 初めての研修をどのような視点で計画・実施したかについては、昨年平木がこちらにまとめています。 2019 年度エンジニア新卒の研修について - Medley Developer Blog 今年は人事部のご協力もいただきながら、昨年の内容を少しアップデートして行いました。 研修の目的は、 新卒メンバーが同じ空間で互いに刺激し合いながら、社会人への思考転換をはかり、業務遂行に必要となる基礎知識とスキルを習得すること です。 研修は以下の 4 つのフェーズに区切って行いました。 研修のフェーズ 研修の内容 ここから 4 つのフェーズ毎に内容を紹介します。 フェーズ 1：社会人&メドレー基礎研修 1. オリエンテーション メドレーの事業や組織、大切にしている行動規範などの概要説明 セキュリティ研修とコンプライアンス研修 2. ビジネス研修 ビジネスマナー研修 ビジネススキル研修 ビジネススタンス研修（外部研修） フェーズ 1 では「医療ヘルスケアの未来をつくる」メンバーの一員として大切にして欲しいことを学ぶフェーズでした。 社会人としての最低限のマナーやスタンスは勿論ですが、メドレーで働く上で土台となるマインドをここで学び、 医療ヘルスケア分野の課題を解決する一員 として共にプロダクトを作るためのベースを築けたと思います。 フェーズ 2：エンジニア基礎研修 1. 開発基礎 1 講義「メドレーが求めるエンジニアとは」 ジョブメドレー と CLINICS の事業・プロダクトについての概要説明 Ruby on Rails（以下 Rails）の基礎トレーニング 2. 開発実践 チーム開発体験 3. 開発基礎 2 書籍 『Web を支える技術 -HTTP、URI、HTML、そして REST』 の輪読会 ドキュメンテーション研修とプレゼンテーション研修 中間報告会の準備と実施 フェーズ 2 から開発の研修がスタートしました。 開発基礎 1 開発の研修に入る前に、エンジニアの執行役員 田中から「メドレーが求めるエンジニアとは」というテーマで講義を行いました。メドレーがどういうエンジニアを求めているのか、目指すところの視点合わせを行い、これから行う研修に対する意識や取り組みの質を上げることを目指しました。 メドレーが求めるエンジニア像については CTO 平山の記事にも詳しく書いています。 メドレー平山の中央突破: THE エンジニア その後ジョブメドレーと CLINICS の事業・プロダクトについての概要説明、Rails の基礎トレーニングを行いました。メドレーのプロダクトは Rails 製です。Rails やウェブアプリケーション開発に慣れていない新卒メンバーは、Rails の基礎トレーニングで Ruby on Rails チュートリアル を使って基礎からみっちり学びます。 Ruby on Rails チュートリアルの進め方 ここで大切なことは、漠然とひたすら写経してチュートリアルを進めるのではなく、毎日のフィードバック会でしっかりその日の進捗や学びを共有し、不明点はメンターに質問してもらうようにすることです。 メンターは、新卒メンバーが理解が浅いまま進めてたり、理解していて欲しいところがいい加減になってたり、進め方や学びの方向性がズレてる場合などはアドバイスを入れて軌道修正することを心掛けました。 また「実際の開発ではこうだよ」といった実務を踏まえたアドバイスや、意識していることも伝えていきました。 20 新卒 S さんの感想 「毎日のフィードバック会の中で、その日学んだ技術がジョブメドレーではどのように利用されているのか、どういったことに留意して利用しているのかなどを確認できたので、現場の人の感覚を少しずつ知ることができた。」 新卒メンバーは毎日リズム良く進捗を出し、メンターは新卒メンバーのフォローと引き上げを意識し、成果を最大化できるよう努めました。 開発実践 続いて開発実践ではチーム開発を行いました。前回までは各自個別に進めていましたが、ここではジョブメドレーに関する課題解決を目的としたプロジェクトに対して、チームで向き合う研修でした。 開発実践の目的と達成すべきこと 実務ではチーム開発が基本となり、チームメンバーとの協働は必須です。学生時代に業務レベルのチーム開発を経験しているのは稀ですし、実務に入る前にチームでプロジェクト推進するとはどういうことかを知るのは、とても価値があると思います。 加えて、チームで課題をどう解決していくのかも、新卒メンバー同士で話し合って決める必要があるので、課題解決力も養われたと思います。 今回はプロトタイプを作って成果発表するところまででしたが、プロジェクト推進においてはスケジューリング、要件定義、各種設計、開発フローやコミュニケーションフローの整備、実装、テスト、などなど、やることは尽きません。 また、このプロセスの中で密なコミュニケーションが必要不可欠となるので、新卒メンバー間のチームワークも向上し、お互いのことを更に知ることができたと思います。 この段階で、チームでプロジェクトを推進することの全体感を知り、プロジェクト推進の苦悩苦闘を実体験できたのは大きな経験値になったと思います。 20 新卒 O さんの感想 「各機能の影響を互いに受けないためにブランチを細分化するブランチ戦略や GitHub を用いたコード管理について理解できた。一方で、UI を考える際にチームの各メンバーの認識のズレが生じたことや、序盤は各メンバーの進捗の詳細を把握できていなかったことから報・連・相の重要性を再認識した。」 20 新卒 T さんの感想 「初めてのチーム開発であったことから、実装の序盤は、どのファイルなら編集しても他のメンバーの作業に影響がないのか、動作確認のための画面を作るファイルは自由に作成して良いのか、どのテーブルから関係する他のテーブルの情報を含めた情報を取得をするかなどに悩んでいた。今になって振り返るとチーム内で話せば解決することに対して、技術的にも心理的にも難しさを感じた。」 ###開発基礎 2 フェーズ 2 最後の開発基礎 2 では、書籍 『Web を支える技術 -HTTP、URI、HTML、そして REST』 の輪読会を行いました。もっと前のフェーズでの実施も検討しましたが、開発基礎 1 と開発実践を経た後の方が書籍の内容の納得感が高くなるだろうという判断で、この段階での実施となりました。 その後、中間報告会に向けたドキュメンテーション研修とプレゼンテーション研修を行いました。仕事を進めていく上では、背景や目的を正しくステークホルダーへ共有しながら進めていくことが必要で、伝えたいことを適切に文章として整理し、他者へ分かりやすく伝えていくことが求められます。中間報告会では、そういったことを意識しながらこれまでの研修でやってきたことや成果、学びをレポートにまとめ、プロダクト開発室の室長と副室長、メンター陣の前でプレゼンテーションして報告しました。 フェーズ 3：事業部 OJT 1.代表取締役医師 豊田の講義 日本における医療制度の課題とそれに対するメドレーの位置付けについての講義 2.ジョブメドレー開発 OJT ジョブメドレーの実際の開発 Issue に対応し、ジョブメドレーの開発プロセスを体験 フェーズ 3 の最初は豊田代表の講義を受けました。基礎的な研修を終え、ジョブメドレー開発 OJT に入る前にメドレー社の社会的意義などを改めて代表から伝えていただきました。 続いて、ジョブメドレー開発 OJT は以下の狙いを持って進めました。 ジョブメドレー開発 OJT の狙い 実際に行ったことは、手始めに小さい不具合系 Issue の対応に取り組んだ後、サーバーレスポンス改善の Issue に取り組むというものでした。 サーバーレスポンスの改善は、1 人 1 画面を担当し、「プロファイルツールで分析 → 改善できそうな箇所を調査 → 改善方針の検討 → 提案 → 実装 → レビュー → リリース」というサイクルを回しました。 1 つ目の Issue 対応でも心掛けたことですが、言われたものを実装するのではなく、 ある課題を解決するためにどうしたら良いかを自分で主体的に考えることを重視しました。実装力と同じくらい課題解決力も大切にしているためです。 とはいえ成果が何も出せないというのは、精神衛生上良くないので、日々の朝会と夕会にて進捗や状況をしっかり確認しながら適宜フォローやインプットを行い、ヒントになりそうな過去 Issue のリンクを渡して参考にしてもらったり、メンターの適切なバックアップも必要です。 今回の OJT を通じて実務を知ることで、実際にエンジニアとして仕事をするイメージが沸き、同時に仕事をする上で足りないことも明確になります。自分の課題と向き合うことで、直近の自身の学習プランの軌道修正もできます。 課題は簡単なものではありませんでしたが、最終的に 1 人 1 つ以上のサーバーレスポンス改善 PR をリリースすることができました。 S さんの感想 「速度パフォーマンスの悪いコードに対する嗅覚、オブジェクトを生成しすぎていないか、無駄に通信を走らせていないかなどを学べた。」 O さんの感想 「Issue を本質的に解決するメドレーの開発姿勢について学んだ。Issue を表面的に解決するのではなく、背景や目的、関連するコードなどの不明点を調査し、十分に理解・納得した上で修正することの意識付けができた。また、Issue に関連する一部分のコードを修正すれば良いという狭い視野を持たず、修正による影響範囲を考慮した上で全体の最適化を考えることが重要であると学んだ。」 フェーズ 4：最終報告 1. 最終報告会 最終報告会の準備と実施 最後のフェーズ 4 では、これまでの研修でやってきたことや成果、学びをレポートにまとめ、役員陣の前でプレゼンテーションして報告しました。 役員陣の前なので緊張は最高潮になりますが、自分達が研修を通じて何を得てどう成長したか、今後どういうエンジニアを目指していくのか、などを役員陣の前でアピールする貴重な機会となりました。 1 人 10 分の枠内で役員陣にどういう情報をどういう表現でプレゼンテーションするかを考える機会にもなったので、情報整理力や表現力が培われる場にもなりました。 さいごに 2020 年度の新卒エンジニア研修も無事終了することができました。改めて、新卒メンバーのみなさん、関係者のみなさん本当にお疲れ様でした。 振り返ると、メドレー社員としてのマインドや開発の基本的なことをしっかりインプットしつつ、新卒メンバーが主体的に課題解決に取り組む研修ができたように思います。 必要な技術スタックを 1 から 10 まで懇切丁寧に資料に落とし込み、講義形式で行う研修も身になることは多いですが、 メドレーの研修のような課題解決を実体験する研修はより実務に繋がる実践的な研修だと思います。 少しハードな面もあるかもしれませんが、このような研修を乗り越え、医療ヘルスケア分野の課題解決に取り組みたい学生エンジニアのみなさん、少しでも興味を持っていただけると幸いです。 もちろん中途エンジニアの方もぜひお気軽にお話をしましょう。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp
自己紹介 株式会社メドレーのエンジニア阪本です。 9 月に入っても暑い日が続く中、皆さんはいかがお過ごしでしょうか。 前回のブログでも書きましたが私は野球観戦（虎党）が趣味で、毎日の試合結果に一喜一憂しています。 このブログの執筆時点ではセ・リーグは首位巨人にマジックが点灯し、残試合 50 を切った状況でのゲーム差 10。優勝を目指す阪神にとっては厳しい状況となりましたが、残り直接対決をすべて勝てば可能性は見えてくるはず。ここは諦めずに応援しようと思います。 次の記事を書く頃には何らかの決着が着いていると思いますので、その時には喜びのメッセージが書ける事を願っています。 はじめに 突然ですが、皆さんは Fargate を使いこなしていますか？ 今まで ECS(EC2)での運用がメインでしたが、ジョブメドレーのシステムでも Fargate に触れる機会が増えてきました。 筆者自身は初めての Fargate でしたが、EC2 の存在が無くなることに不思議な感覚を覚えつつも、管理するものが減って運用が楽になったと実感しています。 しかし、EC2 が無くなった事によりサーバ内にターミナルで入る手段を失いました。 公式の ガイド では 質問２：コンテナの中に ssh や docker exec で入ることは出来ますか？ こちら現状サポートしておりませんが、コンテナワークロードでは「 同一の環境でしっかりテストを行う 」ことや「 ログを外部に全て出す 」ことがベストプラクティスとされていて、コンテナに入る必要性を出来る限り減らす方が将来的にも好ましいです。 と「事前にテストを十分に実施する」「ログは(S3 や CloudWatchLogs など)外部に出力する」 さえ出来ていれば入る必要が無いはずと記載されているものの・・・心配性な自分は不測の事態が発生した時の事を考えてサーバに入る手段を求めてしまいます。 そこで代替手段を模索していた所、 SessionManager を使えば可能との文献を見つけました。 すでに SessionManager 自体は EC2 に対して運用を行っていたため導入の敷居は低いと考え、この手段を採用することにしました。 Session Manager とは？ Session Manager とは AWS の Systems Manager サービスの 1 機能で、AWS 上で管理しているサーバ（マネージドインスタンス）に対してターミナルのアクセスを可能にするものです。 ターミナルへのアクセス手段は、よくある手段だと SSH がありますが この方法は SSH ポートを外部に開放する必要があるため攻撃の対象になりやすく、あまり好ましくありません。 それに比べて Session Manager は SSH ポートの開放は不要でサーバから見てアウトバウンド方向の HTTPS 通信の確保で済む為、外部からの攻撃も受けず安全にアクセス経路の確保が実現できます。 ※通信経路の確保以外にも IAM ロールの設定などが必要となります。詳しくは こちら を参考 「AWS 上で管理しているサーバ」と先に記載しましたが、このサーバは EC2 インスタンスに限らないのが本記事の重要なポイントになります。 オンプレミスなサーバも AWS 上で管理されているのであれば、SessionManager エージェントをインストールする事により管理対象に含めることが可能になるのです。 今回は EC2 で動いていた SessionManager エージェントを Fargate で動くコンテナにインストールする事によりコンテナ自体をサーバと見立ててマネージドインスタンスとし、SessionManager でアクセスする事を目指します。 対応 Systems Manager インスタンス枠をスタンダードからアドバンスドに変更する ／ AWS コンソールでの設定 オンプレミスなサーバに SessionManager にてアクセスする場合、Systems Manager のオンプレミスインスタンスティアを スタンダードからアドバンスドへと変更する必要 があります。 この変更作業は AWS コンソールから行う事になりますが、アドバンスドへの変更に当たって既存のマネージドインスタンスに影響することはありません。 ただし、この逆の場合、スタンダードに戻す際には考慮が必要となるので こちら を参照ください。 SSM Agent のインストール ／ コンテナに対する設定 ここからは実際に動くコンテナに対する設定になります。 AWS のドキュメント 手動でインストール SSM エージェント EC2 で Linux のインスタンス を参考に、OS に合った方法で SessionManager エージェントのインストールを行います。 インストール作業には通信などの時間が必要となるので、事前にコンテナイメージにインストールする形としました。 コンテナをマネージドインスタンスとして登録する ／ コンテナに対する設定 コンテナをマネージドインスタンスとして登録するため、コンテナのスタートアップ(Entrypoint)にて下記スクリプトを実行します。 # 1. ハイブリッドアクティベーションの作成 SSM_ACTIVATE_INFO = ` aws ssm create-activation --iam-role service-role/AmazonEC2RunCommandRoleForManagedInstances --registration-limit 1 --region ap-northeast-1 --default-instance-name medley-blog-fargate-container` # 2. アウトプットからアクティベーションコード/ID の抽出 SSM_ACTIVATE_CODE = ` echo $SSM_ACTIVATE_INFO | jq -r '.ActivationCode'` SSM_ACTIVATE_ID = ` echo $SSM_ACTIVATE_INFO | jq -r '.ActivationId'` # 3. コンテナ自身をマネージドインスタンスへの登録 amazon-ssm-agent -register -code $SSM_ACTIVATE_CODE -id $SSM_ACTIVATE_ID -region "ap-northeast-1" # 4. SessionManager エージェントの起動 amazon-ssm-agent & これらのコマンドについては各行ごとに説明します 1.ハイブリッドアクティベーションの作成 マネージドインスタンス登録に必要なアクティベーションコード/ID 取得のため、ハイブリッドアクティベーションの登録を行います。 後々 AWS コンソールにてインスタンスの識別ができるように、 --default-instance-name オプションにて medley-blog-fargate-container という名前を付与しています。 このコマンドのアウトプットにて下記のような JSON が返される為、一旦変数に格納しています。 { "ActivationId" : "<<アクティベーション ID>>", "ActivationCode": "<<アクティベーションコード>>" } また --iam-role オプションでサービスロール AmazonEC2RunCommandRoleForManagedInstances を使っています。 このロールがまだ存在しない場合、AWS コンソールからハイブリッドアクティベーションから IAM ロール →「必要な権限を備えたシステムのデフォルトコマンド実行ロールを作成」により作成してください。 2. アウトプットからアクティベーションコード/ID の抽出 前項のアウトプットからアクティベーションコード/ID を個々の変数に分離しています。 3. コンテナ自身をマネージドインスタンスへの登録 取得したアクティベーションコード/ID を利用し、コンテナ自身をマネージドインスタンスとして登録します。 環境変数 AWS_DEFAULT_REGION のように AWS の Credential にてデフォルトの Region 設定があった場合でも、このコマンドではオプションで Region 指定が必須となるのでご注意ください。 4. SessionManager エージェントの起動 最後に SessionManager エージェントを起動します。 これにより AWS との通信が確立され、SessionManager が利用できるようになります。 この状態でマネージドインスタンス画面にて目的のインスタンスが「オンライン」であれば設定が完了です。 接続確認 設定が完了したので、実際に SessionManager にて接続してみます。 AWS コンソールのセッションマネージャからセッションの開始を選択し、名前が事前に登録した medley-blog-fargate-container であるものを選択します。 外見は他の EC2 と変わらない表示ですが、この手段で登録したものはインスタンス ID が mi から始まる ID になります(通常の EC2 は i から始まる ID)。 後は普段通りにセッションを開始するとコンテナ内へのアクセスが開始されます。 これで EC2 の無い Fargate 上のコンテナに対してもターミナルに入ることができました。 運用してみての感想 Fargate 上のコンテナに直接入ることにより、今まで出来なかった top コマンドによるプロセス状態の確認 df コマンドによる Disk 容量の確認 などの環境調査が出来るようになりました。 利用頻度が多い訳ではありませんが、調査の選択肢を増やす事により有事の際の早期対応に繋げれられていると感じています。 注意点 ここからは運用に当たっての注意点について数点紹介します。 料金 EC2 での SessionManager と違い、 この方法で登録したサーバへの SessionManager 通信は料金が発生します 。 正確には 「SessionManager エージェントが起動し AWS と通信が確立している状態」 での時間課金で SessionManager での接続有無は問いません。 よって、常時必要ではない場合は SessionManager エージェントを止めて節約する方法を検討してください。 アクティベーションやマネージドインスタンスがリストに残る コンテナ終了時でも AWS コンソールのハイブリッドアクティベーション一覧やマネージドインスタンス一覧に表示が残ってしまうようです。 一覧の上限の記載は見つからなかったものの、無限に増えるとも思えないので適時 Lambda を使って削除しています。 SessionManager での操作について EC2 インスタンスに対しての SessionManager と同様ですが、セッション開始直後のユーザは ssm-user 固定になるようです。 特定ユーザでの操作が必要となる場合、 su コマンドでのユーザ切り替えが必要になります。 さいごに 今回のようにメドレーでは新たな技術を取り入れつつ、サービスの安定を目的とした様々な施策を導入しています。 こういった働き方に興味を持たれた方、まずは下記リンクからお気軽にお話しませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp
自己紹介 株式会社メドレーのエンジニア阪本です。 9 月に入っても暑い日が続く中、皆さんはいかがお過ごしでしょうか。 前回のブログでも書きましたが私は野球観戦（虎党）が趣味で、毎日の試合結果に一喜一憂しています。 このブログの執筆時点ではセ・リーグは首位巨人にマジックが点灯し、残試合 50 を切った状況でのゲーム差 10。優勝を目指す阪神にとっては厳しい状況となりましたが、残り直接対決をすべて勝てば可能性は見えてくるはず。ここは諦めずに応援しようと思います。 次の記事を書く頃には何らかの決着が着いていると思いますので、その時には喜びのメッセージが書ける事を願っています。 はじめに 突然ですが、皆さんは Fargate を使いこなしていますか？ 今まで ECS(EC2)での運用がメインでしたが、ジョブメドレーのシステムでも Fargate に触れる機会が増えてきました。 筆者自身は初めての Fargate でしたが、EC2 の存在が無くなることに不思議な感覚を覚えつつも、管理するものが減って運用が楽になったと実感しています。 しかし、EC2 が無くなった事によりサーバ内にターミナルで入る手段を失いました。 公式の ガイド では 質問２：コンテナの中に ssh や docker exec で入ることは出来ますか？ こちら現状サポートしておりませんが、コンテナワークロードでは「 同一の環境でしっかりテストを行う 」ことや「 ログを外部に全て出す 」ことがベストプラクティスとされていて、コンテナに入る必要性を出来る限り減らす方が将来的にも好ましいです。 と「事前にテストを十分に実施する」「ログは(S3 や CloudWatchLogs など)外部に出力する」 さえ出来ていれば入る必要が無いはずと記載されているものの・・・心配性な自分は不測の事態が発生した時の事を考えてサーバに入る手段を求めてしまいます。 そこで代替手段を模索していた所、 SessionManager を使えば可能との文献を見つけました。 すでに SessionManager 自体は EC2 に対して運用を行っていたため導入の敷居は低いと考え、この手段を採用することにしました。 Session Manager とは？ Session Manager とは AWS の Systems Manager サービスの 1 機能で、AWS 上で管理しているサーバ（マネージドインスタンス）に対してターミナルのアクセスを可能にするものです。 ターミナルへのアクセス手段は、よくある手段だと SSH がありますが この方法は SSH ポートを外部に開放する必要があるため攻撃の対象になりやすく、あまり好ましくありません。 それに比べて Session Manager は SSH ポートの開放は不要でサーバから見てアウトバウンド方向の HTTPS 通信の確保で済む為、外部からの攻撃も受けず安全にアクセス経路の確保が実現できます。 ※通信経路の確保以外にも IAM ロールの設定などが必要となります。詳しくは こちら を参考 「AWS 上で管理しているサーバ」と先に記載しましたが、このサーバは EC2 インスタンスに限らないのが本記事の重要なポイントになります。 オンプレミスなサーバも AWS 上で管理されているのであれば、SessionManager エージェントをインストールする事により管理対象に含めることが可能になるのです。 今回は EC2 で動いていた SessionManager エージェントを Fargate で動くコンテナにインストールする事によりコンテナ自体をサーバと見立ててマネージドインスタンスとし、SessionManager でアクセスする事を目指します。 対応 Systems Manager インスタンス枠をスタンダードからアドバンスドに変更する ／ AWS コンソールでの設定 オンプレミスなサーバに SessionManager にてアクセスする場合、Systems Manager のオンプレミスインスタンスティアを スタンダードからアドバンスドへと変更する必要 があります。 この変更作業は AWS コンソールから行う事になりますが、アドバンスドへの変更に当たって既存のマネージドインスタンスに影響することはありません。 ただし、この逆の場合、スタンダードに戻す際には考慮が必要となるので こちら を参照ください。 SSM Agent のインストール ／ コンテナに対する設定 ここからは実際に動くコンテナに対する設定になります。 AWS のドキュメント 手動でインストール SSM エージェント EC2 で Linux のインスタンス を参考に、OS に合った方法で SessionManager エージェントのインストールを行います。 インストール作業には通信などの時間が必要となるので、事前にコンテナイメージにインストールする形としました。 コンテナをマネージドインスタンスとして登録する ／ コンテナに対する設定 コンテナをマネージドインスタンスとして登録するため、コンテナのスタートアップ(Entrypoint)にて下記スクリプトを実行します。 # 1. ハイブリッドアクティベーションの作成 SSM_ACTIVATE_INFO = ` aws ssm create-activation --iam-role service-role/AmazonEC2RunCommandRoleForManagedInstances --registration-limit 1 --region ap-northeast-1 --default-instance-name medley-blog-fargate-container` # 2. アウトプットからアクティベーションコード/ID の抽出 SSM_ACTIVATE_CODE = ` echo $SSM_ACTIVATE_INFO | jq -r '.ActivationCode'` SSM_ACTIVATE_ID = ` echo $SSM_ACTIVATE_INFO | jq -r '.ActivationId'` # 3. コンテナ自身をマネージドインスタンスへの登録 amazon-ssm-agent -register -code $SSM_ACTIVATE_CODE -id $SSM_ACTIVATE_ID -region "ap-northeast-1" # 4. SessionManager エージェントの起動 amazon-ssm-agent & これらのコマンドについては各行ごとに説明します 1.ハイブリッドアクティベーションの作成 マネージドインスタンス登録に必要なアクティベーションコード/ID 取得のため、ハイブリッドアクティベーションの登録を行います。 後々 AWS コンソールにてインスタンスの識別ができるように、 --default-instance-name オプションにて medley-blog-fargate-container という名前を付与しています。 このコマンドのアウトプットにて下記のような JSON が返される為、一旦変数に格納しています。 { "ActivationId" : "<<アクティベーション ID>>", "ActivationCode": "<<アクティベーションコード>>" } また --iam-role オプションでサービスロール AmazonEC2RunCommandRoleForManagedInstances を使っています。 このロールがまだ存在しない場合、AWS コンソールからハイブリッドアクティベーションから IAM ロール →「必要な権限を備えたシステムのデフォルトコマンド実行ロールを作成」により作成してください。 2. アウトプットからアクティベーションコード/ID の抽出 前項のアウトプットからアクティベーションコード/ID を個々の変数に分離しています。 3. コンテナ自身をマネージドインスタンスへの登録 取得したアクティベーションコード/ID を利用し、コンテナ自身をマネージドインスタンスとして登録します。 環境変数 AWS_DEFAULT_REGION のように AWS の Credential にてデフォルトの Region 設定があった場合でも、このコマンドではオプションで Region 指定が必須となるのでご注意ください。 4. SessionManager エージェントの起動 最後に SessionManager エージェントを起動します。 これにより AWS との通信が確立され、SessionManager が利用できるようになります。 この状態でマネージドインスタンス画面にて目的のインスタンスが「オンライン」であれば設定が完了です。 接続確認 設定が完了したので、実際に SessionManager にて接続してみます。 AWS コンソールのセッションマネージャからセッションの開始を選択し、名前が事前に登録した medley-blog-fargate-container であるものを選択します。 外見は他の EC2 と変わらない表示ですが、この手段で登録したものはインスタンス ID が mi から始まる ID になります(通常の EC2 は i から始まる ID)。 後は普段通りにセッションを開始するとコンテナ内へのアクセスが開始されます。 これで EC2 の無い Fargate 上のコンテナに対してもターミナルに入ることができました。 運用してみての感想 Fargate 上のコンテナに直接入ることにより、今まで出来なかった top コマンドによるプロセス状態の確認 df コマンドによる Disk 容量の確認 などの環境調査が出来るようになりました。 利用頻度が多い訳ではありませんが、調査の選択肢を増やす事により有事の際の早期対応に繋げれられていると感じています。 注意点 ここからは運用に当たっての注意点について数点紹介します。 料金 EC2 での SessionManager と違い、 この方法で登録したサーバへの SessionManager 通信は料金が発生します 。 正確には 「SessionManager エージェントが起動し AWS と通信が確立している状態」 での時間課金で SessionManager での接続有無は問いません。 よって、常時必要ではない場合は SessionManager エージェントを止めて節約する方法を検討してください。 アクティベーションやマネージドインスタンスがリストに残る コンテナ終了時でも AWS コンソールのハイブリッドアクティベーション一覧やマネージドインスタンス一覧に表示が残ってしまうようです。 一覧の上限の記載は見つからなかったものの、無限に増えるとも思えないので適時 Lambda を使って削除しています。 SessionManager での操作について EC2 インスタンスに対しての SessionManager と同様ですが、セッション開始直後のユーザは ssm-user 固定になるようです。 特定ユーザでの操作が必要となる場合、 su コマンドでのユーザ切り替えが必要になります。 さいごに 今回のようにメドレーでは新たな技術を取り入れつつ、サービスの安定を目的とした様々な施策を導入しています。 こういった働き方に興味を持たれた方、まずは下記リンクからお気軽にお話しませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp
自己紹介 株式会社メドレーのエンジニア阪本です。 9 月に入っても暑い日が続く中、皆さんはいかがお過ごしでしょうか。 前回のブログでも書きましたが私は野球観戦（虎党）が趣味で、毎日の試合結果に一喜一憂しています。 このブログの執筆時点ではセ・リーグは首位巨人にマジックが点灯し、残試合 50 を切った状況でのゲーム差 10。優勝を目指す阪神にとっては厳しい状況となりましたが、残り直接対決をすべて勝てば可能性は見えてくるはず。ここは諦めずに応援しようと思います。 次の記事を書く頃には何らかの決着が着いていると思いますので、その時には喜びのメッセージが書ける事を願っています。 はじめに 突然ですが、皆さんは Fargate を使いこなしていますか？ 今まで ECS(EC2)での運用がメインでしたが、ジョブメドレーのシステムでも Fargate に触れる機会が増えてきました。 筆者自身は初めての Fargate でしたが、EC2 の存在が無くなることに不思議な感覚を覚えつつも、管理するものが減って運用が楽になったと実感しています。 しかし、EC2 が無くなった事によりサーバ内にターミナルで入る手段を失いました。 公式の ガイド では 質問２：コンテナの中に ssh や docker exec で入ることは出来ますか？ こちら現状サポートしておりませんが、コンテナワークロードでは「 同一の環境でしっかりテストを行う 」ことや「 ログを外部に全て出す 」ことがベストプラクティスとされていて、コンテナに入る必要性を出来る限り減らす方が将来的にも好ましいです。 と「事前にテストを十分に実施する」「ログは(S3 や CloudWatchLogs など)外部に出力する」 さえ出来ていれば入る必要が無いはずと記載されているものの・・・心配性な自分は不測の事態が発生した時の事を考えてサーバに入る手段を求めてしまいます。 そこで代替手段を模索していた所、 SessionManager を使えば可能との文献を見つけました。 すでに SessionManager 自体は EC2 に対して運用を行っていたため導入の敷居は低いと考え、この手段を採用することにしました。 Session Manager とは？ Session Manager とは AWS の Systems Manager サービスの 1 機能で、AWS 上で管理しているサーバ（マネージドインスタンス）に対してターミナルのアクセスを可能にするものです。 ターミナルへのアクセス手段は、よくある手段だと SSH がありますが この方法は SSH ポートを外部に開放する必要があるため攻撃の対象になりやすく、あまり好ましくありません。 それに比べて Session Manager は SSH ポートの開放は不要でサーバから見てアウトバウンド方向の HTTPS 通信の確保で済む為、外部からの攻撃も受けず安全にアクセス経路の確保が実現できます。 ※通信経路の確保以外にも IAM ロールの設定などが必要となります。詳しくは こちら を参考 「AWS 上で管理しているサーバ」と先に記載しましたが、このサーバは EC2 インスタンスに限らないのが本記事の重要なポイントになります。 オンプレミスなサーバも AWS 上で管理されているのであれば、SessionManager エージェントをインストールする事により管理対象に含めることが可能になるのです。 今回は EC2 で動いていた SessionManager エージェントを Fargate で動くコンテナにインストールする事によりコンテナ自体をサーバと見立ててマネージドインスタンスとし、SessionManager でアクセスする事を目指します。 対応 Systems Manager インスタンス枠をスタンダードからアドバンスドに変更する ／ AWS コンソールでの設定 オンプレミスなサーバに SessionManager にてアクセスする場合、Systems Manager のオンプレミスインスタンスティアを スタンダードからアドバンスドへと変更する必要 があります。 この変更作業は AWS コンソールから行う事になりますが、アドバンスドへの変更に当たって既存のマネージドインスタンスに影響することはありません。 ただし、この逆の場合、スタンダードに戻す際には考慮が必要となるので こちら を参照ください。 SSM Agent のインストール ／ コンテナに対する設定 ここからは実際に動くコンテナに対する設定になります。 AWS のドキュメント 手動でインストール SSM エージェント EC2 で Linux のインスタンス を参考に、OS に合った方法で SessionManager エージェントのインストールを行います。 インストール作業には通信などの時間が必要となるので、事前にコンテナイメージにインストールする形としました。 コンテナをマネージドインスタンスとして登録する ／ コンテナに対する設定 コンテナをマネージドインスタンスとして登録するため、コンテナのスタートアップ(Entrypoint)にて下記スクリプトを実行します。 # 1. ハイブリッドアクティベーションの作成 SSM_ACTIVATE_INFO = ` aws ssm create-activation --iam-role service-role/AmazonEC2RunCommandRoleForManagedInstances --registration-limit 1 --region ap-northeast-1 --default-instance-name medley-blog-fargate-container` # 2. アウトプットからアクティベーションコード/ID の抽出 SSM_ACTIVATE_CODE = ` echo $SSM_ACTIVATE_INFO | jq -r '.ActivationCode'` SSM_ACTIVATE_ID = ` echo $SSM_ACTIVATE_INFO | jq -r '.ActivationId'` # 3. コンテナ自身をマネージドインスタンスへの登録 amazon-ssm-agent -register -code $SSM_ACTIVATE_CODE -id $SSM_ACTIVATE_ID -region "ap-northeast-1" # 4. SessionManager エージェントの起動 amazon-ssm-agent & これらのコマンドについては各行ごとに説明します 1.ハイブリッドアクティベーションの作成 マネージドインスタンス登録に必要なアクティベーションコード/ID 取得のため、ハイブリッドアクティベーションの登録を行います。 後々 AWS コンソールにてインスタンスの識別ができるように、 --default-instance-name オプションにて medley-blog-fargate-container という名前を付与しています。 このコマンドのアウトプットにて下記のような JSON が返される為、一旦変数に格納しています。 { "ActivationId" : "<<アクティベーション ID>>", "ActivationCode": "<<アクティベーションコード>>" } また --iam-role オプションでサービスロール AmazonEC2RunCommandRoleForManagedInstances を使っています。 このロールがまだ存在しない場合、AWS コンソールからハイブリッドアクティベーションから IAM ロール →「必要な権限を備えたシステムのデフォルトコマンド実行ロールを作成」により作成してください。 2. アウトプットからアクティベーションコード/ID の抽出 前項のアウトプットからアクティベーションコード/ID を個々の変数に分離しています。 3. コンテナ自身をマネージドインスタンスへの登録 取得したアクティベーションコード/ID を利用し、コンテナ自身をマネージドインスタンスとして登録します。 環境変数 AWS_DEFAULT_REGION のように AWS の Credential にてデフォルトの Region 設定があった場合でも、このコマンドではオプションで Region 指定が必須となるのでご注意ください。 4. SessionManager エージェントの起動 最後に SessionManager エージェントを起動します。 これにより AWS との通信が確立され、SessionManager が利用できるようになります。 この状態でマネージドインスタンス画面にて目的のインスタンスが「オンライン」であれば設定が完了です。 接続確認 設定が完了したので、実際に SessionManager にて接続してみます。 AWS コンソールのセッションマネージャからセッションの開始を選択し、名前が事前に登録した medley-blog-fargate-container であるものを選択します。 外見は他の EC2 と変わらない表示ですが、この手段で登録したものはインスタンス ID が mi から始まる ID になります(通常の EC2 は i から始まる ID)。 後は普段通りにセッションを開始するとコンテナ内へのアクセスが開始されます。 これで EC2 の無い Fargate 上のコンテナに対してもターミナルに入ることができました。 運用してみての感想 Fargate 上のコンテナに直接入ることにより、今まで出来なかった top コマンドによるプロセス状態の確認 df コマンドによる Disk 容量の確認 などの環境調査が出来るようになりました。 利用頻度が多い訳ではありませんが、調査の選択肢を増やす事により有事の際の早期対応に繋げれられていると感じています。 注意点 ここからは運用に当たっての注意点について数点紹介します。 料金 EC2 での SessionManager と違い、 この方法で登録したサーバへの SessionManager 通信は料金が発生します 。 正確には 「SessionManager エージェントが起動し AWS と通信が確立している状態」 での時間課金で SessionManager での接続有無は問いません。 よって、常時必要ではない場合は SessionManager エージェントを止めて節約する方法を検討してください。 アクティベーションやマネージドインスタンスがリストに残る コンテナ終了時でも AWS コンソールのハイブリッドアクティベーション一覧やマネージドインスタンス一覧に表示が残ってしまうようです。 一覧の上限の記載は見つからなかったものの、無限に増えるとも思えないので適時 Lambda を使って削除しています。 SessionManager での操作について EC2 インスタンスに対しての SessionManager と同様ですが、セッション開始直後のユーザは ssm-user 固定になるようです。 特定ユーザでの操作が必要となる場合、 su コマンドでのユーザ切り替えが必要になります。 さいごに 今回のようにメドレーでは新たな技術を取り入れつつ、サービスの安定を目的とした様々な施策を導入しています。 こういった働き方に興味を持たれた方、まずは下記リンクからお気軽にお話しませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp
自己紹介 株式会社メドレーのエンジニア阪本です。 9 月に入っても暑い日が続く中、皆さんはいかがお過ごしでしょうか。 前回のブログでも書きましたが私は野球観戦（虎党）が趣味で、毎日の試合結果に一喜一憂しています。 このブログの執筆時点ではセ・リーグは首位巨人にマジックが点灯し、残試合 50 を切った状況でのゲーム差 10。優勝を目指す阪神にとっては厳しい状況となりましたが、残り直接対決をすべて勝てば可能性は見えてくるはず。ここは諦めずに応援しようと思います。 次の記事を書く頃には何らかの決着が着いていると思いますので、その時には喜びのメッセージが書ける事を願っています。 はじめに 突然ですが、皆さんは Fargate を使いこなしていますか？ 今まで ECS(EC2)での運用がメインでしたが、ジョブメドレーのシステムでも Fargate に触れる機会が増えてきました。 筆者自身は初めての Fargate でしたが、EC2 の存在が無くなることに不思議な感覚を覚えつつも、管理するものが減って運用が楽になったと実感しています。 しかし、EC2 が無くなった事によりサーバ内にターミナルで入る手段を失いました。 公式の ガイド では 質問２：コンテナの中に ssh や docker exec で入ることは出来ますか？ こちら現状サポートしておりませんが、コンテナワークロードでは「 同一の環境でしっかりテストを行う 」ことや「 ログを外部に全て出す 」ことがベストプラクティスとされていて、コンテナに入る必要性を出来る限り減らす方が将来的にも好ましいです。 と「事前にテストを十分に実施する」「ログは(S3 や CloudWatchLogs など)外部に出力する」 さえ出来ていれば入る必要が無いはずと記載されているものの・・・心配性な自分は不測の事態が発生した時の事を考えてサーバに入る手段を求めてしまいます。 そこで代替手段を模索していた所、 SessionManager を使えば可能との文献を見つけました。 すでに SessionManager 自体は EC2 に対して運用を行っていたため導入の敷居は低いと考え、この手段を採用することにしました。 Session Manager とは？ Session Manager とは AWS の Systems Manager サービスの 1 機能で、AWS 上で管理しているサーバ（マネージドインスタンス）に対してターミナルのアクセスを可能にするものです。 ターミナルへのアクセス手段は、よくある手段だと SSH がありますが この方法は SSH ポートを外部に開放する必要があるため攻撃の対象になりやすく、あまり好ましくありません。 それに比べて Session Manager は SSH ポートの開放は不要でサーバから見てアウトバウンド方向の HTTPS 通信の確保で済む為、外部からの攻撃も受けず安全にアクセス経路の確保が実現できます。 ※通信経路の確保以外にも IAM ロールの設定などが必要となります。詳しくは こちら を参考 「AWS 上で管理しているサーバ」と先に記載しましたが、このサーバは EC2 インスタンスに限らないのが本記事の重要なポイントになります。 オンプレミスなサーバも AWS 上で管理されているのであれば、SessionManager エージェントをインストールする事により管理対象に含めることが可能になるのです。 今回は EC2 で動いていた SessionManager エージェントを Fargate で動くコンテナにインストールする事によりコンテナ自体をサーバと見立ててマネージドインスタンスとし、SessionManager でアクセスする事を目指します。 対応 Systems Manager インスタンス枠をスタンダードからアドバンスドに変更する ／ AWS コンソールでの設定 オンプレミスなサーバに SessionManager にてアクセスする場合、Systems Manager のオンプレミスインスタンスティアを スタンダードからアドバンスドへと変更する必要 があります。 この変更作業は AWS コンソールから行う事になりますが、アドバンスドへの変更に当たって既存のマネージドインスタンスに影響することはありません。 ただし、この逆の場合、スタンダードに戻す際には考慮が必要となるので こちら を参照ください。 SSM Agent のインストール ／ コンテナに対する設定 ここからは実際に動くコンテナに対する設定になります。 AWS のドキュメント 手動でインストール SSM エージェント EC2 で Linux のインスタンス を参考に、OS に合った方法で SessionManager エージェントのインストールを行います。 インストール作業には通信などの時間が必要となるので、事前にコンテナイメージにインストールする形としました。 コンテナをマネージドインスタンスとして登録する ／ コンテナに対する設定 コンテナをマネージドインスタンスとして登録するため、コンテナのスタートアップ(Entrypoint)にて下記スクリプトを実行します。 # 1. ハイブリッドアクティベーションの作成 SSM_ACTIVATE_INFO = ` aws ssm create-activation --iam-role service-role/AmazonEC2RunCommandRoleForManagedInstances --registration-limit 1 --region ap-northeast-1 --default-instance-name medley-blog-fargate-container` # 2. アウトプットからアクティベーションコード/ID の抽出 SSM_ACTIVATE_CODE = ` echo $SSM_ACTIVATE_INFO | jq -r '.ActivationCode'` SSM_ACTIVATE_ID = ` echo $SSM_ACTIVATE_INFO | jq -r '.ActivationId'` # 3. コンテナ自身をマネージドインスタンスへの登録 amazon-ssm-agent -register -code $SSM_ACTIVATE_CODE -id $SSM_ACTIVATE_ID -region "ap-northeast-1" # 4. SessionManager エージェントの起動 amazon-ssm-agent & これらのコマンドについては各行ごとに説明します 1.ハイブリッドアクティベーションの作成 マネージドインスタンス登録に必要なアクティベーションコード/ID 取得のため、ハイブリッドアクティベーションの登録を行います。 後々 AWS コンソールにてインスタンスの識別ができるように、 --default-instance-name オプションにて medley-blog-fargate-container という名前を付与しています。 このコマンドのアウトプットにて下記のような JSON が返される為、一旦変数に格納しています。 { "ActivationId" : "<<アクティベーション ID>>", "ActivationCode": "<<アクティベーションコード>>" } また --iam-role オプションでサービスロール AmazonEC2RunCommandRoleForManagedInstances を使っています。 このロールがまだ存在しない場合、AWS コンソールからハイブリッドアクティベーションから IAM ロール →「必要な権限を備えたシステムのデフォルトコマンド実行ロールを作成」により作成してください。 2. アウトプットからアクティベーションコード/ID の抽出 前項のアウトプットからアクティベーションコード/ID を個々の変数に分離しています。 3. コンテナ自身をマネージドインスタンスへの登録 取得したアクティベーションコード/ID を利用し、コンテナ自身をマネージドインスタンスとして登録します。 環境変数 AWS_DEFAULT_REGION のように AWS の Credential にてデフォルトの Region 設定があった場合でも、このコマンドではオプションで Region 指定が必須となるのでご注意ください。 4. SessionManager エージェントの起動 最後に SessionManager エージェントを起動します。 これにより AWS との通信が確立され、SessionManager が利用できるようになります。 この状態でマネージドインスタンス画面にて目的のインスタンスが「オンライン」であれば設定が完了です。 接続確認 設定が完了したので、実際に SessionManager にて接続してみます。 AWS コンソールのセッションマネージャからセッションの開始を選択し、名前が事前に登録した medley-blog-fargate-container であるものを選択します。 外見は他の EC2 と変わらない表示ですが、この手段で登録したものはインスタンス ID が mi から始まる ID になります(通常の EC2 は i から始まる ID)。 後は普段通りにセッションを開始するとコンテナ内へのアクセスが開始されます。 これで EC2 の無い Fargate 上のコンテナに対してもターミナルに入ることができました。 運用してみての感想 Fargate 上のコンテナに直接入ることにより、今まで出来なかった top コマンドによるプロセス状態の確認 df コマンドによる Disk 容量の確認 などの環境調査が出来るようになりました。 利用頻度が多い訳ではありませんが、調査の選択肢を増やす事により有事の際の早期対応に繋げれられていると感じています。 注意点 ここからは運用に当たっての注意点について数点紹介します。 料金 EC2 での SessionManager と違い、 この方法で登録したサーバへの SessionManager 通信は料金が発生します 。 正確には 「SessionManager エージェントが起動し AWS と通信が確立している状態」 での時間課金で SessionManager での接続有無は問いません。 よって、常時必要ではない場合は SessionManager エージェントを止めて節約する方法を検討してください。 アクティベーションやマネージドインスタンスがリストに残る コンテナ終了時でも AWS コンソールのハイブリッドアクティベーション一覧やマネージドインスタンス一覧に表示が残ってしまうようです。 一覧の上限の記載は見つからなかったものの、無限に増えるとも思えないので適時 Lambda を使って削除しています。 SessionManager での操作について EC2 インスタンスに対しての SessionManager と同様ですが、セッション開始直後のユーザは ssm-user 固定になるようです。 特定ユーザでの操作が必要となる場合、 su コマンドでのユーザ切り替えが必要になります。 さいごに 今回のようにメドレーでは新たな技術を取り入れつつ、サービスの安定を目的とした様々な施策を導入しています。 こういった働き方に興味を持たれた方、まずは下記リンクからお気軽にお話しませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp
自己紹介 株式会社メドレーのエンジニア阪本です。 9 月に入っても暑い日が続く中、皆さんはいかがお過ごしでしょうか。 前回のブログでも書きましたが私は野球観戦（虎党）が趣味で、毎日の試合結果に一喜一憂しています。 このブログの執筆時点ではセ・リーグは首位巨人にマジックが点灯し、残試合 50 を切った状況でのゲーム差 10。優勝を目指す阪神にとっては厳しい状況となりましたが、残り直接対決をすべて勝てば可能性は見えてくるはず。ここは諦めずに応援しようと思います。 次の記事を書く頃には何らかの決着が着いていると思いますので、その時には喜びのメッセージが書ける事を願っています。 はじめに 突然ですが、皆さんは Fargate を使いこなしていますか？ 今まで ECS(EC2)での運用がメインでしたが、ジョブメドレーのシステムでも Fargate に触れる機会が増えてきました。 筆者自身は初めての Fargate でしたが、EC2 の存在が無くなることに不思議な感覚を覚えつつも、管理するものが減って運用が楽になったと実感しています。 しかし、EC2 が無くなった事によりサーバ内にターミナルで入る手段を失いました。 公式の ガイド では 質問２：コンテナの中に ssh や docker exec で入ることは出来ますか？ こちら現状サポートしておりませんが、コンテナワークロードでは「 同一の環境でしっかりテストを行う 」ことや「 ログを外部に全て出す 」ことがベストプラクティスとされていて、コンテナに入る必要性を出来る限り減らす方が将来的にも好ましいです。 と「事前にテストを十分に実施する」「ログは(S3 や CloudWatchLogs など)外部に出力する」 さえ出来ていれば入る必要が無いはずと記載されているものの・・・心配性な自分は不測の事態が発生した時の事を考えてサーバに入る手段を求めてしまいます。 そこで代替手段を模索していた所、 SessionManager を使えば可能との文献を見つけました。 すでに SessionManager 自体は EC2 に対して運用を行っていたため導入の敷居は低いと考え、この手段を採用することにしました。 Session Manager とは？ Session Manager とは AWS の Systems Manager サービスの 1 機能で、AWS 上で管理しているサーバ（マネージドインスタンス）に対してターミナルのアクセスを可能にするものです。 ターミナルへのアクセス手段は、よくある手段だと SSH がありますが この方法は SSH ポートを外部に開放する必要があるため攻撃の対象になりやすく、あまり好ましくありません。 それに比べて Session Manager は SSH ポートの開放は不要でサーバから見てアウトバウンド方向の HTTPS 通信の確保で済む為、外部からの攻撃も受けず安全にアクセス経路の確保が実現できます。 ※通信経路の確保以外にも IAM ロールの設定などが必要となります。詳しくは こちら を参考 「AWS 上で管理しているサーバ」と先に記載しましたが、このサーバは EC2 インスタンスに限らないのが本記事の重要なポイントになります。 オンプレミスなサーバも AWS 上で管理されているのであれば、SessionManager エージェントをインストールする事により管理対象に含めることが可能になるのです。 今回は EC2 で動いていた SessionManager エージェントを Fargate で動くコンテナにインストールする事によりコンテナ自体をサーバと見立ててマネージドインスタンスとし、SessionManager でアクセスする事を目指します。 対応 Systems Manager インスタンス枠をスタンダードからアドバンスドに変更する ／ AWS コンソールでの設定 オンプレミスなサーバに SessionManager にてアクセスする場合、Systems Manager のオンプレミスインスタンスティアを スタンダードからアドバンスドへと変更する必要 があります。 この変更作業は AWS コンソールから行う事になりますが、アドバンスドへの変更に当たって既存のマネージドインスタンスに影響することはありません。 ただし、この逆の場合、スタンダードに戻す際には考慮が必要となるので こちら を参照ください。 SSM Agent のインストール ／ コンテナに対する設定 ここからは実際に動くコンテナに対する設定になります。 AWS のドキュメント 手動でインストール SSM エージェント EC2 で Linux のインスタンス を参考に、OS に合った方法で SessionManager エージェントのインストールを行います。 インストール作業には通信などの時間が必要となるので、事前にコンテナイメージにインストールする形としました。 コンテナをマネージドインスタンスとして登録する ／ コンテナに対する設定 コンテナをマネージドインスタンスとして登録するため、コンテナのスタートアップ(Entrypoint)にて下記スクリプトを実行します。 # 1. ハイブリッドアクティベーションの作成 SSM_ACTIVATE_INFO = ` aws ssm create-activation --iam-role service-role/AmazonEC2RunCommandRoleForManagedInstances --registration-limit 1 --region ap-northeast-1 --default-instance-name medley-blog-fargate-container` # 2. アウトプットからアクティベーションコード/ID の抽出 SSM_ACTIVATE_CODE = ` echo $SSM_ACTIVATE_INFO | jq -r '.ActivationCode'` SSM_ACTIVATE_ID = ` echo $SSM_ACTIVATE_INFO | jq -r '.ActivationId'` # 3. コンテナ自身をマネージドインスタンスへの登録 amazon-ssm-agent -register -code $SSM_ACTIVATE_CODE -id $SSM_ACTIVATE_ID -region "ap-northeast-1" # 4. SessionManager エージェントの起動 amazon-ssm-agent & これらのコマンドについては各行ごとに説明します 1.ハイブリッドアクティベーションの作成 マネージドインスタンス登録に必要なアクティベーションコード/ID 取得のため、ハイブリッドアクティベーションの登録を行います。 後々 AWS コンソールにてインスタンスの識別ができるように、 --default-instance-name オプションにて medley-blog-fargate-container という名前を付与しています。 このコマンドのアウトプットにて下記のような JSON が返される為、一旦変数に格納しています。 { "ActivationId" : "<<アクティベーション ID>>", "ActivationCode": "<<アクティベーションコード>>" } また --iam-role オプションでサービスロール AmazonEC2RunCommandRoleForManagedInstances を使っています。 このロールがまだ存在しない場合、AWS コンソールからハイブリッドアクティベーションから IAM ロール →「必要な権限を備えたシステムのデフォルトコマンド実行ロールを作成」により作成してください。 2. アウトプットからアクティベーションコード/ID の抽出 前項のアウトプットからアクティベーションコード/ID を個々の変数に分離しています。 3. コンテナ自身をマネージドインスタンスへの登録 取得したアクティベーションコード/ID を利用し、コンテナ自身をマネージドインスタンスとして登録します。 環境変数 AWS_DEFAULT_REGION のように AWS の Credential にてデフォルトの Region 設定があった場合でも、このコマンドではオプションで Region 指定が必須となるのでご注意ください。 4. SessionManager エージェントの起動 最後に SessionManager エージェントを起動します。 これにより AWS との通信が確立され、SessionManager が利用できるようになります。 この状態でマネージドインスタンス画面にて目的のインスタンスが「オンライン」であれば設定が完了です。 接続確認 設定が完了したので、実際に SessionManager にて接続してみます。 AWS コンソールのセッションマネージャからセッションの開始を選択し、名前が事前に登録した medley-blog-fargate-container であるものを選択します。 外見は他の EC2 と変わらない表示ですが、この手段で登録したものはインスタンス ID が mi から始まる ID になります(通常の EC2 は i から始まる ID)。 後は普段通りにセッションを開始するとコンテナ内へのアクセスが開始されます。 これで EC2 の無い Fargate 上のコンテナに対してもターミナルに入ることができました。 運用してみての感想 Fargate 上のコンテナに直接入ることにより、今まで出来なかった top コマンドによるプロセス状態の確認 df コマンドによる Disk 容量の確認 などの環境調査が出来るようになりました。 利用頻度が多い訳ではありませんが、調査の選択肢を増やす事により有事の際の早期対応に繋げれられていると感じています。 注意点 ここからは運用に当たっての注意点について数点紹介します。 料金 EC2 での SessionManager と違い、 この方法で登録したサーバへの SessionManager 通信は料金が発生します 。 正確には 「SessionManager エージェントが起動し AWS と通信が確立している状態」 での時間課金で SessionManager での接続有無は問いません。 よって、常時必要ではない場合は SessionManager エージェントを止めて節約する方法を検討してください。 アクティベーションやマネージドインスタンスがリストに残る コンテナ終了時でも AWS コンソールのハイブリッドアクティベーション一覧やマネージドインスタンス一覧に表示が残ってしまうようです。 一覧の上限の記載は見つからなかったものの、無限に増えるとも思えないので適時 Lambda を使って削除しています。 SessionManager での操作について EC2 インスタンスに対しての SessionManager と同様ですが、セッション開始直後のユーザは ssm-user 固定になるようです。 特定ユーザでの操作が必要となる場合、 su コマンドでのユーザ切り替えが必要になります。 さいごに 今回のようにメドレーでは新たな技術を取り入れつつ、サービスの安定を目的とした様々な施策を導入しています。 こういった働き方に興味を持たれた方、まずは下記リンクからお気軽にお話しませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp
自己紹介 株式会社メドレーのエンジニア阪本です。 9 月に入っても暑い日が続く中、皆さんはいかがお過ごしでしょうか。 前回のブログでも書きましたが私は野球観戦（虎党）が趣味で、毎日の試合結果に一喜一憂しています。 このブログの執筆時点ではセ・リーグは首位巨人にマジックが点灯し、残試合 50 を切った状況でのゲーム差 10。優勝を目指す阪神にとっては厳しい状況となりましたが、残り直接対決をすべて勝てば可能性は見えてくるはず。ここは諦めずに応援しようと思います。 次の記事を書く頃には何らかの決着が着いていると思いますので、その時には喜びのメッセージが書ける事を願っています。 はじめに 突然ですが、皆さんは Fargate を使いこなしていますか？ 今まで ECS(EC2)での運用がメインでしたが、ジョブメドレーのシステムでも Fargate に触れる機会が増えてきました。 筆者自身は初めての Fargate でしたが、EC2 の存在が無くなることに不思議な感覚を覚えつつも、管理するものが減って運用が楽になったと実感しています。 しかし、EC2 が無くなった事によりサーバ内にターミナルで入る手段を失いました。 公式の ガイド では 質問２：コンテナの中に ssh や docker exec で入ることは出来ますか？ こちら現状サポートしておりませんが、コンテナワークロードでは「 同一の環境でしっかりテストを行う 」ことや「 ログを外部に全て出す 」ことがベストプラクティスとされていて、コンテナに入る必要性を出来る限り減らす方が将来的にも好ましいです。 と「事前にテストを十分に実施する」「ログは(S3 や CloudWatchLogs など)外部に出力する」 さえ出来ていれば入る必要が無いはずと記載されているものの・・・心配性な自分は不測の事態が発生した時の事を考えてサーバに入る手段を求めてしまいます。 そこで代替手段を模索していた所、 SessionManager を使えば可能との文献を見つけました。 すでに SessionManager 自体は EC2 に対して運用を行っていたため導入の敷居は低いと考え、この手段を採用することにしました。 Session Manager とは？ Session Manager とは AWS の Systems Manager サービスの 1 機能で、AWS 上で管理しているサーバ（マネージドインスタンス）に対してターミナルのアクセスを可能にするものです。 ターミナルへのアクセス手段は、よくある手段だと SSH がありますが この方法は SSH ポートを外部に開放する必要があるため攻撃の対象になりやすく、あまり好ましくありません。 それに比べて Session Manager は SSH ポートの開放は不要でサーバから見てアウトバウンド方向の HTTPS 通信の確保で済む為、外部からの攻撃も受けず安全にアクセス経路の確保が実現できます。 ※通信経路の確保以外にも IAM ロールの設定などが必要となります。詳しくは こちら を参考 「AWS 上で管理しているサーバ」と先に記載しましたが、このサーバは EC2 インスタンスに限らないのが本記事の重要なポイントになります。 オンプレミスなサーバも AWS 上で管理されているのであれば、SessionManager エージェントをインストールする事により管理対象に含めることが可能になるのです。 今回は EC2 で動いていた SessionManager エージェントを Fargate で動くコンテナにインストールする事によりコンテナ自体をサーバと見立ててマネージドインスタンスとし、SessionManager でアクセスする事を目指します。 対応 Systems Manager インスタンス枠をスタンダードからアドバンスドに変更する ／ AWS コンソールでの設定 オンプレミスなサーバに SessionManager にてアクセスする場合、Systems Manager のオンプレミスインスタンスティアを スタンダードからアドバンスドへと変更する必要 があります。 この変更作業は AWS コンソールから行う事になりますが、アドバンスドへの変更に当たって既存のマネージドインスタンスに影響することはありません。 ただし、この逆の場合、スタンダードに戻す際には考慮が必要となるので こちら を参照ください。 SSM Agent のインストール ／ コンテナに対する設定 ここからは実際に動くコンテナに対する設定になります。 AWS のドキュメント 手動でインストール SSM エージェント EC2 で Linux のインスタンス を参考に、OS に合った方法で SessionManager エージェントのインストールを行います。 インストール作業には通信などの時間が必要となるので、事前にコンテナイメージにインストールする形としました。 コンテナをマネージドインスタンスとして登録する ／ コンテナに対する設定 コンテナをマネージドインスタンスとして登録するため、コンテナのスタートアップ(Entrypoint)にて下記スクリプトを実行します。 # 1. ハイブリッドアクティベーションの作成 SSM_ACTIVATE_INFO = ` aws ssm create-activation --iam-role service-role/AmazonEC2RunCommandRoleForManagedInstances --registration-limit 1 --region ap-northeast-1 --default-instance-name medley-blog-fargate-container` # 2. アウトプットからアクティベーションコード/ID の抽出 SSM_ACTIVATE_CODE = ` echo $SSM_ACTIVATE_INFO | jq -r '.ActivationCode'` SSM_ACTIVATE_ID = ` echo $SSM_ACTIVATE_INFO | jq -r '.ActivationId'` # 3. コンテナ自身をマネージドインスタンスへの登録 amazon-ssm-agent -register -code $SSM_ACTIVATE_CODE -id $SSM_ACTIVATE_ID -region "ap-northeast-1" # 4. SessionManager エージェントの起動 amazon-ssm-agent & これらのコマンドについては各行ごとに説明します 1.ハイブリッドアクティベーションの作成 マネージドインスタンス登録に必要なアクティベーションコード/ID 取得のため、ハイブリッドアクティベーションの登録を行います。 後々 AWS コンソールにてインスタンスの識別ができるように、 --default-instance-name オプションにて medley-blog-fargate-container という名前を付与しています。 このコマンドのアウトプットにて下記のような JSON が返される為、一旦変数に格納しています。 { "ActivationId" : "<<アクティベーション ID>>", "ActivationCode": "<<アクティベーションコード>>" } また --iam-role オプションでサービスロール AmazonEC2RunCommandRoleForManagedInstances を使っています。 このロールがまだ存在しない場合、AWS コンソールからハイブリッドアクティベーションから IAM ロール →「必要な権限を備えたシステムのデフォルトコマンド実行ロールを作成」により作成してください。 2. アウトプットからアクティベーションコード/ID の抽出 前項のアウトプットからアクティベーションコード/ID を個々の変数に分離しています。 3. コンテナ自身をマネージドインスタンスへの登録 取得したアクティベーションコード/ID を利用し、コンテナ自身をマネージドインスタンスとして登録します。 環境変数 AWS_DEFAULT_REGION のように AWS の Credential にてデフォルトの Region 設定があった場合でも、このコマンドではオプションで Region 指定が必須となるのでご注意ください。 4. SessionManager エージェントの起動 最後に SessionManager エージェントを起動します。 これにより AWS との通信が確立され、SessionManager が利用できるようになります。 この状態でマネージドインスタンス画面にて目的のインスタンスが「オンライン」であれば設定が完了です。 接続確認 設定が完了したので、実際に SessionManager にて接続してみます。 AWS コンソールのセッションマネージャからセッションの開始を選択し、名前が事前に登録した medley-blog-fargate-container であるものを選択します。 外見は他の EC2 と変わらない表示ですが、この手段で登録したものはインスタンス ID が mi から始まる ID になります(通常の EC2 は i から始まる ID)。 後は普段通りにセッションを開始するとコンテナ内へのアクセスが開始されます。 これで EC2 の無い Fargate 上のコンテナに対してもターミナルに入ることができました。 運用してみての感想 Fargate 上のコンテナに直接入ることにより、今まで出来なかった top コマンドによるプロセス状態の確認 df コマンドによる Disk 容量の確認 などの環境調査が出来るようになりました。 利用頻度が多い訳ではありませんが、調査の選択肢を増やす事により有事の際の早期対応に繋げれられていると感じています。 注意点 ここからは運用に当たっての注意点について数点紹介します。 料金 EC2 での SessionManager と違い、 この方法で登録したサーバへの SessionManager 通信は料金が発生します 。 正確には 「SessionManager エージェントが起動し AWS と通信が確立している状態」 での時間課金で SessionManager での接続有無は問いません。 よって、常時必要ではない場合は SessionManager エージェントを止めて節約する方法を検討してください。 アクティベーションやマネージドインスタンスがリストに残る コンテナ終了時でも AWS コンソールのハイブリッドアクティベーション一覧やマネージドインスタンス一覧に表示が残ってしまうようです。 一覧の上限の記載は見つからなかったものの、無限に増えるとも思えないので適時 Lambda を使って削除しています。 SessionManager での操作について EC2 インスタンスに対しての SessionManager と同様ですが、セッション開始直後のユーザは ssm-user 固定になるようです。 特定ユーザでの操作が必要となる場合、 su コマンドでのユーザ切り替えが必要になります。 さいごに 今回のようにメドレーでは新たな技術を取り入れつつ、サービスの安定を目的とした様々な施策を導入しています。 こういった働き方に興味を持たれた方、まずは下記リンクからお気軽にお話しませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp
自己紹介 株式会社メドレーのエンジニア阪本です。 9 月に入っても暑い日が続く中、皆さんはいかがお過ごしでしょうか。 前回のブログでも書きましたが私は野球観戦（虎党）が趣味で、毎日の試合結果に一喜一憂しています。 このブログの執筆時点ではセ・リーグは首位巨人にマジックが点灯し、残試合 50 を切った状況でのゲーム差 10。優勝を目指す阪神にとっては厳しい状況となりましたが、残り直接対決をすべて勝てば可能性は見えてくるはず。ここは諦めずに応援しようと思います。 次の記事を書く頃には何らかの決着が着いていると思いますので、その時には喜びのメッセージが書ける事を願っています。 はじめに 突然ですが、皆さんは Fargate を使いこなしていますか？ 今まで ECS(EC2)での運用がメインでしたが、ジョブメドレーのシステムでも Fargate に触れる機会が増えてきました。 筆者自身は初めての Fargate でしたが、EC2 の存在が無くなることに不思議な感覚を覚えつつも、管理するものが減って運用が楽になったと実感しています。 しかし、EC2 が無くなった事によりサーバ内にターミナルで入る手段を失いました。 公式の ガイド では 質問２：コンテナの中に ssh や docker exec で入ることは出来ますか？ こちら現状サポートしておりませんが、コンテナワークロードでは「 同一の環境でしっかりテストを行う 」ことや「 ログを外部に全て出す 」ことがベストプラクティスとされていて、コンテナに入る必要性を出来る限り減らす方が将来的にも好ましいです。 と「事前にテストを十分に実施する」「ログは(S3 や CloudWatchLogs など)外部に出力する」 さえ出来ていれば入る必要が無いはずと記載されているものの・・・心配性な自分は不測の事態が発生した時の事を考えてサーバに入る手段を求めてしまいます。 そこで代替手段を模索していた所、 SessionManager を使えば可能との文献を見つけました。 すでに SessionManager 自体は EC2 に対して運用を行っていたため導入の敷居は低いと考え、この手段を採用することにしました。 Session Manager とは？ Session Manager とは AWS の Systems Manager サービスの 1 機能で、AWS 上で管理しているサーバ（マネージドインスタンス）に対してターミナルのアクセスを可能にするものです。 ターミナルへのアクセス手段は、よくある手段だと SSH がありますが この方法は SSH ポートを外部に開放する必要があるため攻撃の対象になりやすく、あまり好ましくありません。 それに比べて Session Manager は SSH ポートの開放は不要でサーバから見てアウトバウンド方向の HTTPS 通信の確保で済む為、外部からの攻撃も受けず安全にアクセス経路の確保が実現できます。 ※通信経路の確保以外にも IAM ロールの設定などが必要となります。詳しくは こちら を参考 「AWS 上で管理しているサーバ」と先に記載しましたが、このサーバは EC2 インスタンスに限らないのが本記事の重要なポイントになります。 オンプレミスなサーバも AWS 上で管理されているのであれば、SessionManager エージェントをインストールする事により管理対象に含めることが可能になるのです。 今回は EC2 で動いていた SessionManager エージェントを Fargate で動くコンテナにインストールする事によりコンテナ自体をサーバと見立ててマネージドインスタンスとし、SessionManager でアクセスする事を目指します。 対応 Systems Manager インスタンス枠をスタンダードからアドバンスドに変更する ／ AWS コンソールでの設定 オンプレミスなサーバに SessionManager にてアクセスする場合、Systems Manager のオンプレミスインスタンスティアを スタンダードからアドバンスドへと変更する必要 があります。 この変更作業は AWS コンソールから行う事になりますが、アドバンスドへの変更に当たって既存のマネージドインスタンスに影響することはありません。 ただし、この逆の場合、スタンダードに戻す際には考慮が必要となるので こちら を参照ください。 SSM Agent のインストール ／ コンテナに対する設定 ここからは実際に動くコンテナに対する設定になります。 AWS のドキュメント 手動でインストール SSM エージェント EC2 で Linux のインスタンス を参考に、OS に合った方法で SessionManager エージェントのインストールを行います。 インストール作業には通信などの時間が必要となるので、事前にコンテナイメージにインストールする形としました。 コンテナをマネージドインスタンスとして登録する ／ コンテナに対する設定 コンテナをマネージドインスタンスとして登録するため、コンテナのスタートアップ(Entrypoint)にて下記スクリプトを実行します。 # 1. ハイブリッドアクティベーションの作成 SSM_ACTIVATE_INFO = ` aws ssm create-activation --iam-role service-role/AmazonEC2RunCommandRoleForManagedInstances --registration-limit 1 --region ap-northeast-1 --default-instance-name medley-blog-fargate-container` # 2. アウトプットからアクティベーションコード/ID の抽出 SSM_ACTIVATE_CODE = ` echo $SSM_ACTIVATE_INFO | jq -r '.ActivationCode'` SSM_ACTIVATE_ID = ` echo $SSM_ACTIVATE_INFO | jq -r '.ActivationId'` # 3. コンテナ自身をマネージドインスタンスへの登録 amazon-ssm-agent -register -code $SSM_ACTIVATE_CODE -id $SSM_ACTIVATE_ID -region "ap-northeast-1" # 4. SessionManager エージェントの起動 amazon-ssm-agent & これらのコマンドについては各行ごとに説明します 1.ハイブリッドアクティベーションの作成 マネージドインスタンス登録に必要なアクティベーションコード/ID 取得のため、ハイブリッドアクティベーションの登録を行います。 後々 AWS コンソールにてインスタンスの識別ができるように、 --default-instance-name オプションにて medley-blog-fargate-container という名前を付与しています。 このコマンドのアウトプットにて下記のような JSON が返される為、一旦変数に格納しています。 { "ActivationId" : "<<アクティベーション ID>>", "ActivationCode": "<<アクティベーションコード>>" } また --iam-role オプションでサービスロール AmazonEC2RunCommandRoleForManagedInstances を使っています。 このロールがまだ存在しない場合、AWS コンソールからハイブリッドアクティベーションから IAM ロール →「必要な権限を備えたシステムのデフォルトコマンド実行ロールを作成」により作成してください。 2. アウトプットからアクティベーションコード/ID の抽出 前項のアウトプットからアクティベーションコード/ID を個々の変数に分離しています。 3. コンテナ自身をマネージドインスタンスへの登録 取得したアクティベーションコード/ID を利用し、コンテナ自身をマネージドインスタンスとして登録します。 環境変数 AWS_DEFAULT_REGION のように AWS の Credential にてデフォルトの Region 設定があった場合でも、このコマンドではオプションで Region 指定が必須となるのでご注意ください。 4. SessionManager エージェントの起動 最後に SessionManager エージェントを起動します。 これにより AWS との通信が確立され、SessionManager が利用できるようになります。 この状態でマネージドインスタンス画面にて目的のインスタンスが「オンライン」であれば設定が完了です。 接続確認 設定が完了したので、実際に SessionManager にて接続してみます。 AWS コンソールのセッションマネージャからセッションの開始を選択し、名前が事前に登録した medley-blog-fargate-container であるものを選択します。 外見は他の EC2 と変わらない表示ですが、この手段で登録したものはインスタンス ID が mi から始まる ID になります(通常の EC2 は i から始まる ID)。 後は普段通りにセッションを開始するとコンテナ内へのアクセスが開始されます。 これで EC2 の無い Fargate 上のコンテナに対してもターミナルに入ることができました。 運用してみての感想 Fargate 上のコンテナに直接入ることにより、今まで出来なかった top コマンドによるプロセス状態の確認 df コマンドによる Disk 容量の確認 などの環境調査が出来るようになりました。 利用頻度が多い訳ではありませんが、調査の選択肢を増やす事により有事の際の早期対応に繋げれられていると感じています。 注意点 ここからは運用に当たっての注意点について数点紹介します。 料金 EC2 での SessionManager と違い、 この方法で登録したサーバへの SessionManager 通信は料金が発生します 。 正確には 「SessionManager エージェントが起動し AWS と通信が確立している状態」 での時間課金で SessionManager での接続有無は問いません。 よって、常時必要ではない場合は SessionManager エージェントを止めて節約する方法を検討してください。 アクティベーションやマネージドインスタンスがリストに残る コンテナ終了時でも AWS コンソールのハイブリッドアクティベーション一覧やマネージドインスタンス一覧に表示が残ってしまうようです。 一覧の上限の記載は見つからなかったものの、無限に増えるとも思えないので適時 Lambda を使って削除しています。 SessionManager での操作について EC2 インスタンスに対しての SessionManager と同様ですが、セッション開始直後のユーザは ssm-user 固定になるようです。 特定ユーザでの操作が必要となる場合、 su コマンドでのユーザ切り替えが必要になります。 さいごに 今回のようにメドレーでは新たな技術を取り入れつつ、サービスの安定を目的とした様々な施策を導入しています。 こういった働き方に興味を持たれた方、まずは下記リンクからお気軽にお話しませんか？ https://www.medley.jp/jobs/
自己紹介 株式会社メドレーのエンジニア阪本です。 9 月に入っても暑い日が続く中、皆さんはいかがお過ごしでしょうか。 前回のブログでも書きましたが私は野球観戦（虎党）が趣味で、毎日の試合結果に一喜一憂しています。 このブログの執筆時点ではセ・リーグは首位巨人にマジックが点灯し、残試合 50 を切った状況でのゲーム差 10。優勝を目指す阪神にとっては厳しい状況となりましたが、残り直接対決をすべて勝てば可能性は見えてくるはず。ここは諦めずに応援しようと思います。 次の記事を書く頃には何らかの決着が着いていると思いますので、その時には喜びのメッセージが書ける事を願っています。 はじめに 突然ですが、皆さんは Fargate を使いこなしていますか？ 今まで ECS(EC2)での運用がメインでしたが、ジョブメドレーのシステムでも Fargate に触れる機会が増えてきました。 筆者自身は初めての Fargate でしたが、EC2 の存在が無くなることに不思議な感覚を覚えつつも、管理するものが減って運用が楽になったと実感しています。 しかし、EC2 が無くなった事によりサーバ内にターミナルで入る手段を失いました。 公式の ガイド では 質問２：コンテナの中に ssh や docker exec で入ることは出来ますか？ こちら現状サポートしておりませんが、コンテナワークロードでは「 同一の環境でしっかりテストを行う 」ことや「 ログを外部に全て出す 」ことがベストプラクティスとされていて、コンテナに入る必要性を出来る限り減らす方が将来的にも好ましいです。 と「事前にテストを十分に実施する」「ログは(S3 や CloudWatchLogs など)外部に出力する」 さえ出来ていれば入る必要が無いはずと記載されているものの・・・心配性な自分は不測の事態が発生した時の事を考えてサーバに入る手段を求めてしまいます。 そこで代替手段を模索していた所、 SessionManager を使えば可能との文献を見つけました。 すでに SessionManager 自体は EC2 に対して運用を行っていたため導入の敷居は低いと考え、この手段を採用することにしました。 Session Manager とは？ Session Manager とは AWS の Systems Manager サービスの 1 機能で、AWS 上で管理しているサーバ（マネージドインスタンス）に対してターミナルのアクセスを可能にするものです。 ターミナルへのアクセス手段は、よくある手段だと SSH がありますが この方法は SSH ポートを外部に開放する必要があるため攻撃の対象になりやすく、あまり好ましくありません。 それに比べて Session Manager は SSH ポートの開放は不要でサーバから見てアウトバウンド方向の HTTPS 通信の確保で済む為、外部からの攻撃も受けず安全にアクセス経路の確保が実現できます。 ※通信経路の確保以外にも IAM ロールの設定などが必要となります。詳しくは こちら を参考 「AWS 上で管理しているサーバ」と先に記載しましたが、このサーバは EC2 インスタンスに限らないのが本記事の重要なポイントになります。 オンプレミスなサーバも AWS 上で管理されているのであれば、SessionManager エージェントをインストールする事により管理対象に含めることが可能になるのです。 今回は EC2 で動いていた SessionManager エージェントを Fargate で動くコンテナにインストールする事によりコンテナ自体をサーバと見立ててマネージドインスタンスとし、SessionManager でアクセスする事を目指します。 対応 Systems Manager インスタンス枠をスタンダードからアドバンスドに変更する ／ AWS コンソールでの設定 オンプレミスなサーバに SessionManager にてアクセスする場合、Systems Manager のオンプレミスインスタンスティアを スタンダードからアドバンスドへと変更する必要 があります。 この変更作業は AWS コンソールから行う事になりますが、アドバンスドへの変更に当たって既存のマネージドインスタンスに影響することはありません。 ただし、この逆の場合、スタンダードに戻す際には考慮が必要となるので こちら を参照ください。 SSM Agent のインストール ／ コンテナに対する設定 ここからは実際に動くコンテナに対する設定になります。 AWS のドキュメント 手動でインストール SSM エージェント EC2 で Linux のインスタンス を参考に、OS に合った方法で SessionManager エージェントのインストールを行います。 インストール作業には通信などの時間が必要となるので、事前にコンテナイメージにインストールする形としました。 コンテナをマネージドインスタンスとして登録する ／ コンテナに対する設定 コンテナをマネージドインスタンスとして登録するため、コンテナのスタートアップ(Entrypoint)にて下記スクリプトを実行します。 # 1. ハイブリッドアクティベーションの作成 SSM_ACTIVATE_INFO = ` aws ssm create-activation --iam-role service-role/AmazonEC2RunCommandRoleForManagedInstances --registration-limit 1 --region ap-northeast-1 --default-instance-name medley-blog-fargate-container` # 2. アウトプットからアクティベーションコード/ID の抽出 SSM_ACTIVATE_CODE = ` echo $SSM_ACTIVATE_INFO | jq -r '.ActivationCode'` SSM_ACTIVATE_ID = ` echo $SSM_ACTIVATE_INFO | jq -r '.ActivationId'` # 3. コンテナ自身をマネージドインスタンスへの登録 amazon-ssm-agent -register -code $SSM_ACTIVATE_CODE -id $SSM_ACTIVATE_ID -region "ap-northeast-1" # 4. SessionManager エージェントの起動 amazon-ssm-agent & これらのコマンドについては各行ごとに説明します 1.ハイブリッドアクティベーションの作成 マネージドインスタンス登録に必要なアクティベーションコード/ID 取得のため、ハイブリッドアクティベーションの登録を行います。 後々 AWS コンソールにてインスタンスの識別ができるように、 --default-instance-name オプションにて medley-blog-fargate-container という名前を付与しています。 このコマンドのアウトプットにて下記のような JSON が返される為、一旦変数に格納しています。 { "ActivationId" : "<<アクティベーション ID>>", "ActivationCode": "<<アクティベーションコード>>" } また --iam-role オプションでサービスロール AmazonEC2RunCommandRoleForManagedInstances を使っています。 このロールがまだ存在しない場合、AWS コンソールからハイブリッドアクティベーションから IAM ロール →「必要な権限を備えたシステムのデフォルトコマンド実行ロールを作成」により作成してください。 2. アウトプットからアクティベーションコード/ID の抽出 前項のアウトプットからアクティベーションコード/ID を個々の変数に分離しています。 3. コンテナ自身をマネージドインスタンスへの登録 取得したアクティベーションコード/ID を利用し、コンテナ自身をマネージドインスタンスとして登録します。 環境変数 AWS_DEFAULT_REGION のように AWS の Credential にてデフォルトの Region 設定があった場合でも、このコマンドではオプションで Region 指定が必須となるのでご注意ください。 4. SessionManager エージェントの起動 最後に SessionManager エージェントを起動します。 これにより AWS との通信が確立され、SessionManager が利用できるようになります。 この状態でマネージドインスタンス画面にて目的のインスタンスが「オンライン」であれば設定が完了です。 接続確認 設定が完了したので、実際に SessionManager にて接続してみます。 AWS コンソールのセッションマネージャからセッションの開始を選択し、名前が事前に登録した medley-blog-fargate-container であるものを選択します。 外見は他の EC2 と変わらない表示ですが、この手段で登録したものはインスタンス ID が mi から始まる ID になります(通常の EC2 は i から始まる ID)。 後は普段通りにセッションを開始するとコンテナ内へのアクセスが開始されます。 これで EC2 の無い Fargate 上のコンテナに対してもターミナルに入ることができました。 運用してみての感想 Fargate 上のコンテナに直接入ることにより、今まで出来なかった top コマンドによるプロセス状態の確認 df コマンドによる Disk 容量の確認 などの環境調査が出来るようになりました。 利用頻度が多い訳ではありませんが、調査の選択肢を増やす事により有事の際の早期対応に繋げれられていると感じています。 注意点 ここからは運用に当たっての注意点について数点紹介します。 料金 EC2 での SessionManager と違い、 この方法で登録したサーバへの SessionManager 通信は料金が発生します 。 正確には 「SessionManager エージェントが起動し AWS と通信が確立している状態」 での時間課金で SessionManager での接続有無は問いません。 よって、常時必要ではない場合は SessionManager エージェントを止めて節約する方法を検討してください。 アクティベーションやマネージドインスタンスがリストに残る コンテナ終了時でも AWS コンソールのハイブリッドアクティベーション一覧やマネージドインスタンス一覧に表示が残ってしまうようです。 一覧の上限の記載は見つからなかったものの、無限に増えるとも思えないので適時 Lambda を使って削除しています。 SessionManager での操作について EC2 インスタンスに対しての SessionManager と同様ですが、セッション開始直後のユーザは ssm-user 固定になるようです。 特定ユーザでの操作が必要となる場合、 su コマンドでのユーザ切り替えが必要になります。 さいごに 今回のようにメドレーでは新たな技術を取り入れつつ、サービスの安定を目的とした様々な施策を導入しています。 こういった働き方に興味を持たれた方、まずは下記リンクからお気軽にお話しませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp
みなさん、こんにちは。エンジニア・デザイナー採用担当の平木です。 メドレーでは iOS 開発コミュニティに微力ながら還元したいと、2017 年より iOSDC に協賛をさせていただいておりますが、今年も シルバースポンサー として協賛させていただくことになりました。 過去の参加レポート entry/2018/09/13/175702 entry/2017/09/27/120000 iOSDC 初のオンライン開催 今年の iOSDC は初のオンライン開催ということで、例年とはまた違った楽しみ方ができそうです。 公式スタッフブログに記載されていますが、今年はノベルティグッズが 配送 されるとのことで、既に届いている方もいらっしゃるようです。弊社のパンフレットも同封させていただいてます。 今年の タイムテーブル も大変興味深い内容が多く、今から視聴が楽しみですが(スポンサーチケットを頂いてはいますが、筆者も自腹でチケット購入しています) ニコニコ生放送での視聴 ということで、例年とは違い、コメントなどで盛り上がりがあるのではないかと、大変期待しています。 Ask the Speaker では Discord を使用するということで、対面とはまた違ったコミュニケーションが取れそうです。参考 URL や図などがすぐに出してもらえたりなど、さらに学びが深くなるのではないかと思っています。 最後に 今回は直接会場でみなさんとの交流はできませんが、弊社のエンジニアも参加予定ですので、一緒に楽しんでいきたいと思います。後日イベントレポートもこちらで公開したいと考えています。 また、メドレーではこうしたイベントにも興味をお持ちの iOS エンジニアを絶賛募集中です。お気軽に下記よりご連絡いただければ、カジュアルにお話をしたいです! https://www.medley.jp/jobs/
みなさん、こんにちは。エンジニア・デザイナー採用担当の平木です。 メドレーでは iOS 開発コミュニティに微力ながら還元したいと、2017 年より iOSDC に協賛をさせていただいておりますが、今年も シルバースポンサー として協賛させていただくことになりました。 過去の参加レポート entry/2018/09/13/175702 entry/2017/09/27/120000 iOSDC 初のオンライン開催 今年の iOSDC は初のオンライン開催ということで、例年とはまた違った楽しみ方ができそうです。 公式スタッフブログに記載されていますが、今年はノベルティグッズが 配送 されるとのことで、既に届いている方もいらっしゃるようです。弊社のパンフレットも同封させていただいてます。 今年の タイムテーブル も大変興味深い内容が多く、今から視聴が楽しみですが(スポンサーチケットを頂いてはいますが、筆者も自腹でチケット購入しています) ニコニコ生放送での視聴 ということで、例年とは違い、コメントなどで盛り上がりがあるのではないかと、大変期待しています。 Ask the Speaker では Discord を使用するということで、対面とはまた違ったコミュニケーションが取れそうです。参考 URL や図などがすぐに出してもらえたりなど、さらに学びが深くなるのではないかと思っています。 最後に 今回は直接会場でみなさんとの交流はできませんが、弊社のエンジニアも参加予定ですので、一緒に楽しんでいきたいと思います。後日イベントレポートもこちらで公開したいと考えています。 また、メドレーではこうしたイベントにも興味をお持ちの iOS エンジニアを絶賛募集中です。お気軽に下記よりご連絡いただければ、カジュアルにお話をしたいです! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp
みなさん、こんにちは。エンジニア・デザイナー採用担当の平木です。 メドレーでは iOS 開発コミュニティに微力ながら還元したいと、2017 年より iOSDC に協賛をさせていただいておりますが、今年も シルバースポンサー として協賛させていただくことになりました。 過去の参加レポート entry/2018/09/13/175702 entry/2017/09/27/120000 iOSDC 初のオンライン開催 今年の iOSDC は初のオンライン開催ということで、例年とはまた違った楽しみ方ができそうです。 公式スタッフブログに記載されていますが、今年はノベルティグッズが 配送 されるとのことで、既に届いている方もいらっしゃるようです。弊社のパンフレットも同封させていただいてます。 今年の タイムテーブル も大変興味深い内容が多く、今から視聴が楽しみですが(スポンサーチケットを頂いてはいますが、筆者も自腹でチケット購入しています) ニコニコ生放送での視聴 ということで、例年とは違い、コメントなどで盛り上がりがあるのではないかと、大変期待しています。 Ask the Speaker では Discord を使用するということで、対面とはまた違ったコミュニケーションが取れそうです。参考 URL や図などがすぐに出してもらえたりなど、さらに学びが深くなるのではないかと思っています。 最後に 今回は直接会場でみなさんとの交流はできませんが、弊社のエンジニアも参加予定ですので、一緒に楽しんでいきたいと思います。後日イベントレポートもこちらで公開したいと考えています。 また、メドレーではこうしたイベントにも興味をお持ちの iOS エンジニアを絶賛募集中です。お気軽に下記よりご連絡いただければ、カジュアルにお話をしたいです! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp
みなさん、こんにちは。エンジニア・デザイナー採用担当の平木です。 メドレーでは iOS 開発コミュニティに微力ながら還元したいと、2017 年より iOSDC に協賛をさせていただいておりますが、今年も シルバースポンサー として協賛させていただくことになりました。 過去の参加レポート entry/2018/09/13/175702 entry/2017/09/27/120000 iOSDC 初のオンライン開催 今年の iOSDC は初のオンライン開催ということで、例年とはまた違った楽しみ方ができそうです。 公式スタッフブログに記載されていますが、今年はノベルティグッズが 配送 されるとのことで、既に届いている方もいらっしゃるようです。弊社のパンフレットも同封させていただいてます。 今年の タイムテーブル も大変興味深い内容が多く、今から視聴が楽しみですが(スポンサーチケットを頂いてはいますが、筆者も自腹でチケット購入しています) ニコニコ生放送での視聴 ということで、例年とは違い、コメントなどで盛り上がりがあるのではないかと、大変期待しています。 Ask the Speaker では Discord を使用するということで、対面とはまた違ったコミュニケーションが取れそうです。参考 URL や図などがすぐに出してもらえたりなど、さらに学びが深くなるのではないかと思っています。 最後に 今回は直接会場でみなさんとの交流はできませんが、弊社のエンジニアも参加予定ですので、一緒に楽しんでいきたいと思います。後日イベントレポートもこちらで公開したいと考えています。 また、メドレーではこうしたイベントにも興味をお持ちの iOS エンジニアを絶賛募集中です。お気軽に下記よりご連絡いただければ、カジュアルにお話をしたいです! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp
みなさん、こんにちは。エンジニア・デザイナー採用担当の平木です。 メドレーでは iOS 開発コミュニティに微力ながら還元したいと、2017 年より iOSDC に協賛をさせていただいておりますが、今年も シルバースポンサー として協賛させていただくことになりました。 過去の参加レポート entry/2018/09/13/175702 entry/2017/09/27/120000 iOSDC 初のオンライン開催 今年の iOSDC は初のオンライン開催ということで、例年とはまた違った楽しみ方ができそうです。 公式スタッフブログに記載されていますが、今年はノベルティグッズが 配送 されるとのことで、既に届いている方もいらっしゃるようです。弊社のパンフレットも同封させていただいてます。 今年の タイムテーブル も大変興味深い内容が多く、今から視聴が楽しみですが(スポンサーチケットを頂いてはいますが、筆者も自腹でチケット購入しています) ニコニコ生放送での視聴 ということで、例年とは違い、コメントなどで盛り上がりがあるのではないかと、大変期待しています。 Ask the Speaker では Discord を使用するということで、対面とはまた違ったコミュニケーションが取れそうです。参考 URL や図などがすぐに出してもらえたりなど、さらに学びが深くなるのではないかと思っています。 最後に 今回は直接会場でみなさんとの交流はできませんが、弊社のエンジニアも参加予定ですので、一緒に楽しんでいきたいと思います。後日イベントレポートもこちらで公開したいと考えています。 また、メドレーではこうしたイベントにも興味をお持ちの iOS エンジニアを絶賛募集中です。お気軽に下記よりご連絡いただければ、カジュアルにお話をしたいです! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp
みなさん、こんにちは。エンジニア・デザイナー採用担当の平木です。 メドレーでは iOS 開発コミュニティに微力ながら還元したいと、2017 年より iOSDC に協賛をさせていただいておりますが、今年も シルバースポンサー として協賛させていただくことになりました。 過去の参加レポート entry/2018/09/13/175702 entry/2017/09/27/120000 iOSDC 初のオンライン開催 今年の iOSDC は初のオンライン開催ということで、例年とはまた違った楽しみ方ができそうです。 公式スタッフブログに記載されていますが、今年はノベルティグッズが 配送 されるとのことで、既に届いている方もいらっしゃるようです。弊社のパンフレットも同封させていただいてます。 今年の タイムテーブル も大変興味深い内容が多く、今から視聴が楽しみですが(スポンサーチケットを頂いてはいますが、筆者も自腹でチケット購入しています) ニコニコ生放送での視聴 ということで、例年とは違い、コメントなどで盛り上がりがあるのではないかと、大変期待しています。 Ask the Speaker では Discord を使用するということで、対面とはまた違ったコミュニケーションが取れそうです。参考 URL や図などがすぐに出してもらえたりなど、さらに学びが深くなるのではないかと思っています。 最後に 今回は直接会場でみなさんとの交流はできませんが、弊社のエンジニアも参加予定ですので、一緒に楽しんでいきたいと思います。後日イベントレポートもこちらで公開したいと考えています。 また、メドレーではこうしたイベントにも興味をお持ちの iOS エンジニアを絶賛募集中です。お気軽に下記よりご連絡いただければ、カジュアルにお話をしたいです! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp
みなさん、こんにちは。エンジニア・デザイナー採用担当の平木です。 メドレーでは iOS 開発コミュニティに微力ながら還元したいと、2017 年より iOSDC に協賛をさせていただいておりますが、今年も シルバースポンサー として協賛させていただくことになりました。 過去の参加レポート entry/2018/09/13/175702 entry/2017/09/27/120000 iOSDC 初のオンライン開催 今年の iOSDC は初のオンライン開催ということで、例年とはまた違った楽しみ方ができそうです。 公式スタッフブログに記載されていますが、今年はノベルティグッズが 配送 されるとのことで、既に届いている方もいらっしゃるようです。弊社のパンフレットも同封させていただいてます。 今年の タイムテーブル も大変興味深い内容が多く、今から視聴が楽しみですが(スポンサーチケットを頂いてはいますが、筆者も自腹でチケット購入しています) ニコニコ生放送での視聴 ということで、例年とは違い、コメントなどで盛り上がりがあるのではないかと、大変期待しています。 Ask the Speaker では Discord を使用するということで、対面とはまた違ったコミュニケーションが取れそうです。参考 URL や図などがすぐに出してもらえたりなど、さらに学びが深くなるのではないかと思っています。 最後に 今回は直接会場でみなさんとの交流はできませんが、弊社のエンジニアも参加予定ですので、一緒に楽しんでいきたいと思います。後日イベントレポートもこちらで公開したいと考えています。 また、メドレーではこうしたイベントにも興味をお持ちの iOS エンジニアを絶賛募集中です。お気軽に下記よりご連絡いただければ、カジュアルにお話をしたいです! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp