投稿

2022の投稿を表示しています

【セッションメモ】AWS Summit 2022 - Design for Resilience - 如何にしてクラウドアプリケーションの耐久力を高めるか

まえおき 先週開催されたAWS Summitのセッションの中で「Design for Resilience - 如何にしてクラウドアプリケーションの耐久力を高めるか」というセッションがとてもよかった&勉強になった。AWS要素は少なくどのクラウドサービスを利用しても適用できるSREの基礎的な内容で、新人やクラウドをこれから始める人はぜひ1回は聞いてほしい内容だった。 6月30日までセッションの動画アーカイブが公開されるらしく、復習しながらメモを書いてみた。 アーカイブを見たい場合は AWS Summit Japnanページ からログインして、 Design for Resilience - 如何にしてクラウドアプリケーションの耐久力を高めるか(SP-04) というセッションを検索すると出ると思う。 資料も早く公開になったらいいな。 レジリエンスとは 言葉の定義 「抵抗力」、「回復力」、「弾力性」 最近では「困難な状況にも関わらず、しなやかに適応する能力」と言われる 情報システムにおけるレジリエンス 定常的に発生しうる部分的な障害に対する適応力 → HA(High Availability) MTBF(平均故障間隔)・MTTR(平均復旧時間) めったに発生しない広範囲の障害に対する回復力 → DR(Disaster Recovery) RTO(目標復旧時点)・RPO(目標復旧時間) 両方の目的は「アップタイムを長く、ダウンタイムを短く、データ損失は最小限にする」 レジリエンスの重要性 我々の日常生活・ビジネスはシステムに大きく依存している メール、生産、物流、ネットの買い物、銀行のATM... 今後システム依存度はどんどん強くなり、代替手段を戻すことも簡単ではない 障害とは システムが正常な稼働状態を維持できなくなること 障害の原因 → コントロールが効きにくい(すべての原因・変化を事前に想定して取り除くことは難しい) コードや設定、データや状態、コアインフラ、災害シナリオ 障害の影響 → コントロールが効きやすい(

TIL (Today I Learned) - Programmatic programming #9

Today's 3 Line Summary Version Control, Regression Testing, Full Automation Our goal as developers is to delight users. Pragmatic Programmers don’t shirk from responsibility. TIL (Today I Learned) date 2022.04.05 The scope I read today Chapter 9 Pragmatic Projects What you want to remember in the book Topic 49. Pragmatic Teams Teams as a whole should not tolerate broken windows—those small imperfections that no one fixes. Don’t adopt new tech, frameworks, or libraries just because “everyone is doing it,” or based on something you saw at a conference or read online. Good communication is key to avoiding these problems. Automation is an essential component of every project team. Topic 50. Coconuts Don't Cut It The purpose of a software development methodology is to helppeople work together. But as with any goal, the key is to keep aiming in the right direction. Topic 51. Pragmatic Starter Kit And that’s the important part: at the proje

TIL (Today I Learned) - Programmatic programming #8

Today's 3 Line Summary Requirements rarely lie on the surface, so you should try to produce mockups and prototypes for customers or become a client. When faced with an intractable problem, enumerate all the possible avenues you have before you. sometimes it is useful to do something different. The agile team should experiment continuously, and need a good design for easy change. TIL (Today I Learned) date 2022.04.03 The scope I read today Chapter 8 Before the Project What you want to remember in the book Topic 45. The Requirements Pit Requirements rarely lie on the surface. Normally, they’re buried deep beneath layers of assumptions, misconceptions, and politics. Even worse, often they don’t really exist at all. In those cases, Pragmatic Programmers rely on the “is this what you meant?” school of feedback.We produce mockups and prototypes, and let the client play with them. There’s a simple technique for getting inside your clients’ heads that isn’t used

TIL (Today I Learned) - Programmatic programming #7

Today's 3 Line Summary Don't write code by Coincidence. Don’t assume it, prove and try it. Write test code, when you write code. Try to Unit test,Property-Based Test Whenever you create a name, you need to think of the reason. TIL (Today I Learned) date 2022.04.01~02 The scope I read today Chapter 7 While You Are Coding What you want to remember in the book Coding is not mechanical. There are decisions to be made every minute—decisions that require careful thought and judgment if the resulting program is to enjoy a long, accurate, and productive life. Topic 37. Listen to Your Lizard Brain First, stop what you’re doing. Make doodles about the code you’re writing, or explain it to a coworker (preferably one who isn’t a programmer), or to your rubber duck Write “I’m prototyping” on a sticky note, and stick it on the side ofyour screen. Topic 38. Programming by Coincidence As developers, we also work in minefields. There are hundreds of traps

TIL (Today I Learned) - Programmatic programming #6

Today's 3 Line Summary Concurrency is a requirement in our system Try to use transaction,semaphores for concurrency issue Consider to use Actor for concurrency without shared state TIL (Today I Learned) date 2022.03.30 The scope I read today Chapter 6 Concurrency What you want to remember in the book Topic 33. Breaking Temporal Coupling Activity diagrams show the potential areas of concurrency, but have nothing to say about whether these areas are worth exploiting. Remember the distinction: concurrency is a software mechanism, and parallelism is a hardware concern. Topic 34. Shared State Is Incorrect State A semaphore is simply a thing that only one person can own at a time. You can create a semaphore and then use it to control access to some other resource. The current design is poor because it delegates responsibility for protecting access to the pie case to the people who use it. Let’s change it to centralize that control. This caused the buil

TIL (Today I Learned) - Programmatic programming #5

Today's 3 Line Summary Try to decoupling between codes If you need to use external golbal data or static configuration wrap an API Try to write code around events TIL (Today I Learned) date 2022.03.26 The scope I read today Chapter 5 Bend, or Break What you want to remember in the book Topic 28. Decoupling Tell, Don’t Ask https://martinfowler.com/bliki/TellDontAsk.html Try not to have more than one “.” when you access something. There’s a big exception to the one-dot rule: the rule doesn’t apply if the things you’re chaining are really, really unlikely to change. Any mutable external resource is global data.the solution is to make sure you always wrap these resources behind code that you control. If It’s Important Enough to Be Global, Wrap It in an API Topic 29. Juggling the Real World But whatever their source, code that’s crafted around events can be more responsive and better decoupled than its more linear counterpart Top

TIL (Today I Learned) - Programmatic programming #4

Today's 3 Line Summary Don't trust evev yourself. When you think "that could never happen", check it if use resources, check to freed status when finish Always take small, deliberate steps, checking for feedback and adjusting before proceeding. TIL (Today I Learned) date 2022.03.24 The scope I read today Chapter 4 Pragmatic Paranoia What you want to remember in the book But Pragmatic Programmers take this a step further. They don’t trust themselves, either. Topic 23. Design by Contract Remember, if your contract indicates that you’ll acceptanything and promise the world in return, then you’ve got a lotof code to write! Topic 24. Dead Programs Tell No Lies Pragmatic Programmers tell themselves that if there is an error,something very, very bad has happened. A dead program normally does a lot less damage than a crippledone. Topic 25. Assertive Programming Whenever you find yourself thinking “but of course that could never happen,

TIL (Today I Learned) - Programmatic programming #2

Today's 3 Line Summary When you are write code, you should consider ETC and DRY, orthogonality There are no final decisions. you should prepare about reversibility The only way to determine the timetable for a project is by gaining experience on that same project TIL (Today I Learned) date 2022.03.21 The scope I read today 2.A Pragmatic Approach What you want to remember in the book Topic 8 The Essence of Good Design ETC:Easier to Change You may need to spend a week or so deliberately asking yourself “did the thing I just did make the overall system easier or harder to change?” Topic 9 DRY The Evils of Duplication Programmers are constantly in maintenance mode.maintenance is not a discrete activity, but a routine part of the entire development process. Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. DRY is about the duplication of knowledge, of intent. It’s about expressing the same

TIL (Today I Learned) - Programmatic programming #1

Today's 3 Line Summary It is your life. Software development skills are in demand in the world. You can change it if you have frustrated the job. You should be responsible for what you did. Don't blame others, don't excuse problems. Don't leave broken windows(bad designs, wrong decisions, or poorcode) Your knowledge becomes out of date. As the value of your knowledge declines, so does your value.You should keep learning. TIL (Today I Learned) date 2022.03.19 The scope I read today Foreword ~ 1.A Pragmatic Philosophy What you want to remember in the book you can change your organization or change your organization. Don’t blame someone or something else, or make up an excuse. but it is up to you to provide solutions, not excuses That’s the way it must be with software: don’t cause collateral damage just because there’s a crisis of some sort. Great software today is often preferable to the fantasy of perfect software tomorrow. Don’t spoil

CDKでインフラとコードを 一緒にデプロイしてみよう(CDKでLambdaをデプロイしてみた)

イメージ
まえおき  今週の水曜日に開催された JAWS-UG 初心者支部の勉強会(#44) に参加した。今回はAWS Builders Online Series recap2 ということで AWS Builders Online SeriesのTrack2 開発者向けAWS入門に関する内容の勉強会だった。私は「CDKでLambdaをデプロイしてみた」をタイトルでLT発表をした。せっかくなので(ブログのアクセスを増やすためにも(笑))ここにもブログ版としても書いてみる。 当時発表した発表版はこちら。 サービス紹介  デプロイをする前に、今回使うサービスの紹介を簡単にする。 AWS CDKとは   AWS Cloud Development Kit(AWS クラウド開発キット) と呼ばれ、慣れたプログラミング言語でAWSリソースを定義できるフレームワークである。プログラミング言語が利用できるので、プログラミング言語の知識と表現力を使用できるのが特徴で、例えばCloudFormationでは利用が難しいif文(条件関数があるけど、複雑に作るのは難しい)やfor文を利用できる。また、言語もCDKライブラリについてもエディターの補完が聞いたり、AWSのベストプラクティスがデフォルト値として入っているため、コード記述量が少なくなるというメリットもある。ただし、CDKコードがそのままAWS環境にデプロイされるわけではなく、CloudFormationのテンプレートに変換されて、AWS環境にデプロイされる仕組みとなっている。 AWS CDK紹介ページより( https://aws.amazon.com/jp/cdk/ ) AWS Lambdaとは   AWS Lambda はサーバーレスでプログラムを実行できるAWSのサービスで、サーバーレスの名前通りにサーバーがないので、インフラ周りのプロビジョニングや管理が不要である。また、リクエスト数に応じて自動スケールしたり、様々なAWSサービスと連携が便利という特徴を持っている。課金もリクエスト数&実行時間という利用した分だけ払えばいい構造となっている。   AWS Lambda紹介ページより( https://aws.amazon.com/jp/lambda/ ) 写真をS3バケットに入れるとLambdaがトリガー

7か月遅れたSecurity Jamに参加した感想

イメージ
まえおき  2021年のAWS Summit OnlineでSecurity Jamに参加したので、紹介と感想を書いてみる。実はブログは途中まで書いたものの放置してしまい、今はあんまり思い出せないけど、頑張って思い出してみる。 Security Jamの紹介  まず、AWS Jamとはユースケースや運用関連のタスクを一連のシナリオで参加者(チーム)に提供し、提供されるAWS環境から課題の解決に取り組むイベントである。いくつかの課題とAWS環境が与えられ、課題を解決すると得点が入り、制限された時間内にどれくらい大きい点数を得るかを競うイベント。その中、Security JamはSecurity系のユースケースに特化した課題が出るJamとなる。  AWSの学習にはいろいろコンテンツがあるけど、やはり実際に触ってみたり、トラブルシューティングしてみないとわからないものが多い。個人のAWS環境で軽く触ってみることはできるが、トラブルシューティングまでは難しい。そういう面でAWS Jamはゲーム形式で様々な課題(トラブル)解決に取り組むことができ、楽しくAWSの学習とスキル検証ができるので、ぜひ参加をおすすめするイベントである。 Security Jamで楽しんでいただきたいこと(Security Jamの紹介スライドより) 今回のJam 申し込み AWS Summit Onlineが開催される何日前くらいに、Summitの次の日にAWS Security Jamを開催するとの案内が、AWS Japan Blogに上がってきた。 AWS Security Jam開催のご案内 AWS Security Jamの歩き方 申し込みはAWS Summitがある5月11(火)、12日(水)にできるということだったが、何時に開放されるかが書いてなかった…(アクセス集中防止のため?)。また先着100名までとのことで、Twitterでは1時間おきでチェックしまくるとかの話もあり、私もライブチケットを予約するくらいの覚悟(?)を決めてSummitの当日を迎えた。 実際には思ったよりは余裕があって、11日の8時から申し込み開始が始まり、12時過ぎに締め切ったようで、私も無事申し込むことができた。 イベント準備 当日のスケジュール 当日のスケジュールはこんな感