EKSでdocker非推奨問題に対応しました - Tech Inside Drecom
こんにちは！enzaのインフラ周りの仕事をしているmendと申します！ 以前に k8s 1.20のDocker非推奨問題でEKSを使用しているプロジェクトが対応することとして、k8s 1.20からのdocker非推奨問題と対応案ついてまとめました。 今回の記事では先の記事でまとめた案の一つであるAWSで対応したAMIがリリースされましたので、実際にEKS 1.21にアップグレードするときに行ったことと、アップグレード時に気を付けるべきことをまとめたいと思います。 EKS 1.21の新機能 2021年 7月27日にAWSの公式からAmazon EKS が Kubernetes 1.21 のサポートを開始という発表がありました。 このEKS 1.21からコンテナランタイムにcontainerdを使用することが正式にサポートようになり、1.20からDockerのコンテナランタイムが非推奨になって
Ruby Kaigi Takeout 2021 速報記事 Day1 午後 - Tech Inside Drecom
始めに こんにちは、enzaプラットフォーム事業本部でSREチームのエンジニアをやっている橘田です。 こちらは、RubyKaigiTakeout2021 の1日目の午後の速報記事です。 1日目の午前の速報記事はこちらをご確認ください。 Optimizing Partial Backtraces in Ruby 3 Rubyで記載されたプログラムをデバッグするためのツールのBacktraces Ruby3以前では、Backtracesの生成に関してコールスタックが深くなると生成コストが高くなるっという問題がありました。 その問題に関しては、Rubyのissueに上がっています。 この問題をいかにして解決して、そしてBacktracesの内部がどのように動作しているのかが説明されました。 Backtracesの開始ポイントからいかにしてトレースを行っていき、最適化していったか そして最適化した
RubyのEnumerableを使ったリファクタリング - Tech Inside Drecom
これはドリコム Advent Calendar 2018の4日目です。 3日目はSmithさんによる、デファクト開発環境が無い HTML5 ゲームの世界で逞しく生きるです。 はじめに プログラミングにおいて、読みやすいコードを書く重要性は改めて述べる必要はないだろう。あえて一言添えるなら、ソフトウェア開発者がコードを読む時間は書く時間よりも遥かに長い。本稿では筆者が見つけた読みにくい書き方を主観的な好みで一つ挙げ、なぜ読みにくいのか、どう書くべきか、そして書き換える場合の注意点について散文的に論じる。 読みにくい書き方 今回のテーマとなるのは下のような書き方だ。 def apply_f_procedurally(original_collection) result = [] original_collection.each do |e| result << f(e) end result
ドリコムシステム運用の今 - Tech Inside Drecom
SRE部の大原です。 この記事では、ドリコムのシステム運用についての共有を行いたいと思います。 ドリコムのシステム運用 システム開発における文脈の「運用」という言葉は、様々な意味がありますが、その中でも私の携わっているプラットフォームシステムにおける「運用」は、以下を指します。 プラットフォームの新規機能開発 定期的なシステム診断(負荷試験や脆弱性診断) キャパシティプランニング(プロモやイベントに合わせたサーバー増減オペレーション) システム証明書やクラウド等のメンテナンス対応 この記事では主に「プラットフォームの新規機能開発」にフォーカスして私達のシステム「運用」の紹介をしたいと思います。 チーム構成 本稿で取り上げるプラットフォームの開発チームは、スクラムによって開発運用を進めています。 スクラムチームは3つあり、それぞれのチームが担う責務は以下となります。 国内の機能開発/運用 海
エラー対応のない世界にしたい - Tech Inside Drecom
初めまして、サーバーサイドエンジニアのホルモンと申します。あだ名です。レバーは苦手です。 運用に2年間携わったあと、新規開発を進めている間に意識していたことについて紹介したいと思います。 テーマ 新規開発・運用問わず、開発をしたいのに開発を進められないときがあります。そうです。 「開発サーバーやJenkins上で起きたエラー（異常系）に対する調査及び対応作業」です。 エラー対応が発生する流れのイメージ 新規成果物を反映する エラーが出る_(:3」∠)_ 調査をする 対策をする エラーが出てしまうと当初予定していない調査や対策をすることになるため、開発コストとなってしまいます。開発中のエラーゼロはとてもとても難しいですが、多いのはプロダクトとしても健全ではありません。 エラー対応コストを減らす方針として2つの観点があると考えています。 観点1: エラーを起こさせない 観点2: 平常時を知る
ドリコムのポストモーテム放出 - Tech Inside Drecom
「ポスモ」って呼んでます こんにちは、 Smith (@do_low) です。 ドリコムの一部のプロジェクトでは、障害や深刻な不具合が発生した場合、そのポストモーテムを書いています。 ポストモーテム自体については様々なサイトで説明がなされているので詳細は省きますが、おおよその説明通り、発生してしまった問題から教訓を得て今後に活かすためのチームの取り組みとして実施しています。 テックブログは普通、イケてる技術的取り組みだったり、登壇報告だったりと、良いことばっかり書くものですが、 Tech Inside Drecom では、ドリコムの等身大のエンジニアリングをお伝えするため、また、ドリコムだけでなく読者の皆様も教訓を得られる機会を提供するため、共有できそうなポストモーテムは公開することにしました。 資料は可能な限り原文のまま記載していますが、人物名、プロジェクトコード、日付や時刻、仕様に関す
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
