最初にお断りしておくと、私は著者達の多くと知り合いです。OCIも多少知っています。
全般的に絵が多くてわかりやすいです。内容も「入門」というよりは、「徹底」という内容でした。ここまでしっかり書かれているOCI本は海外にもないはずですし、他社のクラウド本でも、ここまで書いてあるのは貴重だと思います。
■各章の紹介
1、2章 OCIの用語や基本概念の解説です。Nginxを題材に基本的なクラウド環境を立ち上げるのはわかりやすいです。他のクラウドを使っている人も、XXXでいうと、XXXのことだなとわかりやすいと思います。
アカウントやIAMの話があり(3章)、その後、ネットワーク全体の構成(4章)というのも、一般的なクラウドの考え方や紹介と同じなのでわかりやすいと思います。
5章と6章のcomputeとストレージも必要最小限のサービスがきちんと網羅されている印象です。
7章のDBCSは、OCIの特徴が出ているところだと思います。Oracleの各種形態をクラウド化していて、クラウド特有のところが紹介されています(専有とか、スケールとか、課金とか)
ロードバランサ(8章)は、他のクラウドサービスと異なる印象で、スケーリングも含めてクラウドの設計思想がでるところなんだろうなと感じました。ここも動きを書いてあるので、実務で参考になりますね。
後半(第2部)は、コンサルが解説する、実際の設計や落とし穴の紹介です。よく見られる要件(サンプル要件)を基に設計を一歩づつ進めていくスタイルのため、とてもわかり易いです。きっと実務でも使えると思います。こういう書き方、実は大変なんですよね。
サンプル要件のイメージ↓
10章のコラムも読んでいると、「あるある」と感じる話がでています 笑 他の章でももっとコラムを読みたかったです。
ミッションクリティカルシステム向けなので、DRの記載が多いのも特徴です(12章)。他のクラウド本と比べても、ここまでノウハウが書いてあるのは珍しいのでは?と思います。よく書いたよなあと思います。
バックアップやパッチといった運用周りもしっかりです(14章)。監視は現場での詳細設計を考えるともう少し読みたいところですけど、概要はつかめるので十分と思いました。
■全体を通して
オンプレミスに比較的近いOCIの特徴がでていると思います。他社のクラウド本と比較しながら読み進めると、それがよくわかると思います。
アプリケーション関連のクラウドサービスの記載はありませんが、ここもOCIの特徴だと思います。主なユースケースである、オンプレミスでのアプリケーションをそのまま動かすことを考えれば、これでいいのだと思いました。
「OCIはここが他のクラウドと違うんだなあ」というのが、説明から分かるので他のクラウドを理解している人も読みやすい本です。ここは一緒だなあ、ここは違うなと比較しながら読み進むことができました。
「オンプレミスは詳しいけど、クラウドはまだ知らない」という人にも向いていると思います。比較的オンプレミスに近いOCIについて、クラウド化の際のポイントをきちんと紹介しているためです。
しいて、難点を挙げると、クラウドの進化が早いため、現時点での最新というのはすぐに古くなるんだろうなあという点です。そこは出版社と著者達にがんばってもらって、第2版を出してもらいたいと期待します。
分析系のクラウドサービスの記載がありませんが、これも入れてしまうと本が厚くなってしまうので、割愛していて正解だと思います。OLTPシステムやパッケージソフトをのせるためには本書で十分と思います。
■まとめ
総論としては、他社クラウドを使っている人がOCIを使うために読むにも、いままでクラウド使っていなかったオンプレミスの人が最初に勉強するにもおすすめの本です。
Amazonへのリンク:
https://www.amazon.co.jp/dp/479816903X/ref=cm_sw_r_tw_dp_KJ977SBMFDS6WZCA8Y09
スポンサーサイト
2021/07/22(木) 22:17:34 |
書評
| トラックバック:0
| コメント:0
過去にどうやってスキルアップしたのかを説明する勉強会を開くことになり、ちょうどいいのでまとめてみました。
「いかにショートカットしてなりたい仕事に早く就くか」という戦略ではなく、王道を紹介しているつもりです。
私の経歴(ベンダーでインフラ25年):
社内教育部門(5年くらい)
インフラコンサル(20年くらい。マネジメント含む)
■一般論
自分のブランド(タグ)を作るのは大事。「XXさんと言えば」、もしくは、「XXの領域のことならXXさん」、「XXアカウントのことならXXさん」、一気にやりやすくなる。周りも話しかけやすくなる。これができていない中途入社者や新卒は多い。
実機を触ること。手を動かして検証すること。
若手の人へ。新機能や新しい製品(いまならクラウドなど)がおススメです。既存社員はデリバリに追われているので、新しいものをキャッチアップする時間が取りにくいためです。お互いWin-Winになれます。
ビジコンと一緒で、必要となる直前に本をよむ ※脳の観点からも効率がよいです。
エンタープライズシステム(いわゆるSoR)、およびそのプロジェクトの進め方の学び方
・実プロジェクトで学ぶのが王道。5年はかかると思った方がいい。理由は、通しで経験しないと全体感が分からないこと、そもそもプロジェクト自体が長いため。
幹事や各種横ぐしタスクのリーダー
・苦労するけど、学ぶこと多いです。飲み会幹事もスキルアップになります。
・DC作業、クラウド環境の管理や検証用PCのセットアップなども大事な経験です。
■IT一般の学び方(特に若手向け)
若手へ 一般的なIT用語の理解は大事。2,3年は記事や雑誌を多く読むべきと思います。議事録を書くのも大事なトレーニングです。
社外の勉強会やセミナーに参加するのも大事。つながりを作ると、刺激も情報も得られる。
パフォーマンス
・チューニング仕事に参画する
※最近、SQLチューニングが減っている
計算量、パフォーマンステストの進め方はおススメ ※絵で見てわかるシステムパフォーマンスの仕組み よかったら読んでください。
運用を経験するのも大事。運用の迷惑になるような開発はやっちゃだめ。
コーディングを知っていると、インフラやアーキテクチャの役に立つ。特に深い理解をするためにはコーディングの知識は必要。
※私はもともとプログラムを書くエンジニアでした。それが生きてます。
ネットワーク
※クラウドになるとネットワークは大事。ネットワークもDB同様に深い専門分野。どう付き合うか
・多くのインフラエンジニアにとっては、基本はLAN+インターネットで使われる内容でいい
・WAN(閉域網など)を学ぶのは難しい。概要で十分
※ネットワークキャリアのエンジニアと会話すると憶える。
・レイヤを意識する(L3で受ける、L2で受ける、etc)
・実機で触らないとわからない
・パケット見るのはあり
OS
・何度も構築するのが大事
・サーバー構築
・パフォーマンスチューニング
・(上級者になるためには)システムプログラミングを学ぶ
システムプログラミングは、なんらかの分野のエキスパートになるには、大事な1ピース。
システムプログラミングとは(Wikipediaから抜粋):システムソフトウェアとは、コンピューターのハードウェアの操作・制御のために設計されたコンピューターのソフトウェアであり、アプリケーションソフトウェアを実行するためのプラットフォームを提供する。システムソフトウェアのカテゴリーとしては、オペレーティングシステム、ユーティリティソフトウェア、デバイスドライバ、コンパイラ、リンカなどがある。
難しい本も読む。鈍器と呼ばれたりもしますが、難しい本で評価が高い本は理由があります。オライリーの本などで価値があるものは読みましょう。
■DBの学び方
OracleといったRDBは、かなりの長い間、データソースとして重要なポジションが続くはず、Oracleを学ぶ、Oracleとの連携を学ぶ、Oracleからのデータ移行(バージョンアップ含む)を学ぶことは、キャリア上有利なはず。
Oracleを理解するのは、IT(特にミッションクリティカルや、従来型IT)を理解するにはおススメ。Oracleを扱うのは、ミッションクリティカルシステムの知識を身に付けるためには、うってつけ。
構築して、壊す。そしてリカバリする。再インストールする。
やりたがらない人多いけど、サポート問い合わせにかかわったり、にらめっこするのも、大事な経験。技術を理解するチャンス。
データ連携製品やETL。キーの考え方、重複など、原則はどの製品でも同じ。現在、クラウドも増えたので、データ連携は一般的にニーズ高いです。
SQLを知っておくと、いろいろ役に立ちます(インターフェースとしてのSQLは優秀。各社のクラウドでもSQLはよくつかわれている)
■クラウドの学び方
3つルートがあるように思います。
1:オンプレを学んで、そのあとにクラウド学ぶ
2:クラウドだけ学ぶ ※深いところは学びにくい
3:クラウドで最初学んで、その後に深く学ぶ ※結果的にオンプレも学ぶことになるはず。深い知識はオンプレベースが多い。
※今後の人たちは、2か3になるんでしょうね。3はまだキャリアパスとして確立できていない認識です。
利用者としてであれば、クラウドだけ学ぶのはありですが、トラブルを解決したり、エキスパートとして活躍するためには、いまのところオンプレの知識を持っていると有利だと感じます。
クラウドでインフラエンジニアが不要に、という論調が以前ありましたが、現実はそうではなく、相変わらずインフラエンジニア不足です。
■データモデリング
インフラから離れますが、ビジネスの人たち、いわゆるドメインエキスパートと会話するには経験しておくといいと思います。
データモデリング インフラエンジニアが学ぶ機会はすくない。実は、SQLチューニングにも効果大。プロジェクトに深く入るのなら、データモデリングを知っておくといいと思う。USではDBAがデータモデリングを担当するのも、当たり前らしい。
概念データモデリング:アーキテクト、E/U側にとっては価値がある
ITシステムは、現実世界のシミュレーションという考え方もあります。
■アーキテクチャ
設計書をたくさん読みましょう。デリバリの中でレビュー、アドバイス、調査をする中で、徐々に下のレイヤーからアーキテクチャの知識は身に付いていくと思います。
「絵で見てわかるITインフラの仕組み」は、インフラのアーキテクチャの入門本。 ※宣伝ですみません。
アーキテクチャはトレードオフや考え方、定石、注意点を知ることでスキルが身に付きます。
ATAM(Architecture Tradeoff Analysis Method)を学ぶのはあり。
アーキテクトになるには、大きなプロジェクトに深くかかわる(起こりがちな問題を実感できます)こと、プログラム開発についてもある程度知っていることが欠かせないと思います。
ただし、プログラム開発は、インフラコンサルが経験しにくい内容だと思います。これからはIaCで経験できるかも。
■学び方
アウトプットすることで、学ぶ。これ大事。周りも認識してくれる。最初は背伸びしてもいい。そのうち、情報も集まるようになる。
本を書く。実際には、調べている時間が大半になります。つまり、自分の勉強です(??)
最初は、SNSの記事、その後Web記事、書籍と順番に進む方法もあります。
ノウハウを自分で作る。自分が主張したいことは何か。それを事前に考えておけば、お客様から話があったときに、即座に答えられる。
#お客様の質問にうまく答えられない人をみていると、これを事前にやっていない感じがあります。
トラブルはチャンス。特に大規模では各社のエース級があつまる。いい情報もあつまる。権限より、解決できる人がえらい。(体感で)通常のプロジェクトの十倍以上のノウハウが得られる。トラブル対応は参加したほうがいい。
モブプログラミングやペアプログラミングという手法が流行っていますが、それに近いことはインフラでもできます。昔、グループのミーティングの中でその場で実機にコマンドを打ってもらったりしていました。若手はそこで、アドバイスをもらったり、先輩たちの技を見て学んだりしていました。
シニアなエンジニアは触っている時間ないと思います。レビューするのも、知識を身に付けるチャンス。シニア向けのおススメ。
新しいサービスを作るのは、自分のスキルを伸ばすことになる。社外の同様のサービスを研究したり、書籍で勉強したり、いろいろ考えたり。
■インフラエンジニアの将来に向けて(私の妄想)
CTOやチーフアーキテクトと会話するために、知っておくといいこと
・アーキテクチャの善しあし
・プロジェクト(プログラム ※プロジェクトの集合体のこと)の進め方
・ガバナンスや標準化の進め方
※製品の機能紹介だけだと、会話が盛り上がらない
そもそも、オンプレミスの知識は無くならない:
「いまクラウドよりオンプレを学ぶべき理由」
https://yuichi1004.hatenablog.com/entry/2021/03/14/110852?fbclid=IwAR0gPjj1vVLZ8puF_XKz2SM2k1NP2FzYfbHKQTnLgdLfNKo6Wcxkloi9PMw
製品の優劣だけではなく、会社間の、システムに対する考え方の戦いになると思います。
#フロントエンドとバックエンドの分担とか、マイクロサービスとか、サーバーレスとか、パーパスビルドとか、
各社の考え方、それを適用した時のシステムへの影響、プロジェクトや体制への影響、だから具体的にどうすべきなのか、をリアルに語らないとアーキテクトやCTOには響かない。
参考:今後の傾向(私の見立て):
OSSやメジャークラウドの知識が大事になるはず。相変わらずオンプレの知識も必要とされる。
マイクロサービスやクラウドの開発手法、お作法
アカウント管理も複雑になる。
データ連携。今後、クラウド移行や、クラウド内のデータ連携、ハイブリッドクラウドなどを考えると必要。
インフラエンジニアとしてやれることいっぱいあります。
以上、私の個人的な見解でした。
スキルアップを楽しんでください♪
2021/03/28(日) 15:08:42 |
スキル強化・教育
| トラックバック:0
| コメント:0
いろんなキャリアパスがあると思いますが、エンジニアとして深い知識を身に付けるならOracleデータベースはありだと思います。
・将来も生き残るために:簡単にはオンプレミスのOracleデータベースは無くなりません。エンジニアとして生き残りやすいです。需要のギャップが将来ありそうです。
・将来活躍するために:データソースとしてのOracleはしばらく残ります。そのためデータ連携元・先として、データ移行元として、バージョンアップのために、Oracleの知識が必要になるはずです。
・ITの基礎を鍛えるために:アルゴリズムやOS、ネットワーク、内部構造を理解するにはうってつけの題材。ミッションクリティカルシステムではDBの細かいところも理解することを求められます。すると、DBの内部構造、およびITインフラについて深い知識が身に付きます(身に付けるのに時間もかかるけど)
・ミッションクリティカルシステムの知識:ミッションクリティカルな仕事の仕方は、ミッションクリティカルシステムでしか経験できないです。Oracleはそういうシステムでの出番が多いです。障害対応やサポートとの問い合わせでも鍛えられます。
「PaaSやSaaSを利用する側になってインフラの中身を深く知らない」という戦略もありだと思います。そうではなく、クラウドの中でどうオンプレミスの技術が使われているのか、トラブルや問題の解決ができるエンジニアというキャリアもあると思います。後者の場合、Oracleデータベースは経験する価値があるプロダクトだと今でも思います。
参考。クラウドでもオンプレの技術が求められているという記事はこちら:https://yuichi1004.hatenablog.com/entry/2021/03/14/110852?fbclid=IwAR0OlnU6knL69Abul8hx4Z4lmh51CjDos7Ss4CIL7A0XNCoccp0XDpvAJBw
数年前から、「クラウドが流行ったらオンプレのインフラエンジニアはリストラだー」みたいな話がありましたが、まったくそんな兆しはないですよね。人手不足です。インフラを深く知るモテモテのエンジニアになりませんか?
2021/03/26(金) 14:59:28 |
スキル強化・教育
| トラックバック:0
| コメント:0
本番OS環境でも使えるような軽量な性能分析ツールです。インストールも簡単です。python3ではエラーになったので、python2もインストールします。
yum -y install git gcc
git clone https://github.com/tanelpoder/0xtools
cd 0xtools/
yum install python2
alternatives --set python /usr/bin/python2
#pythonを呼ぶと、python2が実行される設定です。
たとえば、Oracleのあるサーバープロセスを分析したい場合、このようにうちます。
psn -p 47800 -G syscall,state,wchan -a
=== Active Threads =====================================================================================================
samples | avg_threads | comm | state | syscall | state | wchan
------------------------------------------------------------------------------------------------------------------------
88 | 0.88 | (oracle_*_or) | Sleep (Interruptible) | semtimedop | Sleep (Interruptible) | 0
5 | 0.05 | (oracle_*_or) | Running (ON CPU) | read | Running (ON CPU) | 0
3 | 0.03 | (oracle_*_or) | Running (ON CPU) | [running] | Running (ON CPU) | 0
2 | 0.02 | (oracle_*_or) | Sleep (Interruptible) | nanosleep | Sleep (Interruptible) | hrtimer_nanosleep
2 | 0.02 | (oracle_*_or) | Sleep (Interruptible) | read | Sleep (Interruptible) | 0
OracleでASHを使っている人なら馴染みがあると思いますが、瞬間瞬間の状況をサンプリングして、集計して見せてくれています。これであれば、100回サンプリングしたうち、88回はsemtimedopでスリープしていたことを示します。100秒だとすると、88秒がsemtimedopでスリープしていたという推定になります。
psn -p 47800 -G syscall,state,kstack -a
=== Active Threads ===========================================================================================================================================================================================================
samples | avg_threads | comm | state | syscall | state | kstack
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
88 | 0.88 | (oracle_*_or) | Sleep (Interruptible) | semtimedop | Sleep (Interruptible) | ksys_semtimedop()->do_semtimedop()
4 | 0.04 | (oracle_*_or) | Sleep (Interruptible) | nanosleep | Sleep (Interruptible) | __x64_sys_nanosleep()->hrtimer_nanosleep()
3 | 0.03 | (oracle_*_or) | Sleep (Interruptible) | [running] | Sleep (Interruptible) | -
2 | 0.02 | (oracle_*_or) | Running (ON CPU) | [running] | Running (ON CPU) | -
1 | 0.01 | (oracle_*_or) | Running (ON CPU) | [running] | Running (ON CPU) | ksys_read()->vfs_read()->new_sync_read()->sock_read_iter()->inet_recvmsg()->tcp_recvmsg()->sk_wait_data()->wait_woken()
1 | 0.01 | (oracle_*_or) | Running (ON CPU) | read | Running (ON CPU) | ksys_read()->vfs_read()->new_sync_read()->sock_read_iter()->inet_recvmsg()->tcp_recvmsg()->sk_wait_data()->wait_woken()
1 | 0.01 | (oracle_*_or) | Sleep (Interruptible) | [running] | Sleep (Interruptible) | ksys_read()->vfs_read()->new_sync_read()->sock_read_iter()->inet_recvmsg()->tcp_recvmsg()->sk_wait_data()->wait_woken()
コールスタックも表示できるところは表示してくれます。
このツールのいいところは、サンプリング形式の情報収集であるため、軽いことです。psコマンドやtopコマンドと同様、/procを見ていて、軽いのだそうです。
xcapture, schedlat and psn sample the Linux /proc filesystem just like standard tools like ps, top and lsof do. The /proc filesystem is essentially Linux kernel presenting useful metrics into userspace as user-readable files. So, you do not need any additional Linux configuration or anything fancy to be installed on your hosts. 0x.tools require Linux kernel version 2.6 or later, so they will work even on your legacy installations
ツールのURLはこちら。解説動画もあります。
https://0x.tools/
2021/03/06(土) 19:43:52 |
DBA
| トラックバック:0
| コメント:0
sh2さん作成のJdbcRunner(今回はtpccスクリプト)を実行してみました。
Oracle 19.3とJRE8がインストール済みの環境を前提に始めます。
OracleのページからJDBCをダウンロードして、ファイルを置きます。サイトはこちら。
https://www.oracle.com/jp/database/technologies/appdev/jdbc-downloads.html
JdbcRunnerをダウンロードして、解凍します。サイトはこちら。
https://dbstudy.info/jdbcrunner/
こんな感じで、CLASSPATHを通します。
CLASSPATH=/home/oracle/jdbcrunner-1.3/jdbcrunner-1.3.jar:/usr/java/ojdbc8.jar
JdbcRunnerのtpcc_load.js と tpcc.js の接続情報を環境に合わせて書き換えます。
jdbcの設定はこのように書き換えました。ここの'orclpdb'がtnsnames.ora内の名前と対応します。
// JdbcRunner settings -----------------------------------------------
// Oracle Database
var jdbcUrl = "jdbc:oracle:thin:@//localhost:1521/orclpdb";
私の手元だと、tnsnames.oraはこんな感じです。
ORCLPDB =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = ORCLPDB)
)
)
Oracle DBにユーザー作成と権限付与が必要です。tpcc_load.jsのコメント欄に必要なオペレーションが載っています。
* [Oracle Database]
* shell> sqlplus "/ AS SYSDBA"
* sql> CREATE USER tpcc IDENTIFIED BY tpcc;
* sql> GRANT CREATE SESSION, CREATE TABLE, UNLIMITED TABLESPACE TO tpcc;
今回、マルチテナントのため、ここは少しコマンド追加が必要でした。alter session set container=XXXX という形で、PDBに切り替えたうえでユーザーを作っています。
いよいよ、JdbcRunnerの実行です。まず、データを投入です。
> java JR scripts/tpcc_load.js
実際に負荷をかけてみます。
> java -server JR scripts/tpcc.js
アウトプットはこんな感じです。
<前略>
14:29:27 [INFO ] [Progress] 894 sec, 476,496,51,50,48 tps, 340668,340685,34068,34066,34067 tx
14:29:28 [INFO ] [Progress] 895 sec, 504,497,50,50,54 tps, 341172,341182,34118,34116,34121 tx
14:29:29 [INFO ] [Progress] 896 sec, 506,504,49,50,49 tps, 341678,341686,34167,34166,34170 tx
14:29:30 [INFO ] [Progress] 897 sec, 475,477,49,50,46 tps, 342153,342163,34216,34216,34216 tx
14:29:31 [INFO ] [Progress] 898 sec, 508,504,47,48,50 tps, 342661,342667,34263,34264,34266 tx
14:29:32 [INFO ] [Progress] 899 sec, 504,499,52,50,53 tps, 343165,343166,34315,34314,34319 tx
14:29:33 [INFO ] [Progress] 900 sec, 492,508,50,49,44 tps, 343657,343674,34365,34363,34363 tx
14:29:33 [INFO ] [Total tx count] 343657,343674,34365,34363,34363 tx
14:29:33 [INFO ] [Throughput] 381.8,381.9,38.2,38.2,38.2 tps
14:29:33 [INFO ] [Response time (minimum)] 1,1,0,8,1 msec
14:29:33 [INFO ] [Response time (50%tile)] 20,6,1,31,3 msec
14:29:33 [INFO ] [Response time (90%tile)] 32,10,3,43,5 msec
14:29:33 [INFO ] [Response time (95%tile)] 35,13,4,48,6 msec
14:29:33 [INFO ] [Response time (99%tile)] 44,25,5,59,8 msec
14:29:33 [INFO ] [Response time (maximum)] 7241,7214,32,7235,5392 msec
14:29:33 [INFO ] < JdbcRunner SUCCESS
負荷はこんな感じです。負荷は設定で変更できます。
他のツールに比べてセットアップが楽だと思います。
JdbcRunner、おススメです!
2021/02/15(月) 21:18:53 |
DBA
| トラックバック:0
| コメント:0
次のページ