『インターフェイス指向設計 アジャイル手法によるオブジェクト指向設計の実践』を読んだ

インターフェイス指向設計 ―アジャイル手法によるオブジェクト指向設計の実践

どんな本なのか

インターフェイスを用いてどのようにアプリケーションを設計するか詳しく解説された本です。

インターフェイスとは何かから始まり、原則や契約、インターフェイスの評価基準、継承とインターフェイスとの対比について、ピザ屋さんを例にして説明しています。

2008年に出版された本なので古い情報について書かれている部分はありますが、現代のアプリケーション設計でも活かせる内容が書かれていると思います。

以下、目次になります。

• 1章 インターフェイスとは何か
• 2章 インターフェイスと契約
• 3章 インターフェイスと材料
• 4章 何をインターフェイスに持たせるべきか？
• 5章 継承とインターフェイス
• 6章 リモートインターフェイス
• 7章 開発プロセスの開始
• 8章 リンクチェッカー
• 9章 Web自動集約ツール
• 10章 サービレポジトリ
• 11章 パターン

目的

ソフトウェア設計について学ぶことで、テストしやすく・変更しやすい、実装の意図が把握しやすい等、継続的な開発を容易に行える設計を今よりもできるようになりたいからです。

知識や経験がないと開発の際に考えられる幅が小さくなりがちなので、そこは継続的に改善していきたいところです。

感想

具象クラスではなくインターフェイスに依存させて実装してテストの際は差し替えられるようにしたりと設計・実装してきましたが、インターフェイスの原則だったり契約や評価基準というものは知らなかったので、なるほどと思いながら読んでいました。

無意識にしていたことがこの本を読んで言語化されたこともあるので、この本を読んで良かったなと思います。

読書ノート

• ここでの契約は、インターフェイスのユーザーと実装の間に成立する約束事を指す
• 3つの原則
  • 原則1: インターフェイス実装は、そのメソッド名が示す通りの処理をしなければならない
    • 実装はインターフェイスの作成社が意図した通りの処理を実行できなくてはいけない
    • 実装は、戻り値を適切に処理できなくてはいけない
    • 原則1は、「サブタイプの古い米はその継承元と異なってはならない」というリスコフの置換原則(Liskov Substitution Principle: LSP)に対応している
  • 原則2: インターフェイス実装は他に危害を加えてはならない
    • ここでいう危害とは、実装がプログラム内の他モジュールや、別のプログラムの正常な動作を妨害してしまうような場合のことを指す
    • 実装は、リソースをやたらに消費してしまうようなものであってはいけない
  • 原則3: インターフェイス実装は、責務を果たせない場合にそれを呼び出し元に伝えねばならない
    • 実装は、問題に遭遇し、それを自ら修正できない場合は、その問題についての呼び出し側に報告をしなければならない
      • 報告の方法(エラーシグナル)は、リターンコードでも、例外でも構わない
    • インターフェイスが報告するエラーも、インターフェイス契約の一部
• インターフェイスを効果的に使うためには、呼び出し側と実装側がそれぞれ契約を理解していなければならない
  • 実装が呼び出し側のどのような要求に応えるべきであるか、ということについて双方の同意が必要
• 契約の3つの側面
  • 事前条件(precondition)
    • インターフェイスのユーザーは、メソッド呼び出し時に特定の条件が満たされていることを確認しなければならない
  • 事後条件(postcondition)
    • インターフェイス内の各メソッドは、呼び出しが適切に実行された場合に真となる条件を持つ。この保証のこと。
  • クラス不変表明(class invariant)
    • すべてのオブジェクトインスタンスが満たすべき条件を示す
    • インターフェイスにおいては、クラス不変表明は通常、特定の実装のプロパティでありメソッドではない

例)

メソッド	事前条件	事後条件
set_size()	なし	サイズを設定
set_toppings()	サイズが設定されている	トッピングを設定
set_address	サイズとトッピングが設定されている	住所を設定
get_time_till_delivered	サイズ、トッピング、住所が設定されている	なし

• インターフェイスのプロトコルを知ることが大切
  • プロトコルとは、実行可能なメソッドコールの組み合わせ、つまりメソッドシーケンスのまとまりのこと
  • プロトコルには、インターフェイスが作成したコールバック、生成されたイベント、呼び出されたオブザーバも示される
• インターフェイスの機能を分離させることによって、1つのインターフェイスが持つ状態遷移の数を減らすことができ、エラーの発生率を低く抑えることができる
• インターフェイスのテストとは、対象のインターフェイ実装が契約を満たしていることを確認するために行われるべきものだと言える
• Christine MinginsとJean-Marc Jezequelは、契約には複数のレベルがあることを提唱している
  • 型を持つプログラミング言語における、基本となる型の契約
  • 事前条件と事後条件を含む意味的な契約
  • リアルタイムシステムにおける、パフォーマンスの契約
  • 定量化の難しい、サービスの質についての契約
  • ※テストは、こうした異なるレベルの契約それぞれに対して行う必要がある
• データインターフェイス
  • 本書では、たくさんの属性をもつクラスに対応するメソッドで構成されるインターフェイスのこと
  • データインターフェイスのメソッドは、属性に値を設定したり、属性から値を取得したりするためのメソッド
  • 状態を持つ
    • 状態には、クラスの全属性の値が含まれる
• サービスインターフェイス
  • 本書では、渡されたパラメータに対する処理を行うメソッドを中心に構成されているモジュールのこと
  • 渡されたパラメータを処理の対象とし、実装の属性は対象にはならない
• Ivar Jacobsonは、オブジェクトのステレオタイプを3つ定義
  • エンティティオブジェクト
    • オブジェクトの永続的な状態を示す
  • バウンダリオブジェクト
    • システムやアクター(ユーザーおよび外部システム)とのやりとりを司る
  • コントロールオブジェクト
    • 特定の仕様に対する振る舞いを表し、バウンダリオブジェクトとエンティティオブジェクトとの間をやりとりして処理を実行する
• インターフェイス実装は、ステートフル/ステートレスにできる
  • ステートフルインターフェイス
    • メソッドは現在の状態によって異なった動作をする
    • 状態は、メソッド呼び出しの順序によって変化する
    • 長所
      • パラメータリストが短くて済む
    • 短所
      • メソッドコールの順序が重要になる
  • ステートレスインターフェイス
    • 振る舞いがメソッド呼び出しの順序によって変わることはない
    • 長所
      • メソッドコールの順序にこだわらなくてもよい
    • 短所
      • パラメータ数が多くなる
• インターフェイスの書くメソッドは互いに高い凝集度を持たねばならない
  • 各メソッドが提供する機能は共通するコンセプトに基づかねばならないということ
• いくつかの処理をまとめて行うようであれば、それらは同じインターフェイスで扱うべき
• 結合度(coupling)は、あるモジュールが他のモジュールにどれだけ依存しているうかを示す
• 実装ではなくインターフェイスに依存しているのであれば、あるメソッドが別の実装に強く結合することは稀になる
• 疎結合とは、呼び出される側のインターフェイスの実装を変更した際に、呼び出し側のコードを変更する必要がないということ
  • 密結合になっていると、コードを変更しなければならない
• インターフェイスの評価基準
  • 最小
    • Pros: メソッド数が少ないので、実装とテストが簡単
    • Cons: 特定の機能を実現するためにコードを書く必要があり、コードの重複を招くこともある
  • 完全
    • Pros: すべてのメソッドを利用できる
    • Cons: メソッド数が多いため、インターフェイスの理解が難しくなる
  • 単純
    • Pros: 共通する機能を簡単に使える
    • Cons: 変化が必要なときに、新しいメソッドのコーディングが必要になる
  • 複雑
    • Pros: 「好みの方法」を柔軟に選択できる
    • Cons: インターフェイスを理解することが難しい
• インターフェイスは完全性が高まれば高まるほど、メソッドの数は増え、実装は難しくなる
• 凝集度の高いインターフェイスを設計することが大切
  • ただし、何をもって凝集度が高いと判断するのか
• 疎結合を目指す
• ポリモーフィズムとは、あるメソッドの実装を複数のクラスが提供することで実現されるものを指す
  • 実現方法は2つ
    • 継承
    • インターフェイスを用いる方法
• 複数インターフェイスの難しい点は、各実装のメソッドに共通化できるコードがでてしまうこと
  • 避ける方法は2つ
    • 方法1
      • ヘルパークラスによる処理の委譲
    • 方法2
      • インターフェイスを実装したクラスを作成
        • このクラスはメソッドの多くの実装を提供
      • インターフェイスを実装する代わりに、この作成クラスを継承する
• インターフェイス
  • 長所
    • クラス階層を構成する経験が不十分な場合にそれを避けることができる
    • 軽装を横断できる
    • 使い方の共通性によってまとめられる
    • 改装を横断するロールを表しやすい
    • どのメソッドを実装すべきかが明白になる
    • 別の軽装改装にあるクラスがインターフェイスのサービスを提供できる
  • 短所
    • 共通機能を提供するために、ヘルパークラスがないとコードが重複する
    • ヘルパークラスを多く作成しなければならない
• 継承
  • 長所
    • 共通の処理の委譲が少なくて済む
    • 共通の属性を取得できる
    • 実装する処理の共通性によってまとめられる
    • 基底クラスを通じて共通の実装を提供できる
    • 継承と実装が簡単
  • 短所
    • 状況の変化に柔軟に対応できない場合がある
    • ロールの変更が難しい場合はがる
• インターフェイスは、振る舞いの共通点を表す
• 継承は、振る舞いの共通点に加えて、実装の共通点を表す
• ソフトウェアプロジェクトには、ビジョンが必要
• ビジョンとはソフトウェアの使用目的を1文か2文で簡潔に言い表したもの
• ビジョンを明確にしたら、次はソフトウェアの要件を定義する
• 要件を表す形式には、正式の要求仕様書や、ユーザーストーリー(誰々は何々ができる)、ユースケースなど様々なものがある
• ユースケースには、システムに対して要求を行う人と、システムから利益を受けるエンドユーザーを記述する
• ユースケースの定義
  • ビジネスゴールを達成するために、アクターとシステムとの相互作用を定義したもの
  • アクターとは、システムの外部にいて、システムとやり取りする主体のこと
  • ユーザーを表現するクラスやユーザーが担うロール、他システムなどがアクターとなりうる存在
• アクターの特定は、ユーザーが行う具体的な作業やユーザーの組織内での役職だどではなく、システムにおいてユーザーが担うロールに基づいて行う

2021年8月10日 ~ 16日 振り返り

振り返る。

仕事

とある機能のリリース対応

すでに開発完了されていたとある機能の暫定対応版のリリースを行いました。

プロジェクトでは複数の機能が同時並行で開発されており、開発完了したものがお客様都合でリリーススケジュールをずらしたりすることが多々あります。

今回そのうちの一つで、この暫定対応をリリースしないとAPIのクライアントであるモバイルアプリのリリースにも影響があるリリースでした。

ただ、リリース直後エラーが発生し、一旦切り戻すことになりました。

原因としては、暫定対応時に設定していた値が固定値になっており、それが原因でとある計算ロジックで落ちるというものでした。

テストパターンが少なくCIでもテストでエラーにならないために気づけず、本番環境にリリースしていくつかのパターンのリクエストが来て判明しました。

リリース直後にエラーレートが徐々に上昇したため、ログを調査するとそのような原因だったためすぐに前のアプリケーションバージョンに切り戻すことになりました。

サーバサイドチームは何人か夏休みを取得しており人が少なかったため、積極的に調査・バグの修正、再リリースの調整等を行い、無事スプリント最後の日にリリースを完了できました。

検証環境もありCI/CD環境もあるにも関わらず、このバグを見逃したのはテストデータの網羅性が足りなかったのと適切なクラスにテストケースを追加できていなかったからです。

また、クラス設計等に問題がある可能性もあります。とある修正をしたときに正しく計算ロジックがテストで実行されていればバグに気づけた可能性があります。

今後、システムの安定稼働、開発・運用の容易性を高めるためにリファクタリングは行っていきたいと思います。

Lambdaにリソースタグを付与する

プロジェクトでは開発したリソースにタグを付与して、CloudWatchやDatadogで監視しやすいようにしています。

Serverless Frameworkでリソース作成、デプロイをしているLambdaにはこのリソースタグが付与されていなかったため付与する対応を行いました。

以下のようにStackTagsを設定すればLambdaに付与されます。

stackTags:
  key: value
iam:
  # Overwrite the default IAM role which is used for all functions
  role: arn:aws:iam::XXXXXX:role/role

www.serverless.com

プライベート

読書

• ドメイン駆動設計入門 - ボトムアップでわかる！ドメイン駆動設計の基本

blog.ryskit.com

その他

UdemyでAkka Persistenceの動画を見終わりました。

内容も分かりやすく面白いのでおすすめです！

www.udemy.com

『ドメイン駆動設計入門 - ボトムアップでわかる！ドメイン駆動設計の基本』を読んだ

ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本

どんな本か

ドメイン駆動設計についてかなり噛み砕いて説明された本です。

難しく抽象的な説明はあまりなく、具体的なパターンを説明しながらドメイン駆動設計とはどういうものか語られています。

一つの章で一つのパターンが説明されているので読み進めやすく、サンプルコードも豊富に書かれているので具体的なサンプルからなにかヒントを掴みたい人におすすめです。

目次は以下の通り。

• 1章 ドメイン駆動設計とは
• 2章 システム固有の値を表現する「値オブジェクト」
• 3章 ライフサイクルのあるオブジェクト「エンティティ」
• 4章 不自然さを解決する「ドメインサービス」
• 5章 データにまつわる処理を分離する「リポジトリ」
• 6章 ユースケースを実現する「アプリケーションサービス」
• 7章 柔軟性をもたらす依存関係のコントロール
• 8章 ソフトウェア・システムを組み立てる
• 9章 複雑な生成処理を行う「ファクトリ」
• 10章 データの整合性を保つ
• 11章 アプリケーションを1から組み立てる
• 12章 ドメインのルールを守る「集約」
• 13章 複雑な条件を表現する「仕様」
• 14章 アーキテクチャ
• 15章 ドメイン駆動設計のとびらを開こう
• 付録 ソリューション構成

目的

システムやアプリケーションの設計力をつけて、より継続的に開発しやすく変更にも強いシステムを開発できるようになりたいと思い読み始めました。

ドメイン駆動設計にこだわらないですが、よりシステム設計に関する文書をたくさん読み込むことで、自分が持つパターンを増やして表現しやすくしたいという思いもあります。

感想

ドメイン駆動設計がドメインの知識に焦点をあてて設計する手法で、そのためにドメインやユースケースをどのようにコードで表現するのかが具体的で分かりやすかったです。

一方で、どのようにパッケージを分けるのか、どういうアーキテクチャを採用するとすると良いかに関してはページがあまり割かれておらず、他の本で補完する必要があるなと思いました。

また、エリック・エヴァンスのドメイン駆動設計と実践ドメイン駆動設計も読んで、自分の中で腹落ちするまで時間かける必要がありそうです。

読書ノート

• ドメイン駆動設計
  • ドメインの知識に焦点を当てた設計手法
• ドメイン
  • ソフトウェア開発におけるドメインは、「プログラムを適用する対象となる領域」を指す
• モデル
  • 現実の事象あるいは概念を抽象化した概念
• ドメインモデル
  • ドメインの概念をモデリングして得られたモデル
• 値オブジェクト
  • 不変である
  • 交換可能である
  • 等価性によって比較される
  • 独自のふるまいを定義できる
• エンティティ
  • 可変である
  • 同じ属性であっても区別される
  • 同一性によって区別される
  • ライフサイクルが存在し、そこに連続性が存在するかが判断基準
• ドメインサービス
  • 値オブジェクトやエンティティに記述すると不自然になるふるまいが存在するが、それを解決するためのオブジェクト
  • 記述するのは「不自然なふるまい」に限定すること
• ドメイン貧血症
  • ドメインオブジェクトに本来記述されるべき知識や振る舞いがドメインサービスやアプリケーションサービスに記述され、語るべきことを何も語っていないドメインオブジェクトの状態のこと
• リポジトリ
  • 責務はドメインオブジェクトの永続化や再構築を行うこと
  • 重要なのはインスタンスを何らかの手段によって保存するということ
• アプリケーションサービス
  • ユースケースを実現するオブジェクト
  • ドメインオブジェクトのふるまいを呼び出す役目を持つ
  • ドメインオブジェクトのタスク調整に徹するべき
  • ドメインのルールは記述されるべきではない
• 凝集度
  • モジュールの責任範囲がどれだけ集中しているかを測る尺度
  • 凝集度を高めると、モジュールがひとつの事柄に集中することになり、堅牢性・信頼性・再利用性・可読性の観点から好ましい
  • 凝集度を高めるにはクラス分割が簡単な対処法
• サービス
  • クライアントのために何かを行うもの
  • サービスはものごとではなく、活動や行動であることが多い
  • サービスは自身のふるまいを変化させる目的で状態を保持しない
  • 状態を一切もっていないことを意味しない
    • 自身のふるまいを変化させる目的の状態ではない
• 依存関係逆転の原則(Dependency Inversion Principle)
  • A: 上位レベルのモジュールは下位レベルのモジュールに依存してはならない、どちらもモジュールも抽象に依存すべきである
  • B: 抽象は、実装の詳細に依存してはならない。実装の称しあは抽象に依存すべきである。
  • 依存の方向を制御し、すべてのモジュールが抽象へ依存するように制御する
• ファクトリ
  • 求められることは複雑なオブジェクトの生成処理をオブジェクトとして定義すること
  • オブジェクトの生成に関わる地s樹がまとめられたオブジェクト
• ユニットオブワーク
  • あるオブジェクトの変更を記録するオブジェクト
  • オブジェクトの読み取り動作を行う際にインスタンスの状態を記録する。読み取られたオブジェクトの変更や削除はユニットオブワークにつ打ちしない限りデータストアへ反映されることがない
  • コミット処理が呼び出されると、そこまでの変更処理をデータストアに対して適用する
  • このパターンを適用すると、永続化の対象となるオブジェクトの作成・変更・削除といった動作はすべてユニットオブワークを通じて行うようになる
• 集約
  • 関連するオブジェクト同士を線で囲う境界として定義される
  • 集約の外部から境界の内部のオブジェクトを操作してはならない
  • 集約を操作するための直接のインターフェースとなるオブジェクトは集約ルート(AR: Aggregate Root)とよばれるオブジェクトに限定される
  • 外部から内部のオブジェクトに対して直接操作するのではなく、そのオブジェクトを保持するオブジェクトに依頼する形を取る
  • 「変更の単位」で集約を区切る
• 仕様
  • 仕様はあるお部会j区とがある評価基準に達しているかを判定するオブジェクト
  • 値オブジェクトやエンティティにリポジトリを操作させないために取られる手段は仕様と呼ばれるオブジェクトを利用した解決
  • 仕様はれっきとしたドメインオブジェクト

2021年8月2日 ~ 9日 振り返り

久しぶりの振り返り。 毎週やっていたけど、やらなくなると途端に面倒になるので継続するには習慣化が大切だなと思いました。

仕事

外部APIから情報取得していた処理を保存しているキャッシュから読むように修正

PoCを行うため、とある外部サーバーに登録してある情報をリクエストして返すような簡単なAPIが既に実装されていました。 ただ問題があって、この外部サーバーの秒間リクエスト数の制限がかなり厳しいので、それらの情報はキャッシュして使う必要がありました。

外部サーバーに登録済みの情報をRedisにキャッシュとして保存するLambdaは先々週のスプリントで実装したので、先週のスプリントでは既存のコードを書き換えてキャッシュ(Redis)からデータを読むように処理を修正するというタスクを行いました。

キャッシュを読む処理自体はもともとすぐに既存のコードに置き換えやすいように実装していたのでサクッとタスクを完了にはできました。 また、今のプロジェクトはマルチプロジェクト構成になっており、依存関係が複雑になりつつあったのでそこの整理もできたのでなかなか楽しかったです。

Datadogエージェントのアップデート

現在開発しているアプリケーションはEC2上で動いているのですが、ミドルウェア等のアップデートの際はゴールデンAMIを作成して検証環境にデプロイし、アプリケーションの動作に問題ないか確認する必要があります。

Datadogのエージェントは結構早くバージョンが上がるので2,3ヶ月に一回バージョンを上げては動作確認しています。

動作確認等は地味に時間食うのでここらへんは自動化したいところです。

他の会社さんとかは、ミドルウェア等をアップデートした際にアプリケーションに影響ないかの確認はどのようにしているんだろうか。。。

参考にできそうなものがあればどんどん取り入れてプロジェクトを良くしていきたい。

プライベート

やったこと

AWS MLSの試験を受けた

本当は7月30日に受ける予定だったんですが、試験勉強が全く足りないなという判断で8月6日に受けてきました。

合格はできたんですが、継続的な勉強は必要そうです。

blog.ryskit.com

AtCoder Boot camp for Beginners

最近、毎日1問ずつ解くようにしています。

アルゴリズムを今までちゃんと勉強してこなかったので、もっと学び必要があるなと感じてやっています。

少し前までC++で書いていたんですが、Scalaで書きたいなと思い最近はずっとScalaで書いています。

https://kenkoooo.com/atcoder/#/training/Boot%20camp%20for%20Beginners

「Akka Essentials with Scala | Rock the JVM」 コースを修了した

仕事でPlayframeworkやScalaを使用して仕事をしていますが、Akkaをちゃんと学んだことがなかったのでもっと知りたいなと思って始めました。

解説されているAkkaのバージョンが2.5と最新ではないのですが、実際にコードを書きながらAkkaについて学べるのは大変おもしろかったです。

www.udemy.com

次は、「Akka Persistence with Scala」というコースをやってみようと思います。

www.udemy.com

AWS Certified Machine Learning - Specialtyに合格した

本日、2021年8月6日(金) に AWS Certified Machine Learning - Specialty（MLS） に合格しました🎉🎉

AWS Certified Machine Learning 受かった👏👏🎉🎉
今回ばかりはSAPばりに落ちたと思って気持ち的に勢いがなかったけど合格できて良かった！ただまだまだ深く理解できてないし勉強は継続やな。

— 木田 亮介 (@_ryskit) August 6, 2021

スコアとセクションごとのパフォーマンス

今回受けたMLSのスコアは 835 で何とか8割を超えることができました！

そして、セクションごとのパフォーマンスは画像のとおりです。

実際に試験を受けてみた感想

今回MLSに何とか合格することができましたが、正直これを合格できただけでAWSの機械学習関連のサービスを使いこなしてプロダクション環境に構築できるかと言われればノーです。

試験勉強中も正直意味がよく分からんなと思いつつやっていましたし、試験問題解いてるときもやっぱり分からんなと思ってたので、合格できるなんて思ってもなかったです。

機械学習で使われるアルゴリズムはいろいろあって、どういうことを期待するのか、データの特徴によっても最適なアルゴリズムも違うので、試験のためにこれらを理解するのもなかなか大変でした。

あと、そもそもモデルの学習などを一度も試さなかったし、実際にコードを書いてアプリケーションを作ったわけでもないので理解できているとは到底言える状態ではないなというのが本音です。

MLS合格したけどどうするよ？

業務で機械学習を使うわけでもなければ、MLエンジニアでもないのでがっつりのめり込んでやろうとは思ってないのですが、やったことのない分野は勉強したりするのは新鮮で面白みがあります。

せっかくMLSも合格したので、勉強も継続して続けて知識を広げたいなと思っています。

あと、合格してすぐ近くの紀伊国屋に行って、こんな本を買ってみました。

機械学習による実用アプリケーション構築 ―事例を通じて学ぶ、設計から本番稼働までのプロセス

この本を読んで実際にアプリケーションを構築したり、簡単なレコメンドサービスなども作って試してみたいなとも思っています。

最後に

ひとまずAWS 9冠になりました。

残るは、Advanced Networking - Specialtyと Cloud Practitioner だけです。

9月茉までには11 冠まで行けるように頑張ろうと思います！

AWS Certified Data Analytics - Specialtyに合格した

本日、2021年7月9日(金)に、AWS Certified Data Analytics - Specialtyに合格しました🎉🎉

AWS Data Analytics - Specialty合格しました🎉🎉🎉🎉💪💪💪💪
準備期間を間違えて2週間に設定してしまって焦ったけど、何とか合格できて良かった！

— 木田 亮介 (@_ryskit) July 9, 2021

スコア・セクションごとのパフォーマンス

今回受験したData Analyticsのスコアは 821 でひとまず8割を超えたので良かったです。

そして、セクションごとのパフォーマンスは画像のとおりです。

前回受けたDBSのように 改善が必要 と言われることがなくてこちらもひとまず安心しました。

本当に改善は必要ない？

そんなことはありません。

Data Analyticsで出題された分野というのは、正直なところ仕事で関わりを持つことが少ないです。

そして、AWS GlueやAmazon EMRなどのETLサービスやビッグデータフレームワークを実際に構築して運用した経験がありません。

そのため、今の能力としては試験勉強のためにとりあえず知識を頭に詰め込んだだけで、実務に耐えうる知識や経験は不足している状態です。

なので、今後の課題・改善ポイントとしては、

• 実際に出題された範囲のAWSサービスを構築して動かしてみる
• AWS GlueやAmazon Kinesis、Elasticsearchであれば今の仕事でも使いどころはあると思うので、そのためにもっと知識を深める・使用用途を考える
• Athenaはログの分析用途で使っているので、もっと踏み込んだ使い方をする

などなど、やっていこうかなと思います。

今回どうやって勉強した？

今回のDAS取得にあたり勉強のために読んだ書籍や教材を紹介します。

読んだ書籍

そもそもデータレイクやデータウェアハウスの違いもよく分かっていなかったので、AWSの中の人が書いた以下の本をサクッと読みました。

前半はデータレイクの概念や特徴、機能などを基本から解説してくれているので、大まかに理解するにはすごく良かったです。

後半は実際にAWSサービスを立ち上げて動かすようなチュートリアルがありましたが時間がなかったのでスキップしました。時間作ってやろうと思います。

AWSではじめるデータレイク: クラウドによる統合型データリポジトリ構築入門

教材

Udemyのtutorial dojoからリリースされているData Analyticsの模擬試験です。

こちらを3周ほどやりました。

とにかく問題を解いて、間違った箇所や理解が浅い問題に関しては、参考リンクとしてリストアップされているAWSの公式ドキュメントを読み漁りました。

とりあえず、AWSサービスの公式ドキュメントを読めば答えは書いているので、頑張って理解して覚えるのが早いです。

www.udemy.com

最後に

やっとAWS 8冠まで来ました！

残るは機械学習と高度なネットワーキング、クラウドプラクティショナーの3つです。

次は機械学習を7/30 (金)に受験予定なのですが、機械学習の知識はゼロの状態からスタートです。

なかなか理解するのが大変そうな分野ですが、準備期間としては3週間ほどあるので地道に頑張っていこうと思います！

AWS Certified Database - Specialtyに合格した

本日、2021年6月25日(金)にAWS Certified Database - Specialtyに合格しました！

ちょっと待て

今日の午前中に試験を受けている最中、データベース固有の問題に関して記憶が曖昧で合ってるかな？と思いながら回答した問題が多々ありました。

まぁでも概ね自信を持って回答したつもりだったのですが、スコアは 774 と受かったとはいえさすがに低い。

試験結果の内訳を見ても、記憶が曖昧だなと思った問題はやはり間違っている傾向があります。

「分野1のワークロード固有のデータベース設計」ここは明らかな改善ポイントです。合格を喜びつつ、ダメなところは反省して再度勉強し直します。

ちなみにどうやって学習した？

まずは、最近出版された『AWS認定データベース - 専門知識』の対策本を読み込みました。

また、最後の章にある練習問題を解いて、解説もしっかり読んで理解しようとしました。

要点整理から攻略する『AWS認定 データベース-専門知識』 (Compass Booksシリーズ)

次に、もっと問題を解きたかったので以下を購入。

FullTestの問題が一つとDBSの出題範囲のセクションごとの練習問題を解きました。

Tutorial Dojoにも解説が記載されていて、AWSの公式ドキュメントのリンクも添えられているので、とにかく記載されているものにはすべて目を通すというやり方をしていました。

www.udemy.com

学習方法に関しては参考になれば幸いです。

最後に

今週は仕事でシステム障害対応であまり勉強時間を取れませんでしたが、なんとか合格できて良かったです。

www.credly.com

あと、Specialtyは DAS、MLS、ANS、最後にCloud Practitionerを受ければAWS資格11冠を取得できるので、そこまでは突っ走ろうと思います。

ちなみに、DBS合格してオフィスに到着してすぐに、次のDASの試験の申し込みをしましたw

ダラダラ試験勉強しても忘れていく方が多そうなので、短期集中で頑張るぞ！

AWS試験受かったらすぐ次の試験を申し込むムーブ決めた💪

— 木田 亮介 (@_ryskit) 2021年6月25日

AWS CDK + Step Functionsで入門してみた

AWS資格取得のためにドキュメントを読んだりしてStep Functionsは知っていましたが、仕事で使う機会もなかったのでとりあえず触っておくかということで 、AWS builders.flashに公開されている「Step FunctionsでFizzBuzzを実現する」というのをやってみました。

aws.amazon.com

AWS Serverless Application Model (SAM) を使ってデプロイできるように完成済みのプログラムが提供されていましたが、コンソールでポチポチ試したかったので、jsonベースの構造化言語である Amazon States Language(ASL) を記事通りに写経しました。

やってみて分かりましたが正直ASLを手で書くのはツラいw

「これをどうにか楽に書きたい、できればLambdaを組み合わせても試してみたい」と社内Slackでつぶやいたところ、以下のブロク記事を紹介してもらいました。

紹介

前置きが長くなりましたが、紹介したかったのはこちら！

dev.classmethod.jp

AWS CDK + Step Functions + AWS Lambdaの構成で、様々なステートを用いたステートマシンの書き方が紹介されています。

ステート

以下に関しては、実際にAWS CDKで定義してステートマシンを作成するところまでできるので、真似して書くだけで試せるのがありがたいところです。

• Task
• Wait
• Parallel
• Pass
• Choice
• Success *こちらは説明のみ
• Fail *こちらは説明のみ

docs.aws.amazon.com

実践

ブログ記事を参考にステートを組み合わせてステートマシンを作ってみました。

リポジトリにあるREADMEにはセットアップ方法・ビルド・デプロイ方法を記載しています。

github.com

最後に

AWS CDKでStep Functionsを書くのは書き心地が最高に良いので、引き続きいろいろ試してみたいと思います。

Amazon ECSのrun-taskでタスク実行が失敗する

Go言語で書いたプッシュ通知システムをAmazon ECS上で構築・運用し始めてから安定稼働していました。

ある日、朝会でチームメンバーとシステムのメトリクスを見ていたら、SQSのメッセージが前日から滞留している不穏なメトリクスを確認しました。

その障害内容と調査内容、原因、対応内容について備忘録として書いていきます。

プッシュ通知システムの前提知識・その他

• Amazon ECS on Fargate上で構築・運用(Fargate Platform Versionは1.4.0)
• Go言語で実装
• プッシュ通知システムはいくつかの種類のECSタスク(以下、タスクと呼ぶ)で構成されている
  • その中でいくつかのタスクは他のタスクから Amazon ECSの run-task APIをコールして実行されている
• 障害が発生した当日に、別チームがVPCのデフォルトセキュリティグループを削除する対応を行っていた

障害内容

Amazon ECSの run-task APIをコールして実行されるタスクが起動に失敗しており、ステータスが PENDING → STOPPED となっており、メッセージの処理ができず、プッシュ通知を送信できていませんでした。

調査内容

エラー内容を確認する

タスクのステータスが PENDING → STOPPED の状態ではアプリケーションはログを出力しませんが、AWSの管理コンソールからタスクの停止理由を確認することができます。

確認すると以下のように表示されていました。

ResourceInitializationError: unable to pull secrets or registry auth: execution resource retrieval failed: unable to retrieve secrets from ssm: service call has been retried 5 time(s): RequestCanceled: request context canceled caused by: context deadli...

ドキュメントでエラーコードの内容を確認すると、以下のように記載がありました。

docs.aws.amazon.com

このエラーは、コンテナの起動に必要なリソースやタスクの所属先のリソースを作成またはブートストラップすることに Fargate エージェントが失敗した場合に発生します。 このエラーは、プラットフォームバージョン 1.4 以降を使用している場合にのみ発生します。

エラー内容やドキュメントを見て、イメージの取得やネットワーク周りが原因だろうと考えました。

アプリケーションコードを確認する

run-task を実行する場合に以下のようなインプットを渡して実行しています。

func (c ECSClient) NewRunTaskInput(clusterName string, arn string, subnets []string, securityGroupId *string, count int64) ecs.RunTaskInput {
    input := ecs.RunTaskInput{
        Cluster:        aws.String(clusterName),
        PlatformVersion: aws.String("1.4.0"),
        Count:          aws.Int64(count),
        TaskDefinition: aws.String(arn),
        NetworkConfiguration: &ecs.NetworkConfiguration{
            AwsvpcConfiguration: &ecs.AwsVpcConfiguration{
                Subnets: aws.StringSlice(subnets),
            },
        },
        LaunchType: aws.String("FARGATE"),
    }
    if securityGroupId != nil {
        input.NetworkConfiguration.AwsvpcConfiguration.SecurityGroups = []*string{securityGroupId}
    }
    return input
}

今回障害が発生してしまったタスクに関しては、セキュリティグループのIDを引数として渡していないのを確認しました。(それでも今までは動作していた)

おそらくこのSecurityGroupを指定していないことが原因だろうと思い、アウトバウンドを許可したセキュリティグループのIDを渡すように書き換えたところ、検証環境で正常に動作することが確認できました。

原因

いくつかの要因が重なり、障害が発生しました。

• 障害発生当日に別チームがセキュリティリスクを減らすため、VPCのデフォルトのセキュリティグループを削除する対応を行っていた
• 障害が発生したプッシュ通知システムのタスクでは特定のセキュリティグループを指定せずに実行していた

特定のセキュリティグループIDを指定せずに run-task を実行すると、どうなるのか？

aws-sdk-goのコメントに記載がありました。

aws-sdk-go > service > ecs > api.go

// The security groups associated with the task or service. If you do not specify
// a security group, the default security group for the VPC is used. There is
// a limit of 5 security groups that can be specified per AwsVpcConfiguration.
//
// All specified security groups must be from the same VPC.
SecurityGroups []*string `locationName:"securityGroups" type:"list"`

特定のセキュリティグループIDがある場合はそれを使用し、指定がない場合はVPCのデフォルトのセキュリティグループを利用して実行されると明記されています。

つまり、今までVPCのデフォルトセキュリティグループで実行されていたタスクは、デフォルトのセキュリティグループが削除されたことでアタッチできず、ECRと通信ができなくなりイメージを取得できなくなった。

その結果、タスクの実行に失敗していました。

対応内容

run-task 実行時のインプットにセキュリティグループIDを指定するよう修正しました。

まとめ

• ちゃんとライブラリのコードを読もう
• run-task 実行時のインプットには必ず適切なセキュリティグループIDを指定しよう
  • VPCのデフォルトのセキュリティグループを使っちゃダメ

Serverless Framework内部で使用しているwsライブラリの脆弱性対応を行う

とあるシステムでServerless Framework(以下、serverlessと呼ぶ)を使っているのですが、Githubのリポジトリ上で Dependabot alert が出ていたので、それの調査と対応の内容を書き留めておきます。

前提

• serverless@2.41.0 を使用

脆弱性の内容を確認する

npm audit コマンドを実行して脆弱性の内容を確認します。

$ npm audit

                       === npm audit security report ===

# Run  npm update ws --depth 7  to resolve 4 vulnerabilities
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate      │ Regular Expression Denial of Service                         │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ ws                                                           │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ serverless [dev]                                             │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ serverless > @serverless/components >                        │
│               │ @serverless/platform-client > ws                             │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://npmjs.com/advisories/1748                            │
└───────────────┴──────────────────────────────────────────────────────────────┘


┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate      │ Regular Expression Denial of Service                         │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ ws                                                           │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ serverless [dev]                                             │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ serverless > @serverless/enterprise-plugin >                 │
│               │ @serverless/platform-client > ws                             │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://npmjs.com/advisories/1748                            │
└───────────────┴──────────────────────────────────────────────────────────────┘


┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate      │ Regular Expression Denial of Service                         │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ ws                                                           │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ serverless [dev]                                             │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ serverless > @serverless/components >                        │
│               │ @serverless/platform-client-china > @serverless/utils-china  │
│               │ > socket.io-client > engine.io-client > ws                   │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://npmjs.com/advisories/1748                            │
└───────────────┴──────────────────────────────────────────────────────────────┘


┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate      │ Regular Expression Denial of Service                         │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ ws                                                           │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ serverless [dev]                                             │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ serverless > @serverless/components >                        │
│               │ @serverless/platform-client-china > ws                       │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://npmjs.com/advisories/1748                            │
└───────────────┴──────────────────────────────────────────────────────────────┘


found 4 moderate severity vulnerabilities in 668 scanned packages
  run `npm audit fix` to fix 4 of them.

脆弱性の詳細

脆弱性の詳細情報を見ると、以下のように記載がありました。

Overview

In ws before versions 6.2.2 and 7.4.6 there is a ReDOS vulnerability.

Impact

A specially crafted value of the Sec-Websocket-Protocol header can be used to significantly slow down a ws server.

Patches

The vulnerability was fixed in ws@7.4.6

• ライブラリ ws@7.4.6 より前のバージョンで ReDOS の脆弱性がある
• Sec-Websocket-Protocolヘッダに特別な細工を施した値を使用すると、wsサーバの速度を大幅に低下させることができる
• ws@7.4.6 で脆弱性は修正された

対応内容

serverless@2.44.0 にアップデートしました。 serverless@2.44.0 の package.json の内容を確認すると、脆弱性が修正された ws@7.4.6 を指定しているのを確認できます。

https://github.com/serverless/serverless/blob/v2.44.0/package.json

2.44.0 より前のバージョンでは ws@7.4.5 を使用しているため、2.44.0 までアップデートするのが良さそうでした。 脆弱性の内容を見る限り、AWS Lambdaのデプロイにserverlessを使っているだけだったのでそこまで影響がない内容でしたが、アラートを放置するのも良くないのでサクッと対応しました。

最後に

ライブラリはこまめにアップデートしていきたいですね！