機雷がなんだ! 全速前進!

SEというかプログラマというか、日々のエンジニア生活の中で体験したことなどを中心に書き残しています。

Amazon S3 ファイルのMD5ハッシュ値を効率的に計算するLambda

ちょっとした小技です。検索しても情報があまり無かったので一応書き留めておくことにします。

背景

S3にアップロードしたファイルが破損していないことを確認するため、アップロードしたファイルのMD5ハッシュ値を計算してチェックする仕組みが必要でした。S3に配置したタイミングで発火する S3 Object Lambda を用いて実現しようとしたところ、巨大なファイルをうまく処理できないという課題に遭遇しました。

課題

S3には大小さまざまなファイル(最低 0 バイトから最大 5 TB)を配置することができるため、場合によっては超巨大なファイルが処理対処となることもあり得ます。また、AWS Lambda は割り当てるメモリ量(128 MB から 10,240 MB までの任意の量のメモリを 1 MB 単位で関数に割り当て可能)によって単価が高くなるため、コストの観点からも不用意に高めることもできません。

やったこと

以下のように処理方法を変えました。

  • Before
 # S3から一気に全てダウンロードして計算する方式(メモリ不足の懸念あり)
s3_object2 = s3c.get_object(Bucket=src_bucket_name, Key=cpy_object_name)
all_body = s3_object2["Body"].read()
md5_hash_value2 = hashlib.md5(all_body).hexdigest().upper()
  • After
# S3から少しずつダウンロードしながら計算する方式(使用済みデータは捨てる)
s3_object1 = s3c.get_object(Bucket=src_bucket_name, Key=cpy_object_name)
md5 = hashlib.md5()
for chunk in s3_object1["Body"].iter_chunks(chunk_size=10240):
    md5.update(chunk)
md5_hash_value1 = md5.hexdigest().upper()

コピペで動作するサンプルコードとパフォーマンス比較計測結果をGithubにPushしておいたので実際に試してみたい人は以下をご覧ください。

github.com

まとめ

S3に格納されたオブジェクトには巨大なものもあり得るため、特別な理由がない限りは、基本的には【After】のようにMD5ハッシュ値の計算を実装すべきと考えられます。

 

Amazon S3で高速にクロスリージョン間ファイルコピーをする方法

背景

現在はマネージドサービスであるS3 クロスリージョンレプリケーション (CRR) があるのであまりニーズがないかもしれませんが、とある事情でクロスリージョン(東京R→大阪R)間でサイズの大きいS3オブジェクトをコピーし、かつ、コピー先のオブジェクトに既存のオブジェクトのメタデータを引き継ぐだけでなく、新しいユーザー定義のメタデータ(x-amz-meta-xxxx)を追加付与しなくてはいけない要件がありました。

やったこと

S3にオブジェクトをPutしたのをトリガとして S3 Object Lambda から

  • boto3.client('s3').copy_object()
  • boto3.resource('s3').meta.client.copy()

などを使ってリージョン間ファイルコピーを試してみました。しかし、ファイルサイズ制限に引っかかったり、転送速度に難があったり、メタデータを引き継げなかったりと、いずれもやりたい要件をうまく満たすことができませんでした。なるべく独自実装したくなかったのですが、やむを得ず

  • boto3.client('s3').upload_part_copy()

を用いて、マルチスレッドかつマルチパートな通信を実装することで、今回の要件を満たすことができました。処理のサンプルのソースコードはGithubに置いておきます。

github.com

達成したこと

前述した方式は、僅かな差ですが最も速くデータを転送できました。(下図)

alt text

また、コピー元オブジェクトのタグやメタデータを引き継ぎ、新しいユーザー定義のメタデータ(x-amz-meta-xxxx)を追加付与することもできました。

参考

XP祭り2023登壇メモ:日本初のスクラム本「アジャイルソフトウェア開発スクラム」から20年の節目に翻訳者にいろいろ聞く

今更ながら、やりっぱなしでとっ散らかってままになっていた昨年のXP祭り2023の資料や情報を少しまとめて記録しておくことにします。

XP祭り2023について

プロポーザル

XP祭り2023 - 日本初のスクラム本「アジャイルソフトウェア開発スクラム」から20年の節目に翻訳者にいろいろ聞く | ConfEngine - Conference Platform

当日の資料

speakerdeck.com

当日の動画

日本初のスクラム本「アジャイルソフトウェア開発スクラム」から20年の節目に翻訳者にいろいろ聞く - Fumihiro Sunada / akon highfive - YouTube

※動画は公開期限が切れたら見れなくなってしまうかも…

ブログなど

その他

おわりに

ふりかえってみれば準備も覚束ないまま当日を迎えてしまい、下手くそファシリで akon さんの良いところや深い話をうまく引き出し切れなかったな、と反省しつつも、個人的には念願叶って一緒に登壇できてとても楽しかったのでまた挑戦したいです。ご協力&ご参加ありがとうございました🙇(打ち上げ🍶も最高でした😀)

九頭龍蕎麦 本店(飯田橋)

AWS Sorry Page定番パターン整理(ソーリーページ/メンテナンスページ)

はじめに

Webシステムを利用していて「メンテナンス中」や「アクセスが集中しています」などと表示された経験はないでしょうか?あまり頻繁に目にするものでは(というより目にしたく)ありませんが、このようにサービスが一時的に利用できない場合に表示するページを一般的にソーリーページ(SorryPage)と呼ぶことが多いと思います。ソーリーページがないと無骨でそっけないエラー画面が表示されることになるので利用者に現在の状況が伝わらず、サービスへの印象も悪くなってしまいます。

しかし、計画されたメンテナンスと突発的な障害の両方を一緒くたにソーリーページと呼ぶことには個人的には違和感があります。そこで、ここでは次のように区別して呼ぶことにします。

  1. 突発的な障害:ソーリーページ(SorryPage)
  2. 計画的な停止:メンテナンスページ(MaintenancePage)

記事の目的

AWS環境でソーリーページ/メンテナンスページを表示する定番の方式について調査したところ、まとまった情報がなかなか見つからず苦労したので、再度同じ苦労をしなくて済むよう、調査した内容を今後のためナレッジとしてまとめておくことが目的です。

注意点

本記事でまとめた以外にも様々な実現方式が存在すると思います。また、本内容は現時点(2024年2月時点)の情報に基づいた内容になっている点についても併せてご承知おきください。

実現方式

以下に定番の実現方式を示します。

1.突発的な障害:ソーリーページ(SorryPage)

以下の方式は、突発的な障害が発生した際、マネージドサービスのフェイルオーバー機能を利用して、自動的にセカンダリであるバックアップサイトのソーリーページに遷移させます。

続きを読む

*[本]「ソフトウェアアーキテクチャメトリクス」: アーキテクチャ品質を改善する10のアドバイス

昨年の夏頃に @snoozer05 さんこと島田さんがX(旧Twitter)でソフトウェアアーキテクチャに関する翻訳書籍の原稿レビュアーを募集しているのを偶然お見かけしました。ここ最近ソフトウェアアーキテクチャに興味があって、いろいろと書籍を読み漁っていたこともあり、これは良い機会だと直感してすぐにエントリーしました。その後、こちらのレビューに参加させていただけることになりました。

ちなみに原著はこちらの書籍(Software Architecture Metrics)です。

そして、今年の2024年1月24日についに翻訳書が発売されました👏👏👏

www.oreilly.co.jp

以上の経緯から、今回やったこと、感じたことなどを書き留めておくことにします。

期間と実績

約1ヶ月強という比較的短い期間の平日の仕事終わりの時間と週末の空き時間を使って翻訳レビューの作業をしました。〆切のレビュー期限までに書籍全体100%を網羅することができず申し訳なかったです。最終レビュー実績は6割超(188/308ページ)でした。大変お粗末様でした🙇 

作業の内容

いろいろやり方を考えたのですが、今回はGoogle翻訳とDeepLに適切な長さの原著の英文をそれぞれ入力して翻訳文を比較したり、ツール翻訳文を書籍の翻訳案と見比べて分かりにくい点がないかなどをチェックしました。翻訳ツールへの入力の工夫としては、入力する英文をいくつかのパターンに区切って翻訳させて、より確からしい意味を模索するなどしました。気付いた点は、作業用GithubリポジトリにIssueチケットとして起票して翻訳者へお伝えしました。チケット粒度は特に明確なルールはなかったのですが、私は章や節などある程度の単位ことにチケットを起票して、分かりにくいと思った理由と英文を箇条書きで翻訳文と併記しました。また、より分かりやすいと思える翻訳文のアイデアを思いついた箇所は、翻訳文案も併記してお伝えするようにしました。

感じたこと

今回の作業で感じたことは、昨今ではGoogle翻訳やDeepLなどの優れた翻訳ツールがあって本当に助かるなぁ、ということでした。とはいえ、自分が理解するためだけなら、翻訳文の日本語が多少変でも良いと思うのですが、書籍としてできるだけ分かりやすく、なるべく日本語として不自然でなく、原著の意図を汲み取りながら、数百ページの長文を翻訳するのは、やはり大変な労力が必要だなと改めて感じました。況や今日のような便利な翻訳ツールがなかった頃、大量の翻訳をやられていた @a_konno さん達のような先達の苦労は如何ばかりだったかと思うと本当に頭が上がりません。

さいごに

一昨年の2022年には 自分が寄稿した書籍を技術書典13で自ら販売するという機会 を得ましたが、商用本の翻訳レビューのお手伝いは初めての経験でした。実際にやってみると便利な翻訳ツールが整っている今日でも、思った以上に大変な作業でしたが、前述したように先達の苦労を少しだけ窺い知れたことや、技術書の内容を先んじて読んで理解を深めることができたという点において貴重な機会でした。そして謝辞に名前を入れていただけたのが嬉しかったです。ご献本いただきありがとうございました🙇

AWS AWS 認定 DevOps エンジニア – プロフェッショナル(DOP-C02)を【再】取得しました

本日 AWS AWS 認定 DevOps エンジニア – プロフェッショナル(DOP-C02)を無事に【再】取得(11/11)しました。

AWS Certified DevOps Engineer - Professional (AWS 認定 DevOps エンジニア - プロフェッショナル) バッジ

試験対策

今回は時間がなくて、下記の学習を試験の約1ヶ月前から実施しただけでした。

まとめ

AWS Certified DevOps Engineer - Professional (DOP-C02) のスケーリングスコアは 100~1,000点です。合格に必要なスケーリングスコアは 750 点です。 今回のスコアは 823 でコンピテンシーのバランスもまずまずでした。

幸いなことに直近半年くらいは、業務でクラウド(AWSが中心)のシステム構成図のレビューなどを行う立場だったこともあり、普段の業務の中である程度のキャッチアップができていたことが救いだったように思います。

新規取得時とは違い、継続の場合は受験へのモチベーションの維持が最大のテーマな気がいつもしていますが、とりあえず一発で合格できてよかったです。次はまた3年後に頑張ります。とりあえず乙でした🙇

補足

ここ最近は受験後すぐに結果が分からず翌日くらいにメールで合否通知されるのですが、実は受験後2時間くらいで、AWS 認定アカウントのサイト に合否が掲載されています。

合否の通知メールをヤキモキしながら眠れぬ夜を過ごさなくても、当日自分からサイトを見に行けば結果は分かるようでうす。(※必ず当日中に分かるかは保証しませんが)

アーキテクチャがテーマの「デブサミ2023夏」@ONLINEへ参加してきました

先月の7/27(木)に 夏サミ2003@オンライン開催 へ参加してきました。少し時間が経ってしまい既に失念した点もありますが、これ以上忘れないうちに感じたこと、思ったことなどを記録に残しておこうと思います。

テーマについて

今回のテーマは「サービスの継続的発展に向けた、最新技術の活用とアーキテクチャの追求」でした。アーキテクチャあるいはアーキテクチャリングには、ここ最近個人的に興味を持ってインプットしようとしている領域だったので久々に終日ガッツリ参加させていただきました。

オンライン開催について

コロナ禍を経てオンライン開催が中心となったことで、良くも悪くも聞きたいセッションを仕事の合間にチョコっと聴講するといったことができるようになりました。その結果、移動の時間やコストなども気にせず参加でき、イベント参加する際のハードルがかなり下がったと感じます。その反面、コロナ禍前までオフラインで開催されてきたイベントと比較してイベント会場での出会いや、会場の熱量を感じることなどがなくなってしまい、せっかくのイベントに前ほど集中して参加できていないようにも感じます。下世話な話、イベントそれ自体が有償なのか無償なのかというのもありますが、わざわざ交通費や移動時間などの対価を払って参加するのだから、元を取りたい、という感覚もあるように思えます。今回、特に興味がそそられるテーマということもあり(大した対価ではありませんが…)仕事を休んでイベントに集中して参加することにしました。

聴講したセッション

今回聴講したセッションは以下のとおりです。講演資料が公開されているものについては、リンクを貼っておくので詳細についてはリンク先をご参照ください。

 

セッション資料 講演資料

C-1

これから学ぶ人のためのソフトウェアアーキテクチャ入門
島田 浩二[えにしテック]

https://event.shoeisha.jp/devsumi/20230727/session/4471/

これから学ぶ人のための ソフトウェアアーキテクチャ入門: Software architecture is a tool to enhance our humanity - Speaker Deck

D-2
お客様のToilをなくすためのアプリケーション開発支援を始めました
佐藤 慧太[スリーシェイク]

https://event.shoeisha.jp/devsumi/20230727/session/4481/

資料なし(↓当日の様子)

D-3
セキュアに構築するCI/CDパイプラインの最前線!~事例でみるソフトウェア署名をクラウドで実現する方法~
中村 圭祐[デジサート・ジャパン]

https://event.shoeisha.jp/devsumi/20230727/session/4482/

資料なし(↓当日の様子)

B-4
モノリス化したコード・組織の両方を分割してアーキテクチャを改善する
前田 浩邦[サイボウズ]/太田 絵一郎[サイボウズ]/内山 武尊[サイボウズ]

https://event.shoeisha.jp/devsumi/20230727/session/4465/

資料なし(↓当日の様子) 

C-5
ChatGPTはコーディングテストをどこまで解答できるのか?!~Trackと10X社・GMO社のエンジニアが、AIを使って挑戦してみた~
田島 聖也[ギブリー]/石田 光一[10X]/津田 良太郎[GMOグローバルサイン・ホールディングス]

https://event.shoeisha.jp/devsumi/20230727/session/4475/

資料なし(↓当日の様子) 

C-6
見えない壁を越えよう!アジャイルやマイクロサービスを阻む「今までのやり方」
鈴木 雄介[グロース・アーキテクチャ&チームス]

https://event.shoeisha.jp/devsumi/20230727/session/4476/

アジャイルやマイクロサービスを阻む「今までのやり方」 - arclamp

C-7
実体験から考える受託開発でのモノリス脱却の道
能勢 大輔[マネジメントソリューションズ]

https://event.shoeisha.jp/devsumi/20230727/session/4477/

資料なし(↓当日の様子) 

A-8
UiPathのローコードIDEで自動化するUIテスト~テストデータ生成など、AIとも統合された自動テストの未来~
津田 義史[UiPath]/八波 博和[UiPath]

https://event.shoeisha.jp/devsumi/20230727/session/4460/

資料なし(↓当日の様子) 

B-9
日々の意思決定の積み重ねを記録するアーキテクチャ・デシジョン・レコード
内山 高広[リクルート]

https://event.shoeisha.jp/devsumi/20230727/session/4470/

資料なし(↓当日の様子) 

関連資料:〜その意思決定を刻め〜「アーキテクチャ・デシジョン・レコード(ADR)」を利用した設計の記録 - スタディサプリ Product Team Blog

 

ソフトウェアアーキテクチャに対して無関心だと何が起こるか

講演【C-1:これから学ぶ人のためのソフトウェアアーキテクチャ入門】の後半で、「ソフトウェアアーキテクチャに対して無関心だと何が起こるか?」という話がありました。

開発者がアーキテクチャを気にせず設計を進めた場合、特に考えなしにアーキテクチャが決定されてしまい、それは「必要十分なソフトウェアアーキテクチャ」ではなくなってしまうという内容でした。当然、競合する関心事間のトレードオフを考慮した「少なくとも最悪でないアーキテクチャ」であるはずもなく、開発のみならず、その後の運用保守なども含めてプロジェクトの大きなリスクとなり得ます。DX推進が叫ばれ、より多くのものがデジタル/システム化されつつありますが、思考停止して単なる前例踏襲のみでアーキテクチャを決定することはアンチパターンであることを改めて肝に銘じておく必要がある気がしました。

<補足>

夏サミ2023の講演資料は、以下の公式サイトにまとめられる想定のようです。

codezine.jp

しかし、最終更新が(2023/08/08 17:30 更新)となっており、本日時点(2023/8/13)では、私が聴講したセッションの講演資料へのリンクは掲載されていないようでした。