Zennがクラスメソッドのサービスになったことに伴い、入社したcatnoseです。ここ数年間はひとりで仕事をすることが多かったので、大きな会社の中で働くのが楽しみです。 これまで 僕は何かを作ることが好きで、学生の頃に雑誌を作ったり、海外旅行で撮りためた動画を切り貼りしてショートムービーを作ったりしていました。その頃に独学でデザインを学びました。 同じく学生の頃に、お小遣い稼ぎのために企業からWeb制作の案件を請け負っていました。大変なことばかりでしたが、その経験を通してWebデザインの基礎を学びました。 新卒でとても大きな会社に入ったのですが、あまり肌に合わず、空いた時間でWebサービスなどの開発をしていました。たくさん勉強もして、少しずつ自分の作りたいものを作ることができるようになりました。その後小さなスタートアップに入り、実務を通して開発の経験を積みました。 スタートアップをやめてか

昨年12/18（日本時間では12/19）、AWS re:Invent 2020におけるのDr. Werner Vogels（ヴァーナー・ボーガス氏）のキーノートは皆さんご覧になられたでしょうか。 氏のキーノートセッションは毎回恒例ですが、例年だと開発環境や実行環境・AWSインフラについての話にフォーカスがあたっている印象でした。その中で「Everything fail, all the time」や「You build it, You run it」のような名言・格言が語られてきました。 ところが今回は「Developer Keynote」と銘打った上で、よりオペレーション段階の話に長く時間が割かれました。MLやインフラに特化したキーノートが別にあったことも要因のひとつでしょう。 どんなことが語られたのか？　個人的に気になったキーワードをひろってみました。 なお記事中の訳は基本的にぼくの解

開催中のAWS re:Invent 2020、ヴァーナーのキーノート中に、Amazon Managed Service for Prometheus（AMP）とAmazon Managed Service for Grafana（AMG）の二つが発表されました！ Amazon Managed Service for Prometheus | Fully Managed Prometheus | Amazon Web Services Amazon Managed Service for Grafana | Fully Managed Grafana Data Visualization | Amazon Web Services Our new partnership with AWS gives Grafana users more options | Grafana Labs それぞれ

CX事業本部の阿部です。 ジョインしてから関わっている採用活動 ジョインしてから2年半、基本的にはリモートで仕事をしてきました。岡山オフィスができましたが、私がメインで関わるメンバーが東京中心ということもあって、リモートとほぼ変わらない環境で仕事をしていました。 私の仕事の中には採用活動があります。会社説明会などクラスメソッド全体の広報やイベントの活動はエンプロイーサクセス部が取りまとめてくれていますが、応募していただいて以降の面接を含む採用プロセスは各事業本部に移譲されています。 応募者の比率としてどうしても東京が多いため、岡山に住んでいる私はリモートで面接を行う機会が必然的に多くなりました。 COVID-19による環境の変化 このCOVID-19の状況下において、クラスメソッドの採用やジョインのプロセスもリモートが前提となりました。新しくジョインされる方は、私の時と同じように面接から入

Amazon Auroraは商用データベースと同等のパフォーマンスと可用性を低コストで実現するRDBです。 2018年から自動的にキャパシティがスケーリングする Aurora Serverless が提供されていましたが、今年の re:invent でその進化版「 Aurora Serverless v2」がプレビュー公開されました。 Aurora Serverless v2 のポイントは次の2点です。 ワークロードに対してより滑らかにスケーリングするようになった Aurora の様々な高機能に対応 本レポートはその v2 の NEW LAUNCH セッションです。 セッション概要 タイトル : [NEW LAUNCH!] Amazon Aurora Serverless v2: Instant scaling for demanding workloads スピーカー : Murali

CX事業本部＠大阪の岩田です。 この記事はAWS LambdaとServerless Advent Calendar 2020の6日目 です。 先日のブログでご紹介したように、Lambdaのパッケージフォーマットとしてコンテナイメージがサポートされるようになりました。 従来のZIP形式と比較したメリットの１つとして、イメージサイズの上限が10Gまで許容されるという点があります。ZIP形式の上限はレイヤーと関数コードを合わせて250Mであり、サイズの大きなライブラリや機械学習モデルを利用する場合、この上限に抵触することもあったのではないでしょうか？パッケージフォーマットとしてコンテナイメージを選択することで、こういったユースケースにも対応できるようになりました。 ここで1つ疑問が浮かびます。イメージサイズの上限が10GBとのことですが、10GBの巨大イメージからLambdaがコールドスタート

TL;DR 普通に動きました はじめに 今月頭の話ですが、Mackerel で OS 内部のメトリックを収集するエージェントソフトウェア mackerel-agent が Arm アーキテクチャに標準対応しました。 mackerel-agentは Go 言語で書かれているので、以前から動かすことは可能でした。ただし標準レポジトリに入っていたわけではないので、yumコマンドなどで導入することが出来ませんでした。 一方で、AWS は EC2 インスタンスに Arm アーキテクチャ（AWS Graviton2）のものを投入してきているので、Mackerel を監視サービスの基盤に使用している弊社 としては、なんとかこれを動かしたいという要望を持っていました。 特に T 系のインスタンスは汎用型の中でも安価に使えるため、アーキテクチャがamd64(x86_64) かarm64(AArch64) か

CX事業本部＠大阪の岩田です。 2020/11/23付けのアップデートにより、PartiQLを利用したDynamoDBのCRUD操作が可能になりました これまでDynamoDBのテーブルデータを操作するにはGetItemやPutItemといった独自の操作を利用する必要がありましたが、今後はPartiQLを利用した操作方法を選択することも可能になりました。PartiQLはSQL互換のクエリ言語なので、RDBの利用経験がある人が新たにDynamoDBに挑戦する際のハードルが下がったのでは無いでしょうか？ PartiQLを利用したDynamoDBのオペレーションにおいても、GetItemやPutItemといった従来のオペレーションと同等の可用性、レイテンシー、パフォーマンスが提供されるとのことで、PartiQLを利用したからパフォーマンスが上がる/下がるといったことは無いようです。純粋に利用者側

本日のアップデートで Amazon S3 Storage Lens がリリースされました。 Amazon S3 Storage Lens delivers organization-wide visibility into object storage usage and activity trends S3 Storage Lens とは S3 Storage Lens はオブジェクトストレージの使用状況とアクティビティの傾向を可視化し、コスト効率化、データ保護に関するベストプラクティスに向けた推奨事項が提供されます。また AWS Organizations と連携することで AWS Organizations 内のアカウント全体のストレージ使用状況、アクティビティを単一ビューで管理できます。 無料でも使える！ 標準メトリクスのみの場合、S3 Storage Lens は無料で利用できま

本日のアップデートで Amazon Lightsail でコンテナが利用できるようになりました。 Announcing Amazon Lightsail Containers, an easy way to run containerized applications on the cloud 純粋にコンテナだけを使う AWS でコンテナを利用する場合、Amazon EC2、Amazon ECS(EC2/AWS Fargate)、Amazon EKS のいずれかを利用されていたかと思いますが、これらに加えて Amazon Lightsail が選択肢として追加されました。 AWS Fargate の登場でコンテナホストの管理から解放されるなど、随分とシンプルにコンテナ環境を利用できるようになりましたが、それでもまだ IAM ロールやログといったインフラ部分の管理を行う必要があります。 Am

はじめに 皆さんこんにちは！営業推進室の大森です。 クラスメソッド にJoinしてからそろそろ半年になります。弊社の理念は「オープンな発想と高い技術力によって全ての人々の創造活動に貢献する」と言うことですので多くのスペシャリストが在籍しております。そんな中私も最先端の技術を体感していないといけないと感じていました。 また弊社にはCLP（Classmethod Leadership Principle）と言う行動指針や価値観があります。リーダーシップ、パートナーシップ、ダイバーシティ、プロフェッショナル、感謝、顧客視点、フィードバック、情報発信、やってみる、楽しむの10項目です。 まずはやってみる 入社少し前から車の買い替えを検討していたのですが、そこで私は最先端のテクノロジーを体感すべく、またCLPの中の「やってみる」と言うことを忠実に実行するために行動に移しました。 やはり車業界の最新の

こんにちは、崔です。 2020年10月20日〜22日に行われたAWS DevDay 2020 のセッション「第2回 AWS Fargate かんたんデプロイ選手権」を視聴しましたので、レポートをお届けします。 セッション情報 スピーカー Tori Hara 様（アマゾン ウェブ サービス ジャパン株式会社） 概要 デプロイ ー それは秘められた開発を経た新たなソフトウェアが世に送り出される(ときどきロールバックされる)神秘の行為。 昨年日本中を感動の渦に巻き込んだあの伝説のブレイクアウトセッションが装いをあらたに帰ってきました。 常に最高のデプロイ体験を追い続けるあなたに贈る『第2回 AWS Fargate かんたんデプロイ選手権』。お楽しみください！ 本セッションは Amazon Elastic Container Service (Amazon ECS) が対象です。 資料 アジェンダ

去る10/22（木）、Mackerel Online Meetup #1 が開催されました。テーマは「Google Cloud インテグレーション」！ Mackerelミートアップ初のオンライン開催。ツールとしてSpatial Chatが用いられていました。 Zoomなどと違って、画面上に配置された各参加者のアイコン同士の距離が近ければ近いほど声が聞こえる（遠ければ聞こえない）ということで、登壇者のまわりにわらわらとアイコンが集う様子はなんとも楽しげな雰囲気でした。会議やオンライン学習な感じが薄く、「イベントに参加している」感があっていいですね！ 参加者のアイコンが登壇資料にかぶってしまうのも、ご愛敬というべきでしょうかｗ 残念ながら最後まで出席することができなかったため、懇親会の途中までということで、当日の様子をレポートします。 イベント情報 このイベントは、Google Cloud イ

はじめに おはようございます、もきゅりんです。 メールを送信するときには、高信頼性にしましょう、ということを先日のブログ、Amazon SES でメール送信するときのベストプラクティスまとめ(2020年10月) でまとめました。 では、 Amazon SES(以下SES) ではない方法で対応するとどうなるのか。 ということで、皆大好き SendGrid と Amazon Route53(以下Route53) で SPF, DKIM 設定する方法をまとめてみました。 (SendGrid では DMARC は対応していません。) 本稿では改めて SPF, DKIM, DMARC の詳しい説明はしません。(SPF, DKIM, DMARC は被害が後を絶たない、なりすましメールの対策に有効な手法となる「送信ドメイン認証」の方法です。それぞれ異なった技術の認証方式であり、どれかではなく、組み合わせ

オペレーション部 江口です。 先週当部は1泊2日の合宿を北海道で行いました。合宿自体のまとめは他の方がブログに上げてくれると信じて割愛しますが、その際にみんなで行なったボードゲーム「プロジェクトテーマパーク」がなかなか熱かったので、レポートしたいと思います。 なおこのゲームはヌーラボさんが開発したものですが、残念ながら今は販売していないようです。入手できないゲームを紹介するのも少し気が引けるのですが、興味をもった方は是非とも再販してもらえるようヌーラボさんに要望してみてくださいませ。 どんなゲーム？ ブログタイトルに書いたとおり、「プロジェクトマネジメントを学ぶ」ボードゲームです。 舞台はテーマパークで、定められた期限までに、信頼を保ちつつアトラクションを規定の数建設し、無事開業することを目的としています。 かいつまんでゲームの流れを説明すると、以下のような感じです。 毎月、プレイヤー間で

2020年9月26日(土)、日本時間の18時前後に発生していたCloudFront障害について、CloudFrontのアクセスログを調査してみました。 AWSチームのすずきです。 2020年9月26日(土)、 日本時間 PM 5:55 から PM 6:45 の間、日本のCloudFrontのエッジロケーションで断続的にエラーが発生していた件について、 CloudFrontのアクセスログを元に調査する機会がありましたので、紹介させて頂きます。 弊社ポータルのお知らせ 日本時間2020年9月27日(日) 5:47:45 CloudFront お知らせ 日本のエッジロケーションでエラーが上昇しておりました。| Elevated Errors from one of our edge... https://t.co/5qSz7x59vV — AWS障害情報(全リージョン) (@awsstatusj

中山です ソリューションアーキテクトとして、AWS環境の利活用をお手伝いするお仕事をしています。 まれによく見るAWS環境 とりあえずこれを見てほしい。 これが絶対にだめと言いたいわけではないです。 一時的な検証環境だったり、とにかくスピード重視でサービスをデリバリーさせる必要があったり、サービスの提供者側が何ら責任を負わない・障害時のビジネスインパクトが無い（そんな状況あるのか？）という前提があったり、状況次第ではこれで十分な時もあると思います。 しかし、一般的な業務システムやサービスの場合にはいろんな意味で不十分でしょう。 では、このような環境をどのように育てていくとよいでしょうか。 この記事では、そんな育てかたの一例を紹介していきたいと思います。 なお、本記事はくっそ長いです。 ちなみに、最終的にはこうなります。 文字が小さすぎて読めない！ ちょっとそこのハ○キルーペ貸してくれーｗ

突然ですが、以下の機能がそれぞれどういうものか すべて ご存知でしょうか？ CloudWatch ServiceLens X-Ray CloudWatch Contributor Insights CloudWatch Synthetics CloudWatch Container Insights CloudWatch Logs Insights CloudWatch メトリクス Metric Math 検索式 カスタムメトリクス CloudWatch ダッシュボード CloudWatch 異常検出（Anomaly Detection） CloudWatch 埋め込みメトリックフォーマット CloudWatch アラーム 異常検出に基づいたアラーム 複合アラーム 私はわからなかったですね。ここ 1〜2年のCloudWatch系のアップデート量は凄まじいなと個人的には思っていて、Cloud

ちゃだいん（@chazuke4649）です。 今社内で改めて名著であるとしてその名前をよく見聞きする「Unixという考え方」。積ん読になっていたので最近ようやく読みました。すると驚くほど気づきが多かったので今回ブログで書いてみることにしました。 前提として日頃考えていること ちょっと自論ですが、IT（情報技術）、コンピューター、インターネット、これらの分野の本質は「課題解決」であると考えます。それを実現するための道具（手段）として現在私たちがありがたく使っている様々な技術が存在すると思うのです。それはどういうことかというと、これらの技術が発達した背景にはいつも何かの課題があり、それを解決するための工程や軌跡がこれらの歴史を作ってきたという風にみて取れるからです。例えば、ワールドワイドウェブの誕生は多くの場面で語り尽くされていますが学会の論文にて引用している文献をいちいちメールや郵送でやり取

8/13(木)に株式会社はてな様主催のオンラインセミナー「Mackerel 2020年上半期アップデート一挙紹介＆デモ！」に参加してきました?暑い夏でも涼しいお部屋でセミナー受けられるのは幸せですた。 サーバー監視はなぜ必要なのかを改めてお話しいただいた後に上半期アップデートをデモと一緒にご紹介いただきました。最近のMackerelアップデートを追い切れていない方もこの機会に整理しましょう。 上半期アップデート簡単まとめ AWSに関するアップデート 対応サービスの拡充(Batch,WAF(v1/v2),API Gateway) メトリックの追加(ALB,NLB,CloudFront,RDS) Amazon EventBridgeのイベントリソースとして「Mackerel」が選択できるようになった AWSインテグレーションでメトリック単位で監視したい項目を細かく指定できるようになった AWS