マイクロサービスおぼえがき

マイクロサービスについて知っておいたほうが Kubernetes 登場の背景を知れそうな気がしてきたのでメモ

成長したシステムを大きなチームで運用するのは大変

いろんな課題がある

チームが大きいと...

• コミュニケーションコストが高い
• 意思決定コストが高い

システムが大きいと...

• 変更コストが高い
  • 影響範囲が見えづらい
  • 「歴史的経緯」が増えて学習コストが上がる
• テストやビルドに時間がかかる
• 最初に決定した言語、フレームワークに不向きな機能が
• インフラリソースを一部のリソースを食う機能のために合わせなければならない

そこでマイクロサービス化ですよ

チームとサービスを分割して効率化させる

チームが小さいと...

• コミュニケーションコストdown
• 意思決定コストdown

システムが適切に分割されていると...

• 各サービスの変更速度up
  • 歴史的経緯の消滅 & 影響範囲が限定的
  • 機能に最適化された、言語やフレームワークの選択
• テスト/ビルド時間の低下
• インフラリソースの効率化
  • 各サービス毎に必要な部分だけスケールできる

ということは、最初からマイクロサービスじゃなくてよいの?

そう。

1つのチームが複数のサービスを管理するのはむしろ効率が悪い

それに、ある程度サービスが使われないと、分割の勘所も分からない

マイクロサービスにする際に気をつけることは

各チームに責任・権限をしっかり分担すること

• コミュニケーション&意思決定速度を上げるため

データもサービス毎に分割すること

ここをしっかり分けないと、マイクロサービス化する意味は薄い

大前提としてサービスをまたぐトランザクションが発生しないようにサービスを分割すべき 今回のように同一トランザクションでデータ更新をしたい処理であれば、サービス同士が疎結合ではないということであり、そもそもサービス分割の粒度が正しくない可能性が高い

• マイクロサービスアーキテクチャにおけるサービス分割の難しさ - RAKUS Developers Blog | ラクス エンジニアブログ

各サービスが落ちていても動くように疎結合に設計すること

可用性が高くなる

でも、レコメンデーションエンジンの部分が独立して動いていれば、UI部分でレコメンデーションエンジンサービスの故障を検知したら、お薦めリストを表示しないというのもできるし、お薦めのデフォルトを呼び出すような事も可能になる。 こういう依存先サービスの故障を切り離すような機能をサーキットブレーカーと呼ぶ

• マイクロサービス化が進む背景について考えてみた

ある程度の実装の重複は許容すること

下手に共有ライブラリとか作ると、その部分の変更コストが上がる

Cacoo の場合は gRPC サービスや RabbitMQ に関連する処理などがその典型です。これは microservices の特性上、許容すべきことです。共通の処理をライブラリ化してしまうという手もありますが、そうすると複数のサービスが同一のコードに依存してしまうため、microservices のメリットが減ってしまうことになります。

CacooはなぜKubernetesによるmicroservicesへの道を選んだのか？ | ヌーラボ

マイクロサービスの欠点はあるの?

いくつかある。

• サービス間通信が複雑化する
• 各サービスが独自のデータベースを持つのでサービス間でデータの一貫性がなくなる
• アプリケーション全体の可用性が高まるとは限らない(１つのサービスの挙動が悪くなると全体に影響するケースもある
• 統合テストが大変になる

ASCII.jp：マイクロサービスの境界を決める「DDD」とは？ (1/2)

あと、複数サービスが通信する関係上、モノリシックなサービスよりレスポンスは遅くなる

適切にサービスを分割するにはどうしたら良いの

ここが一番マイクロサービス化で難しいところらしい

DDDの「境界づけられたコンテキスト」単位で分けるのが適切らしいです(あんまりわかっていない

DDD本やマイクロサービスアーキテクチャを読むと理解できるのかも...?

エリック・エヴァンスのドメイン駆動設計

マイクロサービスアーキテクチャ

マイクロサービスを動作させるのに適切な方法は何?

各サービスの機能をコンテナ化して、サービス毎のコンテナの集まりを管理するのがモダンらしい

これを実践するのに生まれたのが Kubernetes であるという認識

感想

• マイクロサービス化は、ハイコストハイリターンの「究極的な技術的負債の返済」だと感じた
• 当たり前だけれど「銀の弾丸」ではない
• サービス起動時から予め「このくらいの規模になったらマイクロサービス化を実施する」というのを経営陣と共有しておかないと難しそう

次回

マイクロサービスを理解したところで、それを実際に動作させるプラットフォームとしての Kubernetes を理解する

CircleCIのimage circleci/ruby:*-node-browsers が PhantomJS をサポートしなくなった

Docker Public Convenience Images Update: Firefox - Announcements - CircleCI Community Discussion

応急処置

circleci/ruby:*-node-browsers-legacy を使う

やるべきこと

PhantomJSはサポートが終了しているので、Headless Chrome とかにさっさと移行しましょう

jser.info

古いCentOSのcurlで、githubにアクセスしたい時に見るページ

curl --tlsv1.2 https://github.com/hoge.keys

--tlsv* オプションで、通信に使用するTSL/SSLのバージョンを指定できる

• TLS 1.0 は脆弱性があるため、無効になっているサイトが多い(githubとか)
• しかし、古いバージョンのcurlにはバグがあり、TLS 1.0 でしかアクセスできないらしい
• --tlsv1.2 など、オプションで TSL のバージョンを明示することで、TLS 1.0 以外も使用可能

参考: 世の中にはTLS v1.0も許可しない業界があるようで — サイバートラスト株式会社

ハードリンクしたファイルはinode番号が同一値になる

inode とは

UNIX系ファイルシステムで使われているデータ構造

• UNIXのファイルは、inodeと、実際のデータの組み合わせ
• inodeには、inode番号と、ファイルのサイズなどの属性情報が格納されている

inode番号 とは

各nodeに与えられる任意の値

• 各ディレクトリは、node へリンクを貼ることでファイルを管理している
• node番号は ls -i で確認可能

ハードリンクを生成すると、どちらも同一のファイルを参照するため、node番号は同一値となる

例

$ ls -li aaa bbb
8610608681 -rw-rw-rw-  2 kasei_san  staff  221  8  2 11:28 aaa
8610608681 -rw-rw-rw-  2 kasei_san  staff  221  8  2 11:28 bbb

ls の -i オプションで、inode番号が確認できる

rm まめちしき

• rm コマンドはファイルの削除ではない。ディレクトリから対象のnodeを外すだけ
  • unlink というコマンドもある(カーネルによっては rm のハードリンク)
• 一つもリンクが無く、openされていないnodeは、その後削除される

EC2のリザーブドインスタンス。同一 Region 単位で取得できる最大数は20まで

Region 単位, Availability Zone 単位 それぞれでリザーブドインスタンスは最大20台まで

リザーブドインスタンスは Region 単位 と、availability zone単位 がある

• Region 単位 : どの AZ で動かしてもよいが、AZ にインスタンスの空きがない場合、起動できない
• Availability Zone 単位 : AZ の移動はできないが、予約したインスタンスはかならず確保できる

20台以上必要な場合は、サポートを通じて制限を増やして貰う必要がある

(自分が問い合わせたときには、本社に問い合わせる必要があるので2-3日かかると回答された)

EC2のvCPUは、物理コアをハイパースレッディングでCPUリソースを分割して仮想CPUとして提供している

オプションでハイパースレッディングをOFFにしたり、物理コア数を減らしたりできる(料金は変わらない

• CPU オプションの最適化 - Amazon Elastic Compute Cloud

ハイパースレッディングって何

ハイパースレッディングとは、従来CPUのコア一つに一つしか搭載していなかったコードを実行する装置を複数搭載してコードの処理能力を向上するものである。これにより、ハイパースレッディングを備えたCPUではホストOSから実際搭載しているコア数より多くのコアを搭載しているよう「論理的に」見えることとなり、実コア数より多くのスレッドやプロセスをOSが同時に実行できるようになる。

ハイパースレッディング・テクノロジー - Wikipedia

AWS 認定ソリューションアーキテクト アソシエイト(2018) に合格したので勉強方法について語る

社内勉強会のおかげで無事合格できました!

内訳

合格前の自分のステータス

以下について、実務経験あり

• EC2, ECS, S3, RDS(MySQL), Elastic Beanstalk, CloudWatch, IAM, Lambda, DynamoDB, VPC

どんなふうに勉強したの?

以下のルートで勉強しました

合格対策本を読む → 模試を解く → 知らない分野のBlackBeltを読む

合格対策本を読む

まずは合格対策本をざっくり読んで、自分の知識が浅いところを覚え直しました

• 合格対策本は2018年版より前のテストに沿って書かれていますが、変わらないところも多いので、やっておいて損は無いです

合格対策 AWS認定ソリューションアーキテクト - アソシエイト

模試を解く

ギリギリにやるよりは速いうちにやったほうが良いです!!

問題数こそ本番より少ないですが、出題傾向が分かるので、何を勉強すべきかが明確になります!

• 自分は答えをさらっと言えるまで暗記しました

知らない分野のBlackBeltを読む

AWS クラウドサービス活用資料集 | AWS

スライドは先頭半分だけ読めば十分です

• どのスライドも分量があるので辛いですが、後半は具体的な事例になってくるので、試験対策に限れば読む必要はないです

受験してどうだった?

総括するとやってよかったと思っています、ただし無駄だったなぁと思うことも少々...

良かったこと

• 試験勉強で得た知識で、コストの削減など自分が運用しているサービスの改善提案ができたこと
• 社内勉強会++
  • わからないことをすぐ聞くことができた
  • 次々と合格者が出たので、凄いプレッシャーがかかって合格できた

悪かったこと

• 多分使わないであろうサービスの知識も詰め込む必要があること(AWS CloudFormation とか...)
• 2018年前半の仕様を元にテストが作られているので、その時の仕様で回答する必要があること (2018/07に改善された S3のコレとか)
• テストの日本語の翻訳が微妙なこと。英語版も見ることができるので、そっちも読むと良いかもです

これからどうする?

まずは試験範囲が似ていて取りやすいという、AWS認定 デベロッパー - アソシエイトを、問題の知識が頭から抜けないうちに取ろうかと考えています

その後は1ランク上の AWS 認定ソリューションアーキテクト – プロフェッショナル を目指したいと思います

AWS 認定ソリューションアーキテクト – プロフェッショナル をどう勉強する?

この方の記事がとても参考になりそうです

qiita.com

AWS認定 デベロッパー - アソシエイトに合格したら、この記事に書かれていた、Jayendra's Blog の対策記事でも翻訳しようかな...

jayendrapatil.com

総括

言いたいこともなくはないけど、自分の実力の底上げ&証明になるので取って損はない資格と感じました

特に経験の薄い若手の人こそ、取ると信頼感が増すのではないかと思います

社内勉強会の皆さん本当にありがとうございました!!

他の弊社合格者の記事

critical-alert.hatenablog.com

インフラ神 id:critical-alert の神インフラ知識に本当に助けられました...! 🙇🙏🙇🙏🙇