Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
インストール100回だ(゚Д゚)ゴルァ!! プログラマがインフラ技術を知らなければならないわけ
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
Tadahiro Ishisaka
May 05, 2023
Technology
81
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
インストール100回だ(゚Д゚)ゴルァ!! プログラマがインフラ技術を知らなければならないわけ
プログラマが仮想レイヤーであるインフラを知らないことによる悲劇と、そこをどうしていこうかと言う話。
まぁ古い話ではある。
Tadahiro Ishisaka
May 05, 2023
More Decks by Tadahiro Ishisaka
See All by Tadahiro Ishisaka
開発から見たWindowsの国際化機能
ishisaka
0
230
Other Decks in Technology
See All in Technology
AIがGISを代替する日:〜すべてをAIが創る時代に、私たちがFOSS4Gに関わる意味〜
lehupa
1
220
基本から分かる!AWSセキュリティ運用の考え方と任せ方
cmusudakeisuke
1
480
「AIチャットからもできないの?」と言われたら ~業務アプリをMCP対応するときの認証・認可の勘所
oidfj
0
260
Ebitengine製iOSアプリ公開ボタンを押す会
eiei114
0
110
Sizing, Benchmarking and Performance Tuning Apache Flink Clusters
rmetzger
0
140
「いつか使う」の「いつか」は来ない 〜AI駆動開発における「作らない」判断について〜
ikki0006
0
180
In-Context Learning再入門。ICLの勾配降下的解釈の研究動向を追ってみる。
dai08srhg
1
780
並列度を下げたら速くなった — go build の重複コンパイルを実測で見る
tomoaki25
2
1k
令和の今、あらためて IAM を考える。アクセスキーを「無くせない現実」との向き合い方
kazzpapa3
0
560
Software Engineering in an AI-Driven World
erikjhordan_rey
0
130
セキュリティ専任チームなしで攻撃を先回りするSREが実践したSIEM on Amazon OpenSearch Service
cscengineer
PRO
1
730
視野はAIに、視座は人に / ai-for-breadth-humans-for-perspective
nkzn
6
3.2k
Featured
See All Featured
How to Grow Your eCommerce with AI & Automation
katarinadahlin
PRO
2
350
The AI Revolution Will Not Be Monopolized: How open-source beats economies of scale, even for LLMs
inesmontani
PRO
3
3.8k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
287
14k
What Being in a Rock Band Can Teach Us About Real World SEO
427marketing
0
1.1k
Mind Mapping
helmedeiros
1
430
How to Get Subject Matter Experts Bought In and Actively Contributing to SEO & PR Initiatives.
livdayseo
0
240
Joys of Absence: A Defence of Solitary Play
codingconduct
1
570
JAMstack: Web Apps at Ludicrous Speed - All Things Open 2022
reverentgeek
1
670
Beyond borders and beyond the search box: How to win the global "messy middle" with AI-driven SEO
davidcarrasco
3
300
Why Our Code Smells
bkeepers
PRO
340
58k
YesSQL, Process and Tooling at Scale
rocio
174
15k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
35
2.6k
Transcript
第6回静岡ITPro勉強会インフラ部 インストール100回だ(゚Д゚)ゴルァ!! プログラマがインフラ技術を 知らなければならないわけ
プログラマに インフラ技術が必要なわけ
えーマジ インフラ知らない!? キモーイ インフラを知らないのが許され るのはコーダーまでだよね! キャハハハハハハ
Fact 1 • ネットワーク切断が考慮されていない ネットワーク分散システム – クライアントが数分固まってエラー – RPCを使っているのに相手がいないことを前 提としない(DCOM)
– このため、障害時の調査やデバッグが当て外 れで復旧に多大な時間がかかる。(ハブのス テータス見れば一瞬だった) • 本質的なエラー原因はハブの故障 – 最終的にユーザーは別の会社に修正を依頼し た。
Fact1の本質的な原因 • DCOMという分散オブジェクトを利用してい るが、クライアントプログラムを作ったプロ グラマがC/Sを理解できていなかった。 – ローカルでの開発・デバッグ – フレームワークの仕組みについての無知 –
テストの不足だが、そもそもこれではテスト項目 として洗い出しできない – エラーメッセージもユーザーに対して適切に提供 できていない • DCOMのHRESULTがそのままメッセージボックスに。
Fact2 • クライアントからの呼び出しに応じて RDBMS上のデータを読み書きするサービ スがあったが、ある日RDBMSのサーバー を統合化したのだが、それ以後システム が動作しない。 – シスアドがRDBMS接続の設定ファイルを探し たが見つからず、変更でいない
– 仕様書を確認したが起動パラメーター等もな し
Fact2の本質的原因 • プログラマがRDBMSをそもそもわかって なかった。 – サーバーというものが移動されるという前提 が共有できていない • このため接続設定を変更可能にするという発想が 無かった。
– プログラマがそもそもフレームワークとツー ル任せで接続設定等について理解ができてい ない。 – プログラムの修正が必要になった
Fact3 • 試験環境では正しく動作し、レスポンスも十 分だたしステムが、実行環境に移したら、シ ステムのターンアラウンドに数分もかかって しまい使い物にならない。 – セッションごとにRDBMSが動作するサーバーの負 荷率が数分間100%になる –
ついでにストレージサーバーの負荷率も急上昇 – ストレージサーバーを共有する他システムに影響 が出始める – ユーザーが結局RDBMSチューニングのスペシャリ ストをお願いし、適切なチューニングをして今日 できる範囲にターンアラウンド時間を改善した。
Fact3の事実 • プログラマがSQL言語への知識が薄く、経験 もほぼ無かった • ORMフレームワークを使用し、SQLのクエ リーはノーチューン、テーブルもORM任せで インデックス処理等もされていなかった – 毎回全テーブルスキャンするので遅いのは当たり
前。 • プログラマに大規模なデータになったときに 何が必要か想像できれば事前に何とかできた はず。
プログラマがインフラを知らない と何が起きるのか • 設計の不足 – 非機能要件に対する設計不足 • 障害やパフォーマンスに対する設計 • テストの不足
– 非機能要件に対すテスト不足 • 障害やパフォーマンスに対する試験 • 結果として不完全なソフトウェアシステ ム
ソフトウェアと ソフトウェアシステム • ソフトウェアシステム – 複数のソフトウェアが相互連携して動くのが ソフトウェアシステム – 一つのプログラムでは完結できない •
すべて自分だけですまない • 相手はいないかもしれない • 相手に負荷をかければうまくシステムとして動か ない • 相手との距離感を理解できているか。
自称プログラマの現実 • OSのネットワーク設定ができない • OSのインストールができない、したこと 無い。 • ネットワークとか知らない。(のに自称 WEB系プログラマ。PHPは何となくかける らしい)
• RDBMSってなに?おいしいの? • 配線ができない
そもそもどうやって 自分の書いたコードが 動いているかわかってね-
想像力を持つためのインフラ知識 • 以上の問題は究極的にはプログラマがソ フトウェアシステムに対してどれだけの 想像力を持ち得るのかという問題 • 想像力は山勘では無い – 知識が無いことは想像できない –
経験が無いことは想像できない • プログラマが失敗しない(させない)ために はインフラ知識と経験が必要
プログラマにどのように インフラ技術を教えるか
目的をしっかり持つ • 目的はインフラエンジニアになることで は無い • ソフトウェアシステムの設計・構築を可 能にするための知見を持たせるのが目的 – 深掘りさせすぎてもいけない –
できるだけまんべんなく
ビルド環境の構築と管理 • ビルド環境を構築させる – OSのインストール – ネットワーク環境の設定 – 開発環境のインストール –
ユーザー設定 • ビルド環境のお守り – ユーザー管理 – バックアップ – 設定変更 • 単独サーバーの構築と管理を学ぶ
テスト環境の構築 • 複数のサーバ・クライアントからなるシ ステムの構築と運用 • ネットワークの物理的な接続、SWハブや ルーターの設定等も段階を踏んでやらせ る。 • 場合によっては理論的なところの講義と
かも必要。
丁稚 • OJT – で済まさない – 論理的な点をどこまで教え込むか – やってみせる –
やらせてみる – 背中を見せる • 先輩の姿勢が後輩の姿勢 • 丁稚に出す – 社内に管理部門やサービス部門があれば 帰ってくる約束で配転してみる。
数をこなすことで わかることもある インスコ100回だ ( ゚Д゚)ゴルァ!
経験は積まないといけない • 本だけでは駄目 • 体で覚えることも必要 • 数をこなすことで見えてくることもある • 少ない機会の中でいかにインフラ的経験 を積ませるかが吉
本人と教える側のツール • ITスキル標準 – 目指すはITアーキテクト – 何を目指すのかの目標設定 http://www.ipa.go.jp/jinzai/itss/index.html
IT技術者を目指す • そもそもプログラマと管理者の違いなん て元々無かった • システムが大規模になったので分業化し た • 両方に目を配れるIT技術者を目指そう
*宣伝* • 2/18(土) Windows Azureの勉強会やります! • 第1回JAZUG静岡勉強会/第8回静岡ITPro勉強会 – 場所:静岡県立大 –
http://www.zusaar.com/event/199062
No Code, No Life.