## 初心者でも分かるDockerコンテナ

エンジニアの皆さんは、Dockerやコンテナという言葉を耳にしたことがあるでしょう。仮想化の一種であることは分かっても、なかなかイメージがつかみづらく、理解が難しく思えますが、実は意外にシンプルな概念です。

ここでは、**Dockerコンテナに照準を当て、エンジニアの皆さんにぜひ知ってほしいことを中心に分かりやすく解説**をしますので、ぜひ最後まで読んでください。

【参考】：[ホーム-Docker](https://www.docker.com/)

Dockerとは？使いどころやメリット・デメリットについて解説！

皆さんは「コンテナ」と聞くと、何をイメージしますか？物流のコンテナをイメージする人も少なくないでしょう。確かに「コンテナ」は物流の世界ではよく利用されています。行き先ごとにコンテナに荷物をまとめ、コンテナ単位で船や列車、トラックにそのまま積み、目的地に運べます。

そのため、物流途上での積み替えや振り分けなど、無駄な作業が省け、効率的な物流を実現できます。Amazonはこのコンテナ物流を利用したことで今の地位を築いたとも言われています。

このように**物流業界では「コンテナ」による物流革命が起きましたが、ITの世界でも「コンテナ」が1つの革命を起こした**のです。それが「Dockerコンテナ」です。イメージとしては、次のような関係になります。

　　　　　　　　　　　　　　　*【コンテナA】【コンテナB】*

　　　　　　　　　　　　　　　　　　  *【Doker】*

　　　　　　　　　　　　　　　　　　　 *【OS】*

　　　　　　　　　　　　　　　　　　*【サーバー】*

### コンテナとはユーザー空間のこと

先ほどのイメージをより分かりやすく説明すると、サーバーにはOSがあり、さらにOSとコンテナを動かすためにDocker（エンジン）があります。コンテナはユーザー空間と呼んでも構いません。通常、*ユーザー空間は1つのOSに対して1つですが、Dockerではユーザー空間をコンテナとして複数設けることが可能*です。

**コンテナの中身はアプリケーションとミドルウェア、OSの一部（ライブラリーなど）**です。コンテナはOSのカーネルを利用して、それぞれが独立して動きます。

### Dockerコンテナ環境と仮想マシン環境との違い

ここまでの説明で、多くの方は「ただの仮想環境と何が違うのか？」と思われたかもしれません。確かに仮想マシンを実現する「ハイパーバイザー」と「Docker」の機能は似ているように思いますが、実は次の点で大きく異なっています。

*「仮想マシン環境」では「ハイパーバイザー」の下に「ゲストOS」を立て、その下でアプリケーションが動きます。*つまり、仮想マシンはOSそのものの仮想化です。ハイパーバイザーの詳細については後述します。

一方の「コンテナ型仮想環境」では、「ハイパーバイザー」と同じ位置に「Docker」があり、その下に「コンテナ」が複数あります。「コンテナ」にはOSライブラリー、ミドルウェア、アプリケーションが搭載されていると説明しましたが、Dockerの仮想化対象はコンテナです。

「仮想マシン環境」では必ず「ゲストOS」が必要ですが、**「コンテナ環境」ではアプリケーションを動かす際にサーバーOSのカーネル部分を、カーネル以外の部分はコンテナ自体のOSライブラリーを利用するため、ゲストOSを必要としません。**

上記の説明で簡単に紹介したハイパーバイザーについて、ここで詳しく解説します。**ハイパーバイザーとは、物理サーバー上に仮想環境を構築するためのソフトウェアのこと**です。

ハイパーバイザーには、ホストOSにインストールして使うホスト型ハイパーバイザーと、ホストOSにインストールしないネイティブ型ハイパーバイザーの2種類があります。

ホスト型ハイパーバイザーはOS上でソフトウェアとして稼働することで、OSの上でいくつもの仮想環境を動作させることができます。ホスト型ハイパーバイザーにはVMware Workstation Player・VMware Fusionなどがあります。

一方ネイティブ型ハイパーバイザーは、ハードウェア上で直接プログラムを稼働することで仮想環境を構築します。ネイティブ型ハイパーバイザーにはVMware vSphere・KVMなどがあります。

【参考】：[VMware Workstation Player のダウンロード | VMware | JP](https://www.vmware.com/jp/products/workstation-player/workstation-player-evaluation.html)

【参考】：[KVM](https://www.linux-kvm.org/page/Main_Page)

コンテナ型の仮想化技術はさまざまあります。LinuxベースのOpenVZなどもコンテナ型仮想化の1つです。そうした**コンテナ型仮想化技術を用いたサービスの中で、最も利用されているのがDocker**です。

*Dockerは、2013年にDocker社からリリースされ、Windows、Linux、Macなどのさまざまな環境で動作できる*点が特徴です。

またDockerにはKubernetes（クベルネテス）やDockerUIなどのGUI管理ツールを用いて、コンテナ管理や自動化が行えるメリットがあります。

現在、Dockerはクラウドの3大サービスであるAWS、Azure、GCPでも対応が進められています。

AWSのコンテナについて初心者にも分かりやすく解説！

クラウドエンジニアを目指す方必見！Azureを分かりやすく紹介！

GoogleのGCPについて知り、エンジニアのスキルに生かそう

## Dockerコンテナの利用メリット

コンテナ型仮想化技術を用いたDockerを利用すると、どんなメリットがあるのでしょうか？メリットを確認することで、Dockerに対する理解をさらに深めましょう。 

### 起動までの時間を大きく短縮できる

一般的な仮想サーバーでは、ゲストOS単位で仮想サーバーが生成されるため、OSの起動から利用可能な状態になるまで分単位の時間を要しますが、**コンテナ型仮想化では、コンテナ起動に掛かる時間は数秒程度です。**この身軽さ、素早さは大きな利点です。

*開発したシステムを動かすためには、同一環境を別のマシンで準備*しなければなりません。同一環境の構築の手間、環境確認や環境テストなど、多くの手順が必要です。しかし、**Dockerは環境が丸ごと提供されるため、少ない手順でスピーディーに同じ環境を再現**できます。

### Dockerイメージの配布により開発環境構築の時間が短縮できる

作成した*Dockerイメージはパッケージとして配布*できます。これにより、システム開発などで別のアプリケーションを動かす際にも、**Dockerイメージを利用すれば同一環境となり、環境のずれを防止できます。**Dockerイメージは開発環境を準備する時間の短縮にもおすすめです。

### ハードウェアリソースを削減できる

コンテナ自体は、アプリケーションの実行に必要なものだけに限定され、またホストOSのカーネル部分だけを使用するため、**無駄がなくパフォーマンスが向上し、リソースの削減も実現**します。

Dockerの特徴としてはコンテナ共有化サービスの『Docker Hub』があります。**『Docker Hub』を通じて世界中の開発者の成果物が共有**できます。これによって、よりレベルの高い優れたイメージを効果的、効率的に活用できます。

また、『Docker Hub』ではWebサイト構築に利用するWordPressやPHP、MySQLなどの環境がコンテナイメージとして提供されていますので、これらを利用してローカルに簡単にコンテナ環境を作成することも可能です。

【参考】：[Docker Hub Container Image Library | App Containerization](https://hub.docker.com/)

### インフラ調達は後回しにできる

一般的なシステム開発では、サーバーなどのインフラ環境を先に整えますが、Dockerコンテナでは、まずはアプリケーション作りから始めて問題がありません。アプリケーション開発が進んだところで、**コンテナ単位で本番環境に乗せればよいので、システムエンジニアはインフラを気にせず開発に専念**できます。

ロールバックの時間が速く簡単なことも、Dockerのメリットの1つです。ロールバックとは、日本語で「後退」「巻き戻し」という意味で、PCの状態を指定したところまで戻すことを言います。

開発やテストを行う上で、バージョンアップや処理を繰り返すことは多いです。そのため、バージョンアップする前や処理を実行する前の状態に戻すのに時間がかかると、作業効率が悪くなります。

ロールバックが速く簡単なことは開発・テスト作業を行う上で重要です。**Dockerコンテナは状態の差分を保存するため、ロールバックの時間が速く簡単なのがメリット**です。

良いことだらけに見えるDockerコンテナですが、デメリットもあり、必ずしもオールマイティではありません。そのため利用する際には、デメリットを意識し、対策が必要な場合があります。以下、**Dockerコンテナのデメリットを挙げますので、メリットと同様に認識しましょう。**

**Dockerコンテナは1つのOSに依存するため、OSの自由度はありません。**コンテナはホストOSのカーネルを使って動作します。したがってWindowsOS上で直接Linuxコンテナは動作させられません。同一マシン上で異なるOSを動作させるにはホスト型の仮想マシン環境が必要です。

コンテナはホストOSへの依存度が高く、個別にOSを立てるホスト型の仮想マシンと比較して、OSとの分離レベルが低いというデメリットがあります。**OSの脆弱性などに対する外部からの攻撃に対しては、すべてのコンテナが危険にさらされるため、細かいケアや対策が求められます。**

### Dockerファイルを作成するための知識が必要

**Dockerコンテナは便利なシステムである一方、使いこなすのが難しい**と感じることがあります。Dockerコンテナは使用する容量を少なく効率化するため、独自のファイルシステムを使用しています。このファイルシステムを理解するのが難しいと感じる場合があります。

## Dockerコンテナに関する疑問を解消

Dockerコンテナに関して、ある程度理解は進んだでしょうか？ここでは、**Dockerコンテナに関するよくある疑問について解説します。**

### Dockerコンテナの製品やサービス

Dockerコンテナを実際に製品やサービスとして提供しているものには何があるのか紹介します。

*▪Docker Hub*
**Docker Hubは、開発者が作成したコンテナをWeb上に公開・共有できるサービス**です。公開されているコンテナはダウンロード可能で、他人が作成したコンテナを利用してローカルにコンテナ環境を作成することもできます。

なお、2019年にDocker Store・Docker CloudはDocker Hubに統合されました。

【参考】：[DockerHub-Docker](https://www.docker.com/products/docker-hub/)

*▪AWS Fargate*
AWS Fargateとは、**「Amazon ECS（Elastic Container Service）」および「Amazon EKS（Elastic Kubernetes Service）」 で動作する、コンテナ実行環境**です。

コンテナ向けのサーバーを意識せずに利用できるクラウドサービスです。Googleの「Google Cloud Run」、Azureの「Azure Container Instances」なども同様のサービスです。

【参考】：[AWS Fargate（サーバーやクラスターの管理が不要なコンテナの使用）| AWS](https://aws.amazon.com/jp/fargate/)

*▪Docker Desktop*
**パソコンなどのローカル環境で簡単にDockerコンテナの開発環境を構築、導入できるソフト**です。WindowsやMacなどのOSに対応しています。個人向けプランは無償ですが、企業向けプランは有料化されています。

【参考】：[Docker Desktop - Docker](https://www.docker.com/products/docker-desktop/)

エンジニア必見！ Docker Desktop有料化の影響と対策

### Dockerのインストールと実行方法

Dockerは皆さんのパソコンにインストールをして実際に試すことができます。**インストールは『Docker Hub』から入手**します。以下のサイトでインストール、実行方法などを確認してください。

【参照】[Docker Desktop](https://docs.docker.jp/desktop/toc.html)

**パソコンにインストールしたDockerを利用するには、コマンドを用います。**Windowsであれば、コマンドラインを開いて、直接コマンドを打ち込みます。よく使うコマンドの例を挙げます。

*>docker version*
インストールされているDocker Engineのバージョン情報を確認します。

*>docker ps*
動作中のコンテナ一覧を表示します。

*>docker ps -a*
停止中のコンテナも含めて全てのコンテナを一覧表示します。

*>docker images*
現在取得済みのDockerイメージの一覧を表示します。イメージは主に「Docker Hub」から取得できます。

*>docker pull [イメージID]*
イメージをローカルに取得する際に使うコマンドです。

*>docker create --name [コンテナID] [イメージID]*
取得したイメージからコンテナ作成を行うコマンドです。 

*>docker start  [コンテナID]*
コンテナを実行するコマンドです。

*>docker stop [コンテナID] *
コンテナを停止するコマンドです。

*>docker cp*
コンテナのコピー、ファイル転送するコマンドです。

いかがですか？すでにDockerイメージがあれば、以上のコマンドだけでDockerコンテナのイメージを取得し、コンテナの作成と実行ができます。

## Dockerコンテナは必ず押さえておくべき技術

仮想化技術には、大きく分けるとOSの仮想化とコンテナ（ユーザー空間）の仮想化があります。ここではコンテナ仮想化のDockerについて採り上げ、その概念やメリット、デメリットなどを解説します。Dockerはエンジニアには必須技術ですので、ぜひ学んでください。

Dockerは、Docker社が提供するコンテナを仮想化するコンテナ型仮想環境実現ツール

従来型のホスト型仮想環境と異なり、コンテナ型仮想環境はゲストOSが不要である

Dockerイメージとはテンプレートであり、DockerコンテナとはDockerイメージを実行してできる仮想実行環境である

エンジニア初心者でも分かる！Dockerコンテナの超入門！

## オーバーエンジニアリングとは

オーバーエンジニアリングとは、気をきかせたつもりがありがた迷惑になるような過剰なエンジニアリングのことです。また、シンプルに組み立てることができず無用に複雑にしてしまうエンジニアリングを指すこともあります。

### オーバーエンジニアリングの2つの意味

日本語版のウィキペディアには「オーバーエンジニアリング」の項目はありませんが、英語版では次のように定義されています。

「オーバーエンジニアリングとは、製品を、その用途に必要な以上に頑丈にしたり、多くの機能を装備させること。あるいは、ある機能を装備するために不必要に複雑、非効率な設計することである」

つまり、**製品に過剰な性能を与えること**、あるいはある機能を持たすめの**設計(システム開発)で、最短コースではなく遠回りをしてしまうこと**がオーバーエンジニアリングです。

自転車のタイヤに時速100㎞に耐える性能は必要ないし、独身寮に置く電子レンジに「煮込み機能」や「パン焼き機能」は無用の長物です。

エンジニアリングの場合、同じ機能があるのなら、できるだけシンプルなロジックで書かれたコードが望まれます。

### 過ぎたるは及ばざるがごとし

日常の使用ではオーバーエンジニアリングと思われていた機能が災害時には役に立った、ということもあります。*セキュリティに関してはオーバーエンジニアリングが起きにくい*と言えるかもしれません。しかし、そんなケガの功名がいつも生じるわけではありません。

自転車のタイヤが時速100㎞で壊れなくても不都合はないし、独身寮の電子レンジに煮込み機能が付いていても別に邪魔にはなりません。大は小を兼ねるのです。それにもかかわらず、オーバーエンジニアリングが「過ぎたるは及ばざるがごとし」と言われるのはなぜでしょうか。

最も分かりやすい理由は、**オーバーしている分だけ時間とコストがかかっている**からです。それはユーザーにとっては「*高い価格*」につながるし、メーカーには「*競争力の低下*」をもたらします。

システム開発における**不必要に複雑なロジックは、オーバーエンジニアリングというより、エンジニアリングの失敗**です。見た目では問題なく機能しているようでも、それが*システムの脆弱性*になったり、*バージョンアップの際に手間やコストがかかる*原因になります。

趣味で行なうプログラミングにオーバーエンジニアリングという概念はないかもしれませんが、仕事・企業活動においては常に「過不足ないエンジニアリング」が求められます。

## オーバーエンジニアリングが生じる原因

エンジニア・クライアント・ユーザーそれぞれにデメリットが大きいオーバーエンジニアリングがしばしば生じるのは、**エンジニアリングも人間の行為で、ヒューマンな要因が深く関わっている**からです。

### ソフトウェアの開発に内在するスケーラビリティへの要求

スケーラビリティ（scalability）とは、例えばユーザーが1万人から100万に増えても適応できるような拡張性のことです。エンジニアはシステム開発をするときに、**スケーラビリティを過剰に追求する傾向**があります。

しかし、「将来はこんな機能が役に立つはずだ」とか「この機能ではここも拡張可能にしておいて方が良い」という発想は、オーバーエンジニアリングを生む大きな要因です。

とくに日本人は「おもてなしの精神」が豊かなので、*「不足」を心配するあまりに実装内容が過剰になりがちなメンタリティ*を持っています。

「今のところは、とりあえずこれで間に合う」がもっとも妥当なシステム開発と言えます。現在、自分あるいはプロジェクトが抱えていない問題を解決するコードを書く必要はないのです。

### 自己陶酔型のエンジニアリング

要件をコードに落とし込むときに、なにか**アイディアが浮かぶと、ついそれを実装したくなる誘惑**にかられませんか？

「オレもなかなかやるじゃないか」と思う瞬間があるのはプログラミングの醍醐味ではありますが、「なんてオレは賢いのだろう」という自己陶酔は抑制しないと、いたるところでオーバーエンジニアリングが生じます。

ドキュメンタリー映画を作るときに、効果音楽をドラマチックにしたり、有名俳優をフューチャーしたりするのは逆効果です。自己陶酔型のエンジニアリングでは、このような*フューチャリング(過剰な機能の追加)*が生じがちです。

システム開発中に「こんなこともできる」「あんなこともできる」というアイディアが浮かんだとしても、それは別のプロジェクトに活用すべきアイディアかもしれません。

### 成功体験がセカンドシステム症候群を誘発する

最初のシステム開発では「コンパクトに、シンプルに」という自制心が働いたとしても、それが**成功して「次のバージョンを」というときにやりすぎてしまうのがセカンドシステム症候群**です。

ファーストバージョンの成功は開発者に自信を与え、ステークホルダー(利害関係者)にセカンドバージョンへの期待を抱かせます。このような*勢いに乗ったムードの中でオーバーエンジニアリングを自制するのは、簡単ではありません*。

## オーバーエンジニアリングを避けるには

エンジニアリングという仕事にやりがいを感じている人、創造性がある仕事だと思っている人ほど、オーバーエンジニアリングに陥りがちです。それを避けるには、次のような注意が必要です。

### オーバーエンジニアリングへの誘引が自分の中もあることを自覚する

オーバーエンジニアリングが生じる原因にはヒューマンな要素が大きいので、エンジニアは「気をつけないと自分もやってしまう」という自覚を持つ必要があります。

とくに、**「できるエンジニア」だという自己肯定感は、自己陶酔型のエンジニアリングを誘引しやすい**ので、自制しなければいけません。

*成功体験でチームや会社のムードが盛り上がっているとき*も、セカンドバージョンの設計でオーバーエンジニアリングが生じやすいので、警戒が必要です。

### 要件の本質、解決すべき問題の本質を捉まえる

オーバーエンジニアリングを防ぐには、心構えだけでなく、要件の本質的な意味を理解することが必要です。言い換えるなら、**「なぜこの要件があるのか」をUI(ユーザー・インターフェース)、UX(ユーザー・エクスピアリエンス)の視点で深く捉える**必要があります。

また、 YAGNI（You ain't gonna need it）の原則では、実際に必要となるまでは余計な機能は追加しない方がよいとされます。要件の本質、必要性がユーザー目線で明確化されれば、複数の想定されるソリューションのどれを選ぶべきかは、ある程度絞られてくるはずです。

高品質なシステム開発に欠かせない機能要件と非機能要件とは？

### 要件の意味を包括的、長期的に理解する

個々の要件の意味を、プロジェクト(あるいは製品)の**全体像から理解すること、さらに、できるだけ長期的な観点から理解すること**がオーバーエンジニアリングを防ぐことにつながります。

これは個人の心構えや努力だけでは限度があるので、プロジェクト全体、企業全体の意思統一と見通しが必要です。

要件の理解、ソリューションの選択が、課題の全体像から離れるほどオーバーエンジニアリングが生じやすく、プロジェクトのあちこちでそれが生じるほど、*成果物は将来に向けて厄介な問題を抱え込む*ことになります。

## オーバーエンジニアリングかどうかの分かりやすい基準はない

ここまで述べてきたように、オーバーエンジニアリングがヒューマンな問題である以上、*あるソリューションがオーバーエンジニアリングかどうかの客観的で分かりやすい基準はありません*。

また、あるソリューションがオーバーエンジニアリングかどうかは、セカンドシステムをどの程度視野に入れておくかによっても、判断が異なってきます。

このように単純明快な対処策がないのがオーバーエンジニアリングなので、エンジニアに求められるのは、**要件の意味をUX視点で繰り返し問い直しながら、過不足ないエンジニアリングを心がける**ことです。

システム開発をしているエンジニアがついやってしまいがちなオーバーエンジニアリング。余計な時間がかかるだけでなく、後々システムにとって負の遺産になることもあります。本記事は、オーバーエンジニアリングとはなにか、オーバーエンジニアリングが生じる原因と、予防策について考えます。

オーバーエンジニアリングとは、成果物に本来求められていない機能を装備させることである

オーバーエンジニアリングが生じる原因には人間的な要素が大きい

オーバーエンジニアリングを防ぐには要件の本質をUXから理解する必要がある

オーバーエンジニアリングとはなにか？なぜ発生し、どうすれば防げるのかを徹底解説！

スマホ分野で日本では圧倒的なシェアを誇るiPhoneですが、iPhone人気を支えるものとしてiPhoneアプリの存在があります。

**iPhoneアプリの開発に関して従来はObjective-C言語が中心でしたが、統合開発環境のXcodeが登場し、さらにSwiftの出現でiPhoneアプリの開発環境は大きく前進**しました。

*Apple社が2014年に開発・発表したSwiftは、iPhoneやiPadなどのApple製品向けアプリの開発ができる、オーブンソースのプログラミング言語です*。

Swiftは、主にMacユーザーであれば、開発環境さえ整えれば気軽に取り組めるプログラムで、初心者でも比較的馴染みやすいことも人気を高めています。

*Swiftは英語の「アマツバメ」という鳥のことで、ネーミングにはアマツバメの「速い」「すばやい」という特徴をイメージとして採り入れたとされています*。


新しい言語である**Swiftは、他の先進的なプログラミング言語を研究し、良い点を取り入れながら、現代の開発環境にマッチするように開発**されています。

*1.書きやすく読みやすい言語*
SwiftはObjective-Cと似ていますが、RubyやPython、Javaなどの人気の言語の特徴も見られ、*様々な言語の見習うべき点を積極的に採用し、書きやすく読みやすく、初心者でも学習しやすい言語*に仕上げられています。

*2.他言語との互換性*
Swiftは、従来iOSやMacの開発で使われてきたObjective-Cと互換性があります。またC++やC言語との混在も可能です。*SwiftはObjective-CとのAPIの共有が可能で、Objective-Cと併存できる*点も特徴です。

*3.高速処理が得意*
Swiftは「アマツバメ」の名の通り、*高速動作が特徴*です。これまでのObjective-Cと比較して最大で2.6倍、Python 2.7と比較すると最大で8.4倍のパフォーマンスを記録しています。iPhoneがゲーマーに人気な理由も、このSwiftの高速性によるところが大きいでしょう。

*4.コーディング中の動作確認*
Swiftは「Playground」という機能を持っており、コーディング中に動作のシミュレーションが行えます。

従来、Objective-CやC言語による開発では、修正の都度アプリケーションを起動する必要がありましたが、*Playgroundではコーディングをしながら同時に動作確認が行える*ので、開発やメンテナンス作業が効率化できます。

SwiftはAppleが開発した言語だけに、その利用にはMacが有利です。しかし、現在では*WindowsでもSwiftの実行環境を作ることができる*ので、Windowsユーザーにも開放されている点は強みです。

とはいえ、**App Storeでの公開、商用利用を考えるとMacで開発することをおすすめ**します。

### Swiftの利用に整えておきたいもの

*■Apple ID*
iPhoneやiPadを利用している方なら、誰もが持つ「Apple ID」ですが、Swiftでアプリを作成する場合には、この「Apple ID」が必要です。アプリや楽曲購入に*いつも使っている「Apple ID」をそのまま使えます*。

*■Xcode*
*XcodeはiPhoneアプリの統合開発環境*です。「Mac App Store」で「開発ツール」のカテゴリから*無料ダウンロードが可能*です。このXcodeのダウンロードの際には、「Apple ID」が必要です。

*■Developer ID*
開発したアプリを**App Storeで配布するには、「Apple Developer Program」への登録が必要**になります。メンバーシップ料金として年間11,800円が必要です。「Apple Developer Program」への登録によって、自分で開発されたアプリがAppleのお墨付きとなります。

### iPhoneアプリの開発からリリースまでの流れ

iPhoneアプリの開発からリリースまでの流れは基本的に以下のようになります。

*1.開発ツールの Xcode をインストールする*
Windows機にXcodeをインストールして使うことは不可能ではありませんが、かなりハードルが高くリスクも伴うため、現実的ではありません。**中古機でも構わないので、Macを購入した方が結果的には楽です**。

*2.Xcode を使ってコーディングする*
開発言語は Swift、SwiftUI (あるいは Objective-C)を用います。
※Swift、SwiftUI、Objective-CはすべてXcodeに附属しています。　

*3.Simulatorで確認*
Xcodeの1つの機能である「Simulator」を用いて、*開発中のアプリの動作確認*が行えます。　

*4.iPhoneで開発したアプリを確認する*
iPhoneアプリ開発の勉強や体験なら、ここまでで終わらせても構いませんが、作成したアプリを公開する場合は次に進みます。

*5.Appleに開発者の登録を行う*
**自作アプリをAppleStoreに登録して公開する場合には、開発者登録が必要**です。
年間参加費として、別途1万1千円程度（US$99)が掛かります。

*6.Appleにアプリの申請を行う*
Appleが審査を行い、*承認されるとAppleStoreに公開*されます。

Swiftには興味があるが、わざわざ*学ぶ価値があるのかと疑問に感じる*方もいるでしょう。これから、新たなプログラミング言語として、**Swiftを習得するメリットについて解説**していきます。Swiftの学習を検討している方は参考にしてくだい。

### Apple製品共通のプログラミング言語

SwiftはApple製品で共通のプログラミング言語です。**一度習得すれは、iPhoneやiPad以外にもMacやAppleウォッチなど、Apple製デバイスのアプリはすべてSwiftで開発可能なため、Apple製品のすべてに対応できる**のは強みです。

ほかの言語では、たとえばWebアプリケーション開発の際にはHTMLやCSSに加え、JavaScriptやJavaなどの言語が必要でしたが、Swiftであれば*SwiftとXcodeを覚えておくだけでアプリケーションを開発*できます。このシンプルさもエンジニアにとってはありがたいところでしょう。

### プログラミングの習得がしやすい

まず**SwiftはObjective-Cの発展形言語**であるという点から、*Objective-Cのプログラミング経験者であれば、コーディングルールを覚えるだけでSwiftへの移行が可能*です。

これまでObjective-Cで作成してきたライブラリをコンバートツールを介してSwiftに変換することも容易に行えます。

またObjective-Cで作成されたライブラリをSwiftで利用することも可能です。この互換性の高さは、Objective-CからSwiftを呼び出すこともできます。

また*Swiftはほかの言語と比較してコードの読み書きがしやすく、学習しやすい言語*です。学習環境も整備されており、iPadやMacにはゲーム感覚で「Swift」を学べる学習アプリ「Swift Playgrounds」があります。

公式ドキュメントも整い、iTunes Uでは無料講座などもあり、学習に適した本も多く出版されていますので、学習機会が豊富にあります。

Swiftの強みは、そのシンプルさや高性能さだけではありません。*オープンソースであり、著作権などの制約もありません*。

そうしたことから、**iOSやMac以外でもアプリケーション開発にSwiftを導入する動き**があります。

Google はAndroid用アプリの開発にJavaを利用していますが、Javaの提供元であるOracleとライセンス問題で訴訟を抱えており、オープンソースであるSwiftをAndroidアプリの開発に利用する方向性が高まっています。他にFacebookやUberもSwiftの利用が噂されており、Swiftの利用が加速する可能性があります。

**プログラム言語の教本は、網羅的に必要な情報が載っているため、体系的な勉強ができるというメリット**があります。また多くの人の手を介して作成される本は、*信頼度が高い*ので安心して学習できます。

ネットにも教材や情報がありますが、網羅性や信頼性が担保されていないものが多く、しっかり勉強をしたい人には本を用いた学習をおすすめします。以下、2021年時点で評価の高いものから、*人気が高くおすすめできる本を3つ*選んでみました。ぜひ教本選びの参考としてください。

### 絶対に挫折しないiPhoneアプリ開発「超」入門

*[『絶対に挫折しないiPhoneアプリ開発「超」入門』](https://www.sbcr.jp/product/4815604622/)は5年連続で、もっとも売れているiPhoneアプリのプログラミング入門書です*。2021年8月の[【Swiftおすすめ入門本/参考書ランキング】](https://nuko-programming.com/ranking/Swift/page/1)でも第2位にランクインしています。**Swiftアプリの基本を学ぶなら、必読の書です**。

### 作って楽しむプログラミング　iPhoneアプリ超入門 Xcode 11 ＆ Swift 5で学ぶはじめてのスマホアプリ作成

2020年発売の*[『作って楽しむプログラミング　iPhoneアプリ超入門 Xcode 11 ＆ Swift 5で学ぶはじめてのスマホアプリ作成』](https://www.nikkeibp.co.jp/atclpubmkt/book/20/P53910/)はプログラミングの超初心者でも、簡単なゲームアプリを作りながら、iPhoneアプリ作成の楽しさを体験できる入門書です*。

全11章からなり、1章から順番に読み進めると、**基礎知識の理解から始めて、アプリ作成の準備、画面デザイン、コーディングからアプリ公開手順まで幅広く習得できます**。PCスクールなどの教材としても適しています。

### 詳細!SwiftUI iPhoneアプリ開発入門ノート iOS 13+Xcode11対応

*[『詳細!SwiftUI iPhoneアプリ開発入門ノート iOS 13+Xcode11対応』](https://books.apple.com/jp/book/%E8%A9%B3%E7%B4%B0-swiftui-iphone%E3%82%A2%E3%83%97%E3%83%AA%E9%96%8B%E7%99%BA%E5%85%A5%E9%96%80%E3%83%8E%E3%83%BC%E3%83%88-ios-13-xcode-11%E5%AF%BE%E5%BF%9C/id1492408339)*は**根強い人気のSwift入門本**です。基礎から実践まで幅広くカバーし、*中級者の辞書としても活用*されていますので、入門というよりは実践入門の本を探している方にはおすすめします。

SwiftはAppleがiOSやMac向けアプリの開発用に開発した、比較的新しいプログラミング言語です。特にiOSやMacユーザーの方にはSwiftに興味をお持ちの方も少なくないでしょう。ここでは、Swiftの概要を紹介した後に、独習に適した入門書を紹介します。

Appleが開発したオープンソースの人気言語Swiftは、シンプルで分かりやすく初心者にもなじみやすい

高速性に優れたSwiftだが著作権の問題がなく、GoogleやFacebookなどからも注目され、今後への期待が大きい

SwiftはiPhoneアプリについて本でじっくり学びたいという人におすすめ独習本や参考書が揃っている

Swift入門書でしっかり学んでみたいエンジニアにおすすめの3冊

AWSはクラウドサービスのシェアNo.1ですが、その各種サービスに対する高い評価も特徴です。今回はそのサービスの中から、ロードバランサのサービス、EBLについて解説します。Webサービスの停止や遅延はユーザーへのサービス提供に大きな支障をきたすばかりか、ブランドイメージを大きく損ないます。そのため、Webサービスにおいては*Webサーバーに対する負荷分散は必要不可欠*になっています。

この負荷分散をロードバランシグと呼び、ロードバランシングを行うシステムをロードバランサと称します。このロードバランサについては後ほど詳しく触れますので、まず最初に**AWSが提供するロードバランサ（ELB）について解説**します。

ELBは正式名称「Amazon Elastic Load Balancing」の通称で、AWS が提供する**「負荷分散」に加え、「ヘルスチェック機能」を備えたロードバランササービス**です。ELBには多くの特徴（強み）がありますが、最初にELBの3つのロードバランサを紹介しましょう。

**AWSが提供するロードバランサには3種類があり、Network Load Balancer（略称NLB）・Application Load Balancer（略称ALB）・Classic Load Balancer（略称CLB）**です。
AWSでは、この3種類の中から、利用するシステムの適性に合わせて選択することができます。以下で、それぞれの特徴について説明します。

*1.Network Load Balancer（NLB）*
**NLBは、秒間数百万のリクエストを捌けるように設計されたロードバランサ**です。*TCPプロトコルの標準的なL4でロードバランシング*が行え、大量のアクセスが想定されるシステムに推奨されています。NLBは宛先IPをターゲットIPに変換して転送するため、帰路はロードバランサを介することなく、ターゲットからクライアントに通信できます。このように、NLBではロードバランサとしての処理が最小限であるため、*遅延防止に重きを置いた仕組み*となっています。

*2.Application Load Balancer（ALB）*
**ALBは、HTTP・HTTPSプロトコルのL7（アプリケーション層）への対応**が強化された単一ロードバランサです。異なるURLごとにサーバーに対するリクエストを振り分けることができ、CLB 比較してより細かい設定が可能です。

ALBは複数のアベイラビリティゾーン（データセンター）にまたがって対応することができ、高レベルの耐障害性を実現しています。また、ALB自体に自動的にキャパシティを増減する機能が備わっており、可用性においても非常に優れています。WEBアプリケーション用には、*ALBが最も多く利用されています*。

*3.Classic Load Balancer（CLB）*
**CLBは、AWSで初期から提供されているELBの1つ**です。複雑な設定はできず、*シンプル*なロードバランサです。利用中のユーザーがいるためサービスとしては提供中ですが、**AWS側からは推奨されていない旧タイプ**です。

## ロードバランサについてもっと知ろう

ITエンジニアの記事（17ページ目）