こんにちは(U・ω・U) DevelopersIO BASECAMPのプロダクトマネージャーをしている深澤です。 定期的にDevelopersIO BASECAMP(以下デベキャン)の様子をお届けしているデベキャンだよりです。今月はデベキャンコミュニティ内での各種イベントの様子についてお届けします。デベキャンコミュニティは学習コミュニティで、参加者同士の交流による学習のモチベーションを維持や、自学の習慣を身に付けることを目的とした機能の提供やイベントの開催をしています。今月開催したイベントは以下の通りでした。 ようこそ会 デベラジオ コンテンツを見て雑談する会 それぞれ順番にご紹介していきます！ ようこそ会 こちらは今月から開始した企画となっていて、デベキャンコミュニティに参加したばかりの方を対象に、こちらのブログをベースにして、デベキャンコミュニティ内のイベントや学習の取り組み方を紹介し

こんにちは(U・ω・U) DevelopersIO BASECAMPのプロダクトマネージャーをしている深澤です。 定期的にDevelopersIO BASECAMP(以下デベキャン)の様子をお届けしているデベキャンだよりですが、今月はデベキャンプラクティスで実施したLT大会の様子をお届けします！ 改めてデベキャンとは DevelopersIO BASECAMP(以下デベキャン)はIT技術を業務で活用したい方に向けたトレーニングサービスです。参加者同士の交流によるモチベーション維持や自身の学習を記録して振返りを行える仕組みを提供する「デベキャンコミュニティ」と、ロールプレイを通した実務経験に近い業務の疑似体験を提供し、最新IT技術を活かした業務およびプロジェクトへの参画を支援するプログラムの「デベキャンプラクティス」の2つのサービスを提供しています。詳しくは以下のページをご覧ください。 本日

こんにちは(U・ω・U) DevelopersIO BASECAMPのプロダクトマネージャーをしている深澤です。 DevelopersIO BASECAMP(以下デベキャン)は今年の6月よりリニューアルし、参加者同士の交流によるモチベーション維持や自身の学習を記録して振返りを行える仕組みを提供する「デベキャンコミュニティ」と、ロールプレイを通した実務経験に近い業務の疑似体験を提供し、最新IT技術を活かした業務およびプロジェクトへの参画を支援するプログラムの「デベキャンプラクティス」の2つのサービスを提供しています。 それぞれの詳細については以下をご覧下さい。どちらも無料で、デベキャンコミュニティはDiscordのアカウントだけご用意いただければ今すぐに入ることができます。 デベキャンプラクティスは2023年の1月から3月にかけて実施した第1期と、その後リニューアルしたものをデベキャンプラク

クラスメソッドのAWS総合支援 コスト最適化からセキュリティ、構築支援、運用保守まで、AWS活用を支援します。

[レポート] テクノロジーで成長する！！「DevelopersIO BASECAMP（デベキャン）の今までとこれからについて」というタイトルで登壇 #devio_day1 #sub1 こんにちは(U・ω・U) AWS事業部の深澤です。 先日行われた「DevelopersIO Day One」というイベントにて、「DevelopersIO BASECAMP（デベキャン）の今までとこれからについて」というタイトルで登壇しましたので、レポートブログを書かせていただきます。 資料 話したこと プロパゲート株式会社について 今回お話しするDevelopersIO BASECAMP（略してデベキャンです）を運用している会社はプロパゲート株式会社という会社になります。クラスメソッドの子会社で比較的まだまだ若い会社となっています。 ビジョンのところに書かれている「成長の支援と実践の機会」こそがデベキャンが

こんにちは(U・ω・U) AWS事業部の深澤です。 2022年12月6日に開催されたCM re:Growth 2022に登壇しましたので資料を公開します。 資料 紹介したブログについて 本セッションで紹介したブログは以下の通りです。 最後に 今回も非常に多くのアップデートが発表された中、DevelopersIO BASECAMP（以下デベキャン）に関連のあるアップデートを、メンターそしてカリキュラム作成者の目線からピックアップしてお伝えさせていただきました。今回のアップデートをキャッチアップいただくことで今まで必要だったものが必要なくなり、よりAWSに運用を任せてビジネスに注力していくことができるようになるはずです。 デベキャンでは現在第2期に向けての募集、企画も進行中です。多くの方と関わるべく、さまざまなイベントも企画してます。ぜひ皆さんからエンジニア育成への想いや意見をTwitterの

こんにちは(U・ω・U) AWS事業部の深澤です。 表題の通り、社内勉強会にて「書く技術」というタイトルで登壇しましたので、資料を公開します。 資料 どんな勉強会だったか こちらの勉強会は先日、自分が「AWSの知識地図」という本を出版しましたので、それに併せて社内で開催いただいた勉強会で著者が本書の内容や執筆時に意識したポイントについて話しました。自分はクラスメソッドに入社してから本書を含め5冊の執筆をさせていただきましたので、そんな執筆活動を応援いただいた関係者の皆様への感謝も込めて、「書く技術」というタイトルで発表しました。 自分が執筆をする際に意識しているポイントは以下の4つです。 ストーリーを意識する なるべく幅広く触れる 他の章との連携を意識する 毎日書く ストーリーを意識する 執筆を始めるときに一番最初に行う作業がこちらです。今回の執筆を通して読者に何を伝えたいか、どんなストー

こんにちは(U・ω・U) AWS事業部の深澤です。 表題の通りですがJAWS-UG横浜 AWS re:Invent 2021 Recap ep.2 にて「GitHub Actionsを使ってAWS App Runnerにデプロイできるようになりました」という話をしてきました。 動画 資料 まとめ AWS App Runnerも出たばかりのサービスで、ソースコードやコンテナイメージを手軽にデプロイして動かせるのが特徴のサービスです。詳細は以下のブログが参考になります。 そんなAWS App Runnerにデプロイ可能なCI/CDパイプラインの選択肢にGitHub Actionsが加わりましたというアップデートです。GitHubとAWS App Runnerが連携する機能はこれまでもありましたが、新たにGitHub Actionsの中でビルド処理やテストが行えるようになったのが非常にありがたい

こんにちは(U・ω・U) AWS事業部の深澤です。 タイトルの通りですが、AKIBA.AWS ONLINE #03 -「TerraformとCloudFormationどちらを採用すべき？」というタイトルで登壇してきましたので資料を公開します。 資料 まとめ まずは大前提として状況と比較しましょう。新しい技術にはどうしても学習コストが伴います。新しくて最新の技術がチームにとって必ずしも最適解であるとは限りません。また作って終わりではなく運用が大切です。それぞれの特徴をチームで理解し運用していけるかというのも大切な観点です。 発表で取り上げた観点と特徴を表にまとめるとこんな感じです。 観点 Terraform Cloudformation

話した内容 ざっくりとAWS BatchにおいてEC2をコンピューティング環境にするケースだと以下のようなことが課題となっていました。 今回のアップデートの概要としてはコンピューティング環境がFargateになったことにより上記のような課題が解決したことになります。 これまでFargateを使ったBatch処理が全然できなかったかというと、実はそんなことないんです。これまでもCloudwatchイベントを用いたFargateの定期処理はこれまでもサポートされていました。 この機能は非常に便利ですしこれからも積極的に検討して良い機能だと思います。では表題の通り今回アップデートのAWS Batch Fargate対応は何をもたらすかですよね。これを考える上でBatch処理とは何かを整理する必要があります。なんとなくBatch処理という言葉を使いますが、これは大きく分けて以下の2つがあると思いま

こんにちは(U・ω・U) AWS事業部の深澤です。 皆さん、今日（7月7日）はクラスメソッド の創設記念日です。 こちらのブログでも触れられていますが、アウトプットはクラスメソッドの文化です。 さて私事で恐縮ですがクラスメソッドに入社して大凡半年が経過しました。エントリブログを確認すると入社したのは2019年10月1日です。 まだまだクラスメソッドに入社して歴史の浅い僕ですが、これまでの僕のアウトプットと一緒にこれまでを振り返ってみたいと思います。クラスメソッドのカルチャーの一部が皆さんに伝わると幸いです。 アウトプットを振り返る AWSDevDay 入社して1ヶ月でオフィスから人がほとんどいなくなったのは良い思い出です（研修とか予定が入っていたものに対してはもちろん対応してもらえました）。AWSDevDayが開催されたから皆さんこちらに行かれたんですよね。入社してわずか1週間で業務を調整

こちらのコールドスタート関連については弊社岩田の資料が大変わかりやすいのでオススメです。 Serverless Meetup Osaka #5 で「VPC Lambda×RDSのデメリットについて正しく理解しよう！!」というテーマで発表してきました #serverlessosaka ｜ DevelopersIO では次のコードを見てください。 import time class sleep_class(): def __init__(self): time.sleep(2.0) self.init_time = time.time() def lambda_handler(event, context): s = sleep_class() print(s.init_time) 初期化に2秒ほどかかるsleepクラスがあります。これをLambdaで複数回実行すると次のような結果になります。

こんにちは(U・ω・U) AWS事業部の深澤です。 さて弊社では昨日よりDevelopersIO2020 〜connect〜というイベントが開かれています。 セッションもりもりだよ！ あつまれー！https://t.co/viwYQqiKG7#devio2020_connect — 深澤俊 (@shun_quartet) June 3, 2020 その中で僕は「ハイトラフィック運用 〜スループットの向上を目指して〜」という話でセッションさせていただいたので本ブログではその発表した内容を資料と共にご紹介します！ 動画 資料 セッション内容 今回扱うこと、扱わないこと 今回は観点をメインに紹介します。 それぞれのエンジン等による細かい違いやチューニング方法には触れません。 例：MySQLとPostgras等 メトリクスはCloudWatchのものをご紹介します。 今回はあくまで概要と基本です。

「あれ、GithubにPushできない。。。？？」 「サーバにSSHで入れなくなった。。。」 こんにちは(U・ω・U) AWS事業部の深澤です。 最近は認証方法が変わったり、コンテナ普及に伴ってちょっと前では常識だったSSHキーを使う機会も少なくなったなと思います。ですが、まだまだなくてはならないバリバリ現役の技術ですね。そんな大切なSSH秘密キー（以降、SSHキー）がある日吹っ飛んだらきっとあなたは焦ることでしょう。今回はSSHキーがある日なくなってしまっても全人類が落ち着いて行動できるようにと願いを込めてこのブログを書きます。 え、なんでこんなことを書こうと思ったかって？聞かないで下さい。ちょっと疲れてたんです…。 まずは落ち着きましょう。 いきなりポエムっぽいですが、お茶でも飲んで少し落ち着きましょう。慌ててもなくなったSSHキーは帰ってきません。障害対応と一緒でトラブル対応は落ち着

こんにちは(U・ω・U) AWS事業部の深澤です。 皆さん、Fargate1.4.0のリリースから約2ヶ月が経とうとしておりますが導入は検討されていますでしょうか。今回のリリースにより従来の1.3.0と比較し本当に多くの機能が利用できるようになりました。できるようになった機能一覧は弊社島川のブログが大変わかりやすいので是非ご参照下さい。 さて実はこうしていろんな機能が利用できるようになった背景には、アーキテクチャの変更が大きく関わっています。詳しくは以下のAWS公式のブログが大変参考になります。 端的にまとめますと、コンテナの管理にDocker Engineを使っていましたが、1.4.0からはContainerdに切り替わったり、コンテナエージェントがECSエージェントからFargateの独自エージェントに変わったりしました。これだけアーキテクチャに大きな変更が加わると、コンテナの実行速度

こんにちは(U・ω・U) ElastiCacheおじさんを目指して日々鍛錬を続ける深澤です。 立派なElastiCacheおじさんに成長することを決意したラスベガスでの出来事でした。 — 深澤俊 (@shun_quartet) December 4, 2019 まだ見習いです。 さて皆さんElastiCacheでメモリがモリモリになったご経験はありますでしょうか。運用をご経験された方には分かるかもしれませんがキャッシュでメモリ使用量がモリモリ成長していくのはとっても恐怖ですよね！！さて今回はそんなモリモリになったメモリを一斉に開放した時、ノードへの負荷がどうなるのか実際に検証してみました。 環境 ElastiCache for Redisに対してやってきます。ノードタイプですが、今回はcache.r4.largeを選択しました！搭載メモリは12.3GBですね。 ノードにデータを投入するには

こんにちは(U・ω・U) AWS事業部の深澤です。 さて皆さん、いざプログラミングをしようとしてもなかなかテストがしにくいとか、良い書き方ないかな〜って感じたりしませんか？出来上がったソースコードを数ヶ月後の自分が読んでみて、「あれ？この処理って何してるんだっけ？？」って思うのもよくあることです。また中には実際にスクリプトをbatch処理で使おうとしているけど、どんな風に書いたら良いか悩んでいる方とかいらっしゃるのではないでしょうか。今回は僕が運用の中で学んだ「こう書くと良いんじゃない」というTipsを書いて見ました！今回はshellスクリプトを採用しています。 環境 Amazon Linux 2 AMI (HVM), SSD Volume Type カーネル 4.14.173-137.229.amzn2.x86_64 Bashバージョン GNU bash, version 4.2.46(

こんにちは(U・ω・U) ElastiCacheおじさんを目指して日々鍛錬を続ける深澤です。 立派なElastiCacheおじさんに成長することを決意したラスベガスでの出来事でした。 — 深澤俊 (@shun_quartet) December 4, 2019 皆さん、ElastiCacheのRedisにどんどん情報を保存していって、メモリが溢れたらどんな挙動になると思いますか？ざっくりEvictionが発生してキーが削除されていくんじゃないの？と思われている方も多いかと思います。ですが実はそうとも限らないんですよ。今回はEvictionってなんだろう？というところから、メモリが溢れた場合の挙動について整理していきたいと思います。 Evictionとは？？ どんどんデータが保存されて行ってmaxmemoryに到達した際、発生する挙動です。ちなみにCloudWatchのメトリクスで検知が可能

こんにちは(U・ω・U) AWS事業部の深澤です。 全国のDynamoDBファンの皆さん、CloudWatch Contributor InsightsのGAに伴い、CloudWatch Contributor Insights for Amazon DynamoDBが公開されましたよ！！ 今回はこの機能についてお届けしようと思います！ どんな機能なの？ アクセスが多いキーを検出するための機能です。DynamoDBではパーティションキーによって書き込むディスク（パーティション）を分けて負荷を分散しているのですが同じパーティションキーに対して書き込みが多くなってしまうと同じディスクにアクセスが集中し性能が偏ってしまうという性質があります。なのでキーの偏りを検出するというのはDynamoDBのチューニング上非常に重要です。特にプロビジョニング済みキャパシティモードを採用されている方は更新される

こんにちは(U・ω・U) AWS事業部の深澤です。 皆さん、サービスディスカバリはご存知でしょうか。こちらはサーバ側で提供しているサービスを利用する時、そのサーバのドメインなりIPアドレスなりを知り参照をする必要があるのですがこの辺りの参照と解決をどう実現するかがサービスディスカバリです。最近ではマイクロサービスを構築するにあたり特にこの辺りが課題になってきています。特に内部の通信ですね。少し前だとインターナルのロードバランサを配置されたりして実現されていたかと思いますが、最近ではAWS Cloud Map（以降、Cloud Map）と呼ばれるよりクラウドネイティブなサービスディスカバリを実現するサービスがあります。 マイクロサービスを構築するにあたり必要なコンテナやlambda、DynamoDB、Kinesisといったサービスをお互いに連携する仕組みを提供してくれるサービスです。本ブログ