IT로 세상을 이롭게

Hadoop분산환경에서 FTP연결관련 공부를 하면서 몇가지 테스트 프로그램을 작성했는데..

갑자기 Connection Reset이라는 오류가 발생한다. 구글링을 하면 대부분 Firewall, Network Setting, IPV4, 좀 더나아가서는 Data Connection에 대한 설명들(Active/Passive)이 있다. 

(Data Connection방식에 대한 상세한 설명은 다른 글에서 포스팅할 예정)

그러나.. 며칠동안 나오는 모든 내용을 살펴봤지만 해당하는 부분이 없었다.

<현상>

- Windows IIS FTP 접속시 Data전송요청이나 Command수행 후 재요청하면 Connection Reset이 발생함

원시적인 방법으로 돌아가서 프로그램상의 값을 하나씩 값을 변경해보다가 마침내 원인을 찾았다.

<원인>

- Hadoop에서 사용하고 있는 FTPFileSystem이라는 클래스를 살펴보면 다음과 같이 코딩되어 있다.

client.setFileTransferMode(FTP.BLOCK_TRANSFER_MODE);
client.setFileType(FTP.BINARY_FILE_TYPE);
client.setBufferSize(DEFAULT_BUFFER_SIZE);

이에 관련하여 FTP에 연관되어있는 많은 RFC문서를 볼 수 있는데, 기초가 되는 것이 RFC959 문서이다. 해당 문서를 읽어보면 Transmission Mode에 크게 3종류가 있으며, Hadoop FTPFileSystem은 Block transer mode를 기본으로 사용하고 있다. (https://tools.ietf.org/html/rfc959)

1. Stream Mode : The data is transmitted as a stream of bytes. There is no restriction on the representation type used; record structures are allowed. (가장 기본적인 방식이다.)

2. Block Mode : The file is transmitted as a series of data blocks preceded by one or more header bytes. The header bytes contain a count field, and descriptor code. The count field indicates the total length of the data block in bytes, thus marking the beginning of the next data block (there are no filler bits).

3. Compressed Mode : There are three kinds of information to be sent:  regular data, sent in a byte string; compressed data, consisting of replications or filler; and control information, sent in a two-byte escape sequence.  If n>0 bytes (up to 127) of regular data are sent, these n bytes are preceded by a byte with the left-most bit set to 0 and the right-most 7 bits containing the number n.
compressed data와 그외 정보들로 전송하는 방법이다.

 문제가 되었던 것은 바로 2번 Block Mode!!
리눅스/유닉스 계열의 FTP서버에서는 별 문제가 없지만 IIS 의 FTP에서는 해당 모드를 제대로 지원하지 않아서 계속 EOF 신호를 기다리다가 timeout에 걸려서 server에 socket이 끊어지고 결국 connection reset이 발생하게 된다.
https://technet.microsoft.com/ko-kr/library/cc771040(v=ws.10).aspx
IIS 기반 FTP의 기본 데이터 전송 모드는 스트림입니다. IIS는 현재 블록 또는 압축 데이터 전송 모드를 지원하지 않습니다.
IIS 8.0버전에서 확인해봐도 여전히 Stream Mode만 지원하고 있음.

 현재까지 google이나 naver를 찾아봐도 FTP프로그램 작성시 connection reset현상의 원인에 대해서 FTP Transfer mode에서 해결책을 찾은 경우는 전무하다.
즉 동일한 오류가 발생하더라도 그 원인은 각각 다를 수 있다.


<해결방안>
- 소스를 수정하여 FTPClient 를 Stream Mode로 사용하면 Windows IIS 상에서도 문제없이 전송이 된다.
- 혹은 Block Mode를 사용하고 싶다면 이를 지원하는 FTP Server로 변경하면 된다.

- 왜 Hadoop의 FTPFileSystem에서는 apache net의 FileType이나 FileTransferMode Default값(STREAM_MODE)이 있음에도 불구하고 BLOCK_MODE로 하드코딩을 했을까?
 아마도 Hadoop은 Linux기반의 대용량 처리를 기본으로 하기 때문에 멀티 파일 전송에 유리한 BLOCK_MODE를 택한 것으로 보인다.

<Lesson & Learned>

- 오픈소스들은 결국 어떤 이론과 개념을 코드로 실체화 한 것이기 때문에 사용하기에 앞서서 이해가 필요하다. 원천에 대한 해당 문서를 꼼꼼히 읽어볼 필요가 있다.

- Connection Reset의 경우 매우 다양한 원인에 의해서 발생되지만 로그메시지는 대부분 Socket Read/Write 부분으로 동일하다. 

 따라서 무조건 Google에서 해당 로그를 검색하는 것보다는 Step별로 상세 테스트 케이스를 작성하여 하나씩 검증해나가는 방식을 추천한다. 

 또한 서버환경에 따라서도 다르게 동작하기 때문에 각 구성요소는 동일하게 한다.

아무리 google에 정보가 많아도 일반적이지 않은 오류에 대해서는 무용지물이다.

Flume으로 입력을 받아서 Elasticsearch에 저장

1. Flume설치 

참고사이트 ( https://flume.apache.org/index.html )

1. Download
   1. wget http://apache.tt.co.kr/flume/1.6.0/apache-flume-1.6.0-bin.tar.gz
2. untar
   1. tar -zxvf apache-flume-1.6.0-bin.tar.gz
3. Source, Sink 유형별 참고
   1. https://flume.apache.org/FlumeUserGuide.html

4. 진행해본 Example

   1. 간단한 seq발생source로 elasticsearch 적재 (conf/example.conf)

   2. 특정 디렉토리를spooling하고, kafka channel을 사용해서 elasticsearch에 적재하는 잡을 구성해봄! (conf/test.conf)

5. 환경설정
   1. conf/flume-env.sh : export JAVA_OPTS="-Xms100m -Xmx2000m -Dcom.sun.management.jmxremote"
6. flume 실행 ex)bin/flume-ng agent -n a1 -c conf -f conf/test.conf

2. kafka 설치

참고사이트 ( http://kafka.apache.org/ )

1. Download
   1. wget http://apache.mirror.cdnetworks.com/kafka/0.9.0.1/kafka_2.10-0.9.0.1.tgz
2. unzip
   1. tar -zxvf kafka_2.10-0.9.0.1.tgz
3.  기동 및 테스트
1. bin/zookeeper-server-start.sh config/zookeeper.properties
2. bin/kafka-server-start.sh config/server.properties

3. elasticsearch 설치

참고사이트 ( https://www.elastic.co/ )

1. Download
   1. wget  https://www.elastic.co/downloads/past-releases/elasticsearch-1-7-5
2. unzip
   1. unzip elasticsearch-1.7.5.zip
3. 편리성을 위한 plugin 설치
1. head(인덱스 및 데이터조회)
   1. bin/plugin -install mobz/elasticsearch-head
2. bigdesk(노드 및 클러스터 모니터링)
   1. bin/plugin -install lukas-vlcek/bigdesk
4. 환경설정
   1. config/elasticsearch.yml
      1. cluster.name: elasticsearch
      2. node.name: host01
5.  기동 및 테스트
   1. bin/elasticsearch
   2. curl -X GET http://localhost:9200/

6. plugin을 통한확인

   1. head : http://localhost:9200/_plugin/head/
   2. bigdesk : http://localhost:9200/_plugin/bigdesk/
7. curl을 이용한 데이터 조회방법
   1. https://www.elastic.co/guide/en/elasticsearch/reference/current/search-search.html

데이터의 유형

데이터를 수집함에 있어서 크게 두 분류로 나눌 수 있다.

Event기반으로 계속 흘러들어오는 데이터와 기존 시스템에 이미 적재되어 있는 데이터.

데이터의 활용

 흔히 말하는 빅데이터 분석은 실시간 데이터를 처리하는 것이 아니라 HDFS상에 적재되어 있는 데이터를 기반으로 Map/Reduce등의 병렬프로그래밍을 통하는 것이었으며 최근에는 실시간 분석에 대한 요구도 높아져서 이를 위한 오픈소스들도 많이 생겨나고 있다.

 기존에는 적재되어 있는 데이터를 기반으로 분석하는 것과 실시간 Event가 분리되어 왔다면

앞으로는 두 종류의 데이터가 하나로 합쳐져서 기존 데이터를 기반으로 모델을 구축한 뒤에, 실시간 데이터들을 모델에 적용하여 예측,분류,Anormaly Detection 등을 수행하게 된다.

 람다아키텍처에 대해서는 별도로 정리하도록 해야겠다.

데이터의 수집방법

 모델구축을 위해서는 대량의 데이터가 반드시 필요하여 이를 위해 대표적인 수집을 위한 오픈소스 툴로 Flume, Sqoop, Gobblin등이 있다. 현재 본인은 File,RDB의 데이터를 수집하기 위해서는 Gobblin을 사용하고, 그 외의 Event기반 데이터는 Flume을 사용하여 수집하고 있으며 메시지 유실, 분산처리 scale out을 위해서 Kafka를 사용하고 있다. 그리고 이러한 작업들을 스케쥴링하기 위해서 Oozie를 사용하고 있다.

 Hadoop Ecosystem에 따른 거의 보편적인 아키텍처라고 볼 수 있겠지만 실제로 사용해보면 많은 어려움이 있다. Cluster구조를 가져간다는 이야기는 결국 네트워크에 의한 멤버쉽 관리가 되어야 하며, 병렬처리를 위해서는 처리량의 분배가 균일하게 이루어져야 한다는 것이다. 테스트를 통해서 적절한 수치를 찾는 것도 쉽지 않은 일이며, 막상 결과가 나왔을때 설명가능한 이유를 찾지 못하는 경우도 있다;;

 그리고 수많은 오픈소스로 이루어져있기 때문에 개별 설정도 어렵고, 서로 연관관계 있는 오픈소스들의 설정이 꼬여있을때는 오류발생의 주 원인이 되며 관리하기도 매우 어렵다.

이미지 출처 : http://7246-presscdn-0-21.pagely.netdna-cdn.com/wp-content/uploads/2015/02/Apache-Hadoop-Ecosystem.jpg

사례참고 

 해당 내용에 대한 아키텍처 공유사례는 많지만 구체적인 수치와 유형별 장단점에 대한 내용은 찾기가 어렵다.

실제로 같은 구성요소를 사용하더라도 그 모습은 요구사항에 따라서 천차만별로 구현된다.

최근 cloudera에 공유된 좋은 사례가 있어서 살펴보았다. 

(http://blog.cloudera.com/blog/2016/03/building-benchmarking-and-tuning-syslog-ingest-architecture-at-vodafone-uk/)

0. Overview

syslog를 수집함에 있어서 다음과 같은 high-level의 아키텍처가 있다.

Flume, Kafka 모두 event기반으로 단위 건당 수바이트의 자료를 처리하기에 적합한 오픈소스이며 내부구조에 대해서는 공식사이트를 참고하는 것이 가장 좋다.

1. 구성요소

Flume

Source-Channel-Sink의 구조로 이루어져있다. 이미 다양한 유형의 데이터에 대해서 Source, Sink등이 구현되어 있어서 쉽게 가져다 사용할 수 있으며, 필요한 부분은 사용자 구미에 맞게 코딩할 수 있다.

해당 사례에서는 syslog source - memory channel - Kafka sink와 Kafka source - memory channel - HDFS sink 를 동시에 사용하고 있다. (Consolidation - https://flume.apache.org/FlumeUserGuide.html)

Kafka

Kafka는 pub/sub구조의 message queue로 볼 수 있는데, 저장소로 Disk공간을 쓰는 것이 특징이다. 따라서 메시지 유실이 되지 않는 것을 최우선으로 하는 시스템에서 사용한다. (그런데 메시지 유실이 되어도 됩니다 라는 시스템은 한번도 본적이 없다.;)

2. 검토요소

성능향상을 위해서는 다음과 같은 요소들을 검토할 필요가 있다.

• Number of collection tier agents and nodes
• Number of Kafka sinks per collector tier agent
• Number of Kafka brokers
• Number of Kafka topic partitions
• Kafka broker interconnect network
• Number of Kafka sources
• Number of edge tier nodes and Flume Agents per node
• Number of HDFS sinks
• Batch-sizes on all of the sinks and sources

사이트에 자세한 내용들이 나와있으니 그냥 간단히 정리해보았다.

* Kafka

- partition의 수는 클러스터상의 디스크수와 최소한 같아야 한다.

- Kafka는 Broker를 통해서 모든 작업을 처리하기 때문에 Broker의 숫자와 메모리를 충분히 확보해주어야 한다. 

- Flume Sink(Kafka Producers)는 일반적으로 Cluster내의 하나의 Partition에 대해서 작업을 하기 때문에 성능을 확보하기 위해서는 충분히 많은 Sink를 갖는게 좋다. 그래야 Kafka Broker가 병렬처리가 원할해 진다.

Birthday problem과 같은 문제로 한 Partition에 2개이상 Sink가 접근할 가능성이 있다! write가 균등하게 되면 좋다.

- Flume Source(Kafka Consumers) : Producer나 Partition에 수에 명확한 관계는 없다. Consumer의 수가 Partition의 수보다 많을 경우 idle상태가 발생한다. Consumer의 수를 Partition보다 작게 하면 모든 Consumer가 일을 하게 된다. 

4개의 Sink가 하나의 Partition을 남겨두고 일을 해서 idle이 발생하고 Kafka Source가 놀고 있는 상황

* Flume - Kafka

Flume과 Kafka를 연계하여 사용할 수 있는 방식은 크게 두 가지가 있다.

1. Kafka Sink를 통해서 기록하고 Kafka Source를 통해서 읽어가는 경우

2. Flume Channel을 Kafka Channel로 사용하는 경우 (Channel의 type은 이외에도 memory, file 등이 있다.)

해당 사례에서는 Kafka channel의 throughput문제와 balanced configuration이 어려운 점을 주요 문제로 생각해서

Kafka Source , Sink방식을 채택했다고 한다. (memory channel의 유실 가능성을 염두하더라도..)

현재 본인은 2번 방식을 사용하고 있었는데. (일단 사용하기가 편하다. 세팅도 간단하고..) 

사용량이 늘어날 것을 감안하면 1번 방식으로 바꿔야 할듯 하다. 

1번도 그렇게 어렵지는 않다. Kafka Source나 Sink는 이미 있다.

3. 결론

Flume-Kafka를 적절하게 사용하기 위해서는 세팅이 필요하다는 내용을 다음과 같이 정리하고 있다.

• Enough HDFS sinks to handle the output from the Kafka tier
• A number of Kafka sources fewer than or equal to the number of partitions
• Sufficient number of partitions that the sources are not the bottleneck, and also that all disks in the Kafka cluster are utilized
• Enough Kafka sinks such that we have a good probability of not leaving one or more partitions, and hence sources, idle

 소프트웨어들의 완성된 모습을 보면 그 소프트웨어를 만든 조직의 모습과 놀랄만큼 닮아있는 것을 보게 된다. 콘웨이법칙이라고 해서 나름 유명한 법칙이다.

 이는 단순히 모듈의 갯수나 레이어등을 말하는 것 뿐만 아니라 Responsibility나 Collaboration 방식까지도 매우 유사하게 된다.

 최근에 많은 기업들이 우수한 소프트웨어를 만들기 위해서 해외의 유명한 전문가들도 모셔오고, 강의도 듣고 BP를 찾아서 적용하기 위해서 노력한다. 그런데 가장 중요한 것은 문화이다.

 Top-Down방식으로 경영전략을 세우고, 조직별로 목표를 수립하고 KPI를 달성하기 위해서 일하면, 그러한 모습의 소프트웨어가 나온다. 정해진 프로세스를 준수했기 때문에 정해진 결과물이 나온다. 때로는 수준에 못 미치더라도 억지로 끌어올린다. 품질지표를 만족하는 결과물이 어떻게든 나온다.

그러나 그 소프트웨어의 수명은 조직의 수명과 동일하기 때문에 몇년뒤면 자연스럽게 사라지고 다시 다른 소프트웨어를 만들기 시작한다. 개발자는 그때 그때 필요한 부품에 불과하다.

이렇게 해서는 절대 좋은 소프트웨어가 만들어질 수 없다.

 하나의 소프트웨어 프로덕트가 어느정도의 안정성과 성능, 기능을 확보하려면 제품마다 다르겠지만 최소한 2년, 넉넉하게는 3~5년정도가 걸린다. 그리고 이러한 성장가능한 구조, 아키텍처를 세우는 것은 무엇보다도 중요하다.

 가장 피해야 할 시나리오는 다음과 같다. 최초 A사이트를 타겟으로 v 1.0 을 만들었다. 이후 B사이트가 새로 생겼다. 그런데 새로운 요건을 만족시키기 위해서는 v 1.0 로는 안되기 때문에 v 2.0을 만든다. 물론 v 1.0과는 호환이 안된다. C사이트가 새로 생겼다. 다시 v 3.0을 만든다. 버전별 유지보수는 시간이 흐를수록 불가능이 된다..

 그렇다고 좋은 아키텍처를 잡기위해서 초반에 마냥 시간을 보낼 수도 없다. 우리가 선정한 기술이 목표와 부합하는지 검증도 해야하고, MVP모델도 개발해야한다. 실제 적용도 빨리 해봐야 더 많은 요구사항을 뽑아낼 수 있다. 이러한 과정을 진행하기 위해서 우리는 시간이 매우 부족하기 때문에 애자일을 선호하게 된다.

 많은 사람들이 착각하는 것이 애자일을 하나의 방법론으로 이해하고, 과거해왔던 방식처럼 무언가를 자꾸 적용하고 표준 프로세스와 산출물을 만들려고 한다.

착각하면 안된다. 애자일의 핵심은 좋은 코드를 빠르게 만들어 내는 것에 중점을 두고, 이를 방해하는 것들을 없애는 것이다. 필요한 것을 넣는 것이 아니라 필요없는 것을 빼는 것이다. 꼭 필요한 것만 남기는 것이다.

애자일을 설명할 때 나오는 수많은 기법들이 있다.

이건 그냥  "우리가 이렇게 해봤더니 도움이 되더라.."  일뿐이다. 참고자료이지 정답은 아니다.

애자일 선언과 그 배경원칙들에 대해서 수십번 읽어보시고 곱씹어보시기를 추천드린다.

 기존에 개발팀이 개발하던 방식을 존중하고, 그들의 문화를 관찰해야 한다. 개발자 한명 한명의 성향까지도 고려해야 한다. 어느조직에나 딱 맞는 방법론이란 존재하지 않는다. 자신들만이 가지고 있는 방법을 더욱더 간결하게 다듬어서 맞춰가는 것이 애자일이다.

 실질적으로 이렇게 일하는 문화가 자리잡히면 자연스럽게 Bottom-Up으로 할 일들이 도출된다. 내가 이렇게 만들었더니 이러한 단점이 있더라. 이걸 어떻게 보완하면 좋을까? 서로 의견을 나누어서 더 나은방향으로 개선시킨다. 

 자신의 설계를 공유하고, 코드를 공유하며 Review한다. 자연스럽게 소프트웨어의 품질을 올라갈 수 밖에 없다.

 남들에게 뒤쳐지지 않기 위해서 스스로 학습하고 새로운 것을 항상 찾아본다. 냅두면 알아서 공부하고 자기가 만든 분신과도 같은 소프트웨어를 더욱 발전시키기 위해서 노력한다. 자기주도 학습이다.(self-self-self!!!)

다른사람들과 개발순서를 맞춰야 하기 때문에 자연스럽게 일정이 조정되고, 그 일정은 매우 타이트하다.

 스스로 세운 일정을 준수하는 것은 본인과의 약속이기 때문에 누가 시키지 않더라도 야근을 한다. 그리고 만족할만한 성과가 나온 날은 기분좋게 일찍 퇴근한다. 

다른 사람들은 속일 수 있을지 몰라도 나 자신은 속일 수 없다.

 개발자의 역량이 발전하고 다시 소프트웨어는 새로운 기능으로 무장한다.(개발자에게 있어서 소스는 분신과 같은 존재이다.)

왜 조직은 개인을 믿지 못하고 자꾸 관리하려 드는가? 이에 대해서는 각자 반성해볼 필요도 있다.

그동안 개인은 어떻게 일해왔길래 조직이 신뢰할 수 없는 것일까...

좋은 소프트웨어는 관리를 통해서 만들어질 수 없다.

좋은 아키텍처는 좋은 조직과 문화에서 만들어진다.

조직과 문화는 사람이 만들고 구성원은 계속 변화한다.

현장에서 ThreadPool을 사용할 때 가장 많이 사용하는 것이 Spring에서 내장하고 있는 클래스들이다.

그런데 이 클래스들을 뜯어서 보니 Java에서 기본으로 제공하는 interface나 class와는 구조나 모임의 단위가 조금 달라보인다. google을 아무리 찾아봐도 만족할 만한 답이 없어서 시간이 나는동안 소스를 열어봤다.

가장 많이 사용하는 클래스들을 뽑아서 diagram을 그려봤다.

왼쪽에 Spring, 오른쪽이  Java이다.

1. Java

Java의 Concurrent 패키지에서는 순수하게 기능에 집중해서 작성한 것으로 보인다.

쉽게 가져가서 사용할 수 있는 구조를 위해서 많이 노력한 것으로 보이며 ISP의 원칙을 잘 지킨 것 같다.

a. Executor : Runnable 구동이 가능하며 execute 메소드를 사용한다.

b. ExecutorService : Executor를 상속받았다. Callable 구동이 가능하며 추가적으로 submit 메소드를 제공한다.

ThreadPool의 lifecycle에 관련된 메소드도 보인다.

c. ThreadPoolExecutor : 실제 개발자가 ThreadPool 사용을 위해서는 ThreadPoolExecutor를 생성해서 사용하며,

이를 좀 더 쉽게 사용할 수 있도록 Util성클래스인 Executors 를 제공한다.

d. ScheduledExecutorService : Schedule작업을 위한 인터페이스로 schedule 메소드가 정의되어 있다.

2. Spring

Spring의 경우에는 좀더 사용자의 측면에 접근해서 설계가 되어있는 모습이다.

내부구현은 Java에서 제공하는 class들을 멤버변수로 가지고 있어서 대부분 처리를 진행하고,

사용자가 좀더 편리하게 사용할 수 있도록 다양한 설정포인트를 제공한다.

Thread작업에 task라는 개념을 도입하여 재구성한 형태로 그 출발은 TaskExecutor이다.

a. TaskExecutor : java의 Executor와 완전히 동일하다. Spring에서의 확장을 위해서 만들었다.

b. SyncTaskExecutor : Runnable의 run메소드를 호출만 한다.

c. AsyncTaskExecutor : Runnable과 Callable의 구동이 가능하며, execute 메소드와 submit 메소드를 제공한다.

d. TaskScheduler : Schedule작업을 위한 인터페이스로 scheduler 메소드가 정의되어 있다.

이러한 각 인터페이스를 용도에 맞게 구현하여 아래의 클래스 형태들로 제공하고 사용자는 자신의 목적에 맞도록 선택하여 사용한다.

또한 Spring에서는 Future의 확장을 위해서 ListenableFuture를 별도로 정의하여 사용하고 있다.

이부분은 다음에 시간날때 보도록 해야겠다...

1. 조물주가 이 땅에 특별한 목적을 가지고 생명체를 창조해내었다면, 

프로그래머 역시 어떠한 목적이 있기 때문에 한 객체를 시스템내에서 창조한다.

창조된 생명체는 자신의 역할을 다할 책임이 있다.

<모델링>

Object oriented programming, 이른바 OOP라 불리우는 개념의 기본이다.

흔히 모델링을 접하게 되면 현실세계를 컴퓨터속으로 투영시키는 작업이 모델링이라는 말을 듣게 된다.

RDB모델링에서는 Entity를 도출하고 각 Entity간의 Relation을 정의하는 것이 시작이 된다.

어떠한 정보를 저장하는 가에 중점을 두고 작업을 진행하는 것이 DB모델링이라면

하나의 Object가 어떻게 동작하는가에 중점을 두고 작업을 진행하는 것이 Application모델링.

그중에서도 OOP에 해당한다.

<Responsibility>

 Object는 속성과 행위를 갖게 되며 각각 변수와 메소드라는 형태로 표현이 된다. 개발자는 이 object를 통해서 본인이 의도한 바를 구현하고자 한다. 본인이 하고 싶은 일을 대신 시킨다고 봐도 무방하다.

하나의 object로 모든 일을 처리할 것인지, 여러개의 object로 나누어서 처리할 것인지, 나눈다면 몇개로 어떻게 나눌것인지는 만드는 사람의 몫이다. 해당 시스템이 궁극적으로 이루고자 하는 목적과 범위가 무엇인지를 명확히 파악하고 그에 맞게 적절하게 구성하는 것이다.

 하나의 object로 모든 일을 처리하는 방식을 흔히 God object라고 부르며 이는 대표적인 anti-pattern의 하나이다. 모든 변경사항에 영향을 받기 때문에 항상 변경될 수밖에 없다.

이는 유지보수성을 심각히 저하시켜서 결국 재개발을 할 수 밖에 없다.

 하나의 변경사항에 대한 수정의 범위는 한곳 이 되는 것이 바람직하며(coupling), 유사한 기능에 대해서도 한곳에 모여있는 것이 좋다. (cohesion)